5 простых шагов и 15 минут на разворачивание инструмента мониторинга проблем производительности базы 1С

Публикация № 1040073

Администрирование - Оптимизация БД (HighLoad)

Анализ технологического журнала мониторинг

132
В этой статье мы разберем механизм использования конфигурации "Анализ технологического журнала" на практике, и всего через 15 минут работы вы получите функциональный, удобный инструмент мониторинга проблем производительности базы 1С.

Какой профит? 

  • Простая установка и настройка - за 15 минут рабочее решение для "неограниченного" количества баз
  • Ничего лишнего и никакой "магии" - используются возможности платформы
  • Дружественный интерфейс - только то что нужно
  • Информация в реальном времени - ошибки конфигурации, блокировки, длительные запросы и др.
  • Бесплатно - проект с открытым исходным кодом на GitHub

Структура статьи:

В первой части статьи мы приводим список и описание из 5 шагов для самостоятельного выполнения процедуры.  Если же Вам лень читать и Вы любите смотреть и слушать, то можно перейти к видео-уроку и посмотреть небольшой 5 минутный ролик по выполнению необходимой последовательности действий и повторить при необходимости.

Проект 1с-parsing-tech-log является open source. Уже более года мы активно и продуктивно используем данную систему в облаке для мониторинга наших приложений.

 

1. Установим

Рассматриваются два варианта:

  1. Подключаемся к проекту через EDT, закачиваем конфигурацию с репозитория и разворачиваем базу.
    (github.com/Polyplastic/1c-parsing-tech-log)
  2. Для тех кто по каким-то причинам не хочет использовать EDT скачиваем скомпилированную конфигурацию и разворачиваем через привычный конфигуратор.
    (Решение проблемы быстродействия в ERP на рабочем примере)

Совет. Боевую базу мониторинга лучше всего развернуть на отдельном сервере, по крайней мере на отдельном кластере.

 

2. Определим цели и задачи

Что мы будем мониторить? Проблемные ситуации влияющие в целом на производительность и работоспособность базы:

  1. блокировки,
  2. долгие запросы более 60с,
  3. ошибки.

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

Зачем будем мониторить? Для возможности проведения анализа проблемных ситуаций возникающих при работе базы и последующему их исправлению. Ознакомлен - значит вооружен.

 

3. Настроим технологический журнал (ТЖ) для 1С

Давайте настроим конфигурационный файл для технологического журнала всех указанных случаев. Эту операцию настроим вручную с использованием Notepad++. Однако вы всегда можете воспользоваться специальной обработкой с ИТС для настройки этого файла.

Каждую проблемную ситуацию будем выгружать в отдельный каталог и обрамляется она тегом "log" (примерный исходный код файла приведен ниже). Эти каталоги должны быть видны с сервера где развернута наша конфигурация - можно сделать общий каталог.

