EFSOL расширила возможности Metrika42 On-prem — системы мониторинга и диагностики производительности 1С, которая разворачивается непосредственно в инфраструктуре заказчика. Новые и доработанные дашборды помогают быстрее пройти путь от жалобы пользователя на медленную работу 1С до конкретной операции, сессии, рабочего процесса сервера 1С и событий технологического журнала.
Обновления Metrika42 On-prem были проверены на рабочем контуре 1С:ERP промышленной компании.
В крупных системах общая оценка производительности может выглядеть благополучно, хотя отдельные критичные действия пользователей выполняются значительно дольше ожидаемого времени.
Общая оценка состояния 1С не всегда показывает, на каких конкретно операциях пользователи теряют время. Для диагностики необходимо последовательно перейти от общего показателя к операции, пользователю, сессии и техническим событиям в момент деградации.
От общей оценки APDEX — к конкретной операции
Чтобы быстрее разбирать ситуации с локальной деградацией, в Metrika42 On-prem были расширены дашборды оценки производительности APDEX.
Теперь инженер может последовательно сужать область анализа: от информационной базы и профиля производительности — к конкретной ключевой операции, пользователю, сессии и отдельному замеру.
Такой сценарий позволяет не ограничиваться усредненной оценкой системы, а находить именно те действия, на которых пользователи фактически теряют время.
Сопоставление APDEX с технологическим журналом 1С
Отдельным инструментом стал дашборд сопоставления замера APDEX с событиями технологического журнала 1С.
После выбора конкретной медленной операции специалист может увидеть, какие события происходили непосредственно в период ее выполнения:
- CALL;
- SDBL;
- DBMSSQL;
- TLOCK;
- другие события технологического журнала.
Это сокращает объем ручного поиска по технологическому журналу и помогает быстрее проверять гипотезы о влиянии SQL-запросов, блокировок, серверных вызовов или прикладной логики.
Ключевое изменение: инженер получает возможность перейти от факта медленной пользовательской операции непосредственно к техническим событиям, которые происходили в системе в тот же временной интервал.
Диагностика рабочих процессов сервера 1С
Доработки коснулись и дашбордов состояния сервера 1С. Более точная фильтрация позволяет анализировать нагрузку не только на уровне сервера целиком, но и в контексте конкретных рабочих процессов, пользователей и сессий.
Такой уровень детализации особенно важен в ситуациях,
когда общие показатели CPU и памяти остаются в пределах нормы,
но отдельный rphost, пользователь или информационная база
демонстрируют нетипичное поведение.
Как выглядит диагностический маршрут
В результате обновлений формируется последовательный сценарий расследования деградации производительности 1С.
Зафиксировать ухудшение APDEX. Инженер определяет информационную базу и профиль, в котором произошло отклонение.
Определить проблемную операцию. Из общего профиля выделяется конкретное действие, которое выполняется дольше ожидаемого времени.
Перейти к пользователю и сессии. Анализ уточняется до конкретного контекста, в котором выполнялась операция.
Выбрать длительный замер. Инженер изучает конкретный эпизод деградации, а не только усредненное состояние системы.
Сопоставить замер с техническими событиями. Анализируются события технологического журнала, состояние рабочих процессов и инфраструктурный контекст.
Сформировать проверяемую гипотезу. Собранные данные позволяют определить, какое направление необходимо исследовать дальше: СУБД, блокировки, запросы, серверные вызовы, ресурсы или прикладную логику.
APDEX → операция → пользователь → сессия → замер → технологический журнал → инфраструктурный контекст → проверяемая гипотеза.
Единый контекст вместо разрозненных систем
При традиционном расследовании специалисту приходится переключаться между различными источниками: мониторингом инфраструктуры, сервером 1С, СУБД, технологическим журналом и данными пользовательских операций.
В Metrika42 эти данные связываются вокруг одного инцидента производительности. Инженер видит ухудшение APDEX, проблемную операцию и технические события, которые происходили в тот же момент.
Меньше ручного поиска
Не требуется вручную искать нужный временной интервал в нескольких источниках и сопоставлять события.
Точнее локализация
Анализ можно сузить до базы, операции, пользователя, сессии и рабочего процесса.
Проверяемые гипотезы
Решение о дальнейшем анализе принимается на основании связанных технических данных, а не только общей жалобы «1С тормозит».
Что получает ИТ-директор
Для ИТ-директора такой подход означает снижение количества решений, принимаемых на основании предположений.
Если пользователи жалуются на медленную работу 1С, Metrika42 помогает проверить, связано ли наблюдаемое отклонение:
- с нехваткой серверных ресурсов;
- с работой СУБД;
- с блокировками;
- с SQL-запросами;
- с серверными вызовами;
- с прикладной логикой.
Это позволяет точнее выбирать направление дальнейшей оптимизации и снижает риск необоснованных затрат на инфраструктуру, если данные не подтверждают дефицит серверных ресурсов.
Данные мониторинга остаются внутри инфраструктуры заказчика
Metrika42 On-prem предназначена для организаций, которым необходимо хранить компоненты мониторинга и диагностические данные внутри собственной инфраструктуры.
Решение объединяет данные:
- серверов и инфраструктуры;
- кластера 1С;
- СУБД;
- технологического журнала;
- APDEX и пользовательских операций;
- ошибок;
- блокировок.
«В крупных системах 1С основной проблемой часто становится не отсутствие данных, а время, которое специалист тратит на их сопоставление.
Наша задача — связать сигнал о деградации с конкретной пользовательской операцией и сразу дать инженеру технический контекст этого события.
Новые дашборды Metrika42 On-prem развивают именно этот сценарий: от APDEX и жалобы пользователя — к сессии, рабочему процессу, технологическому журналу и проверяемой гипотезе причины».
Денис Пахомов, руководитель продукта Metrika42
Что изменилось в диагностике 1С
- расширена детализация дашбордов APDEX;
- анализ можно последовательно сузить от информационной базы до конкретного замера;
- APDEX сопоставляется с событиями технологического журнала за тот же период;
- состояние сервера 1С можно анализировать в контексте рабочих процессов, пользователей и сессий;
- инженер получает связанный диагностический маршрут вместо ручного сопоставления данных из нескольких источников;
- технические гипотезы можно проверять до принятия решения об оптимизации кода, СУБД или инфраструктуры.
