Реализация структурированного логирования и использование решения Мониторинг Directum RX

Предпосылки

При внедрении системы у крупного Заказчика в процессе исследования и планирования его будущей инфраструктуры (отказоустойчивый кластер + горизонтальное масштабирование) в сочетании с пониманием планируемой интеграции, дальнейшей ее отладки на этапах ОПЭ и сопровождении пришло понимание, что обычные инструменты и подходы для анализа логов на предмет появления ошибок становится более трудоемкими и выглядят неприменимыми. В связи с этим требуются новые подходы для анализа.

Окружение

Для понимания кейса начнем с описания окружения, которое сформировано у Заказчика на проекте: система установлена в отказоустойчивом кластере и горизонтально масштабирована, т. е. сервисы распределены на 4-х нодах. Нас интересует именно порядок и количество логов, формируемых службами, а именно сервиса интеграции и сервиса асинхронных событий. Исходя из параметров настроенной инфраструктуры службы пишут логи сразу в 8 файлов в разных местах.

Также необходимо взглянуть на объемы интеграции. Реализована интеграция с шиной данных со следующими объектами и количеством данных:

• Подразделения – 4200
• Должности - 9500
• Организаций и банков – 60000
• Физические лица – 90000
• Сотрудники - 21700

Интеграция выполнена с асинхронной обработкой запросов – участвует Сервис интеграции и Сервис асинхронных событий.

Потребность

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

В дополнение уточним, что для анализа логов требуется скачать эти файлы, что уже может занять 20-30 минут, а далее предстоит поиск нужной информации среди сотен тысяч записей в нескольких лог файлах. При этом у Заказчика закрытый контур , доступа к системе нет, таким образом все файлы буду передаваться через облако или почту. Эти нюансы значительно затрудняют своевременное обнаружение проблем.

Учитывая высокие требования к надежности и техническому обслуживанию системы, а также большой объем передаваемых данных, было принято решение унифицировать логи для всех интеграционных потоков и привести их в структурированный вид для фиксации этой информации в логах. Что позволит в  дальнейшем их использовать в решении «Мониторинг Directum RX» для построения наглядных графиков и дашбордов.

Реализация

Перейдем к описанию структур и методов.

При разработке структурированных логов ключевым этапом стало выделение информации, значимой для анализа, которая будет однотипной во всех случаях передачи данных, что позволило создать переиспользуемую структуру логов (log) (см. рис. 1).

Значения свойств функций, операций и типы идентификаторов сущностей, используемые в процессе, были определены в качестве констант и подставлялись в зависимости от контекста использования.

Рисунок 1. Код описания структуры

Для структуры были выделены следующие объекты:

• Функция
• GUID обмена
• Операция
• Идентификатор сущности
• Текст ошибки
• Трассировка

В элемент структуры «Функция» помещаются названия методов интеграций (для логов сервиса интеграции) или названия асинхронных обработчиков (для логов асинхронных событий).

В элемент структуры «Операция» помещаются действия, которые выполняются при обработке сущности, такие как сохранение, проверка блокировки, отправка ответа в шину и т.д.

Элемент структуры «Идентификатор сущности» представляет собой объект типа Dictionary, где ключом выступает тип идентификатора (например, табельный номер для сотрудника или название для подразделения), а значением — сам идентификатор (например, табельный номер или наименование подразделения). Это позволяет наглядно отображать в логах именованные идентификаторы, характерные для конкретного типа сущности или обработчика.

Рисунок 2. Пример сформированной записи для лога

Настройка решения «Мониторинг Directum RX»

После реализации логирования для интеграции следующим этапом было обработка всех накопившихся логов и событий и представления их в виде визуальных графиков и дашбордов. При первоначальной настройке возникли проблемы с тем, что компоненты решения «Мониторинг Directum RX» обрабатывает не все данные из логов, и в конфигурационных файлах компонент понадобились дополнительные настройки для постройки внутренних индексов.

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

В итоге получили следующие дашборды описанные ниже.

Обобщенный дашборд для администратора. 

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

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

Дашборд для разработчиков

Предназначен для тех, кто понимает работу интеграции и могут проанализировать ошибки. Разделен на 3 части. 

2.1. Статистика по сервису интеграции.

На дашборде можно увидеть общее количество запросов, запусков асинхронных обработчиков и ошибок, общих и в разрезе сущностей и сервисов. По графику можно быстро перейти в нужный промежуток и увидеть в какой момент была нагрузка. Если ошибок или расхождений по количеству запросов и запущенных АО нет, то дальше ошибок по обработке нет.

2.2. Статистика по асинхронным обработчикам по обработке сущностей

На дашборде представлена информация в разрезе сущностей по количеству обработок в общем, успешных обработок и обработок с ошибкой. Если есть ошибки, то разработчик смотрит по таблице и разбирает каждый случай в отдельности по message, в котором сказано о причине ошибки и messageGuid для нахождения связи в шине данных.

2.3.Статистика по ответам в шину данных

На дашборде представлено количество асинхронных обработчиков, которые должны были отправить ответ, и какие ответы у нас были с ошибкой. Новое значение «Неотправленные ответы» показывает ошибки именно в асинхронных обработчиках по отправке. Зачастую ошибки связаны с недоступностью шины данных или схожими причинами. Возможно надо заново отправить результат обработки, чтобы шина нам повторно его не отправляла.

Также есть список с ошибками по этому асинхронному обработчику, где можно подробно разобрать из-за чего не удалось успешно завершить выполнение асинхронного обработчика. 

Заключение

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

Ключевые результаты

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

Преимущества:

Перспективы развития