Послуги з налаштування моніторингу та алертингу

Як налаштування моніторингу впливає на швидкість виявлення проблем

Алерт має спрацьовувати раніше, ніж зателефонує клієнт. У більшості інсталяцій, які ми бачимо на аудиті, все інакше: Prometheus стоїть, дашборд висить, а про те, що запити почали падати в timeout, дізнаються через 15 хвилин від користувача. Це відбувається через те, що налаштування моніторингу сприймається як встановлення одного пакета та створення трьох панелей у Grafana. Насправді це архітектурне рішення: що збираємо, як агрегуємо, за якими правилами алертимо, хто отримує сповіщення о 3 ночі та який runbook він відкриває. Ми допомагаємо клієнтам будувати такий моніторинг, який реально знижує MTTR і не генерує шум. Маємо за плечима 7+ років досвіду в observability, понад 50 проєктів — від стартапів до enterprise з тисячами нод.

Prometheus: основа та її обмеження

Prometheus — стандарт де-факто для збору метрик у Kubernetes. Працює за pull-моделлю: сам ходить до таргетів по HTTP /metrics. Якщо таргет недоступний — Prometheus знає про це одразу (up{job="myapp"} = 0).

Service Discovery у Kubernetes. Prometheus виявляє таргети через Kubernetes API автоматично. Анотації на pods:

annotations: prometheus.io/scrape: "true" prometheus.io/port: "8080" prometheus.io/path: "/metrics" 

Кастомний scrape_config для Kubernetes pods:

scrape_configs: - job_name: kubernetes-pods kubernetes_sd_configs: - role: pod relabel_configs: - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape] action: keep regex: "true" 

kube-prometheus-stack — helm‑chart, який розгортає Prometheus Operator, Grafana, AlertManager та набір стандартних dashboards за один helm install. Це точка старту, а не фінальна конфігурація. Після встановлення обов'язково переглядаємо всі дефолтні alerts, вимикаємо нерелевантні — інакше alert fatigue вб'є цінність алертингу.

Чому Prometheus може не справлятися з масштабом?

На великому кластері (1000+ таргетів, висока cardinality метрик) Prometheus починає споживати сотні гігабайт RAM. Рішення — федерація або перехід на VictoriaMetrics.

Federation. Hierarchical Federation: leaf-інстанси збирають метрики у своїх кластерах, global-інстанс агрегує через /federate:

scrape_configs: - job_name: federate-cluster-eu honor_labels: true metrics_path: /federate params: match[]: - '{job="kubernetes-pods"}' - '{__name__=~"(up|node_.*|container_.*)"}' static_configs: - targets: ['prometheus-eu.monitoring.svc.cluster.local:9090'] 

Remote Write — альтернативний варіант: Prometheus відправляє метрики у зовнішнє сховище в реальному часі. Дозволяє використовувати Prometheus тільки як scraper, а довгострокове зберігання винести у VictoriaMetrics.

remote_write: - url: https://victoriametrics.example.com/api/v1/write queue_config: max_samples_per_send: 10000 max_shards: 30 write_relabel_configs: - source_labels: [__name__] regex: go_.* action: drop 

VictoriaMetrics: коли Prometheus не справляється

VictoriaMetrics — drop‑in заміна для довгострокового зберігання метрик. Single‑node інстанс витримує мільйони active time series при 10–20× меншому споживанні пам'яті порівняно з Prometheus на тих самих даних. Це не маркетингові цифри — перевіряємо: включаємо remote_write з Prometheus у VM, порівнюємо RSS процесів.

VMAgent замінює Prometheus як scraper. Ті самі scrape_configs, ті самі service discovery конфіги, але з вбудованою буферизацією на диск при недоступності remote_write. Якщо VictoriaMetrics тимчасово недоступна — VMAgent збереже метрики та відправить при відновленні. Prometheus в аналогічній ситуації втрачає дані.

Для більшості продакшн-інсталяцій single‑node VictoriaMetrics закриває потреби до ~10 млн активних time series. Cluster потрібний при горизонтальному масштабуванні або вимозі zero‑downtime обслуговування.

Як побудувати стратегію алертингу, що знижує MTTR?

Хороший моніторинг — не той, де багато дашбордів, а той, де кожен алерт вимагає дії. Ось три принципи, які ми застосовуємо:

1. Алерт без runbook — сміття. Кожне правило повинно мати анотацію runbook_url з конкретними кроками.
2. Алерт, що спрацьовує частіше разу на тиждень — або неправильний threshold, або невирішена системна проблема.
3. PagerDuty о 3 ночі — тільки за те, що не можна дочекатися ранку.

- alert: HighErrorRate expr: | rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.05 for: 5m labels: severity: critical annotations: summary: "High error rate on {{ $labels.job }}" description: "Error rate is {{ $value | humanizePercentage }}" runbook_url: "https://wiki.example.com/runbooks/high-error-rate" 

for: 5m — алерт не спрацьовує негайно. Короткочасний spike у 30 секунд — не алерт. Стійка проблема — так.

AlertManager routing — кому та коли:

