Розробка системи моніторингу та візуалізації даних
Система моніторингу збирає метрики, події та логи з різних джерел (сервери, додатки, IoT-пристрої, бізнес-процеси) та надає інструменти для виявлення аномалій, налаштування сповіщень та візуалізації в реальному часі.
Stack моніторингу
Розробка власного stack має сенс, коли готові рішення (Grafana + Prometheus) недостатні: потрібна нестандартна візуалізація, бізнес-контекст (не лише технічні метрики), вбудований моніторинг як функція продукту (embedded monitoring).
Архітектурні компоненти:
Джерела даних (сервери, IoT, API)
↓ push/pull
Колектор (Vector, Fluentd, custom agent)
↓
Time-Series БД (InfluxDB, TimescaleDB, ClickHouse)
↓
Query Engine + Alert Engine
↓
Візуалізація (WebSocket → React dashboard)
Time-Series бази даних
TimescaleDB — розширення PostgreSQL. Hypertable автоматично розділяє дані за часом:
-- Створення time-series таблиці
SELECT create_hypertable('metrics', 'time');
-- Швидке вставлення
INSERT INTO metrics (time, device_id, temperature, humidity)
VALUES (NOW(), 'sensor_42', 23.5, 61.2);
-- Агрегація з 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;
InfluxDB — спеціалізований TSDB з SQL-подібною мовою Flux. Добре для IoT-сценаріїв.
ClickHouse — стовпчастовий СУБД, оптимальний при великому обсязі подій (мільярди рядків).
Real-time оновлення
Візуалізація в реальному часі вимагає WebSocket або SSE:
// WebSocket підписка на метрику
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);
};
Сервер публікує нові значення з time-series БД кожні N секунд через Redis Pub/Sub або Apache Kafka.
Система сповіщень
Сповіщення — правило: «якщо метрика X перевищує поріг Y протягом Z хвилин → повідомити». Типи сповіщень:
-
Threshold:
cpu_usage > 90% протягом 5 хвилин - Anomaly detection: відхилення від історичної норми на N стандартних відхилень
- Absence: метрика не поступала N хвилин (пристрій не відповідає)
- Rate of change: метрика виросла/впала більш ніж на X% за період
Канали сповіщень: email, Telegram, Slack, PagerDuty, SMS, webhook.
Анотації та контекст
Анотації — маркери на часових графіках, що пояснюють аномалії: розгортання нової версії, планова перевірка, інцидент. Допомагають зрозуміти: «тут метрика підскочила, тому що ми розгорнули v2.3».
CREATE TABLE annotations (
id, title, description TEXT,
tags TEXT[], start_time, end_time,
created_by
);
IoT візуалізація
Для промислового моніторингу та IoT-сценаріїв часто потрібні спеціалізовані візуалізації:
- Heatmap — розподіл значень за часом
- Gauge — поточне значення з кольоровими зонами (зелений/жовтий/червоний)
- Topology map — схема об'єктів з кольоровим статусом (SCADA-подібна)
- Geo-map — місцеположення пристроїв з кольоровим статусом
Зберігання даних
Time-series дані ростуть швидко. Політика зберігання:
- Raw дані (кожну секунду): 7 днів
- Агреговано за хвилину: 90 днів
- Агреговано за годину: 2 роки
- Щоденні агрегати: необмежено
У TimescaleDB налаштовується через add_retention_policy:
SELECT add_retention_policy('metrics', INTERVAL '7 days');
Графік
MVP (збір метрик, базові графіки, пороговані сповіщення): 6–8 тижнів. Повна система з anomaly detection, IoT-візуалізацією, кастомними панелями та інтеграцією PagerDuty: 4–6 місяців.