Клиент — крупная промышленная инжиниринговая группа, работающая с телекоммуникационными и инженерными системами. У компании распределённая ИТ-инфраструктура, собственные компетенции разработки и производства и опыт международных проектов, поэтому требования к безопасности, контролю доступа и качеству эксплуатации ИТ-систем традиционно повышенные. Ключевая система для операционной деятельности — 1С, через которую проходят основные учетные и управленческие процессы, и любые просадки производительности быстро становятся заметны пользователям.
Повод обращения был практичным: ИТ-команда хотела получить специализированный мониторинг 1С, который позволит оперативно находить причины замедлений и опираться на объективные данные, а не на фрагментарные жалобы. Отдельным принципиальным требованием стало размещение системы мониторинга строго внутри инфраструктуры заказчика — без выноса данных наружу. Это было критично с точки зрения корпоративных политик безопасности и разграничения доступа.
В кейсе описано внедрение Metrika42 On-Prem — enterprise-формата системы мониторинга 1С, разворачиваемой в локальном контуре. Мониторинг построен так, чтобы дать единую точку контроля состояния серверов 1С и СУБД, обеспечить анализ технологических журналов и прозрачную диагностику как инфраструктурных, так и прикладных причин замедлений.
Схема 1 – Внедрение Metrika42 On-Prem
Задачи клиента
- Развернуть мониторинг 1С строго on-premise, внутри контура, с доступом по внутренним ролям и политикам.
- Получить единую картину состояния серверов 1С и компонентов (кластеры, службы, СУБД MS SQL) с быстрым выявлением отклонений.
- Настроить анализ технологического журнала (ТЖ) и оценку производительности для поиска первопричин просадок.
- Организовать мониторинг ключевых операций (например, проведение документов, формирование отчетов) и объективно измерять влияние изменений в коде/инфраструктуре на пользовательский опыт.
- Научиться быстро локализовывать инциденты по потреблению ресурсов (CPU/память/диски) вплоть до сеанса конкретного пользователя.
- Встроить систему оповещений с разделением на критические технические алерты и события бизнес-логики 1С.
- Обеспечить длительное хранение данных для пост-инцидентного анализа без ограничений облачных лимитов.
Схема 2 – Задачи мониторинга 1С
Решение
- Внедрили Metrika42 On-Prem в локальном контуре заказчика: данные мониторинга остаются внутри инфраструктуры, а доступ управляется внутренними ролями и политиками.
- Настроили сбор, анализ и визуализацию сотен метрик по серверам 1С, кластерам, службам и MS SQL, а также детальный разбор ТЖ.
- Организовали единую точку контроля со “светофором” состояния серверов 1С для мгновенной оценки здоровья контуров.
- Реализовали мониторинг ключевых операций 1С (проведение документов, отчеты) для измерения отклика и контроля эффекта от доработок.
- Включили диагностику потребления ресурсов до уровня пользовательского сеанса, чтобы ускорить расследование «кто/что создает нагрузку».
- Настроили оповещения в Telegram, разделив технические критические сигналы и события, связанные с бизнес-логикой 1С.
- Зафиксировали политику хранения данных без лимитов: заказчик сам задаёт срок хранения под свои регламенты и получает стабильную базу для доказательной эксплуатации.
Схема 3 – Решение для мониторинга 1С
Результат
- Уже на стадии тестовой эксплуатации выявили скрытые проблемы, влияющие на отклик и стабильность:
- критическое потребление RAM процессами RpHost;
- высокая нагрузка на дисковую подсистему (очереди, влияние на отклик);
- высокая фрагментация индексов в БД, требующая реорганизации;
- длительные/неоптимальные SQL-запросы, блокировки и таймауты;
- превышение целевого времени выполнения ключевых бизнес-операций 1С.
- ИТ и разработка получили общий язык в цифрах: стало проще отделять проблемы кода от инфраструктуры и СУБД и быстрее выходить на первопричины.
- Появилась возможность масштабировать мониторинг на критичные контуры без компромиссов по безопасности.
- За счет длительного хранения метрик и событий у заказчика сформировалась база для пост-инцидентного анализа и доказательной эксплуатации, что снижает стоимость простоев и ускоряет разбор причин.
Схема 4 – Ключевые результаты