Созданный файл "logcfg.xml" копируем в папку с установленным предприятием 1С боевого сервера (обычно куда-то по похожему пути: "c:\Program Files\1cv8\8.3.12.1855\bin\conf\").

Пример файла "logcfg.xml":

 


Совет. Обязательно ставьте фильтры для настроек технологического журнала. Никогда не сохраняйте всё подряд. Для рассматриваемого примера нам важны только проблемные ситуации, а не весь стек всех возможных событий. 

4. Настроим базу мониторинга 

Теперь перейдем к настройке самой базы мониторинга. Наши логи уже начали формироваться, т.ч. продолжим.

  • Создаем в справочнике "Замеры" три замера с наименованиями по ситуациям: блокировки, долгие запросы и ошибки;
  • Указываем путь к соответствующим каталогам; 
  • Ставим флаг "загружать в реальном времени" - означает, что данные будут подгружаться автоматически регламентным заданием;
  • Ставим флаг "загружать автоматически" и указываем интервал загрузки 5-10 минут - будет загружаться по регламентному заданию;
  • Детализируем расписание загрузки лога.

После создания замеров с указанными параметрами загрузка логов технологического журнала будет выполняться автоматически (по регламентному заданию для каждого замера).

 

Совет. Вы можете для каждого замера указать фильтры загрузки данных из логов, чтобы ограничить количество и качество поступаемой информации (дополнительно к настройкам logcfg.xml). К примеру, игнорировать события не подлежащие анализу - обрывы соединений и т.п.

 

5. Запустим и проверим

Фактически все необходимые операции мы выполнили и теперь можно проверить что получилось.

Для анализа ситуации у нас имеются следующие обработки:

1. Журнал событий замеров. Позволяет просматривать список событий в временной последовательности с отборами и сортировками.

2. Рабочее место по изменению количества событий. Позволяет сравнить изменение количества событий на временной относительной оси по двум временным окнам, к примеру, сравнить среду и вторник текущей недели или разных.

Совет. Для изменения состава отображаемых колонок (добавить новые поля через ссылку, которых нет изначально) в динамическом списке пользуйтесь возможностью "изменить форму" через "еще".

Видео-урок.

В этом видео-уроке мы с вами установим конфигурацию "Анализ ТЖ", проведем необходимые настройки и посмотрим результаты на примере искусственных ситуаций.

 

Дополнительно.

Подключиться к проекту или его скачать вы можете с git-hub репозитория polyplastic 1c-parsing-tech-log.

Если хотите посмотреть в действии и вам "лень" ставить/компилировать EDT, то можете воспользоваться ссылкой для скачивания присоединенного файла конфигурации из статьи Решение проблемы быстродействия в ERP на рабочем примере. Также в этой статье приводится методика пример выполнения задачи оптимизации проблемного участка для базы 1С.

Есть ли аналоги? К аналогам в какой-то мере можно отнести: Notepad++ и другие механизмы полу-ручного анализа; ЦУП от 1С из Корпоративного инструментального пакета.

 

Исправления и анализ проблемных ситуаций.

Проблемы исправляются в зависимости от проведения анализа и дальнейшей классификации. К примеру, выявленные ошибки можно классифицировать по следующим уровням:

  • ошибки разработчика - ошибки вызванные результатом деятельности разработчиков. Локализуются, формируются задачи на исправления через систему баг трекинга и исправляются последующими релизами;
  • ошибки системные - ошибки вызванные проблемами окружения: доступ, отсутствие сети, проблемы внешних ресурсов, недостаток места на диске или выделенной памяти и др. Локализуются и в зависимости от возможности исправления формируются задачи на их устранение.

Наличие "долгих" запросов сообщает о проблемах в производительности базы данных. Для их анализа и наличия можно воспользоваться журналом "свойства замеров" с сортировкой по длительности и фильтром за сегодня. Их можно классифицировать

  • проблемы rls - вызваны сложными ограничениями и/или не верным назначением прав доступа;
  • проблемы запроса - не правильный запрос, который стоит оптимизировать;
  • проблемы производительности - проседание мощности в часы пик или по другим подобными причинам.

Наличие конфликта блокировок говорит об наличии определенных ситуациях в базе приводящих к отказам в действиях пользователей. Их рост во временном интервале может свидетельствовать о грядущих проблемах, который может быть связан с ростом пользователей, проблемами архитектуры и требует незамедлительных мероприятий по устранению. Провести анализ ситуации во времени можно с помощью рабочего места "анализ". 

132

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. the1 341 18.04.19 12:14 Сейчас в теме
Есть ли аналоги?

Есть отличный инструмент "Анализ технологического журнала" в Инструментах разработчика
5. Sedaiko 48 18.04.19 13:05 Сейчас в теме
(1) есть - cat, grep, sed и awk + Мозги
user612295_death4321; CSiER; +2 Ответить
7. the1 341 18.04.19 14:35 Сейчас в теме
(5)
cat, grep, sed и awk

линуксоид штоле?
10. AlX0id 18.04.19 15:18 Сейчас в теме
(7)
Можно и powershell-ом, чего греха таить _)
22. Sedaiko 48 18.04.19 23:48 Сейчас в теме
(7) эти команды можно и на винде выполнить. И не всегда красивые графические кнопочки и таблички - значит гибко, быстро и эфективно
6. tormozit 5328 18.04.19 13:53 Сейчас в теме
(1) Точнее "Анализ техножурнала"
mvxyz; Il; fokses; CSiER; +4 Ответить
23. Serg O. 171 19.04.19 09:34 Сейчас в теме
(1) анализ от Группы Гилева - анализ Тех.Журнала,
а так же Анализы: Длительных запросов, Блокировок, Взаимо-блокировок
всё там есть... и давно
tormozit; +1 Ответить
2. YPermitin 2024 18.04.19 12:28 Сейчас в теме
(0) используется только технологический журнал?

