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

Все мы с этим сталкивались: вроде бы сервис работает, графики зелёные, ресурсы свободны — а пользователи всё равно жалуются. Открываешь мониторинг — 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 — мониторинг в реальном времени на уровне хоста.

Итог

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

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