Привет, Хабр! В прошлых статьях мы уже обсуждали эволюцию подходов к мониторингу — от ручного анализа данных до использования MCP-серверов для взаимодействия с LLM и сравнивали философию open-source стека (Prometheus + Grafana) с готовыми APM-платформами. Сегодня хочу применить этот опыт к важной области, о которой говорят реже — мониторингу систем на платформе «1С:Предприятие».
Задача мониторинга 1С-ландшафта традиционно считалась нетривиальной. Причин несколько: закрытость платформы, специфические источники данных и сложность интерпретации происходящего для бизнеса. Давайте посмотрим, какие вообще существуют способы заглянуть под капот работающей 1С — от классических штатных средств до современных решений, строящих единую картину наблюдаемости.
1. Штатные средства: Журнал регистрации и контроль пользователей
Самый очевидный и встроенный в платформу инструмент — Журнал регистрации (ЖР). Он фиксирует практически все значимые события: вход и выход пользователей, выполнение операций, ошибки и предупреждения. По сути, это первоисточник данных для анализа активности и поиска «крайнего».
Настраивается Журнал регистрации в Конфигураторе («Администрирование» → «Настройка журнала регистрации») и можно выбрать уровень детализации: от полного отключения до регистрации всех событий. В приложении 1С есть удобный интерфейс для просмотра — «Монитор пользователей», который показывает активных пользователей и даёт отфильтровать события ЖР по пользователю, объекту или времени.
Однако у этого подхода есть объективные ограничения. Во-первых, хранение данных в текстовых файлах или SQL-базах быстро становится неэффективным при большой нагрузке. Во-вторых, Журнал регистрации не предназначен для глубокого анализа производительности и поиска корневых причин тормозов — он скорее отвечает на вопрос «что делал пользователь?», а не «почему запрос выполнялся 2 минуты?»
2. Технологический журнал (ТЖ)
А вот здесь по-настоящему интересные данные. Технологический журнал — это низкоуровневый механизм самой платформы 1С, который покажет детализированную информацию о работе сервера. В отличие от ЖР, ТЖ собирает события на уровне выполнения кода, запросов к СУБД, блокировок и времени ожидания.
Анализируя ТЖ, можно восстановить полную хронологию операции: увидеть, сколько времени ушло на выполнение SQL-запроса, сколько на обработку в коде 1С и были ли блокировки.
ТЖ незаменим, когда проблема уже локализована и нужно понять, что именно её вызвало: конкретный запрос, блокировка или ожидание ресурса. Но держать его включённым постоянно затратно — сырые логи весят гигабайты, и, чтобы с ними работать, нужны настроенные фильтры, парсеры и место для хранения.
3. RAS и RAC: удалённое управление и сбор метрик
Следующий важный слой — это инструменты администрирования кластера 1С: RAS (Remote Administration Server) и RAC (Remote Administration Client).
RAS — служба с унифицированным API для управления кластером 1С. Через неё система мониторинга в реальном времени забирает количество сессий, состояние рабочих процессов, блокировки и другие параметры.
RAC — консольная утилита, которая использует RAS для выполнения команд.
На этой паре часто строят сбор метрик кластера. Типичная схема — через Zabbix: по LLD-шаблонам (Low-Level Discovery) он сам обнаруживает информационные базы, а данные о сессиях получает скриптами через RAC. Так видно динамику нагрузки на кластер, и можно настраивать алерты на аномалии. Подход рабочий, но требует заметных трудозатрат на запуск и поддержку.
4. Популярные подходы: OpenSource-стек
Если смотреть на рынок, многие компании строят собственные системы мониторинга 1С на базе open-source компонентов. Как мы уже обсуждали, такой подход даёт полный контроль, но требует значительных инженерных ресурсов.
Современная архитектура здесь обычно выглядит так:
Сбор данных: ТЖ и ЖР парсятся и отправляются в колоночную СУБД, идеально подходящую для хранения и агрегации больших объёмов событийных данных.
Сбор метрик: с помощью RAS собираются текущие метрики кластера и сохраняются в базу временных рядов, например Prometheus или VictoriaMetrics.
Визуализация: как правило, Grafana — либо что-то совсем кастомное.
Итак, платформа даёт три источника данных — ЖР, ТЖ и RAS, плюс есть способ собрать из них систему мониторинга самостоятельно. Но у всех этих путей общее свойство: обвязку приходится строить и поддерживать своими силами — парсеры ТЖ, шаблоны Zabbix, хранилища, дашборды. Дальше расскажу, как мы подошли к этой задаче в Ключ-АСТРОМ.
Мониторинг 1С в APM Ключ-АСТРОМ
Мы пошли по пути специализированного расширения для платформы 1С: оно собирает данные из штатных механизмов и отправляет их в APM-систему автоматически.
Давайте разберём, как это работает на практике.
Архитектура решения
Расширение «Интеграция с Ключ-АСТРОМ» встраивается непосредственно в инфраструктуру 1С как cfe-расширение и использует её стандартные механизмы, не требуя вмешательства в код конфигурации или изменения архитектуры серверов.
Вот как выглядит поток данных:
1. Источники данных. Расширение подключается к четырём основным источникам:
Кластер 1С — через RAS (Remote Administration Server) для сбора инфраструктурных метрик (CPU, RAM, сессии).
Подсистема «Оценка производительности» — через встроенный механизм Библиотеки стандартных подсистем (БСП) для получения замеров времени выполнения ключевых операций и расчёта APDEX.
Журнал регистрации (ЖР) — для сбора событий, ошибок и предупреждений на уровне прикладного кода.
Технологический журнал (ТЖ) — детальные внутренние показатели работы 1С.
2. Обработка и отправка. Расширение агрегирует данные из этих источников, структурирует их и по защищенному протоколу HTTPS отправляет в ваше окружение Ключ-АСТРОМ.
3. Визуализация и анализ. В Ключ-АСТРОМ все данные автоматически превращаются в готовые метрики с тегами (по инфобазе, пользователю, серверу и т.д.), на основе которых можно строить графики и дашборды без дополнительной настройки парсеров.
Этот подход реализует идею сквозного мониторинга (full-stack observability), объединяя данные об инфраструктуре, производительности приложения и пользовательском опыте в единую картину.
Что именно мы собираем?
Расширение собирает три категории данных, каждая из которых закрывает свой аспект наблюдаемости.
1. Метрики кластера: здоровье инфраструктуры
Чтобы понять, упирается ли система в нехватку ресурсов, расширение забирает данные напрямую с серверов 1С через RAS:
Доступность и нагрузка: состояние рабочих процессов (
rphost,rmngr), загрузку CPU, потребление памяти.Активность пользователей: общее количество сеансов, количество активных сеансов, сеансов фоновых заданий и веб-сервисов.
Длительность вызовов: максимальную длительность текущих интерактивных вызовов, вызовов фоновых заданий и веб-сервисов.
Блокировки: количество таймаутов и взаимоблокировок (по желанию).
Все эти метрики помогают инженеру быстро ответить на вопрос: «Проблема в коде или в сервере?».
2. APDEX и замеры времени: пользовательский опыт
APDEX закрывает то, чего не видно в инфраструктурных метриках, — насколько быстро система работает с точки зрения пользователя.
Вместо разбора сырых логов расширение использует встроенный механизм «Оценка производительности» (на базе БСП). Когда пользователь открывает форму или формирует отчёт, платформа 1С сама фиксирует время выполнения операции, а расширение забирает уже готовые данные из регистра БСП — то есть ничего не замеряет самостоятельно и не создаёт дополнительной нагрузки.
Дальше из этих данных считается APDEX (Application Performance Index) — агрегированный показатель удовлетворённости пользователей скоростью работы. Рассчитывается не по одной операции, а за период (по умолчанию 5 дней): так оценка получается статистически значимой, а случайные выбросы сглаживаются.
Порог задаёт администратор — для каждой ключевой операции, например, «Открытие формы документа», в справочнике «Ключевые операции» указывается целевое время (T). Относительно него система автоматически классифицирует каждый замер как «Удовлетворительный», «Терпимый» или «Разочаровывающий» и вычисляет итоговый APDEX.
3. Журнал регистрации: события и ошибки
Третья категория — логи. Расширение выгружает события из Журнала регистрации 1С, и дальше их можно разбирать в одном месте:
Ошибки и предупреждения — то, на что нужно реагировать сразу.
Действия пользователей — кто, когда и что делал в системе.
Контекст операций — детали конкретной ошибки или события без переключения между интерфейсами.
Настройка: гибкость и контроль
Среды у всех разные, поэтому в расширении настраивается и то, что оно собирает, и то, как себя ведёт.
Подключение к Ключ-АСТРОМ. Нужны три параметра: адрес кластера ka.client.team, идентификатор окружения и токен. Кнопка «Проверить соединение» сразу показывает, всё ли работает.
Таймауты и повторные попытки. Чтобы мониторинг сам не стал источником проблем, задаются таймауты и число повторов: при временных сбоях сети данные не потеряются, а расширение не зависнет.
Управление логами. Логи самого расширения не разрастаются бесконтрольно — ротация настраивается по времени (например, хранить сутки) или по количеству записей.
Режимы выгрузки. Их три:
По расписанию — основной режим для постоянного мониторинга.
В реальном времени — для диагностики критических проблем.
Выгрузка за период — чтобы восстановить данные после сбоя.
От данных к решениям: визуализация и дашборды
В Ключ-АСТРОМ каждая метрика приходит с тегами (infobase, user_name, server_name и т.д.), поэтому срезы делаются без сложных запросов. Например:
APDEX операции «Формирование отчёта» в разрезе информационных баз;
какой пользователь грузит CPU сильнее всех;
ошибки по конкретному модулю или серверу.
На основе этих данных собираются дашборды под конкретные вопросы:
«1C-APDEX» — показывает пользовательский опыт: APDEX и фактическое время выполнения критических операций.
«Инфраструктура 1С» — нагрузка на сервер: CPU, память, диск, количество сессий.
«Ошибки и логи» — стабильность системы: количество ошибок и предупреждений, последние критические события.
С СУБД, файловой системой и IIS расширение не работает напрямую — только через стандартные API платформы 1С (регистры, ЖР, RAS). Поэтому оно не зависит от типа СУБД и конфигурации инфраструктуры, а поверхность взаимодействия с системой остаётся минимальной.
Что в итоге
Расширение снимает рутину: не нужно вручную собирать логи и связывать между собой несколько инструментов — состояние серверов, скорость работы пользователей и ошибки приходят в одну систему. При этом расширение закрывает прикладной слой, а не весь стек: за глубокой диагностикой и стороной СУБД остаются свои инструменты, о которых говорили выше.
Отдельно интересно, как задачу мониторинга 1С решают у вас. Удалось ли «оцифровать» пользовательский опыт — или скорость работы для пользователей до сих пор остаётся вопросом ощущений, а не метрик?
Мы сознательно не стали парсить ТЖ в постоянном режиме, но знаем команды, которые строят весь мониторинг вокруг ТЖ в ClickHouse и считают это единственно правильным путём. Если вы из таких — расскажите, как справляетесь с объёмами и поддержкой.
Делитесь кейсами в комментариях. Идеального решения тут нет, и чем конкретнее мы обсудим, кто что собирает и обо что спотыкается, тем полезнее выйдет разговор.
