Zabbix + Telegram, 1С и всё остальное: интеграции, которые превращают мониторинг в систему реагирования

Меня зовут Евгений Семёнов, я технический директор компании «АйТи Фреш». Больше пятнадцати лет мы занимаемся IT-аутсорсингом для московских компаний до 50 рабочих мест и держим собственную мониторинговую инфраструктуру на серверах в дата-центре МТС. В обзорной статье о Zabbix в 2026 году я рассказывал, почему выбрали именно эту систему, а в пошаговом мануале по установке Zabbix 7.0 мы разворачивали сервер за один вечер. Сегодня — про то, что превращает свежепоставленный Zabbix из красивой панельки с графиками в рабочую систему реагирования: оповещения в Telegram, эскалации по SLA, мониторинг 1С и бэкапов, отчёты в Grafana и автоматизацию через API. Всё — из нашей ежедневной практики сопровождения клиентов.

Мониторинг без реагирования — это просто красивые графики

Самая частая ошибка, которую мы видим у новых клиентов: Zabbix стоит, собирает сотни метрик, рисует нарядные дашборды — а когда ночью падает сервер 1С, об этом никто не узнаёт до утра, пока первый бухгалтер не позвонит с вопросом «почему база не открывается». Мониторинг, который никого не будит, не стоит электричества, которое тратит.

Метрика приобретает ценность ровно в тот момент, когда по ней кто-то встал среди ночи и починил проблему до того, как её заметил бизнес. Всё, что между сбором данных и этим действием, — техническая обвязка, и именно она отличает «поставили и забыли» от системы, за которую платят. Цепочка, которую мы выстраиваем на каждом внедрении, выглядит так:

• Триггер — условие на метрике, которое переводит проблему из «данные в базе» в «событие, требующее реакции».
• Нужный человек — событие адресуется не абстрактной группе, а конкретному дежурному, который сейчас на смене.
• Нужный канал — сообщение приходит туда, куда человек реально смотрит: в Telegram, а не в почтовый ящик, который открывают дважды в день.
• Эскалация — если через оговорённое время дежурный не отреагировал, тревога поднимается выше по цепочке автоматически, без ручного «а ты Пете написал?».

В нашем договоре аутсорсинга реакция на критический алерт измеряется минутами, и это возможно только потому, что тревога прилетает дежурному инженеру в мессенджер, а не оседает в почте. Ниже — как именно мы это собираем, шаг за шагом. Начнём с самого востребованного: оповещений в Telegram.

Telegram-оповещения по-взрослому

Telegram в российских реалиях — де-факто стандарт для оперативных технических уведомлений: клиент моста, десктоп, телефон, часы — тревога догонит инженера везде. Хорошая новость: в Zabbix 7.0 LTS для этого не нужны сторонние костыли — интеграция встроена в коробку.

Штатный тип оповещений Telegram (webhook) в 7.0

Zabbix 7.0 поставляется с готовым способом оповещения (media type) «Telegram» на базе webhook. Он использует официальный Bot API мессенджера и умеет форматировать сообщения в Markdown и HTML. Настройка сводится к трём вещам: создать бота у @BotFather, получить его токен, узнать chat_id получателя. В разделе Alerts → Media types → Telegram прописывается токен бота, а форматирование включается параметром ParseMode. Дальше токен и текст шаблона выглядят примерно так:

# Media type "Telegram" — параметры webhook
Token       = 7180000000:AAH_ваш_секретный_токен_бота
ParseMode   = markdown

# Шаблон сообщения для проблемы (Message templates → Problem)
Subject: {EVENT.SEVERITY}: {EVENT.NAME}
Message:
*{EVENT.SEVERITY}* на `{HOST.NAME}`
Проблема: {EVENT.NAME}
Началась: {EVENT.TIME} {EVENT.DATE}
Узел: {HOST.CONN}
Событие ID: {EVENT.ID}

После этого способу оповещения назначается получатель: у пользователя во вкладке Media в поле «Send to» указывается тот самый chat_id (личный или групповой). Формально на этом Telegram-алерты уже работают. Но «работают» и «работают по-взрослому» — разные вещи, и дальше начинается наша практика.

Наш паттерн: отдельный бот и отдельный чат на каждого клиента

