Розробка системи моніторингу та візуалізації даних
Метрики розкидані по серверах, дашборди Grafana відображають лише технічні показники, а алерти приходять із запізненням — знайома картина? Для логістичної компанії ми побудували систему на базі TimescaleDB та ClickHouse, що об'єднала 10 000 IoT-сенсорів. Час реакції на інциденти скоротився з 30 до 2 хвилин, витрати на інфраструктуру знизилися на 40%. У проєкті для фінтех-компанії економія на ліцензіях готових рішень склала 30%, що заощадило значну суму на рік. Досвід понад п'ять років та понад 50 проєктів показує: універсальні інструменти гарні, але коли потрібна унікальна візуалізація, бізнес-контекст або embedded monitoring — без власного стеку не обійтися.
Проблеми готових стеків моніторингу
Grafana чудово малює графіки, але для бізнес-метрик не вистачає семантики. Prometheus — потужний, але retention обмежений. Коли клієнту потрібно бачити не cpu_usage, а завантаження_складу_у_відсотках_від_місткості — доводиться будувати свою систему. Якщо моніторинг — частина продукту (SaaS, IoT-платформа), його не можна прив'язати до стороннього інтерфейсу. Embedded monitoring дозволяє вбудувати дашборди та алерти прямо у ваш інтерфейс, зберігаючи єдиний стиль та логіку. Ми гарантуємо, що система працюватиме без збоїв: впроваджуємо моніторинг за best-practices з алертингом, логуванням та тестами.
Як вибрати time-series базу даних?
Вибір TSDB визначає продуктивність та вартість. Для гібридних запитів на PostgreSQL — TimescaleDB, для IoT з частотою до 100K записів/с — InfluxDB, для аналітики на мільярдах рядків — ClickHouse. TimescaleDB перевершує InfluxDB у складних запитах до 10 разів, але InfluxDB виграє за пропускною здатністю запису.
| TSDB |
Коли брати |
Обмеження |
| TimescaleDB |
Потрібна реляційна схема + час (PostgreSQL-екосистема) |
При 10K+ вставок/с може гальмувати |
| InfluxDB |
IoT, сенсори, до 100K записів/с |
Немає повноцінного SQL |
| ClickHouse |
Аналітика, мільярди рядків, складні агрегації |
Висока затримка вставки (не real-time 1:1) |
TimescaleDB — фаворит для бізнесу. 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;
Джерело: документація TimescaleDB
Як організувати real-time візуалізацію?
WebSocket — стандарт для дашбордів. Використовуємо ws для Node.js або Tornado для Python. Приклад підписки:
// 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);
};
Сервер публікує нові значення з TSDB через Redis Pub/Sub або Kafka. Затримка — менше 1 секунди. Для frontend використовуємо React, Recharts або D3, створюючи кастомні дашборди моніторингу.
Алерти та анотації
Алерти бувають чотирьох типів:
| Тип алерту |
Опис |
Приклад |
| Пороговий |
Перевищення фіксованого значення за період |
CPU > 90% за 5 хв |
| Anomaly detection |
Відхилення від історичної норми (ML) |
CPU > 3σ |
| Відсутність даних |
Зникнення метрик від сенсора |
Немає даних від sensor_42 |
| Rate of change |
Різкий стрибок |
CPU виріс >20% за хвилину |
Канали сповіщень: email, Telegram, Slack, PagerDuty, SMS, webhook.
Анотації — маркери на часових графіках, що пояснюють аномалії: деплой нової версії, планове обслуговування, інцидент.
CREATE TABLE annotations (
id, title, description TEXT,
tags TEXT[], start_time, end_time,
created_by
);
Приклад архітектури для IoT
- Collector: MQTT broker → Telegraf → InfluxDB
- Backend: Node.js + WebSocket
- Dashboard: React + Recharts
- Alert: custom Python service with ML anomaly detection
Що входить в роботу
До складу послуги входить: проєктна документація (архітектурний опис, схема даних), вихідний код з тестами, документація з експлуатації, навчання команди (воркшоп з адміністрування системи), а також гарантійний супровід протягом 12 місяців. Додатково надаємо SLA на час реакції — до 4 годин для критичних інцидентів. Ви отримуєте fully managed рішення: ми розгортаємо систему на вашій інфраструктурі, налаштовуємо CI/CD та передаємо всі доступи.
Процес розробки та терміни
- Аналітика: виявляємо джерела метрик, частоту, критичність (2–3 дні).
- Проєктування: вибираємо TSDB, схему даних, архітектуру (3–7 днів).
- Реалізація: пишемо collector, alert engine, дашборди (MVP 6–8 тижнів).
- Тестування: навантажувальне тестування, chaos engineering (2 тижні).
- Деплой та документування: розгортання на вашій інфраструктурі, навчання команди (1 тиждень).
- Гарантія та підтримка: 12 місяців супроводу, SLA 4 години.
Терміни: MVP — 6–8 тижнів, повна система — 4–6 місяців. Вартість розраховується індивідуально — запитайте комерційну пропозицію.
Чому обирають нас
Досвід понад 5 років, 50+ проєктів (від IoT до фінтеху), власні шаблони дашбордів та бібліотеки алертів. Використовуємо ClickHouse за best-practices. Сертифікати виробників. Зв'яжіться з нами — покажемо кейси, аналогічні вашому, і запропонуємо архітектуру за 3 дні. Замовте консультацію, щоб обговорити вашу архітектуру.
Як налаштувати веб-аналітику: GA4, GTM, Яндекс.Метрика та Amplitude
Ми часто бачимо: конверсія 1.2 %, трафік зростає, а конверсія стоїть. Маркетолог дивиться в Google Analytics і каже: «користувачі йдуть з кроку 2 оформлення замовлення». Розробник відкриває той самий крок — помилок немає, в Sentry тиша. Значить, справа не в JS-базі, а в UX або в кривих даних, які показує аналітика. Аналітика ламається непомітно: подія перестала трекатися після редеплою — ніхто не помітив; GTM-тег стріляє двічі — дані задвоїлися; фільтр GA4 виключає бота, який насправді — реальний трафік з корпоративного проксі. Замовте аудит поточних тегів — ми знайдемо причину за тиждень. Ми маємо понад 5 років досвіду в налаштуванні веб-аналітики для 100+ проєктів — гарантуємо прозорість та достовірність даних.
Після правильного налаштування економія рекламного бюджету може досягати значної суми щомісяця — це реальний кейс інтернет-магазину з 50 000 сесій на день, де дедуплікація purchase повернула 20 % невірно приписаних конверсій.
Чому події GA4 дублюються і як це виправити?
Universal Analytics закрито, його місце зайняла подієва модель GA4. У ній немає фіксованих хітів сторінок і транзакцій — лише події з параметрами. Це гнучкіше, але вимагає правильного дизайну подій.
Автоматичні події GA4 збирає сам: page_view, scroll, click, session_start. Рекомендовані події потрібно реалізувати самостійно: purchase, add_to_cart, begin_checkout, view_item. Google очікує конкретну схему параметрів — якщо передати product_id замість item_id, дані потрапляють в GA4, але не в стандартні звіти e-commerce. Кастомні події для специфіки проєкту: filter_applied, video_progress, form_step_completed. Кастомні параметри необхідно зареєструвати в GA4 Admin → Custom definitions, інакше вони не будуть доступні у звітах.
Часта помилка — подія purchase з дублями. Причина: тег спрацьовує на сторінці /thank-you, користувач оновлює сторінку — другий purchase іде в GA4. Рішення: на бекенді генеруємо унікальний transaction_id і передаємо в подію. GA4 de-duplicates по ньому — перевіряйте через DebugView. Правильна атрибуція економить до 20 % рекламного бюджету, який раніше йшов на невірно приписані конверсії.
Як налаштувати data layer, щоб не втратити дані?
GTM — інструмент для керування тегами без деплою коду. Але «без коду» не означає «без архітектури». Data Layer — основа всього. Передаємо дані з застосунку в GTM через dataLayer.push(). Структура: event + контекстні дані. Для e-commerce: перед відкриттям сторінки продукту — push з даними товару. GTM-тег читає з dataLayer, не з DOM.
window.dataLayer = window.dataLayer || [];
dataLayer.push({
event: 'view_item',
ecommerce: {
items: [{
item_id: 'SKU-12345',
item_name: 'Назва товару',
price: null,
currency: null
}]
}
});
Погана практика: GTM-тег парсить DOM — шукає ціну в span.price, назву в h1. Це ламається при будь-якій зміні верстки. Хороша практика: завжди dataLayer. Використовуємо Preview Mode для налагодження та GTM Server-Side для чутливих даних — відправка з сервера, не з браузера, обходить блокувальники реклами, не втрачає дані. Server-side підхід у 2-3 рази надійніший за client-side за показником втрати подій через розширення браузера.
Як Яндекс.Метрика доповнює веб-аналітику?
Для російської аудиторії Метрика обов'язкова — особливо Вебвізор. Запис сесії користувача, який кинув кошик, часто дає відповідь швидше, ніж тиждень аналізу воронки. Цілі в Метриці: подієві (через ym(COUNTER_ID, 'reachGoal', 'GOAL_NAME')) або автоматичні (клік по кнопці, відвідування сторінки). Зв'язка з CRM через Метрика Плюс — передача офлайн-конверсій. Наш досвід: у 8 з 10 проєктів після налаштування Метрики знаходили приховані баги в UX, які не показували інші системи.
Що дає product analytics в Amplitude?
Amplitude — продуктовий інструмент, на відміну від маркетингових GA4 та Метрики. Він заточений під аналіз поведінки користувачів всередині продукту: воронки, ретеншн, user paths. Amplitude підходить для SaaS-продуктів, мобільних застосунків та будь-яких сервісів із зареєстрованими користувачами, де важливо зрозуміти, як проходять онбординг, на якому кроці йдуть, які фічі використовують частіше. Ключові концепції: identify (пов'язати анонімного користувача з userId після авторизації), group (акаунт у B2B SaaS), когорти для утримання. Amplitude Chart — воронка кроків за останні 30 днів з розбивкою за джерелом.
Моніторинг якості даних
Аналітика без моніторингу — чорна скринька. Налаштовуємо:
- GA4 Realtime — перевіряємо після кожного деплою, що ключові події приходять
- Alerting в GA4 — аномалія в кількості подій
purchase (різке падіння = щось зламалося)
- GTM Preview в staging-оточенні перед продакшеном
- Ручні тести воронок раз на тиждень — просто пройти шлях покупця і перевірити, що все трекається
Якщо ви помітили розбіжності в даних — зв'яжіться, проведемо безкоштовний аудит коректності тегів.
Що перевіряємо після кожного деплою
- Чи всі рекомендовані події присутні в DebugView
- Чи немає задвоєнь (рахуємо кількість
purchase на 100 сесій)
- Чи не змінилася структура dataLayer після оновлення фронтенду
Що входить в роботу
| Компонент |
Опис |
| Аудит поточних тегів |
Перевірка існуючих GTM-тегів, dataLayer, дублів та помилок |
| Дизайн подієвої схеми |
Документація: список подій, параметри, тригери |
| Налаштування GA4 + GTM |
Створення конфігурації, тегів, Custom definitions |
| Яндекс.Метрика |
Встановлення лічильника, створення цілей, налаштування Вебвізора |
| Amplitude (опціонально) |
Налаштування клієнтського та серверного SDK, когорти |
| QA та моніторинг |
Тестування в Preview Mode, Alerting |
| Навчання та передача |
Доступи, інструкція з додавання нових подій, консоль |
Процес та терміни
- Аудит поточних тегів та даних (2 дні)
- Дизайн подієвої схеми (2 дні)
- Розробка Data Layer та налаштування тегів (3–5 днів)
- QA в Preview Mode та на staging (2 дні)
- Деплой та налаштування дашбордів (1 день)
| Сценарій |
Термін |
| Базове налаштування GA4 + GTM |
1 тиждень |
| Повний e-commerce tracking + Метрика |
2–3 тижні |
| Server-side GTM + Amplitude |
3–5 тижнів |
Вартість розраховується індивідуально. Отримайте консультацію з налаштування веб-аналітики для вашого проєкту — ми оцінимо обсяг робіт за один день. Зв'яжіться з нами, щоб почати. Для точного розрахунку вартості залиште заявку — ми проаналізуємо ваш стек за 1 день.