Просто ведь без магии иногда не обойтись, потому что ни план запроса через ТЖ без последствий нормально не получить, ни причины замедления запроса и др.

За труды спасибо, плюс поставил.
3. ivanov660 1150 18.04.19 12:57 Сейчас в теме
(2)
1. Проект развивается. На текущий момент доступен такой функционал.
2. В вашем случае мы используем дополнительно другие инструменты и методики для поиска сопоставления запроса с точкой в конфигурации (когда не понятно).
YPermitin; +1 Ответить
4. YPermitin 2024 18.04.19 12:59 Сейчас в теме
(3) спасибо за инструмент еще раз.

Попробую на досуге.
8. Darklight 17 18.04.19 14:44 Сейчас в теме
А есть ли возможность сделать внутри аналитической базы фильтра(отбора/группировки) по Иинформационной базе/Серверу1С/СерверуSQL/Пользователю т.е. архитектура конфигурации подразумевает что под каждую ИБ/Сервер нужно заводить отдельную ИБ анализа ТехЖурнала и уже в каждой настраивать общий доп фильтр по ИБ/Серверу или я что-то не так понял?

Жалко нет скриншота с возможными настройками, непосредственно связанными с анализом разобранного тех журнала

И ещё резонный вопрос - как это всё хранится - скажем, если тех журнал весить в тексте 1Gb то сколько он будет весить в такой аналитической базе (с учётом того, что всё что есть в тех журнале - загружается в базу).
Понятно, что объёмами тех журнала в 1Gb даже в день никого не удивишь и не шокируешь - но в больших базах, в час, тех журналы, ежедневно, бывают и по 10Gb на сервер/ИБ, а уж в периоды сдачи отчётности или под НГ могут быть и по 100Gb в час - даже если в них писать только самое важное - итого - у крупных организаций с кучей баз это будут, в пике, уже десятки терабайт в сутки! Даже если хранить это всё не более суток, как с этим объёмом справится данная аналитическая база? Компактность хранения, фильтрации, и насколько эффективно идёт разбор таких больших логов?

Да и, смотрю, нет никакой защиты от чрезмерного роста объёма данных - а желательно бы - на кризисный случай: т.е. хотя бы ограничить не только сроком хранения, а, скажем, числом записей тоже (причём, хорошо иметь не только общий максимум, но и отдельно - по каждой ИБ).
9. ivanov660 1150 18.04.19 15:11 Сейчас в теме
(8)
1. Удаление старых событий или "нет никакой защиты от чрезмерного роста":
- Есть константа "УдалятьУстаревшиеСобытия" и регламентное задание "УдалениеУстаревшихСобытий".
- Для замеров есть параметр Глубина Хранения - при условии не равном "0" данные будут очищаться.

2. "..журнал весить в тексте 1Gb.." - ставьте фильтры на собираемые данные. Для действительно полезных данных объемы значительно меньше!

3. В журнал событий замеров можно вывести информацию о всех доступных свойствах лога в сообщении:
p:processName - имя базы.
t:computerName - имя компьютера,
t:applicationName,
#Пользователь,
#Описание
и другие смотрите описание о назначении для формата лога технологического журнала
(Как добавить колонки я писал в статье и показал в видео).
Далее создаете отборы в динамическом списке по полям и получаете необходимые отборы.
Таже мы рекомендуем ставить отбор на форме журнала "Дата события больше Начало этого дня".