Обслуживая полтора десятка компаний, мы никогда не валим все тревоги в один поток. На каждого клиента заводится отдельный групповой чат «Мониторинг: ООО Ромашка», в который приглашён бот и дежурная смена. Так инженер с одного взгляда понимает, чья инфраструктура горит, а клиент при желании видит прозрачную картину по своим серверам, не подглядывая за чужими. Severity мы дублируем эмодзи-маркерами (🔴 Disaster, 🟠 High, 🟡 Warning), потому что цветной кружок в ленте считывается мгновенно, а слово «High» ещё надо прочитать. И в каждое сообщение кладём прямую ссылку на график проблемной метрики через макрос — чтобы дежурный тапнул и сразу увидел динамику, а не лез руками искать нужный элемент данных.

Разделение потоков: Critical и High — дежурным, Warning — в дайджест

Второй принцип — не приучать людей игнорировать бота. Если в чат дежурных сыплется всё подряд, включая «диск заполнен на 71%», через неделю инженеры перестают туда смотреть, и настоящая тревога тонет в шуме. Поэтому потоки мы разводим по важности:

• Disaster, High, Critical → немедленно в чат дежурной смены, с пингом и звуком.
• Warning и Information → не мгновенно, а собираются в утренний дайджест, который бот присылает раз в сутки одним сообщением: «за ночь накопилось 6 предупреждений, разберите на плановом обходе».

Технически это делается двумя действиями (Actions) с разными условиями по severity и разными способами доставки. Дежурный видит только то, что действительно требует ночного вмешательства, а мелочи не размывают его внимание.

Тест «умер интернет у клиента»

И главный тест, который почему-то почти никто не проводит. Представьте: у клиента полностью отвалился канал в интернет. Сервер Zabbix, стоящий внутри его сети, в этот момент сам отрезан от мира — и тревога «связь потеряна» физически не может уйти в Telegram, потому что уходить ей некуда. Классическая ситуация «сторож заперт вместе с тем, что сторожит». Поэтому доступность внешнего периметра клиента мы всегда мониторим с независимой ноды — нашего сервера в ЦОД МТС, который проверяет клиентские сервисы снаружи. Если у клиента ляжет весь канал, тревогу отправит именно внешняя нода, а не задохнувшийся Zabbix изнутри упавшей сети. Это разница между «мы узнали о проблеме первыми» и «нам позвонил разъярённый директор».

Эскалации и расписания под SLA

Одного оповещения мало: человек может спать, ехать в метро без связи, банально не услышать. Договор аутсорсинга обещает клиенту не «мы вам напишем», а «проблема будет решена за N минут» — и это гарантируется эскалацией, а не надеждой на то, что дежурный не спит. В Zabbix эскалация настраивается в действии (Action) через операции с шагами и задержками между ними.

Наша типовая лестница из трёх шагов для критической проблемы выглядит так:

Ключевая деталь — условие «событие не подтверждено». Как только любой инженер нажимает «Acknowledge» (подтвердить) и берёт проблему в работу, дальнейшие шаги эскалации не выполняются: старшего и руководителя дёргать больше незачем, человек уже занимается. Это делается условием операции по статусу подтверждения. Приведу упрощённую логику операций одного действия:

# Action → Operations (эскалация критической проблемы)
Step 1 (0 min):
    Send to user group: Дежурные, media: Telegram
Step 2 (start after 30 min):
    Condition: Event acknowledged = No
    Send to user group: Старшие инженеры, media: Telegram
Step 3 (start after 120 min):
    Condition: Event acknowledged = No
    Send to user: Руководитель, media: Telegram, SMS

# Recovery operations: уведомить всех, кого затронула эскалация

Отдельно решается вопрос «кого можно будить ночью». Никто не хочет получать SMS в три часа ночи из-за того, что на тестовом сервере кончилось место на диске. За это отвечает расписание доставки в настройках получателя (user media → When active). У дневных предупреждений мы ставим окно активности «рабочие часы», и ночью они просто не доставляются — ждут утра. А критические события (Disaster) идут круглосуточно: если ночью встала боевая база 1С, будить дежурного правильно.

Окна обслуживания: не спамить во время плановых работ

