Как настроить мониторинг, чтобы не проспать проблему

Все мы с этим сталкивались: вроде бы сервис работает, графики зелёные, ресурсы свободны — а пользователи всё равно жалуются. Открываешь мониторинг — CPU в порядке, память не забита, места на диске полно. А люди продолжают писать: «У вас тормозит». Знакомо?

Давайте разберёмся, как настроить мониторинг так, чтобы проблемы ловились сразу — ещё до того, как начнут ломиться сообщения в поддержку.

Почему стандартный мониторинг не спасает

Обычно мы смотрим на классические метрики:

• нагрузка на процессор

• использование памяти

• заполненность дисков

Они, конечно, важны — но не всегда дают полную картину. Например: процессор загружен на 50%, память спокойна, диск чистый. А в это время какой-то запрос к API повис и тянет за собой очередь. Пользователи получают тайм-ауты — а на графиках всё отлично.

У нас, например, была ситуация: по метрикам всё хорошо, а юзеры жалуются — «тормоза». Оказалось, мы следили только за состоянием железа, а не за состоянием самих сервисов. Отсюда и проблема.

Что нужно мониторить на самом деле

Разберёмся, какие метрики действительно помогут вовремя понять, что сервису плохо.

1. Следим за ошибками API

Ошибки 500 и прочие сбои — это первое, что должно сразу бросаться в глаза. Если их становится много — значит, где-то что-то поломалось.

Как настроить:

• Собираем ошибки через Prometheus.

• Заводим алерт в Alertmanager — чтобы уведомление приходило, если ошибок стало слишком много за короткий промежуток времени.

Пример алерта:

- alert: HighAPIErrorRate
  expr: rate(http_requests_total{status="500"}[1m]) > 5
  for: 1m
  labels:
    severity: critical
  annotations:
    summary: "API ошибок больше 5 за минуту"

2. Время отклика — не забываем про скорость

Процессор может спать, а сервис — тормозить. Если пользователю приходится ждать 3-4 секунды — скорее всего, он просто уйдёт.

Как настроить:

• Считаем время отклика через Prometheus.

• В Grafana строим дашборды.

• Добавляем алерты — например, если 95-й перцентиль больше 2 секунд.

Пример алерта:

- alert: SlowResponseTime
  expr: histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[1m])) > 2
  for: 2m
  labels:
    severity: high
  annotations:
    summary: "Медленный отклик на 95 процентиле"

3. Логи — источник правды

Иногда баги не попадают в стандартные метрики, но прекрасно видны в логах. Их тоже нужно мониторить.

Как настроить:

• Собираем логи через Loki или ElasticSearch.

• Настраиваем фильтры по ключевым словам: ERROR, Exception, Timeout и т.д.

• Строим отчёты, чтобы видеть динамику по количеству ошибок.

Пример конфига Loki:

scrape_configs:
  - job_name: 'api_logs'
    static_configs:
      - targets: ['localhost:3100']
        labels:
          job: 'api'

4. Уведомления — чтобы не проспать аварию

Если что-то пошло не так — нужно знать об этом сразу. Алерты должны приходить в понятном виде туда, где их точно увидят.

Как настроить:

• Подключаем Alertmanager.

• Настраиваем интеграции: Slack, Telegram, почта — что удобнее.

Пример настройки для Slack:

receivers:
  - name: 'slack_receiver'
    slack_configs:
      - api_url: 'https://slack.com/api/chat.postMessage'
        channel: '#alerts'
        send_resolved: true
        text: '{{ .CommonAnnotations.summary }}'

5. Периодический аудит мониторинга

Важно помнить: мониторинг — это не "поставил и забыл". Сервисы меняются, добавляются новые компоненты, архитектура усложняется. Раз в квартал стоит пересматривать настройки: что-то добавить, что-то убрать.

Полезные инструменты

Из того, что хорошо себя зарекомендовало:

• Prometheus — сбор метрик.

• Grafana — визуализация.

• Alertmanager — алерты и уведомления.

• Loki / ElasticSearch — сбор логов.

• Sentry — ловит ошибки в коде.

• pgBadger — разбор логов PostgreSQL.

• Netdata — мониторинг в реальном времени на уровне хоста.

Итог

Мониторинг — это не просто красивые графики. Это инструмент, который должен помогать ловить проблемы ещё до того, как пользователи начали нервничать. Главное — не ограничиваться только метриками железа, а внимательно следить за поведением самих сервисов.

Если есть что добавить или считаешь что что-то из мной сказанного можно отнести к "вредным советам" - милости прошу в комментарии. Я прочитаю и отредактирую, если твое предложение будет более актуально. Также пишите свои случаи "неправильного" мониторинга или случаи, когда ситуация в действительности отличалась от наблюдаемой - будет интересно почитать.