Grafana + Telegram-алерты для офиса: настройка мониторинга, который действительно будит

Меня зовут Семёнов Евгений Сергеевич, я директор АйТи Фреш. За пятнадцать лет обслуживания корпоративных IT-инфраструктур в Москве и Подмосковье я понял простую вещь: мониторинг, который не доходит до правильного человека за минуту, не существует. Висящий в углу экрана дашборд Grafana — это не мониторинг, это настенная декорация. Сегодня расскажу, как мы в АйТи Фреш строим оповещения в Telegram, которые приходят туда, куда нужно, и не превращаются в фоновый шум.

С чего начались наши «алерты-в-телеграм»

В конце 2023 года к нам обратился клиент — компания на 35 рабочих мест, два сервера 1С, NAS, IP-телефония. У них стоял Zabbix, который кому-то когда-то поставили, и он честно собирал метрики. Только письма с алертами улетали в почтовый ящик ИТ-руководителя, который читал почту дважды в день. В пятницу вечером упал контроллер домена, в понедельник утром компания вошла без сети. 60 человек простояли два часа, пока мы экстренно поднимали AD из бэкапа. Стоимость простоя — 380 000 рублей по их же оценке.

После этого случая мы поменяли подход. Теперь любой клиент АйТи Фреш получает связку Zabbix или Prometheus + Grafana + Telegram-бот. Critical-уведомления приходят в дежурный чат за 30 секунд, warning — в рабочее время в чат смены, info — в архивный канал. С момента внедрения мы пропустили один инцидент за два года, и тот — потому что у клиента отвалился интернет на стороне провайдера и алерт физически не мог уйти.

Что такое Unified Alerting и почему мы выбираем именно его

Начиная с Grafana 9, разработчики выкинули старую систему алертов и заменили её на Unified Alerting. Это встроенный Alertmanager внутри Grafana, который полностью совместим с Prometheus alerting rules, но управляется через нормальный графический интерфейс. Для офисного сценария это критически важно: я не могу позволить, чтобы инженер второй линии правил YAML-файлы напрямую и положил весь мониторинг из-за пропущенной запятой.

Архитектурно Unified Alerting состоит из четырёх кубиков:

• Alert rules — правила срабатывания. Запрос к источнику данных (PromQL для Prometheus, обычный SQL для PostgreSQL, LogQL для Loki) плюс пороги.
• Contact points — каналы доставки. Telegram, email, Slack, Mattermost, webhook на любой сторонний сервис.
• Notification policies — маршрутизация. Дерево правил «если severity=critical и сервис=AD, то отправляй в чат @корп-дежурный».
• Silences и mute timings — глушилки. Чтобы при плановом обновлении в субботу ночью не пришло 80 уведомлений.

Для офиса до 50 рабочих мест отдельный Alertmanager избыточен. Встроенного в Grafana хватает за глаза, и поддерживать одну систему дешевле, чем две.

Telegram-бот за пять минут: пошаговая инструкция

Telegram оказался идеальным каналом доставки для российских реалий: работает почти везде, у каждого инженера установлен, поддерживает форматирование и кликабельные ссылки. Вот точная последовательность, которую мы выполняем для нового клиента:

1. В Telegram открываем @BotFather, отправляем команду /newbot. Имя — что-то осмысленное вроде «КорпМонБот», username должен заканчиваться на bot, например corp_company_alert_bot.
2. Получаем токен вида 7123456789:AAFxxx.... Сохраняем в менеджер паролей — этот токен даёт полный доступ к боту.
3. Создаём в Telegram две группы: «Алерты-Дежурные» и «Алерты-Инфо». Добавляем туда бота. Обязательно даём боту права администратора, иначе он не будет видеть chat_id.
4. Отправляем в каждую группу любое сообщение, потом в браузере открываем https://api.telegram.org/bot7123456789:AAFxxx/getUpdates и вытаскиваем chat_id. Для группы он будет с минусом, например -1001234567890.
5. В Grafana идём в Alerting → Contact points → New contact point, выбираем тип Telegram, вставляем токен и chat_id, жмём Test. Должно прийти тестовое сообщение.

Главная ошибка, которую совершают на этом этапе: добавляют бота в группу, но не дают ему прав администратора, после чего getUpdates возвращает пустой массив. Если у вас так — снимите и заново добавьте бота, на этот раз сразу с правами.

Конфигурация контакт-поинтов через Provisioning

Кликать в UI хорошо для прототипа, но для продакшна мы храним конфигурацию в YAML-файлах под Git. Это даёт код-ревью изменений, откат на предыдущую версию и одинаковую конфигурацию у всех клиентов с похожими требованиями.