route: receiver: slack-dev group_wait: 30s group_interval: 5m repeat_interval: 4h routes: - match: severity: critical receiver: pagerduty - match: severity: warning receiver: slack-dev - match: alertname: Watchdog receiver: "null" 

Routing по namespace: production‑алерти → pagerduty, staging → slack. Досягається через label namespace на алерті та match у routing tree.

SLO‑based alerting

Замість threshold‑алертів (CPU > 80%) — error budget alerting. Якщо SLO — 99.9% availability за 30 днів, error budget — 43,8 хвилини. Алерт спрацьовує, коли burn rate перевищує допустимий:

- alert: ErrorBudgetBurnRateHigh expr: | ( sum(rate(http_requests_total{status=~"5.."}[1h])) / sum(rate(http_requests_total[1h])) ) > (1 - 0.999) * 14.4 for: 5m annotations: summary: "Error budget burning at 14.4x rate" 

14.4× burn rate означає, що при такому темпі error budget на 30 днів згорить за 2 дні. Це дійсно вимагає негайної уваги.

Як уникнути alert fatigue?

Основна причина — забагато алертів із низькою значущістю. Рішення:

• Встановити for на всі алерти (мінімум 1–5 хвилин).
• Використовувати severity: warning → тільки в slack, critical → тільки в pager.
• Кожен квартал переглядати алерти: вимикати ті, що не приводили до дій за останні 30 днів.
• Впровадити SLO‑based alerting — він автоматично фільтрує шум.

Grafana: організація дашбордів

Grafana без дисципліни перетворюється на кладовище дашбордів: 200 панелей, половина не оновлювалася рік. Рекомендована структура:

Overview/ ├── Infrastructure Overview (всі ноди, навантаження, пам'ять) ├── Kubernetes Cluster (pods, nodes, deployments) └── Cost Overview (якщо є cloud provider metrics) Services/ ├── API Gateway ├── Auth Service └── <per-service dashboards> Infrastructure/ ├── PostgreSQL ├── Redis └── Kafka On‑Call/ └── Incident Response (велико, тільки найважливіше) 

Дашборди як код через Grafonnet або Terraform grafana_dashboard resource. Дашборди в Git, deployment через CI. Ручні зміни в Grafana UI — тільки тимчасові, потім переносяться в код. Для Kubernetes kubernetes‑mixin дає відмінні baseline dashboards, які потрібно кастомізувати під свої namespace та label conventions.

Datadog: коли потрібен комерційний продукт

Datadog виправданий у сценаріях: велика організація, кілька команд, потрібен єдиний інструмент (метрики + логи + traces + APM + RUM) або окремого DevOps немає і платна підтримка важливіша за самообслуговування. Однак вартість зростає нелінійно: при 50 хостах і включених APM + Logs monthly bill може становити $4000–6000, що для багатьох стартапів неприйнятно.

Datadog Agent у Kubernetes — DaemonSet з autodiscovery:

datadog: apiKey: <DD_API_KEY> clusterName: production logs: enabled: true containerCollectAll: true apm: portEnabled: true 

Рекомендуємо явно включати тільки потрібні namespace через pod annotations. APM через Datadog вимагає мінімальних змін коду (один import + init). Correlation logs‑to‑traces через dd.trace_id у structured logs.

Zabbix: legacy‑інфраструктура та змішані середовища

Zabbix зберігає актуальність для моніторингу Windows‑серверів, мережевого обладнання (SNMP), bare‑metal заліза, legacy‑додатків без /metrics. Zabbix Agent 2 підтримує Kubernetes monitoring через нативний плагін, але для повноцінного K8s краще залишити Prometheus/VictoriaMetrics для кластера, а Zabbix використовувати для інфраструктурного рівня (гіпервізори, мережеві пристрої, фізичні сервери). Інтеграція Zabbix → Prometheus через zabbix-exporter дозволяє уніфікувати алертинг через AlertManager.

Централізоване логування

Метрики — не логи. Prometheus зберігає тільки числа, не рядки. Для логів — окремий стек. Loki + Grafana — мінімальний варіант: Loki не індексує вміст логів, тільки labels (app, namespace, pod). Це дає дешеве зберігання (в 10–30× дешевше Elasticsearch), але повільний пошук по довільному тексту. OpenTelemetry Collector — якщо потрібна гнучкість: приймає дані в будь-якому форматі (OTLP, Jaeger, Zipkin, Prometheus), трансформує, відправляє в будь-який backend.

Що входить у роботу

Ми пропонуємо повний цикл налаштування моніторингу під ключ:

Вартість розраховується після аудиту: важливо зрозуміти поточну інфраструктуру, кількість сервісів та нод, вимоги до retention. Гарантуємо працездатність стеку після передачі — всі алерти протестовані, дашборди перевірені на реальних даних. Сертифіковані спеціалісти з Kubernetes, досвід роботи з інфраструктурою від 10 до 5000 нод. Отримайте консультацію з вибору стеку моніторингу — зв'яжіться з нами для аудиту вашої системи. Замовте налаштування моніторингу під ключ.