Последний штрих цивилизованной эскалации — подавление тревог на время плановых работ. Если каждую субботу в 22:00 мы обновляем платформу 1С, и в этот момент службы штатно перезапускаются, Zabbix честно поднимет десяток тревог «служба недоступна» — и разбудит дежурного зря. Чтобы этого не было, на окно работ заводится Maintenance с типом «без сбора данных» или «со сбором, но без действий». В окне обслуживания метрики продолжают собираться для истории, но оповещения не уходят. Инженер, выполняющий обновление, ставит окно на час вперёд и работает спокойно, не глуша при этом весь мониторинг клиента целиком.

Мониторим 1С:Предприятие — самое ценное у клиентов

Для большинства наших клиентов 1С — это сердце бизнеса: пока работает база, работает и компания. Поэтому мониторинг сервера 1С:Предприятие мы прорабатываем детальнее всего. Хорошая новость — Zabbix прекрасно видит всё, что нужно, штатным агентом, без дорогих специализированных инструментов, если знать, за какими метриками следить.

Службы кластера: ragent, rmngr, rphost

Кластер сервера 1С:Предприятие живёт на трёх типах процессов: ragent (агент сервера, точка входа), rmngr (менеджер кластера) и rphost (рабочие процессы, в которых и крутятся сеансы пользователей). Если на Windows-сервере они оформлены как службы, их доступность отслеживается через низкоуровневое обнаружение служб Windows (service.discovery) с триггером на состояние. Проще всего повесить проверку на конкретную службу агента сервера:

# Проверка состояния службы агента сервера 1С (Windows)
service.info["1C:Enterprise 8.3 Server Agent",state]

# Триггер: служба не в состоянии "Running"
last(/Сервер 1С/service.info["1C:Enterprise 8.3 Server Agent",state]) <> 0

Количество и память rphost: утечки и «процессов ноль»

Самое интересное — рабочие процессы rphost. Их поведение рассказывает о здоровье сервера больше, чем любая другая метрика. Мы держим на них два разнонаправленных триггера. Первый — «процессов стало ноль»: если rphost не запущен ни один, кластер мёртв, пользователи не могут войти, и это критическая тревога немедленно. Второй — на утечку памяти: если суммарная память рабочих процессов ползёт вверх день за днём и упирается в потолок, скоро сервер начнёт свопиться и тормозить у всех разом. Считаем количество и память процессов через агентские ключи proc.num и proc.mem:

# Сколько рабочих процессов rphost запущено
proc.num[,,,rphost]

# Суммарная память всех rphost, байт
proc.mem[rphost]

