Как стать автором
Обновить

Комментарии 8

Вот так метрики производительности собираешь, мониторишь, ищешь проблему… а там оказывается в просто внутри обработки или конфигурации нахламокожено и оно не может не тормозить, потому что пол базы вычитывает при каждом движении и сама себе блокировки таблиц накидывает побольше.
… но виноваты по дефолту админы.

Могу только добавить, что собирать метрики в отрыве от пользовательских сессий 1С и регламентных заданий можно, но этого недостаточно поскольку трудно будет провести корреляцию событий. Даже один бухгалтер использующий обработку с корявым кодом может легкими движениями раздувать базу(ы) TempDB с шагом в пару гигабайт в минуту до пары сотен гигабайт.
Язык не повернется поспорить.
Но!
Чтобы припереть программиста к стенке как раз и нужно собирать метрики.
Этими мы понимаем что что-то произошло нехорошее, а логами ТЖ или тем же профайлером находим кто накосячил.
Это пока за пределами публикации но вполне реализуемо

Ну раз вы дополнили комментарий, то и я допишу свой )
Совсем трудно будет провести корреляцию событий
Клянусь своей треуголкой.
Тот же профайлер интегрируется со счетчиками perfmon и вы в 60 сек поймете кто что и зачем делает.
Будет интересно — голосуйте, напишу)

Думаю очередная статья про event collector.

А тут даже проще.

Собирайте всё в elasticsearch.

События системы/метрики + экспорт из журнала 1с.

Дальше будет видна корреляция между действиями в 1с и нагрузками на сервер.

Продемонстрируйте.
Я имел в виду статью плюсаните )
Договорились
Все точно.
Про extended events.
Надо только получше разобраться.
elasticsearch наверное круто, но его надо поднимать, ни разу не пробовал
И в этом случае надо 3 метрики собирать
1. перфмон
2. ТЖ
3. профайлер
если это делать не в моменте это неплохо нагрузит систему?
Perfmon -> MetricBeat (собирать метрики Windows, SQL)
ТЖ -> Любые статьи в гугле «1С elasticsearch»
EventLog -> WinLogBeat (собирать события входа на RDP сервер)
Импорт в elastic порождает довольно много трафика, это может серьезно сказаться если сбор данных идет с удаленного сервера через vpn канал.
Если не настроить фильтрацию перед загрузкой в ELK, то дискового объема нужно будет очень много.
Любые статьи в гугле «1С elasticsearch»

Про это я в курсе
Но там в основном мониторят ошибки по ТЖ
Это легкий журнал
А если попытаться такой связкой понять кто ставит колом сервер своими запросами, то это во первых будет очень тяжелый ТЖ, а во вторых сбор такого ТЖ сам по себе не хило тормознет сервер и в третьих из него не факт что легко выйти на нагрузку, потому как в базе 500 человек а в ТЖ только время и длительность события
Поэтому таких статей в гугле не найдешь
Поэтому жду от вас пруф
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.