<< Click to Display Table of Contents >> Мониторинг системы Directum RX > Настройка решения Типы ошибок |
Типы ошибок задаются в конфигурационном файле exceptionType.yml сервиса Logstash. В поставку решения входит конфигурационный файл с типовыми настройками для мониторинга лог-файлов Directum RX. При необходимости задайте собственные настройки.
ВАЖНО. После изменения конфигурационного файла exceptionType.yml перезапустите сервис Logstash, чтобы настройки применились.
Настройки задаются в формате YAML. Структура конфигурационного файла:
{Имя сервиса}
{Тип ошибки}
{Описание ошибки}
- exception: {Тип исключения}
message: {Текст ошибки}
genericMessage: {Обобщенное сообщение}
stackTrace: {Стек ошибки}
Имя сервиса Directum RX, указанное в имени соответствующего лог-файла. Названия сервисов необходимо указывать с учетом регистра символов. В стандартной поставке используются значения:
•Nomad – сервис NOMAD;
•SungeroServer – сервер приложений;
•WebClient – веб-клиент;
•WebServer – веб-сервер;
•WebAgent – Агент веб-доступа;
•workflow – служба Workflow.
Тип ошибки. По умолчанию возможны значения:
•critical – критичная ошибка;
•noncritical – некритичная ошибка.
При необходимости администратор может задать собственные типы ошибок.
Примечание. Если найденная ошибка не относится ни к одному из заданных типов, ей присваивается тип unknown. В этом случае на дашборде она отображается как неизвестная.
Описание ошибки. Состоит из полей:
•exception – тип исключения;
•message – текст ошибки;
•genericMessage – обобщенный текст ошибки. Представляет собой текст ошибки без идентификаторов объектов и привязки к пользователям;
•stackTrace – стек ошибки.
Поля настройки Описание ошибки необязательны для заполнения. Если поле не заполнено или указаны символы «’*’», то совпадение считается найденным при любом значении.
В качестве значения полей можно указывать регулярное выражение в формате Ruby. В этом случае строка должна начинаться с «(regex)». Подробнее о регулярных выражениях см. на сайте Rubular.
Если нужно изменить типы ошибок, заданные в файле exceptionType.yml:
1.Перейдите на сайт панели управления Kibana по ссылке http://<IP-адрес сервера>:5601.
2.В поисковой строке введите запрос «exceptionRuleMatching: *».
В результатах поиска отображаются записи с условием, по которому сработала ошибка. Если тип ошибки не задан (unknown), то вместо условия отображается значение empty.
3.При необходимости измените настройки типов ошибок, задайте их для неизвестных и удалите неактуальные в файле exceptionType.yml.
Пример. Настройка типа ошибок в конфигурационном файле
Постановка задачи:
1.Все ошибки с текстом сообщения «Module cover is not available. Reason: Module has no items» считать критичными. Остальные поля могут быть любыми.
2.Ошибки AccessDeniedLicenseException считать некритичными, если в тексте ошибки встречается подстрока «RxServer.Nomad.Host.Core.Infrastructure.CommonSoapMiddleware».
Решение:
WebServer:
critical:
- message: 'Module cover is not available. Reason: Module has no items'
noncritical:
- exception: 'AccessDeniedLicenseException'
message: 'Отсутствует лицензия на модуль.'
© Компания Directum, 2024 |