Всем нам нравится время от времени переключаться на другую деятельность. Для меня большое удовольствие – иногда нырнуть в техническую работу, которую «настоящему консультанту» вроде бы и делать не пристало. Так, иногда на две-три недели приходится переключаться на программирование при выпуске новой версии CleverENGINE. А на этой неделе я занимался подготовкой к курсу по программированию OMNITRACKER, который мне предстоит вести в ноябре, и настройкой мониторинга внутренней инсталляции OMNITRACKER, обеспечивающей автоматизацию наших бизнес-процессов. Братцы, какое же это удовольствие!
Последний раз я занимался администрированием серверов году в 2002-м. С тех пор очень многое изменилось. В частности, появились новые средства мониторинга, а на смену широко распространенному в те годы WSH пришел PowerShell. Вот с этими делами я и разбирался. В качестве основы для мониторинга мы выбрали PRTG – это решение вполне функционально, а на наших масштабах к тому же еще и бесплатно. Помимо традиционных источников данных (типа SNMP, WMI, Performance monitor, текстовых логов, Windows event log’ов, syslog’а и прочих) этот продукт умеет использовать в качестве сенсоров произвольные скрипты SQL, VBS, PowerShell. С PowerShell пришлось немного повозиться, но так как обычный shell в прошлой жизни я использовал весьма активно, понимание базовых возможностей пришло довольно быстро. Просто удивительно, что можно сделать одной строчкой кода с применением конвейеризации и возможностей среды .NET. Теперь мы контролируем такие вещи, как размер исходящей почтовой очереди Omni, потребление лицензий Omni, свободное место на ftp-сервере, который используется для удаленного хранения оперативных резервных копий, и многое другое.
Но в реальной корпоративной среде – сотни серверов, приложений, баз данных, сетевых каналов. И если компания серьезно относится к мониторингу, появляется множество диагностических скриптов, которые а) жаль и дорого терять, б) надо уметь обновлять и при появлении их новых версий (ведь они могут использоваться на разных узлах), и при изменении самих объектов мониторинга. Опыт показывает, что эти задачи здорово помогает решать CMDB – она может хранить и сами «пробники», и связи с объектами мониторинга для корректного обновления. В далеком 2008 году мы занимались этим с BSGV, а с тех пор мне пока не попадались компании, дозревшие до такого учета. А может быть, просто теперь соответствующий учет может обеспечить непосредственно инструментарий мониторинга, взяв часть функций CMDB на себя?
В целом лучше отдавать такие вещи во вне. Поскольку у каждой внешней компании свои средства мониторинга для своих сервисов, как и чем они будут это контролировать и обеспечивать отчетность, это их проблема.
По OMNITRACKER есть такой пример