# Триггер "кластер лёг": ни одного рабочего процесса
max(/Сервер 1С/proc.num[,,,rphost],#3)=0

Порог по памяти подбирается под конкретный сервер — универсального числа нет, оно зависит от объёма ОЗУ и числа пользователей. Мы обычно ставим предупреждение на 80% доступной памяти и тревогу на 90%, чтобы был запас времени на реакцию до того, как сервер начнёт агонизировать.

Доступность опубликованной базы по HTTP

Служба запущена, процессы живы — а база всё равно не открывается, потому что упала веб-публикация на IIS или Apache, через которую заходят тонкие клиенты и мобильное приложение. Проверять надо не «жив ли процесс», а «отвечает ли база пользователю». Для этого в Zabbix есть веб-сценарии (web scenarios): агент периодически ходит по HTTP на адрес публикации, проверяет код ответа и, при необходимости, наличие нужной строки в теле. Это тот самый мониторинг «с точки зрения пользователя», который ловит проблемы, невидимые для проверок процессов:

# Web scenario "Публикация базы Бухгалтерия"
Step 1: GET https://1c.client.ru/buh/
    Required status codes: 200
    Required string: "Информационная база"
    Timeout: 15s
# Триггер на шаге: код ответа != 200 или строки нет
# → "Веб-публикация базы Бухгалтерия недоступна"

Свежесть файла выгрузки бэкапа 1С

Ещё одна ценная и дешёвая проверка — контроль того, что ночная выгрузка базы (dt-файл или архив) реально создаётся. Zabbix умеет читать время последнего изменения файла ключом vfs.file.time. Если файл выгрузки старше суток — задание бэкапа сломалось, и об этом надо знать сегодня, а не в день, когда база понадобится из архива:

# Время последней модификации файла выгрузки (Unix time)
vfs.file.time[/backup/1c/buh_nightly.dt,modify]

# Триггер: файл не обновлялся более 26 часов
fuzzytime(/Сервер 1С/vfs.file.time[/backup/1c/buh_nightly.dt,modify],26h)=0

Где Zabbix заканчивается и начинается ЦУП

Честная граница: блокировки, замеры APDEX, разбор технологического журнала построчно, детальный анализ длительности запросов — это уже не работа Zabbix. Пытаться затащить в него полноценный разбор техжурнала — значит превратить мониторинг в тормозящего монстра. Для глубокой аналитики производительности 1С существуют специализированные инструменты — Центр управления производительностью (ЦУП) из состава КИП и сторонние решения на базе APDEX. Zabbix отвечает на вопрос «жива ли инфраструктура и не пора ли будить инженера», а «почему конкретная проводка тормозит три секунды» — вопрос к профильным инструментам 1С. Смешивать эти слои — типичная ошибка, ведущая к разочарованию в обоих.

Мониторинг бэкапов — священная корова

Скажу без преувеличения: примерно в девяти из десяти аудитов новых клиентов мы обнаруживаем, что «бэкап настроен» на словах, а по факту не работает уже недели или месяцы. Задание отвалилось после обновления, кончилось место на приёмнике, сломался токен облака — причин масса, а результат один: в день, когда база понадобится из копии, копии не окажется. Поэтому мониторинг бэкапов у нас — не опция, а обязательный пункт сдачи любого договора.

Принцип простой: доверять надо не факту «задание запланировано», а факту «свежая копия физически появилась и весит столько, сколько должна». Проверяем это тремя дополняющими друг друга паттернами.

• Свежесть и размер файла. Комбинация vfs.file.time (когда создан) и vfs.file.size (сколько весит) ловит две беды разом: копия не создалась вовсе и копия создалась, но пустая или обрезанная. Особенно коварен второй случай — файл вроде есть, а внутри огрызок. Мы ставим порог «размер меньше вчерашнего более чем на 30%» как сигнал, что выгрузка оборвалась на середине.
• Лог задания бэкапа. Veeam, wbadmin или самописный скрипт по завершении знают, успешно ли отработали. Пусть post-job-скрипт отправляет этот результат в Zabbix через zabbix_sender — тогда мониторинг получает не косвенную улику, а прямой вердикт самого бэкапа.
• «Копия не пришла вовремя». Функция nodata() ловит саму тишину: если за сутки не прилетело ни одного отчёта об успешном бэкапе, значит задание вообще не запускалось. Отсутствие данных — это тоже данные.

Вот как post-job-скрипт рапортует Zabbix об успехе через отправку значения на сервер:

# В конце скрипта бэкапа: рапорт в Zabbix
# -z сервер, -s имя хоста как в Zabbix, -k ключ, -o значение
zabbix_sender -z zabbix.itfresh.ru -s "Файл-сервер Ромашка" \
  -k backup.job.status -o 1

# А триггер на стороне Zabbix ловит и провал, и тишину:
#   last(...backup.job.status)=0  → задание отчиталось об ошибке
#   nodata(...backup.job.status,26h)=1 → отчёта нет сутки

Grafana поверх Zabbix — дашборды для директора

Сам Zabbix рисует всё, что нужно инженеру: графики нагрузки, панели проблем, карты сети. Но когда речь заходит о ежемесячном отчёте руководителю клиента, штатные дашборды Zabbix выглядят по-инженерному сухо. Директору хочется одну красивую панель «здоровье инфраструктуры», а не таблицу с сотней элементов данных. Здесь на сцену выходит Grafana.

Связка делается официальным плагином-источником данных Zabbix для Grafana (он же grafana-zabbix, авторства Александра Зобнина). Плагин ставится в Grafana, настраивается на API вашего сервера Zabbix — и дальше все собранные метрики доступны для построения панелей средствами Grafana с её богатой библиотекой визуализаций. Мы применяем эту связку в двух сценариях:

• Месячный отчёт клиенту. Одна страница: аптайм ключевых сервисов в процентах, число и длительность инцидентов, тренд загрузки серверов. Понятно директору, не требует расшифровки, отлично смотрится в PDF.
• Дашборд на ТВ в переговорной. Большая панель «светофор инфраструктуры» на экране в офисе: всё зелёное — работаем, что-то покраснело — видно от двери. Дисциплинирует лучше любого регламента.

Важная честная оговорка: Grafana — опциональный слой, а не обязательный. Оповещения, эскалации и весь оперативный контроль прекрасно живут в самом Zabbix; Grafana мы добавляем там, где клиенту нужна представительская визуализация для руководства. Ставить её «потому что модно», добавляя ещё один сервис в обслуживание, — лишняя работа. Нужен красивый отчёт директору — ставим; хватает инженерных панелей Zabbix — не усложняем.

Zabbix API для ленивых и умных

Всё, что можно сделать мышкой в веб-интерфейсе Zabbix, можно сделать программно через его API. Это JSON-RPC 2.0: вы шлёте HTTP-POST с описанием метода и параметров, получаете JSON-ответ. Для рутинных задач внедрения и отчётности API экономит часы кликов. Работа всегда начинается с авторизации методом user.login, который возвращает токен сессии, — его затем подставляют в заголовок последующих запросов.

# 1. Авторизация: получаем токен сессии
curl -s -X POST https://zabbix.itfresh.ru/api_jsonrpc.php \
  -H 'Content-Type: application/json-rpc' \
  -d '{
    "jsonrpc": "2.0",
    "method": "user.login",
    "params": {"username": "api-bot", "password": "СЕКРЕТ"},
    "id": 1
  }'
