Следим за здоровьем NOMAD. Часть вторая

По теме мониторинга систем написано уже бесчисленное количество статей, как на клабе, так и на просторах интернета. Цель данной статьи не дублировать все уже написанное, а акцентировать внимание на применимости данных систем к мониторингу сервера NOMAD.

Для того чтобы правильно мониторить сервер NOMAD нужно разобраться что это вообще такое и какие функции выполняет. Итак, NOMAD это веб-сервис, обеспечивающий взаимодействие мобильных клиентов с ECM-системами, причем NOMAD обеспечивает возможность работы мобильных приложений в оффлайн режиме. К сервису клиенты обращаются по протоколу SOAP, вызывая какие-либо методы, а за безопасность обмена отвечает протокол https.

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

Отслеживаем доступность

Так как NOMAD это веб-сервис, логично отслеживать его доступность. Тут нужно выбрать какой-нибудь метод, который не будет сильно нагружать систему, но в то же время будет выполнять бизнес -логику (недостаточно просто пинговать сервис, необходимо получить корректный ответ, чтобы определить, что сервис действительно функционирует нормально). Например, можно вызывать метод IsSessionEstablished сервиса Session.asmx. Метод внутри очень простой и какой-либо нагрузки на сервер создавать не будет. В качестве ответа метод возвращает информацию о том, подключен ли текущий пользователь или нет, результат ответа в данном случае значения не имеет, если ответ пришел – значит сервис работает корректно.

Для выполнения метода и уведомления администратора можно использовать SCOM или Zabbix (да хоть в powershell скрипт написать и назначенным заданием вызывать). Т.к. для безопасности запрещается использование GET-запросов необходимо использовать POST. В идеале, запрос нужно выполнять так же, как и мобильный клиент, например, если в организации настроена DMZ, то обращение к сервису нужно выполнять снаружи, для того, чтобы гарантированно отловить все возможные проблемы.

Сертификаты шифрования

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

Проверки для поддержки офлайн-режима

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

1. Пользователь выполняет вход с мобильного устройства.
2. NOMAD создает сессию пользователя и сохраняет ее.
3. NOMAD выполняет построение списка объектов необходимых пользователю, проверяя появились ли новые, удаленные или измененные и отдает их клиенту.
4. С заданной периодичностью NOMAD проверяет изменения объектов и сообщает об этом клиенту.

Из описания следует, что для того чтобы на клиенте всегда были свежие данные необходимо чтобы NOMAD проверял изменения и отправлял информацию на мобильные клиенты. Поэтому в список проверок можно добавить проверку количества подключенных пользователей, ведь если пользователей 0, значит данные на всех клиентах неизбежно устареют и важные задания не будут просмотрены в срок.

Количество подключенных пользователей фиксируется в лог-файл performance. <текущая дата>.log, для парсинга можно использовать Elastic Stack (для загрузки логов в реальном времени можно использовать filebeat) или настроить nlog (используется для логирования в NOMAD) для отправки письма администратору.

Своевременность доставки актуальных данных

Основной ролью сервиса является отслеживание изменений и доставка объектов на мобильные устройства. Если эта функциональность будет нарушена работа в мобильном клиенте будет бессмысленна. Для своевременной доставки актуальных данных должно быть соблюдено 2 условия:

1. NOMAD корректно выполнил поиск изменений объектов. Поиск изменений выполняет метод FillScope, отследить корректность его выполнения можно по серверному логу.
2. Все измененный объекты без ошибок отправлены на клиента. Для получения объектов клиенты вызывают метод GetObjects, корректность его выполнения так же можно смотреть в логе server. <текущая дата>.log

Для парсинга логов в реальном времени можно использовать Elastic Stack. Для периодического отслеживания ошибок отлично подойдет AppHealth.

Проверка физических ресурсов

Даже самый надежный сервис может упасть, если ему не хватит физических ресурсов, поэтому нужно следить за основными показателями сервера:

1. Оперативная память
2. Процессор
3. Жесткий диск

За большей частью параметров можно следить в логе performance.<текущая дата>.log, также тут можно использовать описанные выше SCOM, Zabbix или Elastic Stack.

Серверные логи

Так как NOMAD выступает посредником между ECM-системой и мобильным клиентом, ошибки могут возникать и в прикладном коде. Подобные ошибки нужно искать в серверном логе. Например, при возникновении ошибок в прикладном коде системы DIRECTUM с большой вероятностью в логе будет фигурировать ошибка ComException.

Сертификаты ApplePush

Для отправки информации об изменениях NOMAD использует push-уведомления. Зачастую, это практически единственный вариант обновления данных на iOS клиентах. Для работы push-уведомлений на сервере NOMAD должны быть установлены сертификаты ApplePushProductionJazz.p12 и ApplePushProductionSolo.p12 (входят в поставку и находятся в папке app_data/certificate). Эти сертификаты так же имеют срок действия, за которым нужно следить (не так критично, конечно, как за сертификатами из пункта 2). При возникновении каких-либо проблем с этими сертификатами соответствующая информация будет зафиксирована в серверном логе (Push. <сообщение об ошибке>).

* * *

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

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