Разговор про мониторинг 1С почти всегда начинается одинаково. Звонит главбух и говорит, что «программа тормозит». Айтишник заходит на сервер, смотрит диспетчер задач, видит, что процессор загружен на девяносто процентов, перезапускает службу — и на полдня становится легче. Через неделю всё повторяется. Через месяц эта история становится нормой жизни: раз в неделю 1С «залипает», раз в неделю кто-то что-то перезапускает, и никто не может внятно ответить на вопрос, почему.
Проблема здесь не в 1С и даже не в железе. Проблема в том, что сервер приложений 1С — одна из немногих систем, где деградация почти всегда постепенная. Он не падает мгновенно, как упавший nginx, который сразу перестаёт отдавать двухсотый код. Он медленно набирает вес: растут сеансы, растут блокировки, разрастается tempdb, регламентные задания начинают наезжать друг на друга. К моменту, когда пользователь позвонил, система деградировала уже несколько дней. И вот это самое обидное: все сигналы были, просто их никто не записывал.
Ниже — набор метрик, которые действительно предсказывают проблемы на 1С, с объяснением, что каждая означает на практике и какие пороги имеют смысл. Это не теоретический список из документации, а то, что реально стреляет в проде.
Почему обычный мониторинг на 1С не работает
Стандартный мониторинг, который ставят по умолчанию, проверяет три вещи: жив ли сервер (ping), отвечает ли порт, сколько свободно на диске. Для веб-сервера этого почти достаточно. Для 1С — почти бесполезно.
Сервер приложений 1С может отвечать на своём порту и при этом быть полностью нерабочим для пользователей. Классическая ситуация: рабочий процесс rphost упёрся в лимит памяти, кластер начал его перезапускать, сеансы отваливаются с ошибкой соединения — а порт кластера при этом слушается как ни в чём не бывало. Проверка «порт открыт» вернёт зелёный статус. Пользователи в это время не могут работать.
Вторая причина в том, что 1С — это всегда связка минимум из двух систем: сервер приложений и СУБД. Проблема почти никогда не живёт в одном месте. Тормоза в интерфейсе могут быть следствием блокировок в базе, блокировки — следствием разросшейся таблицы регистра, рост таблицы — следствием того, что полгода не выполнялось свёртка или регламентное задание падало с ошибкой и никто не смотрел. Мониторить только сервер приложений — это смотреть на симптом, а не на причину.
И третья причина, самая скучная: у 1С почти всё интересное лежит не в системных метриках операционной системы, а внутри — в кластере, в журнале регистрации, в счётчиках СУБД. Чтобы это увидеть, нужно специально пойти и забрать данные оттуда.
Метрики уровня операционной системы: минимум, который всё равно нужен
Начнём с базы. Системные метрики сами по себе проблему не диагностируют, но без них невозможно отличить «1С тормозит» от «серверу физически не хватает ресурсов».
Загрузка процессора на сервере 1С интересна не мгновенным значением, а формой графика. Ровные девяносто процентов в течение рабочего дня — это не авария, это, скорее всего, нормальная нагрузка на закрытии месяца. А вот пила, где загрузка каждые двадцать минут прыгает от десяти до ста и обратно, почти всегда означает, что какое-то регламентное задание или фоновая обработка запускается по расписанию и съедает весь ресурс. Один график — и уже понятно, куда смотреть.
Оперативная память — самая недооценённая метрика на 1С. Здесь важно не общее потребление, а потребление отдельными рабочими процессами. В типовой конфигурации кластера у рабочего процесса есть ограничение, при превышении которого он будет перезапущен. Если вы видите, что процесс раз за разом подбирается к лимиту и рестартует, вы нашли причину «странных вылетов у пользователей», о которых вам полгода рассказывали, но которые никогда не воспроизводились при вас.
Дисковая подсистема на 1С — это отдельная религия. Показатель, который стоит снимать, — не занятое место, а очередь к диску и время отклика. База в четыреста гигабайт на медленном диске ведёт себя нормально ровно до того момента, пока в неё не начали одновременно писать десять человек и регламент. Место при этом свободно, а система стоит.
Свободное место всё же тоже нужно, но по-умному: не «осталось десять процентов», а «при текущей скорости роста место кончится через N дней». Разница принципиальная. Первое вы узнаете за ночь до аварии, второе — за две недели, когда ещё можно спокойно запланировать расширение диска или чистку.
Метрики кластера 1С: то, ради чего всё затевается
Здесь начинается специфика, которую не даст ни один универсальный агент из коробки.
Количество активных сеансов — базовая метрика бизнес-нагрузки. Само по себе число мало о чём говорит, пока вы не наложите его на историю. Когда вы знаете, что в обычный вторник у вас работает семьдесят сеансов, а сегодня их сто сорок, — это либо аврал в бухгалтерии, либо кто-то не закрывает сеансы и они копятся. Второе, кстати, встречается чаще: зависшие сеансы от закрытых клиентских приложений вполне могут висеть часами, занимая лицензию и память.
Отдельно от сеансов стоит смотреть на соединения. Разница между ними неочевидна, но полезна: рост числа соединений при неизменном числе сеансов почти всегда указывает на фоновые задания и внешние интеграции — обмен с сайтом, выгрузку в CRM, приём заказов через веб-сервисы. Если у вас интеграция с Битрикс24 или с интернет-магазином начала сходить с ума и долбить базу в цикле, вы увидите это именно здесь.
Память по рабочим процессам, как уже сказано, — критичная вещь. Если вы снимаете только суммарное потребление по серверу, вы не увидите, что один процесс раздулся, а остальные простаивают. Разбивка по процессам сразу отвечает на вопрос «это общая нагрузка или конкретный процесс поймал тяжёлую операцию».
Длительность вызовов сервера — метрика, которую мало кто снимает и зря. Если среднее время ответа на серверный вызов выросло с двухсот миллисекунд до двух секунд, пользователи уже страдают, но ещё не жалуются: работать можно, просто неприятно. Это идеальное окно для того, чтобы среагировать до звонка главбуха.
И, наконец, лицензии. Свободные клиентские лицензии — метрика, которая ничего не говорит о производительности, но зато отлично говорит о том, что через два дня новый сотрудник не сможет войти в программу. Это дешёвый способ убрать целый класс инцидентов, которые в момент возникновения кажутся катастрофой.
Метрики СУБД: где на самом деле живут тормоза
Сколько бы вы ни оптимизировали сервер приложений, большая часть настоящих тормозов 1С живёт в базе данных. Здесь важны четыре вещи.
Блокировки и ожидания — самое главное. Пользователь, который «висит» при проведении документа, почти всегда ждёт освобождения ресурса, который держит другой пользователь или фоновое задание. Метрика количества ожиданий и их средней длительности — это прямой индикатор той самой боли, которую невозможно объяснить через загрузку процессора. Отдельно стоит ловить взаимоблокировки: они видны в логах СУБД и почти всегда указывают на конкретную проблему в коде конфигурации или в порядке проведения документов.
Размер базы и скорость роста. Тут интересна не абсолютная цифра, а динамика по таблицам. База, которая растёт на два гигабайта в неделю, — это нормально. База, которая за одну ночь выросла на сорок гигабайт, — это либо кто-то запустил обмен без фильтра, либо разошёлся регистр сведений, либо журнал регистрации не чистился с прошлого года. Всё это чинится за час, если знать. И превращается в аварию с остановкой работы, если узнать через месяц.
Долгие запросы. Топ самых тяжёлых запросов за сутки — это, по сути, готовый список задач для программиста 1С. Не абстрактное «оптимизируйте систему», а «вот эти три запроса съедают сорок процентов всего времени СУБД».
Состояние обслуживания. Индексы, статистика, план обслуживания — вещи, которые все настраивают один раз при внедрении и больше никогда не проверяют. Между тем, если ночной регламент по перестроению индексов молча падает три недели подряд, деградация будет плавной и совершенно необъяснимой для тех, кто не смотрит в эти метрики.
Регламентные задания: тихий источник половины проблем
Отдельный разговор — про регламентные и фоновые задания. Это место, где чаще всего прячется причина непонятных тормозов и странных расхождений в данных.
Снимать здесь нужно три вещи. Первая — факт выполнения: задание отработало или упало. Вторая — длительность: обмен, который раньше занимал пятнадцать минут, а теперь занимает три часа, — сигнал задолго до того, как он начнёт наезжать на рабочий день. Третья — пересечение: два тяжёлых задания, которые начали выполняться одновременно, могут положить систему, хотя по отдельности каждое отрабатывает нормально.
Классический сценарий: обмен с сайтом настроен на каждые тридцать минут, закрытие месяца запускают в семь вечера, и в какой-то момент обмен начинает занимать сорок минут. Дальше он накладывается сам на себя, очередь растёт, база блокируется, и в восемь вечера бухгалтер не может провести документ. Ни одна системная метрика не покажет причину — покажет только история выполнения заданий.
Журнал регистрации: не логи ради логов
Журнал регистрации 1С — это, по сути, единственный источник правды о том, что происходило с точки зрения приложения. Проблема в том, что его либо не читают вообще, либо читают только когда авария уже случилась.
Практический подход: не пытаться разобрать журнал целиком, а вытаскивать из него несколько конкретных типов событий. Ошибки при проведении и записи объектов — это то, что напрямую бьёт по пользователю. Ошибки соединения с СУБД — предвестники проблем с базой. Неудачные попытки аутентификации — вопрос безопасности, особенно если база опубликована через веб. Ошибки в фоновых заданиях — как раз тот случай, когда всё работает, но данные тихо расходятся.
Когда эти события собираются в централизованное хранилище логов, у них появляется свойство, которого нет у журнала внутри 1С: их можно сопоставить по времени с метриками. Всплеск ошибок в 14:32 и провал по памяти в 14:30 на одном графике — это готовый ответ, а не два отдельных наблюдения.
Какие пороги ставить, чтобы алерты не превратились в шум
Самая частая ошибка при настройке мониторинга 1С — поставить алерты на абсолютные значения и получить сто уведомлений в день, которые через неделю все начнут игнорировать.
Работающий подход строится на трёх принципах.
Первый: алерт должен срабатывать не на факт превышения, а на устойчивое превышение. Процессор на девяносто процентов в течение минуты — это норма при проведении тяжёлого документа. Процессор на девяносто процентов в течение пятнадцати минут — уже разговор.
Второй: пороги должны опираться на вашу собственную историю, а не на советы из интернета. Соберите метрики две-три недели без единого алерта, посмотрите, как выглядит нормальный день, нормальная пятница и нормальное закрытие месяца, и только потом ставьте границы. Хороший ориентир — превышение обычного уровня в полтора-два раза для того же дня недели и того же часа.
Третий: каждый алерт обязан отвечать на вопрос «что делать». Уведомление «высокая загрузка процессора» бесполезно. Уведомление «загрузка процессора выше 85% пятнадцать минут, топ-процесс rphost PID 4212, активных сеансов 143 при норме 70» — это уже начало расследования.
И отдельно: не заводите алерты на то, на что вы не собираетесь реагировать. Метрику снимать полезно всегда, а вот будить человека ночью имеет смысл только ради того, что действительно нельзя отложить до утра.
Как это выглядит на практике
Технически задача сводится к трём слоям. Системные метрики снимаются с самой машины. Метрики кластера и сеансов забираются с сервера приложений. Метрики СУБД и долгие запросы — из базы данных. Дальше всё это должно оказаться в одном месте, с общей шкалой времени и общей историей, иначе сопоставить события не получится.
Именно на этом обычно спотыкаются самодельные решения: скрипт, который пишет метрики в текстовый файл, работает ровно до первого расследования, когда нужно посмотреть, что было в прошлый вторник и сравнить с позапрошлым.
В COSCIO для этого сделан отдельный модуль интеграции с 1С: он подключается к серверу и к базе, собирает метрики кластера, сеансы, состояние регламентных заданий и ошибки из журнала регистрации, кладёт всё в общую ленту с метриками серверов и поднимает инцидент, когда показатели уходят за пороги. Плюс в том, что 1С перестаёт быть отдельным островом: на одном экране видно и сервер, и базу, и Битрикс24 рядом, а инциденты по всем системам живут в одной ленте с общей историей — той самой, по которой потом считается время восстановления.
Но принципиально важно другое: даже если вы соберёте это на связке из скриптов и любимого open-source инструмента, набор метрик останется тем же. Сеансы, память рабочих процессов, длительность серверных вызовов, блокировки, рост базы, регламентные задания и ошибки из журнала — вот тот минимум, при котором вы узнаёте о проблеме раньше пользователя.
С чего начать, если сейчас не снимается ничего
Не пытайтесь построить всё сразу — это верный способ бросить на середине.
Начните с трёх метрик: активные сеансы, память рабочих процессов и статус выполнения регламентных заданий. Соберите их за две недели без всяких алертов, просто чтобы увидеть, как выглядит нормальная жизнь вашей системы. Почти наверняка вы уже на этом этапе найдёте что-то, что вас удивит, — например, что каждую среду в 11 утра сеансов в два раза больше, или что ночной обмен падает через раз с прошлого квартала.
Дальше добавьте блокировки и долгие запросы из СУБД — это даст ответ на вопрос «почему тормозит», а не только «что тормозит». И только потом настраивайте оповещения, опираясь на собранную историю.
Такой порядок работает потому, что вы сначала получаете картину, а потом уже решаете, где ставить границы. Обратный порядок — сначала алерты, потом разбираться — приводит ровно к тому, с чего мы начали: к системе, которой никто не верит, и к звонку главбуха как основному инструменту мониторинга.