Мониторинг 1С в Grafana: три слоя, метрики и алерты, которые работают
Иван Недомолков · Опубликовано: · Обновлено:
В большинстве компаний мониторинг 1С устроен одинаково: его нет. О том, что “1С лежит”, первым узнаёт бухгалтерия - по телефону. О том, что база деградирует, не узнаёт никто - до дня, когда проведение документа начинает занимать минуту и работа встаёт.
В этой статье - как устроен мониторинг серверов 1С на открытом стеке Grafana + Prometheus: архитектура из трёх слоёв, конкретные метрики, пороги алертов и честное сравнение с Zabbix и платными сервисами. Всё описанное ниже - не концепт, а работающее продуктивное решение: несколько кластеров 1С, высоконагруженные базы на MS SQL Server, таблицы журналов регистрации на миллиард с лишним событий.
Зачем мониторить 1С
Два аргумента, оба измеримые.
Первый - время реакции на сбой. Без мониторинга цепочка выглядит так: сервис упал → пользователь заметил → пользователь дозвонился → администратор понял, что это не “у меня одного” → началась диагностика. Это 15-60 минут до начала работ. С алертами цепочка сокращается до “упал → через минуту сообщение в Telegram → диагностика”. При стоимости часа простоя учётной системы даже небольшой компании разница окупает мониторинг за один-два инцидента.
Второй - деградация копится незаметно. База растёт, статистика устаревает, запросы, укладывавшиеся в секунду, начинают занимать три. По отдельности каждый день ничего не меняется; на графике за месяц тренд очевиден. Без графика за месяц тренда не существует - существует только авария в конце.
Есть и третий аргумент, административный: без метрик любой разговор о производительности - спор мнений. “Тормозит из-за сервера” против “тормозит из-за кривого кода” решается не совещанием, а графиком.
Архитектура: три слоя
Проблемы производительности 1С живут на трёх этажах, и мониторить нужно все три - иначе видна только часть картины.
СУБД (MS SQL) ──── sql_exporter ────────┐
Кластер 1С ─────── rac-exporter ────────┼──→ Prometheus ──→ Grafana ──→ Alertmanager ──→ Telegram
Журналы регистрации ── экспортер ЖР ────┴──→ ClickHouse ──→ GrafanaСлой 1: СУБД
Поверх DMV-представлений SQL Server работает sql_exporter с девятью группами коллекторов, которые Prometheus опрашивает каждые 30 секунд: доступность, блокировки, производительность (batch requests, компиляции, CPU), память, ожидания, долгие запросы, Always On AG, RCSI/tempdb - и отдельно прикладные очереди обмена прямо из таблиц 1С. Последнее - принципиально: очередь интеграционных сообщений - такая же метрика, как загрузка процессора, и жить она должна в том же Grafana.
Метрики отвечают на вопрос “есть ли проблема”. На вопрос “кто, кого и каким запросом” отвечает событийный коллектор: он опрашивает DMV раз в секунду, и при блокировке дольше 5 секунд фиксирует событие с полными текстами блокирующего и заблокированного запроса, логином и хостом. Дедлоки разбираются по графам из Extended Events: из xml_deadlock_report извлекаются участники и жертва, полный граф сохраняется для разбора. Почему раз в секунду, а не раз в 30: блокировка, родившаяся и умершая между двумя опросами, для 30-секундного мониторинга не существует - а для кассира, который её поймал, вполне.
Слой 2: кластер 1С
Штатная консоль администрирования кластера показывает “сейчас” и не хранит историю. Экспортер, опрашивающий утилиту rac каждые 10 секунд, превращает это в метрики Prometheus: состояние rphost/ragent/rmanager, сессии по каждой базе (всего/активных/спящих/заблокированных - раздельно “ждут СУБД” и “ждут менеджер блокировок 1С”), память процессов, потребление лицензий. Облегчённую версию этого слоя, без склейки с SQL-процессами, но с готовым дашбордом Grafana и правилами тревоги, мы выложили отдельным инструментом: экспортер кластера 1С в Prometheus. Какие поломки у такого экспортера бывают на деле, от CRLF в выводе до службы RAS, которая перестала стартовать после обновления платформы, собрано в разборе почему Prometheus не принимает метрики кластера 1С.
Тонкий момент - кардинальность. Отправлять в Prometheus метрики по каждой из тысяч сессий нельзя - база метрик распухнет. Отправлять только агрегаты - потерять виновников. Решение: по-сессионные метрики уходят только по “интересным” сессиям - заблокированным, с активным соединением СУБД, Top-N по памяти и CPU, с вызовом СУБД дольше 5 секунд.
Самая ценная функция этого слоя - REST API соответствия SPID → сессия 1С: по номеру SQL-процесса мгновенно получаем пользователя 1С, приложение (тонкий клиент / фоновое задание / web) и базу. Без этой склейки разбор инцидента выглядит как “какой-то SQL-логин что-то заблокировал”; с ней - “фоновое задание такое-то держит таблицу, страдают вот эти пользователи”.
Слой 3: журналы регистрации → ClickHouse
Журнал регистрации - главный прикладной источник правды в 1С, и штатный просмотр в конфигураторе для аналитики непригоден. Решение - потоковый экспорт .lgp/.lgx в ClickHouse (доработанный open-source OneSTools.EventLog): служба сама находит базы в каталоге кластера, поднимает воркер на каждую, пишет события порциями почти в реальном времени.
Смысл этого слоя не в графиках, а в том, что ошибки становятся считаемыми: пока они лежат в журнале, их формально видно, а фактически нет, и потому годами никто не чинит. Что меняется, когда ошибки начинают считать и показывать, мы разобрали на своих цифрах - “Почему ошибки в 1С не чинятся”.
Результат в цифрах: таблицы больше миллиарда событий на базу (журнал ~1 ГБ в день) остаются быстрыми - ошибки в разрезе пользователей, аудит изменений, частотный анализ отвечают за секунды SQL-запросом вместо листания журнала. Отдельная выстраданная деталь: upstream-версия экспортера при повреждённой записи журнала уходила в бесконечный цикл рестартов; пришлось патчить парсер на уровне бинарного формата, чтобы он находил границу следующей корректной записи и продолжал чтение.
Как этот слой устроен внутри - схема хранения, движки таблиц ClickHouse, устройство экспортёра и запросы, которыми сняты замеры, - разобрано на объёме в 35 миллиардов событий в статье “Журнал регистрации 1С на 35 миллиардов событий: как заставить его открываться за 0,11 секунды”.
Какие метрики реально нужны
Типичная ошибка - собрать всё, что отдают экспортеры, и получить 40 дашбордов, на которые никто не смотрит. Стартовый набор, закрывающий 90 % инцидентов:
| Метрика | Слой | Зачем |
|---|---|---|
| Доступность инстанса SQL и состояние БД (ONLINE) | СУБД | ”Жив ли сервис” - база любого алертинга |
| Заблокированные сессии, макс. время ожидания | СУБД | Главный источник жалоб “1С висит” |
| Счётчик дедлоков | СУБД | Каждый дедлок - чей-то откаченный документ |
| CPU инстанса, batch requests/sec | СУБД | Отделяет “сервер занят” от “сервер простаивает, а всё висит” |
| Page Life Expectancy | СУБД | Ранний признак нехватки памяти |
| Долгие запросы (порог 30 с) | СУБД | Тренд деградации кода и статистики |
| Место на дисках, размер tempdb и version store | СУБД | Аварии “кончилось место” - самые глупые и самые частые |
| Состояние rphost/ragent/rmanager | Кластер | Перезапуски rphost - типичная скрытая причина “вылетов” |
| Сессии по базам: активные, спящие, заблокированные | Кластер | Норма нагрузки и её аномалии |
| Потребление лицензий | Кластер | Чтобы “лицензии кончились” не случалось в пиковый день |
| Глубина и возраст очередей обмена | Прикладной | Встал обмен - узнать из метрики, не от филиала |
| Ошибки в журнале регистрации (частота по базам) | Прикладной | Всплеск ошибок после обновления виден за минуты |
Что сознательно не входит в стартовый набор: wait stats по всем категориям, по-объектная статистика ввода-вывода, метрики самого мониторинга. Это всё полезно на разборе инцидентов, но в первую очередь нужны метрики, по которым можно алертить.
Алерты, которые не надоедают
Главная болезнь мониторинга - не отсутствие алертов, а алерты, которые все научились игнорировать. Правило простое: каждое уведомление должно означать “нужно действовать”. Всё остальное - на дашборд, не в Telegram.
Работающая схема из продуктива, 12+ правил только по слою СУБД:
- Два уровня серьёзности. Заблокированные сессии - warning; блокировка дольше 30 секунд - critical. Warning смотрят в рабочем порядке, critical будит.
- Мгновенные critical без порогов ожидания: дедлок (по приросту счётчика), база не в ONLINE, экспортер недоступен. Последний пункт обязателен: молчащий мониторинг хуже отсутствующего, потому что создаёт ложное спокойствие. Проверять надо не только экспортер, но и сам канал доставки: у нас было настроенное правило, от которого не доходило ни одного сообщения, потому что исходящий трафик с машины не выпускали - как это вскрылось.
- Ресурсные пороги с запасом на реакцию: CPU > 80 %, Page Life Expectancy < 300 с, свободное место ниже порога. Цель - узнать за часы до аварии, а не в момент.
- Прикладные алерты наравне с системными: рост очереди обмена, всплеск долгих запросов, деградация RCSI (разрастание version store, “зависшая” старая транзакция).
И обязательный этап, который чаще всего пропускают: обкатка порогов 2-4 недели на реальной нагрузке. Пороги, назначенные из головы в первый день, дают либо тишину, либо спам. Первые недели алерты калибруются: сработал впустую - порог поднимается или добавляется условие; проблема прошла без алерта - порог опускается. Только после этого мониторингу можно доверять.
Grafana + Prometheus, Zabbix или платный сервис мониторинга 1С
Вопрос “grafana 1с или zabbix 1с” всплывает в каждом втором обсуждении. Честное сравнение:
| Критерий | Grafana + Prometheus | Zabbix | Платные сервисы мониторинга 1С |
|---|---|---|---|
| Лицензии | бесплатно (open source) | бесплатно (open source) | подписка, обычно за базу или сервер |
| Специфика 1С из коробки | нет - нужны экспортеры | нет - нужны шаблоны и скрипты | да, это их продукт |
| СУБД и инфраструктура | сильно: экосистема экспортеров | сильно: классика инфра-мониторинга | обычно ограниченно |
| Гибкость метрик и дашбордов | максимальная | средняя; модель “item/trigger” жёстче | что предусмотрел вендор |
| Аналитика больших журналов | да (связка с ClickHouse/Loki) | не по этой части | редко |
| Порог входа | средний: PromQL, конфиги | средний: свои концепции | низкий |
| Привязка к подрядчику/вендору | нет - стек остаётся у вас | нет | да, данные и опыт живут у вендора |
Наша позиция и почему:
- Zabbix - зрелый инструмент, и если он уже развёрнут в компании для серверов и сети, дублировать его Прометеем ради самих серверов не нужно. Но специфику 1С (кластер через RAS, склейка SPID→сессия, журналы регистрации) в Zabbix придётся строить самим же - готовых полноценных решений этого уровня нет, а модель данных Zabbix хуже приспособлена к событийной аналитике.
- Платные сервисы - самый быстрый старт и хороший вариант, когда нет своей инфраструктурной команды. Минусы: подписка навсегда, метрики и история живут у вендора, глубина настройки ограничена, а слой СУБД и ОС обычно всё равно приходится закрывать чем-то ещё.
- Grafana + Prometheus 1С выигрывает там, где нужен единый стек на все слои - от дисков до прикладных очередей - без лицензионных платежей и с полным владением: всё развёрнутое остаётся у вас, с документацией, и не исчезает при смене подрядчика. Цена этого - экспортеры под 1С нужно либо писать, либо брать у того, кто уже написал. Наши написаны и обкатаны на продуктиве, поэтому мониторинг 1С мы ставим готовой связкой: rac-экспортер со склейкой SPID в сессию, sql_exporter с девятью группами коллекторов и событийный сбор блокировок.
С чего начать: минимальный набор за неделю
Не начинайте с трёх слоёв и ClickHouse. Рабочая последовательность:
- День 1-2. Prometheus + Grafana + Alertmanager на отдельной ВМ (Docker-контейнеры - самый короткий путь). Node/windows_exporter на серверы 1С и СУБД: CPU, память, диски.
- День 2-3. Экспортер СУБД: доступность, блокировки, долгие запросы, место. Это слой, где живёт большинство инцидентов.
- День 3-4. Первые алерты в Telegram: сервис недоступен, база не ONLINE, место на диске, блокировка дольше 30 с, дедлок. Пять правил, не пятьдесят.
- День 4-5. Один дашборд “здоровье системы”: доступность, CPU, блокировки, сессии, место. Один - чтобы на него смотрели.
- Недели 2-4. Обкатка порогов. Затем следующий слой: экспортер кластера 1С, потом журналы регистрации.
Такой набор уже закрывает главное: о падении вы узнаёте из Telegram за минуту, а не от бухгалтерии за полчаса. Остальное - наращивается по мере надобности.
Если своих рук на это нет - мы разворачиваем мониторинг 1С под ключ: три слоя, дашборды, откалиброванные алерты, документация и передача вашей команде без абонентской привязки. Мониторинг хорошо ложится в связку с регулярным обслуживанием баз 1С - метрики показывают, что чинить, обслуживание - чинит. А если хочется сначала понять текущее состояние системы без внедрения чего-либо - начните с экспресс-аудита: это быстрый снимок тех же слоёв, по которым потом строится мониторинг.
Коротко
Мониторинг 1С - это три слоя: СУБД (sql_exporter, событийный сбор блокировок раз в секунду, дедлок-графы), кластер 1С (экспортер через RAS/RAC со склейкой SPID→сессия) и журналы регистрации в ClickHouse. Начинать нужно не с покупки инструмента, а с пяти алертов и одного дашборда - и с готовности 2-4 недели калибровать пороги. Стек Grafana + Prometheus не требует лицензий и остаётся у вас; Zabbix уместен, если уже внедрён; платные сервисы - если некому владеть инфраструктурой. Худший вариант ровно один: узнавать о сбоях по телефону.
Отдельный случай, где привычные метрики врут, - интеграционная шина. Там фиксированный порог на поток фолзит при суточном разбросе в тридцать пять раз, а канал может стоять сутки при пустой очереди. Что мониторить в такой связке, разобрано в статье “1С:Шина в продуктиве”.