Замер для каждого сервера отдельно, у вас не получится писать в одну папку на диске разным серверами 1С.
Базу для каждого сервера не обязательно создавать - вы создаете замер под каждый каталог, к примеру, "замер для сервера1 по ошибкам", "замер для сервера 2 по блокировкам", "замер для сервера 3 только для базы ERP по длительным запросам" и т.п.

4. Если у вас возникнут идеи по "фитчам", то пишите в issues, а еще лучше подключайтесь)
К примеру, можно добавить справочник сервер и сделать его реквизитом замера.

5. Анализ разобранного журнала это отдельная сложная задача и не входит в рамки этой промо-статьи. Для разных ситуаций оптимальны разные наборы колонок и отборов. В дальнейшем приведем еще некоторые примеры использования - все зависит от востребованности данного инструмента коллегами.
new_user; +1 Ответить
12. w.r. 210 18.04.19 16:04 Сейчас в теме
(9)

ставьте фильтры на собираемые данные. Для действительно полезных данных объемы значительно меньше!


Это прекрасно! Ставьте фильтры, готовьте данные вручную. Да на какой хрен тогда нужна эта утилита. Я таким же образом могу тех журнал в CSV перегнать и фильтры в Excel ставить
13. ivanov660 1150 18.04.19 16:08 Сейчас в теме
(12)Не нужна не пользуйтесь)
15. YPermitin 2024 18.04.19 16:24 Сейчас в теме
(12) зачем так грубо.... инструмент не космический корабль конечно, но пользоваться можно)

Хоть я и предпочитаю на проде другие подходы.
16. ivanov660 1150 18.04.19 16:43 Сейчас в теме
(15)Я ответил вполне тактично и мягко на провокационное замечание коллеги
...Да на какой хрен тогда нужна эта утилита...


Разверну немного ответ почему необходимо ставить фильтры и зачем:
Входная информация
1. Сама 1С говорит никогда не сохраняйте все подряд. Это много лишней и ненужной информации.
2. Человек не может обработать психологически, а иногда физически большие объемы. И через какое-то время просто перестается проводится обработка.
3. Мы когда мониторим проблемы (согласно статьи) выбираем какие-то определенные ситуации, которые по объему данных должны быть минимальны. В идеале событий должно быть 0.
Согласитесь, ошибок должно быть 0, блокировок должно быть 0, долгих запросов должно быть 0.

И как только появляются отклонения начинаем анализировать и искать пути решения. А после применения решения ситуация опять должна вернуться к 0.

Если же все время висит проблема, которую мы не можем исправить или она нам не критична (ошибки коннектов и т.п.), то мы ее исключаем через настройку тж или фильтры замеров. Можно выделить при необходимости в отдельный фоновый замер - типа шум.

В результате. Проводить определенные настройки необходимо, т.к. от конкретной ситуации зависит многое (решение из коробки нужно допилить) - это думаю ясно.
В случае использования нашего инструмента нет необходимости использования сторонних решений, нет лишних преобразований, манипуляций, необходимости вызывать шамана знающего перл и RegExp. Тут нет никакой готовки данных вручную.
Проведение настроек, если есть понятие что делать занимает очень мало времени и выполняется практически разово в данном контексте.
new_user; Krio2; YPermitin; +3 Ответить
19. YPermitin 2024 18.04.19 17:39 Сейчас в теме
(16) я как-раз коллеге w.r. и говорил :)
ivanov660; +1 Ответить
21. w.r. 210 18.04.19 18:51 Сейчас в теме
(16) вот на счёт 0 не соглашусь. Ошибки есть некритические, главное чтобы они не были связаны с данными. Блокировки и долгие запросы - если это какой-нибудь отчёт, который запускает пользователь раз в месяц на ночь, тогда по сути ничего страшного. Включать ради этого тех журнал, увеличивая нагрузку на сервер. Настраивать журнал. Потом разбираться, например, с вашей утилитой. Анализировать планы запросов и искать пути оптимизации...Овчинка выделки не стоит, имхо
26. ivanov660 1150 20.04.19 09:36 Сейчас в теме
(21)Включенный журнал с хорошими фильтрами не создает ощутимой нагрузки (сама 1с говорит об этом и рекомендует его включать мониторинг производительности).
блокировки могут вам положить базу 3 апреля и до конца месяца вы не досидите - куй железо пока горячо.

