Мониторинг системы DirectumRX: настраиваем прикладное логирование

С версией 3.2 вышло новое решение для мониторинга системы DirectumRX. Решение собирает данные из лог-файлов системы DirectumRX и значения счетчиков производительности операционной системы. Полученные результаты помогают наглядно оценить стабильность развернутых сервисов, загрузку процессора, состояние оперативной памяти и т.д.

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

Администратор контролирует состояние системы с помощью дашбордов – рабочих областей на странице решения. На дашборде размещаются панели, на которых выводятся метрики.

По умолчанию решение обрабатывает стандартные лог-файлы системы. При этом в прикладной разработке могут быть заданы действия, которые тоже полезно отслеживать. Например, выполнение автоматического импорта пользователей из Active Directory. Для этого с помощью среды разработки DirectumRX нужно добавить логирование в программный код.

Решение «Мониторинг системы DirectumRX» работает со структурированными данными. За хранение, индексирование и поиск данных отвечает поисковая система Elasticsearch, входящая в состав решения. Чтобы решение могло обработать данные, лог-файл нужно вести в структурированном виде. В статье расскажем, как это сделать.

Формат сообщения в лог-файле

Для быстрого и корректного распознавания метрик в решении используется формат JSON:

JSON: {"имя_метрики": "значение_метрики"}

Например, веб-агент записывает в лог-файл сообщения вида:

2019-09-06 10:16:00.000+04:00 5.8.1.9001 Info log_native_proxy:69 JSON: {"extension_str":"XMIND","operation":"OpenDocument","plugin_str":"DocumentProcessObserverPlugin","size_KB_int":789} [Domaint\Ivanov_II :RX[DirRX]]

JSON-объект, содержащийся в сообщении, отправляется в Elasticsearch как структурированный объект. Решение собирает информацию из полей объекта и выводит результаты на дашборде.

Аналогичные сообщения можно формировать из прикладной разработки DirectumRX. Для этого должны быть выполнены условия:

1. Строка, заключенная в фигурные скобки, должна быть валидным JSON-объектом. Это можно проверить в любом онлайн-парсере JSON. Например, здесь.
2. У строки сообщения должен быть префикс «JSON:».
3. Если метрика используется как число, то ее нужно записывать без кавычек: {"my_number_int": 255}. Пример такой метрики – размер документа.
4. Если число используется только для группировки или поиска, а не для арифметических операций, то число лучше записать как строку. Например, если ИД объекта – число, то его лучше записать как строку: {"rule_id_str": "65"}. Это связано с тем, что поиск и группировка по ИД используются на практике, а сложение значений ИД – нет.
5. Для идентификации объекта рекомендуется фиксировать его ИД, а не наименование. Это связано с тем, что наименование может содержать конфиденциальную информацию. Кроме того, если пользователи переименовывают объект, его нельзя найти по лог-файлу.
6. Рекомендуется использовать постфиксы, чтобы однозначно определить, с каким типом данных хранить значение в Elasticsearch. Также это позволяет разграничить поля со схожими названиями. Например, если поле называется fact, то легко перепутать, какие данные в нем хранятся: строковое имя фабрики или число отработанных часов по плану. Тип полей fact_str и fact_int перепутать сложнее.

Для наиболее распространенных параметров рекомендуется использовать предопределенные поля:

• operation – название операции, тип данных – строка;
• duration – длительность операции, тип данных – число;
• message – сообщение, заданное прикладным разработчиком, тип данных – строка. Если прикладной разработчик не задал сообщение, то в поле записывается исходное сообщение лог-файла.

Поддерживаемые постфиксы

• _byte – байт, целое число от 0 до 255. Рекомендуется использовать, если число не выходит за пределы байта. Это позволяет экономить место в Elasticsearch;
• _date – дата;
• _dbl – дробное число;
• _int – целое число;
• _str – строка до 8000 символов. Если у строки не указан постфикс, то она по умолчанию определяется как строка с постфиксом _str;
• _text – строка более 8000 символов. Как правило, в сообщении лог-файла не требуется фиксировать такое большое количество символов, поэтому используется редко. По полю с этим постфиксом нельзя группировать текст.

Ограничения

Есть предопределенные поля, которые нельзя использовать, так как они определяются автоматически:

• serviceName – имя сервиса, который пишет данный лог-файл;
• user – имя пользователя;
• tenant – имя тенанта;
• logLevel – уровень логирования;
• source – исходный путь к файлу с логом;
• processId – ИД процесса;
• threadId – ИД потока;
• host – имя или IP-адрес хоста;
• @timestamp – время записи лог-файла;
• @version – версия сервиса;
• fields.rx_server – имя сервера. Поле заполняет сервис Filebeat;
• createdTimestamp – время создания записи в Elasticsearch.

Чтобы использовать поле с похожим наименованием, необходимо к названию поля добавить постфикс. Например, вместо user можно использовать user_str.

Пример настройки

В качестве примера покажем, как можно расширить возможности решения «Интеграция с Active Directory». Чтобы отслеживать, как выполняется автоматический импорт, в лог-файл будем записывать факт начала и завершения импорта, количество импортированных пользователей и возникших ошибок.

В программный код решения добавим логирование:

Logger.Debug("JSON: { \"operation\": \"Import started.\" }");
Logger.DebugFormat("JSON: {{ \"operation\": \"Import finished.\", \"SavedCount\": {0}, \"ErrorCount\": {1}}}", employees.Count - errorCount, errorCount);

В результате в лог-файл записываются сообщения:

2019-09-16 10:00:04.548+04:00 3.2.0.0000  13016+28 Debug Sungero.Core.Logger -  JSON: { "operation": "Import started." }  [Administrator :DirServ]
2019-09-16 10:00:05.126+04:00 3.2.0.0000  13016+28 Debug Sungero.Core.Logger -  JSON: { "operation": "Import finished.", "SavedCount": 2, "ErrorCount": 0}  [Administrator :DirServ]

В данном случае выполняются серверные вычисления, поэтому сообщения фиксируются в лог-файле сервера приложений.

В решении «Мониторинг системы DirectumRX» создадим дашборд, который в наглядном виде выводит количество импортированных пользователей и возникших ошибок. В качестве параметров поискового запроса дашборда укажем уровень логирования Debug, имя сервиса WebServer и операцию Import finshed. Подробную информацию, как создать дашборд, см. в документации решения.

На скриншоте видно, что в указанное время импортировались 24 пользователя и возникли 2 ошибки.

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

* * *
Ждем ваши вопросы и комментарии!