Мониторинг системы Directum RX > Настройка решения

Типы ошибок задаются в конфигурационном файле exceptionType.yml сервиса Logstash. В поставку решения входит конфигурационный файл с типовыми настройками для мониторинга лог-файлов Directum RX. При необходимости задайте собственные настройки. Вы также можете настроить критичность ошибок для сервисов Ario.

ВАЖНО. После изменения конфигурационного файла 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: 'Отсутствует лицензия на модуль.'

СМ. ТАКЖЕ