Статус сервиса за 30 секунд
Один ряд из 4 стат-панелей: Uptime %, p95 Latency, Error Rate, RPS. Ниже — два тайм-серии: ошибки 5xx и задержка p95. Всё на одном экране, без скролла.
Рубрика · Выпуск 17 · Q3 2025
Мониторинг и логирование: как собрать наблюдаемость без хаоса
От сырых метрик Prometheus до дашбордов Grafana и централизованных логов. Разбираем, как выстроить систему, которая отвечает на «почему упало», а не только на «что упало».
Наблюдаемость — это не «поставил Prometheus и забыл». Это связка из трёх слоёв: метрики, которые показывают состояние системы во времени, трейсы, которые связывают запросы между сервисами, и логи, которые объясняют конкретные ошибки. В этом выпуске мы сосредоточимся на первых двух и на лог-агрегаторах.
Ниже — три практических раздела: как правильно собирать метрики в Prometheus, как проектировать дашборды в Grafana, чтобы они не превращались в стену цифр, и какие лог-агрегаторы реально работают в продакшене.
Слой 01 · Метрики
Метрики Prometheus: что собирать и что бросить
Чем больше метрик, тем дороже хранение и тем сложнее найти сигнал среди шума. Разбираем, какие 20 метрик покрывают 90% инцидентов.
Prometheus — это не «всё, что можно, тащим». У нас в редакции действует правило: если метрика не привязана к конкретному SLI или алерту, она не попадает в production. Мы собираем четыре типа метрик — counter, gauge, histogram и summary — и для каждого сервиса фиксируем не более 15–20 метрик.
Ключевая ошибка, которую мы видим у 80% команд: они тегуют каждую метрику уникальным значением request_id или user_id. Через неделю кардинальность взлетает, Prometheus не справляется с запросами, и система мониторинга падает раньше, чем сама инфраструктура.
Ниже — минимальный набор метрик, который мы рекомендуем для любого микросервиса. Это то, что у нас держит на контроле 95% инцидентов.
http_requests_total
Счётчик обработанных HTTP-запросов с тегами method, handler и status_code. Из него вычисляем RPS, долю ошибок 5xx и среднюю задержку через rate().
http_request_duration_seconds
Гистограмма времени обработки запросов. Buckets: 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10. Из неё считаем p95/p99 и алертим, если p99 > 800 мс дольше 5 минут.
process_resident_memory_bytes
Текущий объём RAM процесса. Алерт при 80% от лимита memory.limit_in_bytes из cgroup. Без этой метрики утечки памяти обнаруживают только пользователи.
db_pool_connections_active
Количество активных соединений в пуле. Если значение стабильно упирается в максимум пула — у нас либо утечка, либо деградация БД. Алерт при 90% от max_pool_size.
Слой 02 · Визуализация
Grafana: дашборды, которые читают за 10 секунд
Дашборд — это не витрина всех метрик. Это ответ на вопрос «здоров ли сервис прямо сейчас?». Разбираем структуру, которая у нас проходит code review.
У нас в редакции есть чёткий стандарт: каждый дашборд начинается с одного статуса — зелёный, жёлтый или красный. Этот статус вычисляется из 3–4 ключевых SLI (доступность, задержка, ошибки, saturation). Если всё зелёное, инженер уходит. Если красный — он смотрит дальше.
Мы сознательно разбиваем дашборды на три уровня: Service Overview (высокоуровневый статус), Component Drill-down (по конкретному сервису) и Infra Baseline (CPU, RAM, disk, network по нодам). Никаких «все метрики в одном месте».
Ключевая настройка, которую мы прописываем в каждом дашборде: time range = 30 min по умолчанию и refresh = 30s. Это достаточно, чтобы видеть тренд, но не перегружает браузер и Prometheus.
Внутренности одного микросервиса
Панели по компонентам: HTTP layer, DB pool, queue consumers, external API calls. Каждая панель имеет свой алерт-порог, который подсвечивает границу. Разбираем на примере сервиса order-service.
Ноды Kubernetes без воды
CPU, RAM, disk I/O, network throughput по каждой ноде. Плюс — heatmap по Pod-ам, чтобы сразу видеть, кто «съедает» ресурсы. Без 50 панелей, которые никто не смотрит.
Слой 03 · Логирование
Лог-агрегаторы: Elasticsearch, Loki, ClickHouse
Три рабочих варианта. Разбираем по стоимости хранения, скорости поиска и сложности эксплуатации. Без «всё зависит от контекста» — конкретные цифры.
Логирование — это самый дорогой слой наблюдаемости. Если вы тегите каждый лог-запись уникальным request_id и храните 90 дней, вы платите за терабайты данных, которые никто не ищет. Мы храним логи 14 дней в горячем хранилище и 90 дней в архиве на S3. Этого достаточно для 95% инцидентов.
Ниже — сравнение трёх систем, которые мы реально используем в разных проектах. Цифры — из нашего продакшена, не из маркетинговых материалов вендоров.
Loki + Grafana
Дешёвый и простой. Хранит логи как «сырые» строки, индексация — по label-ам. Поиск через LogQL. Стоимость: ~$40/мес на 200 GB/день. Минус: нет полнотекстового поиска по содержимому строк.
Elasticsearch + Fluentd
Мощный полнотекстовый поиск, гибкие индекс-паттерны, зрелый экосистем. Стоимость: ~$320/мес на 2 TB/день. Минус: сложная настройка JVM, memory pressure на больших кластерах.
ClickHouse + Vector
Колонный движок, сжатие x10, агрегации на лету. Стоимость: ~$180/мес на 10 TB/день. Минус: нет «живого» поиска, только batch-запросы. Подходит для аналитики, не для debug-инцидентов.
Структура лог-записи
Каждая запись: timestamp, level, service, trace_id, message. Никаких user_id, request_id в теле — это убьёт кардинальность. trace_id связывает с OpenTelemetry.
Наблюдаемость в цифрах
Что мы измеряем в каждом проекте
14дн
Хранение логов в горячем хранилище
18м
Метрик на сервис (среднее по редакции)
3ур
Уровня дашбордов: Overview → Drill-down → Baseline
95%
Инцидентов, которые ловим до пользователей
Рассылка
Каждый четверг — новый разбор инфраструктуры
Собираем лучшие практики по мониторингу, логированию и наблюдаемости. Без рекламы, без «10 способов», без инфоценов. Только то, что проверено в продакшене.
Частые вопросы
Что спрашивают про наблюдаемость
Ориентир: до 100 000 активных time series на один Prometheus-нод. Если у вас 50 сервисов и по 20 метрик на каждый — это 1 000 series, и вы в 100 раз от лимита. Проблема начинается не в количестве метрик, а в кардинальности: если одна метрика имеет 10 000 уникальных комбинаций тегов, это уже 10 000 series.
Если вы храните менее 500 GB логов в день и вам не нужен полнотекстовый поиск по содержимому строк — Loki. Он дешевле в 5–8 раз, проще в эксплуатации и интегрируется нативно с Grafana. Elasticsearch оправдан, когда у вас сложные запросы типа «найди все логи, где message содержит 'timeout' И service = 'payment' И level = 'ERROR'».
Да, если у вас более 3 микросервисов. OpenTelemetry даёт вам распределённые трейсы — без них вы не увидите, почему запрос занял 3 секунды: где именно он «застрял». Prometheus даёт вам метрики «что», трейсы дают вам «где». Для одного монолита трейсы не нужны.
Наш стандарт: 14 дней в горячем хранилище (быстрый поиск), 90 дней в архиве на S3 (медленный поиск, дёшево). Если у вас есть требования регулятора (PCI DSS, 152-ФЗ) — храните 365 дней в архиве. Но не храните 365 дней в Elasticsearch — это бессмысленная трата денег.