Настройка алертинга с нуля: от метрики до уведомления в Telegram и Slack | AdminWiki
Logo
Timeweb Cloud — сервера, Kubernetes, S3, Terraform. Лучшие цены IaaS.
Попробовать

Настройка алертинга с нуля: от метрики до уведомления в Telegram и Slack

22 апреля 2026 8 мин. чтения
Содержание статьи

Система алертинга превращает пассивный мониторинг в активный инструмент реагирования на инциденты. Это пошаговое руководство поможет вам создать такую систему с первого шага: от выбора ключевых метрик до получения понятного уведомления в мессенджер. Вы получите готовые конфигурации для Prometheus Alertmanager, которые можно адаптировать и сразу внедрить в работу.

Получить готовые рабочие конфигурации

Основа системы - конфигурационные файлы Prometheus и Alertmanager. Ниже приведены проверенные на практике примеры, которые покрывают базовые сценарии мониторинга.

Пример правил алертов для Prometheus (alert.rules.yml)

Этот файл определяет, какие условия считаются проблемой. Правила используют язык запросов PromQL.

groups:
  - name: infrastructure.rules
    rules:
      # Критическая загрузка CPU
      - alert: HighCpuLoad
        expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
        for: 2m
        labels:
          severity: critical
          service: node_exporter
        annotations:
          summary: "Высокая загрузка CPU на {{ $labels.instance }}"
          description: "Средняя загрузка CPU за 5 минут составляет {{ $value }}%."

      # Недостаточно свободной памяти
      - alert: LowMemoryAvailable
        expr: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100 < 10
        for: 3m
        labels:
          severity: warning
          service: node_exporter
        annotations:
          summary: "Мало свободной памяти на {{ $labels.instance }}"
          description: "Доступно только {{ $value | humanizePercentage }} памяти."

      # Диск заполнен
      - alert: DiskSpaceRunningOut
        expr: (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} * 100) < 15
        for: 5m
        labels:
          severity: critical
          service: node_exporter
        annotations:
          summary: "Заканчивается место на диске ({{ $labels.mountpoint }})"
          description: "На {{ $labels.instance }} осталось {{ $value | humanizePercentage }} свободного места."

      # Сервис недоступен (проверка по метрике up)
      - alert: ServiceDown
        expr: up == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Сервис {{ $labels.job }} на {{ $labels.instance }} недоступен"
          description: "Прометей не может получить метрики от цели более 1 минуты."

Базовая конфигурация Alertmanager (alertmanager.yml)

Этот файл управляет маршрутизацией и отправкой уведомлений. Конфигурация включает приемники для Slack и Telegram.

global:
  # Интервал между повторными уведомлениями для непогашенных алертов
  repeat_interval: 6h
  # Таймаут для отправки уведомлений
  smtp_smarthost: 'localhost:25'
  smtp_from: 'alertmanager@yourdomain.com'

# Маршрутизация алертов по меткам
route:
  group_by: ['alertname', 'severity', 'service']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 12h
  receiver: 'default-receiver'
  routes:
    - match:
        severity: critical
      receiver: 'critical-alerts'
      group_interval: 1m
      repeat_interval: 2h
    - match:
        severity: warning
      receiver: 'warning-alerts'

# Определение приемников (receivers)
receivers:
  - name: 'default-receiver'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK'
        channel: '#monitoring-alerts'
        title: '{{ .GroupLabels.alertname }}'
        text: '{{ range .Alerts }}{{ .Annotations.summary }}\n{{ .Annotations.description }}\n{{ end }}'
        send_resolved: true

  - name: 'critical-alerts'
    telegram_configs:
      - api_url: 'https://api.telegram.org'
        bot_token: 'YOUR_BOT_TOKEN'
        chat_id: YOUR_CHAT_ID
        parse_mode: 'HTML'
        message: '<b>[CRITICAL] {{ .GroupLabels.alertname }}</b>\n{{ range .Alerts }}{{ .Annotations.description }}\n{{ end }}'
        send_resolved: true

  - name: 'warning-alerts'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK'
        channel: '#monitoring-warnings'
        title: '{{ .GroupLabels.alertname }}'
        text: '{{ range .Alerts }}{{ .Annotations.summary }}\n{{ end }}'
        send_resolved: true

# Подавление алертов (inhibit_rules) для предотвращения шума
inhibit_rules:
  - source_match:
      severity: 'critical'
    target_match:
      severity: 'warning'
    equal: ['instance', 'service']