# /etc/grafana/provisioning/alerting/contact-points.yaml
apiVersion: 1
contactPoints:
  - orgId: 1
    name: tg-critical
    receivers:
      - uid: tg-critical-uid
        type: telegram
        settings:
          bottoken: "$__file{/etc/grafana/secrets/tg_token}"
          chatid: "-1001234567890"
          parse_mode: HTML
          disable_web_page_preview: true
          message: |
            {{ template "tg.itfresh" . }}

  - orgId: 1
    name: tg-warning
    receivers:
      - uid: tg-warning-uid
        type: telegram
        settings:
          bottoken: "$__file{/etc/grafana/secrets/tg_token}"
          chatid: "-1009876543210"
          parse_mode: HTML

  - orgId: 1
    name: email-archive
    receivers:
      - uid: email-archive-uid
        type: email
        settings:
          addresses: it-archive@company.ru
          singleEmail: false
          subject: "[Grafana] {{ .Status }}: {{ .CommonLabels.alertname }}"

Токен лежит в отдельном файле с правами 600 на пользователя grafana. Это позволяет открывать YAML-файлы для код-ревью без риска утечки.

Notification policies: правильное дерево маршрутизации

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

apiVersion: 1
policies:
  - orgId: 1
    receiver: tg-warning  # дефолт — всё, что не попало в матчеры
    group_by: [alertname, instance]
    group_wait: 30s
    group_interval: 5m
    repeat_interval: 4h
    routes:
      # Critical — всегда в дежурный чат, не группируем долго
      - receiver: tg-critical
        matchers:
          - severity = critical
        group_wait: 10s
        group_interval: 1m
        repeat_interval: 30m
        continue: true

      # Дублирование critical в email для постмортемов
      - receiver: email-archive
        matchers:
          - severity = critical
        group_wait: 10s
        repeat_interval: 1h

      # Warning ночью молчит
      - receiver: tg-warning
        matchers:
          - severity = warning
        mute_time_intervals: [nighttime]
        group_wait: 1m
        repeat_interval: 4h

      # Info — только в архив
      - receiver: email-archive
        matchers:
          - severity = info

Ключевые цифры из нашей практики: group_wait для critical — 10 секунд, чтобы не пришло три отдельных сообщения, если упали три сервиса одновременно. repeat_interval — 30 минут для critical, чтобы дежурный не забыл про инцидент, но и не получил 50 повторов за час. Для warning — 4 часа, потому что warning — это «обрати внимание утром», а не «беги тушить».

Mute timings: чтобы плановые работы не превращали бота в спамера

У нас есть клиент, у которого по субботам в 23:00 запускается полный бэкап с гипервизора. Нагрузка на диск 95 %, в Zabbix падает три алерта про IO latency, один про CPU, один про температуру SAS-контроллера. Если бы мы не настроили mute timing, дежурный получал бы пять сообщений каждую субботу — и в итоге начал бы их игнорировать.

apiVersion: 1
muteTimes:
  - orgId: 1
    name: nighttime
    time_intervals:
      - times:
          - start_time: "23:00"
            end_time: "07:00"
        weekdays: [monday:friday]
        location: Europe/Moscow

  - orgId: 1
    name: backup-window
    time_intervals:
      - times:
          - start_time: "23:00"
            end_time: "03:00"
        weekdays: [saturday]
        location: Europe/Moscow

Mute timing привязывается к политике через mute_time_intervals. На время бэкапа можно отключить только конкретные алерты (через label component=backup), а critical продолжать слать — на случай если упадёт сам гипервизор.

Шаблон Telegram-сообщения: чтобы дежурный понял за 5 секунд

Сообщения по умолчанию из Grafana выглядят как стена непонятного текста. За три года я выработал формат, который читается за пять секунд и сразу даёт понять, что произошло и что делать.

# /etc/grafana/provisioning/alerting/templates.yaml
apiVersion: 1
templates:
  - orgId: 1
    name: tg-itfresh
    template: |
      {{ define "tg.itfresh" }}
      {{ if eq .Status "firing" }}🔴 СРАБОТАЛО{{ else }}🟢 ЗАКРЫТО{{ end }}
      {{ range .Alerts }}
      <b>{{ .Labels.alertname }}</b>
      Сервис: {{ .Labels.service | default "—" }}
      Хост: {{ .Labels.instance }}
      Уровень: {{ .Labels.severity }}
      {{ if .Annotations.summary }}
      📋 {{ .Annotations.summary }}
      {{ end }}
      {{ if .Annotations.runbook }}
      📖 <a href="{{ .Annotations.runbook }}">Что делать</a>
      {{ end }}
      Когда: {{ .StartsAt.Format "02.01 15:04 MSK" }}
      ───
      {{ end }}
      {{ end }}

Обратите внимание на ссылку «Что делать» — это указатель на runbook в нашей корпоративной базе знаний. Дежурный в три часа ночи не должен помнить наизусть, как перезапустить pgbouncer; он должен открыть ссылку и пойти по шагам.

Какие алерты обязательны для офисной инфраструктуры

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

