Услуги по настройке мониторинга и алертинга

Как настройка мониторинга влияет на скорость обнаружения проблем

Алерт должен срабатывать раньше, чем позвонит клиент. В большинстве инсталляций, которые мы видим на аудите, всё иначе: 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 нод. Получите консультацию по выбору стека мониторинга — свяжитесь с нами для аудита вашей системы. Закажите настройку мониторинга под ключ.