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

Привет! Меня зовут Семёнов Евгений Сергеевич, и я директор АйТи Фреш. За пятнадцать лет, что мы обслуживаем корпоративные инфраструктуры в Москве и Подмосковье, я понял одну простую, но очень важную вещь: мониторинга, который не доходит до нужного человека за минуту, просто не существует. Дашборд 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. По сути, это встроенный в Grafana Alertmanager, который полностью совместим с 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 секунд

Кликать в UI хорошо для прототипа, но в продакшене всё держим в YAML под Git:

# /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 минут в неделю мы экономим часы рабочего времени.

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

Чтобы сразу расставить все точки над «i» по денежному вопросу: для типичного офиса на 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 серверами.