14 алертов покрывают 95 % офисных аварий. Дальше уже идёт специфика: для офисов с IP-телефонией — алерт на регистрацию SIP-транков; для производств — алерты на SCADA-серверы; для ритейла — мониторинг кассового ПО.

Реальный кейс: как мы поймали тихо умирающий RAID

Декабрь 2025 года. Клиент — оптовая база на 28 ПК, сервер 1С на HP DL380 Gen9, RAID 10 из шести SAS-дисков. В 14:42 в дежурный Telegram прилетает алерт: «🔴 СРАБОТАЛО — RAID Array Degraded, hostname: srv-1c-01, физический диск 3 в slot 4 пометен как Failed». Дежурный инженер за 7 минут согласовал с клиентом замену, в 16:30 новый диск был установлен, в 19:00 ребилд завершился. Никто из 60 пользователей даже не заметил, что что-то происходило.

Без алерта по SNMP с iLO этот диск тихо умер бы, через неделю-другую посыпался бы второй, и в один прекрасный понедельник база встала бы на ребилд из бэкапа на 8 часов. Потеря дня работы оптовой базы стоит около 1.2 млн рублей по оценке самого клиента. Стоимость нашего мониторинга — 12 000 рублей в месяц, окупился за час.

Борьба с alert fatigue: шесть правил, которые работают

Alert fatigue — состояние, когда инженер начинает свайпать уведомления в сторону, не читая. Это смертный приговор любому мониторингу. Вот наши правила, которые держат количество ложных срабатываний на уровне 1–2 в неделю:

1. Каждый алерт обязан требовать действия. Если на алерт нечего делать — он не нужен. Уберите. Метрика для дашборда не должна быть алертом.
2. Только три уровня severity. Critical — будит ночью. Warning — приходит в рабочее время. Info — складывается в архив. Никаких «major», «minor», «trace» — людям сложно держать в голове больше трёх категорий.
3. Pending period обязателен. CPU, который скакнул на 2 секунды до 100 %, не повод будить инженера. Используйте for: 5m для warning и for: 1m для critical.
4. Гистерезис. Если алерт срабатывает при заполнении диска >85 %, разрешать его нужно при <75 %. Иначе на грани вы получите мигание «firing/resolved» каждые две минуты.
5. Runbook для каждого critical. Без исключений. Если нет runbook — нет алерта.
6. Еженедельный 15-минутный review. Каждую пятницу смотрим, какие алерты срабатывали, какие были ложные, что подкрутить. За 15 минут в неделю мы экономим часы рабочего времени.

Сколько это стоит, если делает АйТи Фреш

Чтобы сразу закрыть финансовый вопрос: для типичного офиса на 25–35 ПК, с одним сервером 1С и контроллером домена, развёртывание мониторинга «под ключ» у нас стоит 65 000–95 000 рублей единовременно. Это включает установку Prometheus + Grafana или Zabbix + Grafana на отдельной виртуалке, настройку 18–22 алертов, два Telegram-чата с маршрутизацией, mute timings под расписание клиента, шаблоны сообщений и обучение дежурных.

Дальше — 8 000–12 000 рублей в месяц на сопровождение: добавление новых правил при изменении инфраструктуры, разбор ложных срабатываний, обновление Grafana, ежеквартальная проверка, что всё ещё доходит до Telegram. Если клиент уже на нашем абонентском обслуживании, мониторинг входит в тариф «Стандарт» без дополнительной платы.

FAQ — частые вопросы перед внедрением

Сколько серверов нужно, чтобы внедрять Grafana с алертами?

Уже от 5 серверов или 1 сервера 1С + сетевое оборудование. Если у вас стоит хотя бы один продуктовый сервис, который терпит простой не более часа — Grafana с Telegram-алертами окупается за месяц.

Можно ли обойтись без отдельного Alertmanager?

Да. Grafana 9+ имеет встроенный Unified Alerting со всеми возможностями: маршрутизация, группировка, silence, mute timings. Отдельный Alertmanager нужен только при нескольких независимых Grafana-инстансах.

Сколько алертов оптимально для офиса с 1 сервером 1С и AD?

15–25 правил. Главный принцип: каждое уведомление требует действия. Если на алерт нечего делать — это не алерт, а виджет на дашборде. Лучше 20 точных алертов с инструкциями, чем 200 шумящих.

Как сделать так, чтобы алерты ночью не будили зря?

Через mute timings и разные уровни severity. Critical приходит круглосуточно, warning — только в рабочее время. Информационные алерты вообще уходят в email или второй чат, а не в дежурный Telegram.

Делает ли АйТи Фреш мониторинг под ключ?

Да. Развёртываем Zabbix/Prometheus + Grafana, пишем правила под вашу инфраструктуру, настраиваем Telegram-чаты с маршрутизацией по типу сервиса. Стартовая стоимость — от 45 000 ₽ для офиса до 30 рабочих мест с 1–2 серверами.