Минимальные телодвижения и расход мозготоплива придется совершать и расходовать в любом случае.

Однако, если у вас нет необходимости в оценке и отслеживании как дела там у меня на проде и ждем когда гром грянет, это ваш выбор.
28. w.r. 210 21.04.19 20:20 Сейчас в теме
(26) лично я считаю, что чем меньше дополнительных вмешательств в систему - тем надежнее система. Найти и устранить большинство проблем можно не применяя костылей
29. Sergey.Noskov 1009 22.04.19 15:50 Сейчас в теме
(28) это не вмешательство, это контроль. Контроль должен быть всегда. С таким же успехом и тахометр в машине можно вмешательством в систему назвать.
37. ivanov660 1150 08.05.19 00:50 Сейчас в теме
(12)
(36) Уже залито в основную ветку. Читайте внимательнее:
"Как только будет доработана и согласована, то задача уйдет в основную ветку мастер."
11. acanta 48 18.04.19 15:31 Сейчас в теме
Насколько я помню в виндовс нт была возможность ограничить размер папки. Вероятно, если включается технологический журнал, администратор может добавить такое ограничение.
14. ivanov660 1150 18.04.19 16:12 Сейчас в теме
(11) В свойствах logcfg.xml есть свойство для сохраняемого лога history="число". По этим настройкам 1С удаляет устаревшие файлы самостоятельно, поэтому при более или менее стандартной ситуации прыгать размер папки с логами по объему не должны.
17. myxins1989 47 18.04.19 17:02 Сейчас в теме
Насколько знаю, Duration с 8.3.какой-то измеряется в микросекундах, 60000 - это 0.6 секунд, а не 60. Плюс с таким примером очень легко пропустить запросы, которые выполняются часто, но быстро, и могут давать львиную долю нагрузки.

Ошибки - штука полезная, но любое исключение, которое обрабатывается в попытке, будет валиться в журнал.

Еще бы неплохо мониторить вызовы - память, длительность. И ожидания на получение блокировки - TLOCK. Конфликт блокировок отлавливается в том же TLOCK, TTIMEOUT и TDEADLOCK, а не в исключениях.

Поверхностно, очень поверхностно...
18. ivanov660 1150 18.04.19 17:35 Сейчас в теме
(17)
1. Да, вы почти правы делить надо на 10 000, т.е. поправить надо на 600 000.
2. В текущем варианте система не предлагает полноценной замены Тест Центра, но даже текущих возможностей достаточно, чтобы получить определенного минимума информации, особенно актуально у кого нет ничего и для них ТЦ - это космос.
3. Для получения информации по вопросам про нагрузку и другие параметры системы у нас стоит Zabbix.
20. myxins1989 47 18.04.19 17:53 Сейчас в теме
(18)
1. Я полностью прав, микросекунд, 6 нулей плюсом. Пруф - https://its.1c.ru/db/metod8dev#content:5809:hdoc. Кстати, тут же написано, что надо писать Durationus
2. Тест центр применяется для нагрузочного теста, а не мониторинга. Наверное имелся ввиду ЦУП. При этом на двух сдачах на эксперта ни разу не получилось его настроить, и по ощущениям особо он бы не помог.
3. Говоря про память, я имел ввиду Memory и MemoryPeak в CALL. Но в этом предложении важнее суммарная длительность. Сталкивался с огромным отчетом в 400 Гб базе, 30 секунд выполнялся запрос на СУБД, 10-15 минут длился вывод на экран на стороне сервера. При этом улетает память, нагрузка на процессор.
24. PerlAmutor 35 20.04.19 06:30 Сейчас в теме
(0)
долгие запросы более 60с,

Поправьте logcfg.xml в статье. Во-первых он у меня не "взлетел", копировал из вашей публикации. Не знаю с чем это связано (может комментарии, может какие спец. символы в xml), но я настроил его по аналогии с нуля. Во вторых Вы указывается длительность запроса "60000", а это 6 секунд, а не 60. Надо добавить еще один ноль справа.

