Metrics scattered across servers, Grafana dashboards reflecting only technical indicators, and alerts arriving late — sound familiar? For a logistics company, we built a system on TimescaleDB and ClickHouse, unifying 10,000 IoT sensors. Incident response time dropped from 30 to 2 minutes, infrastructure costs reduced by 40%. In a fintech project, savings on licensing ready-made solutions reached 30%, saving a significant amount per year. With over five years of experience and more than 50 projects, we know: universal tools are good, but when unique visualization, business context, or embedded monitoring is needed, a custom stack is essential.
Problems with Ready Monitoring Stacks
Grafana draws great charts, but lacks semantics for business metrics. Prometheus is powerful but retention is limited. When a client needs to see not cpu_usage but warehouse_load_percentage_of_capacity — we build a custom system. If monitoring is part of a product (SaaS, IoT platform), it can't be tied to a third-party interface. Embedded monitoring allows embedding dashboards and alerts directly into your interface, maintaining consistent style and logic. We guarantee the system will run smoothly: we implement monitoring with best practices including alerting, logging, and tests.
How to Choose a Time-Series Database?
Choosing a TSDB determines performance and cost. For hybrid queries on PostgreSQL — TimescaleDB, for IoT with up to 100K writes/sec — InfluxDB, for analytics on billions of rows — ClickHouse. TimescaleDB outperforms InfluxDB in complex queries up to 10 times, but InfluxDB wins in write throughput.
| TSDB | When to Use | Limitations |
|---|---|---|
| TimescaleDB | Need relational schema + time (PostgreSQL ecosystem) | May slow down at 10K+ inserts/sec |
| InfluxDB | IoT, sensors, up to 100K writes/sec | No full SQL |
| ClickHouse | Analytics, billions of rows, complex aggregations | High insert latency (not real-time 1:1) |
TimescaleDB is a favorite for business. Hypertable partitions by time automatically:
-- Create time-series table SELECT create_hypertable('metrics', 'time'); -- Fast insert INSERT INTO metrics (time, device_id, temperature, humidity) VALUES (NOW(), 'sensor_42', 23.5, 61.2); -- Aggregation with time_bucket SELECT time_bucket('5 minutes', time) AS bucket, AVG(temperature) AS avg_temp FROM metrics WHERE device_id = 'sensor_42' AND time > NOW() - INTERVAL '24 hours' GROUP BY bucket ORDER BY bucket; Source: TimescaleDB documentation
How to Organize Real-Time Visualization?
WebSocket is the standard for dashboards. We use ws for Node.js or Tornado for Python. Example subscription:
// WebSocket subscription to metric const ws = new WebSocket('wss://monitor.example.com/stream'); ws.send(JSON.stringify({ subscribe: ['cpu_usage', 'memory_usage'], device_id: 'server_01', interval: 5000 })); ws.onmessage = ({ data }) => { const metric = JSON.parse(data); updateChart(metric.name, metric.value, metric.timestamp); }; The server publishes new values from TSDB via Redis Pub/Sub or Kafka. Latency is under 1 second. For frontend we use React, Recharts, or D3, creating custom monitoring dashboards.
Alerts and Annotations
Alerts come in four types:
| Alert Type | Description | Example |
|---|---|---|
| Threshold | Exceeding a fixed value over a period | CPU > 90% for 5 min |
| Anomaly detection | Deviation from historical norm (ML) | CPU > 3σ |
| Missing data | Metric disappearance from sensor | No data from sensor_42 |
| Rate of change | Sudden spike | CPU increased >20% in a minute |
Notification channels: email, Telegram, Slack, PagerDuty, SMS, webhook.
Annotations are markers on time charts explaining anomalies: new deployment, planned maintenance, incident.
CREATE TABLE annotations ( id, title, description TEXT, tags TEXT[], start_time, end_time, created_by ); Example architecture for IoT
- Collector: MQTT broker → Telegraf → InfluxDB
- Backend: Node.js + WebSocket
- Dashboard: React + Recharts
- Alert: custom Python service with ML anomaly detection
What's Included in the Work
The service includes: project documentation (architecture description, data schema), source code with tests, operational documentation, team training (workshop on system administration), and warranty support for 12 months. Additionally, we provide an SLA on response time — up to 4 hours for critical incidents. You get a fully managed solution: we deploy the system on your infrastructure, configure CI/CD, and hand over all access.
Development Process and Timeline
- Analysis: identify metric sources, frequency, criticality (2–3 days).
- Design: choose TSDB, data schema, architecture (3–7 days).
- Implementation: write collector, alert engine, dashboards (MVP 6–8 weeks).
- Testing: load testing, chaos engineering (2 weeks).
- Deployment and documentation: deploy on your infrastructure, team training (1 week).
- Warranty and support: 12 months of maintenance, SLA 4 hours.
Timeline: MVP — 6–8 weeks, full system — 4–6 months. Cost is calculated individually — request a commercial proposal.
Why Choose Us
Experience of over 5 years, 50+ projects (from IoT to fintech), proprietary dashboard templates and alert libraries. We use ClickHouse following best practices. Vendor certifications. Contact us — we'll show cases similar to yours and propose an architecture in 3 days. Request a consultation to discuss your architecture.