# → {"jsonrpc":"2.0","result":"3a7b...токен...","id":1}

# 2. Список хостов группы "Серверы 1С" с их IP
curl -s -X POST https://zabbix.itfresh.ru/api_jsonrpc.php \
  -H 'Content-Type: application/json-rpc' \
  -H 'Authorization: Bearer 3a7b...токен...' \
  -d '{
    "jsonrpc": "2.0",
    "method": "host.get",
    "params": {
      "output": ["host", "name"],
      "selectInterfaces": ["ip"],
      "groupids": "10"
    },
    "id": 2
  }'

На этом фундаменте мы строим три типовых сценария, которые окупают знакомство с API многократно:

• Выгрузка инвентаризации. Метод host.get с секцией selectInventory отдаёт заполненные поля инвентаря (серийники, ответственные, расположение). Скрипт складывает это в таблицу — и вот у вас актуальная опись парка серверов без ручного ведения Excel, который всегда врёт.
• Массовое создание хостов при внедрении. Когда заходим к новому клиенту с полусотней машин, никто не заводит их руками. CSV со списком серверов прогоняется скриптом через host.create — за минуту создаётся всё, с привязкой к нужным группам.
• Автопривязка шаблонов. Метод host.massadd вешает шаблон «Windows Server», «Сервер 1С» или «Файл-сервер» на пачку хостов сразу, по правилу из имени или группы. Единообразие мониторинга без кликанья по каждому узлу.

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

Миграция на Zabbix с того, что было

К нам редко приходят с чистого листа — обычно у клиента уже что-то стоит: бесплатный PRTG, старый Nagios, а чаще всего зоопарк самописных скриптов в планировщике. Переезд на Zabbix мы делаем без обрыва наблюдения, и подход к каждому источнику свой.

С PRTG Free: маппинг сенсоров и лимит в 100

Бесплатный PRTG — частый выбор небольших офисов, пока они не упираются в его потолок в 100 сенсоров. Логика переноса прямая: сенсор PRTG становится элементом данных (item) Zabbix, а его каналы с порогами — триггерами. Историю метрик из PRTG мы принципиально не тащим: это трудозатратно, а ценность старых графиков близка к нулю — важна динамика вперёд, а не археология. Главный выигрыш переезда именно в снятии лимита: там, где PRTG заставлял выбирать, что мониторить, Zabbix берёт всё.

С Nagios и Icinga: проверки и замена NRPE

