Quis custodiet ipsos custodes?

Это первая статья в серии, рассказывающей о построении своими руками системы мониторинга рассчитанной на большой поток событий.

Немного теории для начала

Согласно WIKI:

Мониторинг — процесс систематического или непрерывного сбора информации о параметрах сложного объекта или процесса.

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

Качество работы любой системы мониторинга определяется тремя основными показателями :

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

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

Есть еще один, неофициальный показатель — степень доверия. Это то, на сколько доверяют системе мониторинга операторы. 🙂

В повседневной работе у нас много самых разных систем мониторинга — специфика такая. Это и традиционные, ставшие стандартом системы (HP OpenView, NetCool), и специфичные системы поставляемые вендорами телекоммуникационного оборудования, и собственные разработки.

И в большинстве из них можно выделить три основных части системы мониторинга:

• Объекты мониторинга. Агенты, собирающие аварии. Другие системы, интегрированные с рассматриваемой.
• Собственно сервер системы мониторинга.
• Аларм-терминалы, средства извещения и нотификации.

В разных системах мониторинга все вышеперечисленное может быть реализовано совершенно поразному. Но эти три части (с поправкой на реализацию) можно выделить всегда. Поговорим о каждой из них подробнее.

Объекты мониторинга — это чаще всего сложные критичные системы (иначе не было бы нужды в слежении за их состоянием) и очень часто включают в себя собственные средства диагностики. Исходя из этого агенты чаще всего представляют из себя анализаторы log’ов и разборщики printout’ов команд диагностики, которые перобразуют данные об объекте мониторинга и генерируют на основе этих данных события.

Эти события обрабатывает сервер системы мониторинга. В самом простом случае — сохраняет записи о событиях в журнал. Но оснавная задача — известить о событии оператора.

Вообще говоря стандартные требования к системам мониторинга в крупных компаниях — это увесистый том (а иногда и не один) по объему сопоставимый c ITIL/ITSM . Но если в кратце система мониторинга должна быть:

• Надежной — поддерживать дублирование и резервирование, проверку и перепроверку данных. Но при этом достаточно
• Простой. В противном случае снижается надежность и может получиться так, что понадобится система мониторинга для системы мониторинга :-).
• Безопасной. Система мониторинга обязательно должна поддерживать разграничение прав пользователей и максимально подробно фиксировать действия выполняемые оператором в рамках этой системы. Чем подробнее фиксируются действия оператора — тем лучше (в том числе и для самого оператора).

Как всегда чем-то ради чего-то приходится жертвовать, например — приходится усложнять систему для того, чтобы интегрировать ее с системой инцедент-менеджмента или с какими-либо информационными системами.

Это требования к системе вцелом. К ним добавляются требования к пользовательским интерфейсам, API и прочим «регламентам взаимодействия» 🙂 .

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