Эти конфигурации - отправная точка. Подставьте свои значения api_url, bot_token, chat_id и адаптируйте пороги срабатывания под вашу инфраструктуру. Для более глубокого погружения в настройку связки Prometheus и Alertmanager, включая тонкости группировки и подавления алертов, изучите полное пошаговое руководство по настройке алертинга в Prometheus и Alertmanager.

Увидеть пошаговый алгоритм от метрики до уведомления

Создание системы алертинга - это последовательность логически связанных шагов. Пропуск любого этапа приводит к неработоспособности цепочки.

Шаг 1: Выбор и сбор метрик

Система начинается с метрик. Убедитесь, что Prometheus собирает данные с нужных источников (экспортеров). Базовые метрики для мониторинга инфраструктуры предоставляет node_exporter. Проверьте статус цели в веб-интерфейсе Prometheus (http://your-prometheus:9090/targets). State должен быть UP.

Шаг 2: Написание PromQL-запроса и установка порога

В консоли Prometheus (http://your-prometheus:9090/graph) протестируйте запрос, который будет ядром правила алерта. Например, запрос для проверки доступности памяти: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100. Определите порог срабатывания. Значение меньше 10% - это проблема. Этот логический переход «метрика → правило» аналогичен принципам, используемым в системах автоматизации, например, когда рабочий процесс n8n анализирует долю времени разговора на встрече и применяет к ней пороговое правило (>70%) для формирования отчета.

Шаг 3: Создание правила алерта в alert.rules.yml

Оформите тестированный запрос и порог в виде правила YAML, как показано в примерах выше. Ключевые поля:

  • expr: PromQL-выражение, возвращающее true при проблеме.
  • for: Длительность, в течение которой условие должно быть истинным перед генерацией алерта. Это фильтр кратковременных скачков.
  • labels: Метки для классификации и маршрутизации (например, severity: critical).
  • annotations: Человекочитаемые заголовок и описание для уведомления.

Шаг 4: Настройка маршрутизации и приемников в Alertmanager

Скопируйте файл alertmanager.yml в рабочую директорию Alertmanager. Настройте приемники:

  • Для Slack: Создайте Incoming Webhook в настройках вашего Slack-канала и укажите полученный URL в api_url.
  • Для Telegram: Создайте бота через @BotFather, получите токен. Узнайте chat_id (можно получить, отправив сообщение боту и запросив https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates).

Шаг 5: Запуск и верификация

  1. Перезагрузите конфигурацию Prometheus (отправьте SIGHUP или перезапустите сервис).
  2. Запустите Alertmanager с указанием конфигурационного файла: ./alertmanager --config.file=alertmanager.yml.
  3. Проверьте статус: откройте веб-интерфейс Alertmanager (http://your-alertmanager:9093). На вкладке «Status» должны отображаться ваши приемники.
  4. Сымитируйте проблему, чтобы проверить цепочку. Например, создайте высокую нагрузку на CPU или заполните диск. Убедитесь, что алерт появился в интерфейсе Prometheus («Alerts») и Alertmanager («Alerts»), а затем пришло уведомление в мессенджер.

Избежать типовых ошибок и проблем совместимости

Большинство проблем при настройке возникает на этапе интеграции компонентов.

Уведомления не приходят

  • Проверка webhook: Убедитесь, что URL webhook (Slack) или API (Telegram) указан верно. Для диагностики используйте curl: curl -X POST -H 'Content-type: application/json' --data '{"text":"Test"}' YOUR_SLACK_WEBHOOK_URL. Ошибка 404 указывает на неверный URL, что аналогично проблемам с подключением источников данных в Grafana.
  • Ошибки TLS/сертификатов: Если ваша инфраструктура использует самоподписанные сертификаты, Alertmanager может не доверять внешнему API. Добавьте параметр tls_config: { insecure_skip_verify: true } в конфигурацию приемника (только для тестовых сред).
  • Брандмауэр и таймауты: Убедитесь, что хост с Alertmanager имеет исходящий доступ к api.telegram.org (порт 443) или hooks.slack.com. Проверьте настройки сетевого экрана.

Алерт срабатывает некорректно или не срабатывает

  • Проверка PromQL: Убедитесь, что запрос в правиле возвращает данные при проблеме. Используйте консоль Prometheus для проверки.
  • Параметр for: Если алерт не создается, возможно, условие не держится указанное в for время. Временно уменьшите этот интервал для отладки.
  • Версия ПО: Убедитесь в совместимости версий Prometheus и Alertmanager. Для версий 2026 года актуальны v2.45+ и v0.25+ соответственно. Синтаксис конфигурации может меняться между мажорными версиями.

Если вы решаете, какую систему алертинга интегрировать в ваш стек, сравнение архитектурных подходов Grafana Alerting и Prometheus Alertmanager поможет принять взвешенное решение. Подробный разбор сценариев использования есть в руководстве «Grafana Alerting vs Prometheus Alertmanager: практическое руководство по выбору».

Понять критерии выбора метрик и порогов

Эффективный алертинг строится на осмысленных метриках и обоснованных порогах, а не на мониторинге всего подряд.

Базовые метрики для разных сервисов

  • Веб-сервер (Nginx/Apache):
    http_requests_total (объем трафика), rate(http_requests_total{status=~"5.."}[5m]) (частота 5xx ошибок), nginx_connections_active (активные соединения).
  • База данных (PostgreSQL/MySQL):
    pg_postmaster_uptime_seconds (аптайм), rate(pg_errors_total[5m]) (ошибки), pg_stat_activity_count (активные сессии), pg_database_size_bytes (размер БД).
  • Приложение (экспортер собственных метрик):
    Метрики бизнес-логики (например, количество неудачных операций, время ответа 95-го перцентиля).

Установка порогов на основе SLA/SLO

Пороги должны отражать реальные соглашения об уровне обслуживания. Например:

  • Если SLO доступности сервиса - 99.9%, то порог для алерта «сервис недоступен» (up == 0) может срабатывать сразу (без for), так как каждая минута простоя критична.
  • Порог для загрузки CPU можно установить на уровне 85% для предупреждающего алерта (severity: warning) и 95% для критического (severity: critical), основываясь на исторических данных (p95 за последнюю неделю).

Различие между warning и critical должно быть четким: warning - требует внимания, но не срочно; critical - требует немедленного вмешательства, угрожает работе сервиса.

Обеспечить надежность и управление алертами

Неконтролируемая система алертинга быстро приводит к «усталости от уведомлений», когда важные сигналы теряются в шуме.

Группировка и интервалы

Конфигурация route в Alertmanager позволяет управлять потоком:

  • group_by: ['alertname', 'instance'] объединяет все алерты одного типа с одного хоста в одно уведомление.
  • group_wait: 30s задерживает отправку первой группы, чтобы собрать возможные связанные алерты.
  • repeat_interval: 6h предотвращает спам, отправляя напоминания о непогашенном алерте только раз в 6 часов.

Заглушки (Silences) и эскалация

  • Silences: В веб-интерфейсе Alertmanager можно создать заглушку на определенный период (например, на время плановых работ). Это временно отключает уведомления для выбранных алертов (по меткам).
  • Простая эскалация: Настройте два приемника. Первый (warning-alerts) отправляет уведомления в тихий канал. Второй (critical-alerts) - в общий канал команды. Если алерт не будет погашен в течение заданного времени, его можно перенаправить на более высокий уровень (например, в SMS-сервис), добавив вложенный маршрут с условием по времени.

Для построения комплексной системы мониторинга, частью которой является алертинг, полезно изучить руководство по созданию системы мониторинга производительности, где разбирается весь стек - от сбора метрик до их визуализации.

Адаптировать решение под свой стек и окружение

Представленная схема гибкая и адаптируется под различные инструменты и ограничения.

Альтернативные инструменты и мессенджеры

  • Discord/Matrix: Alertmanager не имеет встроенных приемников для них, но поддерживает общий webhook_config. Необходимо создать промежуточный сервис (например, на Python или с помощью n8n), который будет принимать webhook от Alertmanager и преобразовывать его в формат API нужного мессенджера.
  • Grafana Alerting: Если ваш стек использует Grafana как основную панель мониторинга, вы можете создавать алерты напрямую в ней. Это избавляет от необходимости писать правила в Prometheus, но перекладывает логику оценки на Grafana. Для сложных распределенных систем часто используют обе системы совместно.

Настройка в изолированных сетях или через прокси

  • Если Alertmanager не имеет прямого выхода в интернет для отправки в Telegram/Slack, настройте исходящий HTTP/HTTPS прокси. Добавьте в конфигурацию глобальные параметры:
    global:
  http_config:
    proxy_url: http://your-proxy:3128
  • Для домашней лаборатории (Homelab) или систем типа TrueNAS, где может быть установлен Prometheus, логика остается идентичной. Упростите конфигурацию, отправляя все алерты в один Telegram-чат, и настройте менее агрессивные пороги.

Выбор окончательного решения зависит от масштаба, критичности и стека технологий. Чтобы сделать этот выбор осознанно, изучите объективное сравнение систем алертинга для DevOps, где разбираются сильные и слабые стороны разных решений.

Поделиться:
Сохранить гайд? В закладки браузера