Наследие Nagios/Icinga — это набор проверок (checks), часто исполняемых на удалённых хостах через демон NRPE. При переезде сами проверки конвертируются в items и triggers Zabbix, а вместо NRPE на хосты ставится штатный Zabbix agent 2 — он и функциональнее, и активно поддерживается, и умеет плагины из коробки. Существующие плагины Nagios при желании можно даже переиспользовать как external checks на первое время, но правильная цель — постепенно заменить их родными ключами агента.

С зоопарка скриптов: самый частый и самый приятный случай

Реальность малого бизнеса — не стройный Nagios, а десяток bash- и PowerShell-скриптов в cron и планировщике задач: этот проверяет диск и шлёт письмо, тот пингует роутер, третий смотрит очередь печати. Работает, но истории нет, алерты уходят в почту, а при увольнении автора никто не знает, что вообще проверяется. Прелесть Zabbix в том, что эти скрипты не нужно выбрасывать. Их оборачивают в UserParameter или отправку через zabbix_sender — и вся самодельная логика получает сверху историю, графики, пороги и цивилизованные оповещения с эскалацией. Вот как скрипт превращается в метрику Zabbix одной строкой конфига агента:

# /etc/zabbix/zabbix_agentd.d/custom.conf
# Свой ключ, значение которого возвращает существующий скрипт.
# Параметр [*] пробрасывает аргументы в скрипт.
UserParameter=queue.print[*],/opt/scripts/check_print_queue.sh $1

# Пример без аргументов — число писем в очереди postfix:
UserParameter=mail.queue,mailq | grep -c '^[0-9A-F]'

После этого queue.print[hp-office] становится обычным элементом данных: с графиком, с историей за год, с триггером «очередь растёт третий час» и алертом в Telegram. Ноль переписанной логики — максимум пользы.

Параллельный период: две-четыре недели

Ни один переезд мониторинга мы не делаем рубильником «вчера PRTG — сегодня только Zabbix». Две-четыре недели старая и новая системы работают параллельно. Это даёт спокойно убедиться, что Zabbix ловит все те же события, что и прежняя система, не молчит там, где старая пищала, и не сыплет ложными тревогами. Только когда новая система отработала пару недель без нареканий, старую гасят. Дешёвая страховка от неприятного открытия «а вот это мы, оказывается, перестали видеть».

Итог: слоёная модель зрелости мониторинга

Если свести всё сказанное в одну картину, зрелость мониторинга — это пять слоёв, каждый из которых бесполезен без предыдущего и неполон без следующего:

1. Собираем — метрики стекаются в систему. Здесь останавливается большинство «поставили Zabbix».
2. Алертим — на метриках стоят триггеры, тревога уходит в Telegram нужному человеку.
3. Эскалируем — если дежурный молчит, тревога автоматически поднимается выше по SLA.
4. Отчитываемся — руководитель видит здоровье инфраструктуры и статистику инцидентов (тут и пригождается Grafana).
5. Автоматизируем реакцию — типовые проблемы система чинит сама (перезапуск службы, очистка временных файлов) через remote commands, а человека зовёт только на нештатное.

Наша позиция по опыту сопровождения: офис до 50 рабочих мест обязан дойти минимум до третьего слоя. Собирать и даже алертить недостаточно — без эскалации ночная тревога упрётся в спящего дежурного, и обещанное клиенту время реакции превратится в фикцию. Четвёртый и пятый слои — уже про зрелость и удобство, но первые три — гигиенический минимум, ниже которого мониторинг не выполняет свою единственную задачу: чтобы о проблеме первым узнал тот, кто её чинит, а не тот, кто от неё страдает.

Чек-лист самопроверки из 10 пунктов

Пройдитесь по своему мониторингу с этим списком. Каждое «нет» — дыра, через которую однажды прилетит неприятность:

Если хотя бы половина пунктов вызвала сомнение — самое время навести порядок, пока порядок не навела за вас ближайшая авария. А если разбираться с этим некому или некогда — мы в «АйТи Фреш» разворачиваем и сопровождаем мониторинг по этому самому регламенту: от установки Zabbix до эскалаций в Telegram и отчётов вашему руководству. Напишите в Telegram @ITfresh_Boss или позвоните +7 903 729-62-41 — посмотрим вашу инфраструктуру и подскажем, где в цепочке «метрика → человек» разорвано звено.