📈 Мониторинг, логирование и observability

Короткий ответ Самые частые ошибки: путать среднее значение с процентилем, не замечать смену масштаба оси Y между обновлениями, не учитывать интервал агрегации (rate(...[5m]) сглаживает резкие всплески) и забывать про часовой пояс при сравнении графика с временем инцидента. Как это работает подробнее Grafana строит ось Y автоматически по диапазону данных на экране, поэтому один и тот же абсолютный разброс значений может казаться "маленьким" или "огромным" в зависимости от текущего авто-масштаба — нужно явно проверять числа, а не только форму линии. Окно агрегации в rate()/avg_over_time() сглаживает короткие пики: пятиминутный всплеск ошибок на 30 секунд может быть почти не виден на графике с окном [5m]. Пример кода Что использовать на практике Практика. при расследовании инцидента стоит сверять время на графике с временем в логах/алертах в одном часовом поясе (Grafana и Prometheus обычно работают в UTC, если явно не настроено иное) и уменьшать окно агрегации для поиска коротких всплесков, а не полагаться толь

Читать полностьюgrafana

Короткий ответ Структурированный лог записывается в виде набора полей с именами (обычно JSON: level, msg, service, trace_id и т.д.), а не произвольной строки текста; это позволяет системе агрегации логов искать, фильтровать и строить метрики по конкретным полям, а не парсить текст регулярными выражениями. Как это работает подробнее вместо строки "2024-05-01 10:02:11 ERROR checkout: payment failed for order a1b2" структурированный логгер пишет {"ts":"...","level":"error","service":"checkout","msg":"payment failed","order_id":"a1b2"}. Система агрегации (Elasticsearch, Loki с label-ами) может индексировать каждое поле отдельно и строить быстрые запросы по ним. Пример кода Что использовать на практике Практика. структурированные логи особенно важны в микросервисной архитектуре, где нужно быстро отфильтровать логи по service, trace_id или order_id среди миллионов строк от десятков сервисов; для нового проекта разумно сразу выбирать JSON-логирование через стандартную библиотеку логирования языка (например, logrus/z

Читать полностьюlogging

Короткий ответ В pull-модели сервер мониторинга сам периодически опрашивает (scrape) эндпоинт /metrics у приложений; в push-модели приложение само отправляет метрики на сервер или в промежуточный агрегатор. Prometheus по умолчанию использует pull, что проще для контроля нагрузки и обнаружения "упавших" целей. Как это работает подробнее при pull Prometheus по конфигурации scrape_configs сам ходит по списку целей (статическому или через service discovery) и забирает текущие значения метрик раз в заданный интервал. При push клиент (приложение или StatsD-агент) сам инициирует отправку данных по сети на коллектор, который может их буферизовать и агрегировать. Пример кода Что использовать на практике Практика. pull-модель удобна, когда сервер мониторинга может достать до всех целей по сети (типично внутри одного кластера/VPC), и позволяет легко увидеть, что цель недоступна (метрика up == 0). Push-модель нужна для короткоживущих задач (batch job, serverless-функция), которые завершаются быстрее scrape-интервала — дл

Читать полностьюmetrics

Короткий ответ Единого рецепта нет — нужно явно спроектировать независимый, по возможности более простой "сторожевой" слой (например, внешний dead man's switch / healthcheck, отдельный минимальный стек в другом домене отказа), который детектирует именно недоступность самого observability-стека, а не полагаться на то, что система, которая должна сигнализировать о проблемах, сама просигнализирует о собственном отказе. Как это работает подробнее типичная схема — "dead man's switch": правило, которое должно постоянно срабатывать (heartbeat) и отправлять сигнал во внешнюю независимую систему (например, другой облачный провайдер или SaaS типа отдельного uptime-мониторинга); если сигнал не приходит в течение ожидаемого интервала, внешняя система сама поднимает алерт о том, что основной observability-стек, вероятно, недоступен или не функционирует. Также важно физически разделить failure domain: если Alertmanager и Prometheus работают в том же кластере/регионе, что и мониторируемые сервисы, сбой всего региона лишает

Читать полностьюalertmanager

Короткий ответ Шумные алерты — это уведомления, которые срабатывают слишком часто, дублируются или не требуют реального действия от дежурного; самая частая простая причина — слишком чувствительный порог или отсутствие временного условия (for), из-за чего алерт мигает (flapping) при естественных краткосрочных колебаниях метрики. Как это работает подробнее если правило алерта срабатывает при любом однократном превышении порога без задержки, то кратковременный всплеск (например, на один scrape) немедленно создаёт уведомление, даже если через 10 секунд метрика вернулась в норму. Многократные такие срабатывания за день приучают дежурного игнорировать уведомления — это называется "alert fatigue". Пример кода Что использовать на практике Практика. базовое средство от простого шума — добавление for (условие должно оставаться истинным N минут подряд, прежде чем алерт перейдёт в firing) и выбор порога, основанного на реальном распределении метрики за прошлые недели, а не на произвольном "круглом" числе. Также стоит отл

Читать полностьюalerting

Короткий ответ Кардинальность метрики — это количество уникальных комбинаций значений её labels, то есть количество отдельных временных рядов, которые она порождает; высокая кардинальность (например, label со значением user_id или request_id) приводит к взрывному росту числа рядов, потребления памяти и диска в Prometheus. Как это работает подробнее каждая уникальная комбинация значений labels — это отдельный временной ряд в TSDB, который Prometheus хранит и индексирует независимо. Если добавить в метрику label с миллионом возможных значений (например, user_id), то вместо одной метрики с разумным числом рядов получится до миллиона отдельных рядов, что резко увеличивает потребление памяти (в первую очередь — индекса TSDB). Пример кода Что использовать на практике Практика. labels должны иметь ограниченное и предсказуемое количество значений — например, method, status_code, region, service обычно безопасны, а user_id, email, request_id, полный URL с параметрами — нет. Для таких "уникальных на запрос" идентификат

Читать полностьюcardinality

Короткий ответ Exporter — это отдельный процесс, который собирает метрики из системы или приложения, не умеющего отдавать их в формате Prometheus, и публикует их на HTTP-эндпоинте /metrics в нужном текстовом формате; node_exporter делает это для метрик операционной системы (CPU, память, диск, сеть). Как это работает подробнее exporter читает данные из своего источника (файлы /proc и /sys в случае node_exporter, API стороннего сервиса в случае других exporter'ов, например postgres_exporter или blackbox_exporter) и преобразует их в строки формата Prometheus exposition format, которые затем забирает scrape. Пример кода Что использовать на практике Практика. exporter'ы ставят как отдельный процесс или sidecar рядом с тем, что нужно мониторить — на каждый узел кластера обычно разворачивают один node_exporter (часто как DaemonSet в Kubernetes). Для приложений, которые сами умеют отдавать метрики (например, через клиентскую библиотеку Prometheus), отдельный exporter не нужен — это называется "нативная инструментация

Читать полностьюexporters

Короткий ответ Health check — это специальный HTTP-эндпоинт (например, /healthz или /livez), который приложение отдаёт для простой проверки "жив ли процесс и может ли он обслуживать запросы"; системы мониторинга и оркестрации периодически опрашивают его и на основе ответа решают, считать сервис рабочим или перезапускать/выводить из балансировки. Как это работает подробнее эндпоинт обычно возвращает 200 OK, если внутренние проверки (доступность процесса, иногда — базовых зависимостей) прошли успешно, и ошибку или таймаут — если нет. Внешний мониторинг (blackbox_exporter, Kubernetes liveness probe) регулярно дёргает этот эндпоинт и на основе серии неудачных ответов принимает решение — поднять алерт или перезапустить контейнер. Пример кода Что использовать на практике Практика. важно разделять "простой" health check (процесс отвечает) и "глубокую" проверку (база данных доступна, кеш доступен) — слишком тяжёлая проверка в liveness может привести к каскадным перезапускам, если временно недоступна внешняя зависимос

Читать полностьюhealth-checks

Короткий ответ Scrape interval — как часто Prometheus опрашивает цели (например, каждые 15 секунд); retention — как долго собранные данные хранятся локально на диске (по умолчанию в Prometheus 2.x это 15 дней); меньший интервал опроса даёт более точные графики, но быстрее заполняет диск при том же retention. Как это работает подробнее каждый scrape создаёт новую точку данных для каждого временного ряда; чем чаще scrape, тем больше точек накапливается за одно и то же время хранения, и тем больше места на диске и нагрузки на TSDB это требует. Retention задаётся флагом --storage.tsdb.retention.time (или по размеру — --storage.tsdb.retention.size), и по его истечении старые блоки данных удаляются автоматически. Пример кода Что использовать на практике Практика. типичный scrape interval — 15–60 секунд для большинства сервисных метрик; более частый опрос (1–5 секунд) используют только для узких задач с явной необходимостью высокой точности по времени. Для хранения метрик дольше, чем позволяет локальный диск Prometh

Читать полностьюmonitoring