Мониторинг, CMDB и удовольствие от работы

workerВсем нам нравится время от времени переключаться на другую деятельность. Для меня большое удовольствие – иногда нырнуть в техническую работу, которую «настоящему консультанту» вроде бы и делать не пристало. Так, иногда на две-три недели приходится переключаться на программирование при выпуске новой версии CleverENGINE. А на этой неделе я занимался подготовкой к курсу по программированию OMNITRACKER, который мне предстоит вести в ноябре, и настройкой мониторинга внутренней инсталляции OMNITRACKER, обеспечивающей автоматизацию наших бизнес-процессов. Братцы, какое же это удовольствие!

Последний раз я занимался администрированием серверов году в 2002-м. С тех пор очень многое изменилось. В частности, появились новые средства мониторинга, а на смену широко распространенному в те годы WSH пришел PowerShell. Вот с этими делами я и разбирался. В качестве основы для мониторинга мы выбрали PRTG – это решение вполне функционально, а на наших масштабах к тому же еще и бесплатно. Помимо традиционных источников данных (типа SNMP, WMI, Performance monitor, текстовых логов, Windows event log’ов, syslog’а и прочих) этот продукт умеет использовать в качестве сенсоров произвольные скрипты SQL, VBS, PowerShell. С PowerShell пришлось немного повозиться, но так как обычный shell в прошлой жизни я использовал весьма активно, понимание базовых возможностей пришло довольно быстро. Просто удивительно, что можно сделать одной строчкой кода с применением конвейеризации и возможностей среды .NET. Теперь мы контролируем такие вещи, как размер исходящей почтовой очереди Omni, потребление лицензий Omni, свободное место на ftp-сервере, который используется для удаленного хранения оперативных резервных копий, и многое другое.

prtg

Но в реальной корпоративной среде – сотни серверов, приложений, баз данных, сетевых каналов. И если компания серьезно относится к мониторингу, появляется множество диагностических скриптов, которые а) жаль и дорого терять, б) надо уметь обновлять и при появлении их новых версий (ведь они могут использоваться на разных узлах), и при изменении самих объектов мониторинга. Опыт показывает, что эти задачи здорово помогает решать CMDB – она может хранить и сами «пробники», и связи с объектами мониторинга для корректного обновления. В далеком 2008 году мы занимались этим с BSGV, а с тех пор мне пока не попадались компании, дозревшие до такого учета. А может быть, просто теперь соответствующий учет может обеспечить непосредственно инструментарий мониторинга, взяв часть функций CMDB на себя?

ITIL Expert Уверенная дорога до ITIL Expert
 

Экономия на обучении до 30% для тех, кто хочет быстро добраться до высшей ступени в ITIL
 

Узнайте больше!

Комментарии и мнения

  1. Альберт

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

    По OMNITRACKER есть такой пример

    1. Илья Рунов

      1 О, Роскомнадзор снова отличился. Закрыл ссылку "пример".

      2 Не согласен с тем,что проблема "мониторинга" — это _всегда_ проблема Заказчика, а не внедряющей компании. Поясню мысль. Заказчик не всегда обладает достаточной экспертизой, чтобы, не зная досконально внутреннюю архитектуру "решения" целиком и приложения в частности, правильно спроектировать "сенсоры" и "источники данных". Прошу обратить внимание: проектировать, не значит реализовывать мониторинг через программные средства Заказчика. 

        1. Илья Рунов

          Я не совсем точно выразился. РКН+МТС чудит. Т.е. результат от провайдера зависит. РКН только публикует ссылки. МТС их "грамотно" блокирует на соответствующем оборудовании. Ранее я такую же ситуацию с github ловил.

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

    2. Дмитрий Исайченко Автор

      Альберт, спасибо за ссылку — интересная инфа, раньше не видел. Только это итеграция Omni с мониторингом и инвентаризацией инфраструктуры (регулярно делается в проектах), а я делал более "мелкую" вещь — настраивал мониторинг самого Omni.

  2. Андрей Вишняков

    >просто теперь соответствующий учет может обеспечить непосредственно инструментарий мониторинга, взяв часть функций CMDB на себя?

    конечно, как вариант, аналог ресурсно-сервисной модели (связь компонент ИТ инфраструктуры с ИТ-услугами) реализован в системе мониторинга в виде "моделей здоровья" по каждой ИТ-услуге (при этом, дерево по отдельной услуге может быть очень сложным, с правилами наследования алертов с нижележащих уровней наверх до корневого объекта ИТ-услуги в своей модели здоровья, сложные проверки и многообразие синтетических тестов, заложенных в модель здоровья ИТ-услуги сводятся к бинарному пониманию операционного состояния корневого объекта мониторинга ИТ-услуги — "зеленая"/ "красная")

     

    1. Дмитрий Исайченко Автор

      Андрей, это мне понятно, этот функционал есть уже давно (например, в MOM'е, который теперь называется SCOM'ом, он есть еще с 2004 года, а в OVO, насколько я помню, он был еще раньше). Но я немного не о том, а о контроле версий диагностических скриптов и об отслеживании привязки тех или иных скриптов к объектам мониторинга.

  3. Илья Рунов

    Теперь мы контролируем такие вещи, как размер исходящей почтовой очереди Omni, потребление лицензий Omni, свободное место на ftp-сервере, который используется для удаленного хранения оперативных резервных копий, и многое другое.

    Дмитрий, а размер входящей очереди писем контролируете, дабы понять, успевает ли продукт ее обрабатывать/конвертировать в обращения?

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

НОЯ
19
Учебный курс:
Основы ITIL (очно)