Кто мне скажет, есть ли обратная операция для Like в logcfg.xml, хочу сделать "Not Like", некоторые события в ТЖ нормальные, но их слишком много и они мне не нужны?
25. ivanov660 1150 20.04.19 08:54 Сейчас в теме
(24)
1. Поправил. Duration (в 10 000 долях секунды) использовалось до версии 8.3, но работает и видимо оставлено для совместимости. Изменил на рекомендуемое значение Durationus и значения в миллионных долях секунды. Пример: Мониторинг на серверах Durationus="20000000" это 20 секунд.
2. Не забывайте, что формат файла "logcfg.xml" нужно ставить в utf-8. Также если при вставке добавятся "левые" символы, то соответственно работать не будет.
3. Фильтр на исключения можно добавить на вкладке "Фильтры" замера в поле "Исключить" (по правилам RegExp). Пример:
,Descr=[\s\S]*(Сеанс отсутствует или удален|Текущему соединению с информационной базой не назначен сеанс|Требуется переустановка соединения)
. Исключит встречающиеся записи с информацией служебным по проблемам связанным с переустановкой сеансов.
new_user; +1 Ответить
27. PerlAmutor 35 20.04.19 15:00 Сейчас в теме
(25) Тут написано
1. Русские символы. Классика жанра — если в logcfg вы поставили русские символы в любом месте, кроме значений параметров, то ТЖ работать не будет.


http://1sprogress.ru/texnologicheskij-zhurnal-ot-a-do-ya.html

У Вас работает ТЖ с русскими комментариями?
30. user924776 22.04.19 17:51 Сейчас в теме
У вас проект рабочий? ошибки вылезают при обновлении базы, по типу:
Журнал процесса выполнения:
Ссылка на неизвестный метод - CommonModule.ОбновлениеДанныхРегламентное.АвтозагрузкаРегламентное
Ссылка на неизвестный метод - CommonModule.ОбновлениеДанныхРегламентное.УдалениеУстаревшихСобытий
РегламентноеЗадание.Автозагрузка - Имя метода должно быть задано
РегламентноеЗадание.УдалениеУстаревшихСобытий - Имя метода должно быть задано
ФункциональнаяОпция.ИспользоватьПолнотекстовыйПоиск - Не установлено Хранение функциональной опции
31. ivanov660 1150 22.04.19 18:04 Сейчас в теме
(30) Рабочий.
Обратите внимание, проект использует версию платформы 1С 8.3.12
32. user924776 22.04.19 18:21 Сейчас в теме
Да у меня установлена 8.3.12.1412
33. user924776 22.04.19 18:43 Сейчас в теме
Вопрос снят, разобрался.
34. capitan 1170 23.04.19 16:48 Сейчас в теме
Сравнение изменений двух периодов - со второго принтскрина, кому то получилось из ветки мастер загрузить ?
35. ivanov660 1150 23.04.19 17:14 Сейчас в теме
(34) Смотрите ветку Доработки по использованию доп обработок и отчетов
Как только будет доработана и согласована, то задача уйдет в основную ветку мастер.
36. aspirator23 392 07.05.19 09:09 Сейчас в теме
39. ivanov660 1150 08.05.19 22:31 Сейчас в теме
(36) ветка залита в мастер. все изменения уже доступны в основной ветке, а побочная удалена после слияния.
38. freelancer 93 08.05.19 15:13 Сейчас в теме
Доброго дня!

"Формат данных XML EDT версии (0.0.0) проекта 'parsing-tech-log' несовместим с текущей версией EDT (1.9.2).
Пожалуйста, сделайте реимпорт проекта из информационной базы".

Это при импорте проекта хоть с локально загруженного, хоть непосредственно с github.

Помогите разобраться, плз.
Прикрепленные файлы:
40. ivanov660 1150 08.05.19 22:36 Сейчас в теме
(38)Не встречалась подобного рода ошибка, могу предположить, что у вас старая версия EDT установите последнюю 1.10.2. В ней при переходе произошло изменение формата проекта и он может быть не совместим со старыми версиями.
Оставьте свое сообщение