Анализ ТЖ 1С с помощью ELK

В качестве исходной системы использовались сервер 1С на базе Windows с несколькими базами на СУБД Postgresql, стек ELK версии 6.5.4, развернутый в среде docker в виде контейнеров (https://github.com/deviantony/docker-elk). Подробнее о технологиях, примененных здесь для запуска ELK, можно посмотреть здесь. Все, что касается путей к файлам конфигурации приложений стека далее в статье следует отмерять относительно каталога, в котором находится файл docker-compose.yml

Событийный мониторинг — накопление и структурирование информации на основе записей о произошедших событиях. В этой статье речь пойдет о мониторинге состояния систем, в частности 1С, с помощью стека ELK, собирающего и анализирующего записи журналов. Пример полученных данных в графическом интерфейсе Kibana может выглядеть как на изображении. Если вам удалось после настройки конвейера днных получить у себя нечто похожее, значит у вас все получилось.

1С имеет два журнала — журнал регистрации и технологический журнал. Информация из обеих может быть полезна, как с точки зрения оперативного мониторинга, так и для аналитической работы. Здесь речь пойдет о мониторинге ТЖ — очень объемного журнала, содержащего в себе информацию о практически всех событиях, происходящих во время работы платформы 1С. Для работы стека понадобится полный технологический журнал за 1 час. Для запуска его сбора необходимо разместить файл logcfg.xml в каталоге c:\Program files\1cv8\conf со следующим содержимым:

Логи будут собираться с каталог C:\Log. Почему достаточно хранить логи всего за 1 час, что сильно снижает риск заполнения ими диска на сервере 1С, будет рассказано далее.

Сбор данных с помощью filebeat

Для передачи данных из файлов журналов в logstash при меняется filebeat. Он представляет собой службу, конфигурируемую с помощью yml файла, постоянно перечитывающую указанные в конфигурации журналы. Filebeat также запоминает до какой строки дочитан каждый журнал и при следующих чтениях передает появившиеся данные. В случае с ТЖ 1С необходимо настроить в filebeat многострочные события чтобы правильно получать события, содержащие запросы или контексты.
Дистрибутив filebeat нужной версии (версии компонентов ELK должны совпадать) необходимо взять с сайта https://www.elastic.co. После его установки на сервере 1С появится служба filebeat. Во избежиние проблем с блокировкой файлов журналов имеет смысл сразу настроить задание, перезапускающее службу раз в пару часов, это позволит устаревшим файлам журналов беспрепятственно удалиться службой кластера 1С.

В файле конфигурации filebeat.yml необходимо выполнить настойку источника данных, многострочность, тип и координаты получателя. Секция inputs должна принять следующий вид:

filebeat.inputs:
- type: log
multiline.pattern: '^[0-9]{2}:[0-9]{2}.[0-9]{6}'
multiline.negate: true
multiline.match: after
enabled: true
paths:
c:\log**.log
tags: ["onec"]

Обработка данных с помощью logstash

Главная задача logstash — разбор полученного события на составляющие его поля. Это позволит в дальнейшем работать с длительностью событий, их типами, пользователями и многим другим. Также необходимо, чтобы дата появления события бралась из записи журнала, а не создавалась в момент прибытия события в elasticsearch. В связи с особенностями записи времени события в ТЖ 1С, часть времени нужно взять из имени файла, а часть из самого журнала, объединить в одно поле и разобрать с помощью фильтра date.
Для конфигурирования logstash необходимо подключиться к узлу, на котором он работает и редактировать файл logstash/pipeline/logstash.conf. В нем потребуется описать входной поток, фильтры и получателя выходного потока данных.
Для модификации полей событий применяется плагин grok. Он позволяет находить входждения подстроки в событие по регулярным выражениям и сохранять результат в отдельное поле.
Фильтр mutate позволяет создать синтетическое поле, состоящее из двух ранее созданных полей — часа и дня, и внутричасового времени, взятых из имени файла и журнала плагином grok.
Фильтр date формирует время события по полученному ранее полю со временем.

input{
beats {
port => 5000
}
}
filter {
if "onec" in [tags] {
grok {
patterns_dir => ["/usr/share/logstash/pipeline/patterns"]
match => { "message" => "%{TIME:MoH}[0-9]{3}-%{DURATION:Duration_msec:int},%{TYPE:Event_type},%{NESTING:Nesting_level:int}" }
match => { "message" => ",process=%{PROCESS:process}" }
match => { "message" => "p:processName=%{PPROCESSNAME:pprocessname}" }
match => { "message" => "t:applicationName=(?[A-Za-z]+),"}
match => { "message" => "Usr=(?.?),"} match => { "message" => "Regions=(?.?),"}
match => { "message" => "Locks='(?.?)',"} match => { "message" => "WaitConnections=(?.?),"}
match => { "message" => "Context='(?.+?)'"}
match => { "message" => "Descr='(?.+?)'"}
match => { "source" => "(?[0-9]{8}).log"}
break_on_match => false
}
mutate {
add_field => { "MyTime" => "%{DaH}%{MoH}" }
}
date {
match => ["MyTime", "yyMMddHHmm:ss.SSS"]
target => "@timestamp"
}
}}
output {
if "onec" in [tags] {
elasticsearch {
index => "onec-%{+YYYY.MM.dd}"
hosts => "elasticsearch:9200"
}
}
}

В качестве выхода описан сервер elasticsearch. Его рассмотрение выходит за рамки статьи, так как в данном случае с ним ни чего не требуется делать. Следует только упомянуть, что он хранит полученные на этом этапе данные в виде индексов (indices), в формате json. После того, как данные попали в elasticsearch, можно заходить в веб-интерфейс Kibana и заниматься из анализом — строить различные визуализации, выявлять закономерности и аномалии.

Анализ данных в Kibana

Теперь можно зайти в веб-интерфейс и проверить наличие данных. Если все сделано правильно, то в Kibana можно будет увидеть индекс onec-* и добавить его для анализа. В этом примере хост с запущенным приложением называется kibana, поэтому вход выполняется на http://kibana:5601 Kibana не имеет встроенных средств авторизации, поэтому если она нужна, ее необходимо настроить внешними средствами. После входа необходимо перейти в раздел Management и выполнить Create Index:

После простого диалога определения паттерна имени индекса и поля с временной меткой индекс будет добавлен и данные станут доступны для анализа и визуализации. Увидеть данные можно в разделе Discover:

Теперь, если все сделано правильно, есть возможность с молниеносной скоростью анализировать весь объем данных ТЖ. Самое большое, что было необходимо анализировать автора, составляло около 4 миллионов событий в час и анализ такого объема событий за день не заставил мучаться ожиданием между выполнением отборов данных благодаря эффективности хранения и поиска данных в Elasticserarch.

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

Количество исключений в разрезе пользователей:

Контексты исключений, ранжированные по количеству возникновения этих событий:

А на этом графике контексты ранжированы по количеству возникновения в них исключительных ситуаций у конкретных пользователей:

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

Для получения исчерпывающей информации о возможностях Kibana настоятельно рекомендую посетить сайт производителя https://www.elastic.co/products/kibana

Оповещение и обслуживание

Оповещение возможно в платной версии Kibana, либо с помощью приложения Ellast Alert. Это не плагин, а именно отдельное приложение, выполняющее запросы к elasticsearch и принимающее решение на основании их результатов результатов. Его рассмотрение немного выходит за рамки этой статьи, но описание его применения обязательно появится на сайте.

Для обслуживания, а именно, удаления устаревших данных следует применять приложение Curator. Это также отдельное приложение, суть которого заключается в выполнении запроса к Elasticsearch на удаление индекса определенного возраста по расписанию. Подробнее о его установке и настройке можно прочитать здесь