Inventory Monitoring System или CMDB на коленке

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

    В одно прекрасное утро я получил довольно внушительный «втык» от руководства за неожиданно ставший неработоспособным компьютер главного бухгалтера. Ничего экзотического – неожиданно закончилось место на системном диске. ОС «упала» и отказалась подниматься самостоятельно. Быстренько устранив инцидент, я подумал, неплохо бы было получать информацию о том, что тот или иной пользователь заполонил своими фотками весь диск C немного раньше, чем откажет его компьютер.

    image

    Я написал и запустил с помощью Task Sheduler-а на одном из серверов несколько простеньких скриптов на VBS, которые регулярно подключались к рабочим станциям пользователей по WMI и собирали информацию о томах на всех доступных рабочих станций в домене (ActiveDirectory).

    Получилось прикольно. Аппетит разгорелся . Через пару месяцев в базе данных (MS SQL Server) новорожденной Inventory Monitoring System (IMS) было вполне приличное описание практического всего ИТ-оборудования компании, а на внутреннем сайте (IIS + ASP) можно было эту информацию в удобном виде посмотреть или выгрузить в MS Excel.

    Кроме сбора информации о конфигурации и состоянии различного оборудования было настроено сканирование и контроль внутренних IP-сетей, сбор данных производительности серверов (загрузка CPU, использование памяти, производительность сети и дисков) и доступности различных ИТ-ресурсов (страничек внутреннего и внешнего сайтов, доступа в интернет и т.п).

    Что удивило – вроде делалось это, чтобы освободить побольше времени для творчества и отдыха , а на самом деле автоматизированный сбор данных об ИТ-ресурсах обнаружил большое количество скрытых мелких проблем, которые мне же и пришлось решать.

    МТС


    В компанию МТС я пришел в подразделение, которое занималось серверами Windows. Только сервера — никаких рабочих станций, принтеров, пользователей. Красота! Только серверов этих было несколько сотен, и каждые полгода их количество удваивалось.

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

    На сегодня этой платформе уже 14 лет. Это система полностью разработана сотрудниками компании (у нас специально для таких продуктов есть название СИТР – система собственной ИТ -Разработки). IMS рос и менялся вместе с процессами в компании. 10 лет назад он содержал информацию только о серверах МТС Москвы – сейчас содержит информацию практически обо всем ИТ-оборудовании МТС и ее дочерних компаний по всей России.

    Сбор данных с оборудования происходит преимущественно удаленно. На серверах платформы запускается множество отдельных процессов, подключающихся к серверам и оборудованию (WMI, SSH, SNMP, SOAP), которые собирают и отправляют в базу платформы полученную информацию. Процессы запускаются с помощью штатного планировщика TaskSheduler. Весь процесс добавления/удаления задач в TaskSheduler тоже автоматизирован. План сбора метрик, указанный в карточке объекта, автоматически реализуется в конкретные задачи в TaskSheduler на конкретных серверах платформы.

    План метрик может быть назначен объекту с помощью набора профилей вручную или автоматически (в зависимости от типа оборудования, местоположения и т.п.) и дополнен собственным персональным набором «штатных» метрик.

    Кроме этого, можно подготовить и назначить к сбору комплект своих, особенных метрик, характерных только для конкретного объекта. Для этого нужно воспользоваться специальным конструктором и создать метрики для получения данных одним из стандартных предопределенных методов, например, через WMI, SNMP, командой SSH и т.п. (всего полтора десятка разных методов получения данных).

    Результатами работы процессов являются параметры сервера. В карточке объекта (веб-интерфейс) можно посмотреть их в виде списка последних собранных значения или проанализировать исторические значения в виде графиков и таблиц (с возможностью выгрузки в Excel).

    image

    Кроме динамических параметров собирается различная инвентаризационная информация: сведения об оборудовании, ОС, локальных пользователях, дисковых томах, интерфейсах, установленных приложениях, сессиях RDP и SSH, установленных системных обновления и т.п.

    Происходящие с объектом изменения фиксируются в журналах: сообщения от систем мониторинга можно увидеть в журнале сообщений, информация о плановых и аварийных работах – в журнале событий, изменения, вносимые в карточку объекта – в журнале изменений.

    Жизненный цикл оборудования можно довольно подробно описать на специальной вкладке «Эксплуатация». Можно распечатать и наклеить на оборудование этикетку c QR-ссылкой на карточку в IMS.

    image

    IMS имеет развитую систему поиска и отображения информации об объектах, хранящихся в системе. Позволяет искать нужный набор объектов по большому количеству критериев, составным условиям и по списку значений. Для отображения полученного набора объектов можно воспользоваться стадартными формами с определенным набором характеристик объектов или собственной формой с произволным наборм характеристик. Есть также возможность подготовки динамических отчетoв (dashboard).

    Преимущества текущей реализации


    Сразу было понятно, что система будет полезна и окупит потраченные на нее силы только если будет содержать нужные и актуальные сведения. Если за актуальность данных, которые собираются автоматически, можно было, в принципе, не беспокоиться, то обеспечение актуальности информации, вносимой пользователями вручную (системными администраторами), организовать было гораздо сложнее. Их необходимо было заинтересовать и мотивировать использовать IMS как инструмент для оперативной повседневной работы.

    Исходя из этого, определилось несколько ключевых целей:

    • принципы работы и процессы в системе должны быть максимально открыты, просты и интуитивно понятны;
    • интерфейс должен быть максимально прост, быстр и интуитивно понятен;
    • сотрудники – источники «ручной информации» – должны постоянно работать в системе, активно используя ее для решения своих оперативных задач, получая нужную для себя информацию, – тогда они будут максимально заинтересованы в поддержании актуальности «ручных» сведений.

    И, по-моему, это удалось. Это и объясняет успешную и такую продолжительную эксплуатацию платформы, несмотря на устаревшие технологии, использованные для ее разработки. Напомню: ПО платформы изначально было написано на Microsoft ASP + VBScript, и большая часть кода до сих пор сохранилась на этом диалекте и в этой парадигме. Хотя, конечно, доработка и разработка нового функционала, по возможности, ведется на современных продуктах платформы .NET.

    Как показал опыт, простая открытая архитектура ASP и VBScript, возможность быстрого и наглядного исправления ошибок и внесения правок позволяла быстро и эффективно дополнять и перестраивать процессы получения, управления и отображения данных с учетом текущих потребностей и пожеланий коллег. Это и дало возможность создать этот удобный и практичный (как мне кажется) инструмент для системного администратора.

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

    Владимир Наумов (v_naumov), старший эксперт-куратор отдела автоматизации ITSM процессов МТС.
    МТС
    66,00
    Компания
    Поделиться публикацией

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

      +1
      Zabbix.
      0
      Вендерных CMDB-продуктов много. Каждый имеет свои плюсы и минусы. И основной минус – это стоимость решения, лицензий и кастомизация. IMS же позволять легко интегрироваться с любыми решениями и выступать в роли поставщика инвентаризационных данных.


      А Вы бесплатно делиться будете?
        0
        Не знаю, вряд ли. Это не коммерческий и не open source продукт. Это СИТР, собственность компании МТС. Возможно будет предоставляется как сервис.
          +4
          Тогда не ясно, зачем вы о нем рассказываете. По сути, нет ни каких технических деталей реализации (необычных, интересных для сообщества), вы просто рассказываете какой вы молодец…
        +2
        Это все здорово, но вот не понятен один момент — зачем в CMDB метрики по загрузке cpu и прочего? С большим трудом поверю что в МТС нет полноценной системы мониторинга. А если она таки есть — то к чему это тут?
          0
          IMS – не является в компании системой мониторинга, мониторинг отдельная тема, другое подразделение, другое ПО.
          Статистика нагрузки и использования ресурсов собирается IMS-ом и используется в процессе прогнозирования и планирования мощностей (Capacity Planning) ИТ-инфраструктуры.
            +1
            Такое себе решение — тащить одни и те же данные в 2 разные системы. Хотя при развитой бюрократии наверно другого выхода и нет?
            • НЛО прилетело и опубликовало эту надпись здесь
                0
                Ответственные за функционал серверов тоже хотят видеть некоторые метрики, это легче чем получить доступ и учиться разбираться в Zabbix или в других системах анализа и мониторинга которые у нас существуют.
                Да и на самом деле, чего уж таить, вместо спец средств, эксплуатация порой тоже может заглянуть в IMS, у нас по сути если что-то непонятное и есть проблема то первое что открывается это IMS родненький (:
                  0
                  Ну если смотреть со стороны — то я бы сделал коннект к БД того же Заббикса (нам тут и ридонли хватит) и просто забирал бы уже и так имеющиеся метрики.
              +1
              Аналогичный вопрос. Если система недоступна, то вся заметка о чём? «Посмотрите какой я молодец»?
              0
              Заметка о нашем видении и реализации CMDB в компании. Принципах, которые мы закладываем в реализацию этого процесса.
                0
                С виденьем и так понятно, о реализации не рассказано практически ничего.
                У меня в общем то просто один технический вопрос, все остальное понятно и просто:
                В каком виде и как локальный модуль инвентаризации передает информацию в базу? Мне слабо верится, что тысячи агентов напрямую в базу льют данные. Наверняка есть промежуточный сервер/сервис в который агенты льют данные, и который уже в базу все по полочкам раскладывает.

                Как у вас это реализовано?
                  0

                  Именно так. Только агентов не тыЩа, а порядка сотни. И они льют данные НАПРЯМУЮ в РЕЛЯЦИОННУЮ базу. А агентом в данном решении называется хост, которого выполняется опрос.

                0
                Мониторинг безагентский. На сервера ничего не устанавливается. Есть примерно сотня серверов-агентов IMS которые собирают данные удаленно с оборудования (WMI/SSH/SNMP/SOAP). Эти агенты работают напрямую с базой.
                  0

                  ocsinventory

                    0
                    Ну судя по всему у Вас получилось нечто среднее между CMDB и системой мониторинга. Не совсем понятно почему вы из стандартной задачи мониторинга (а мониторинг свободного места это уж никак не задача CMDB) вдруг сделали то что сделали.
                    С точки зрения CMDB ведется ли у Вас в данной системе конфигурация сервисов с их зависимостями и есть ли в базе сетевое оборудование?
                      0
                      Это просто приятное дополнение к CMDB, как уже писал выше, владельцев систем и функционалов много, не все умеют в Zabbix и др.
                      Про конфигурацию сервисов, если имеется ввиду аналогия с системами управления конфигурациями Ansible, Puppet, Chef и тп., то нет. Сетевое оборудование да.
                      Мало того для физических серверов мой коллега запрашивал доработку для IMS, чтобы было визуальное представление как в Racktables и после реализации мы от него отказались и ведем все в одном месте.
                        0
                        Под конфигурацией сервисов я подразумеваю именно конфигурацию сервисов (не конфигурирование), то есть из каких CI состоит сервис, анализ того как себя поведет при сбое того или иного узла.
                        +1
                        «вдруг сделали то что сделали» — Все произошло не вдруг, а по нужде :). Через некоторое время выяснилось, что просто данных мониторинга в системе недостаточно для эффективной поддержки, очень нужна еще организационная информация (где находится оборудование, чем занимается, кто поддерживает, история RFC и т.п) и информация о текущей конфигурации и история ее изменений. А еще через некоторое время оказалось что CMDB-информация в системе ценнее чем мониторинговая.
                          +1
                          Сетевое оборудование есть, разумеется. А также инженерное (ИБП, PDU, датчики, камеры и т.п), оборудование оптический сетей, массивы, библиотеки.
                            +1
                            Реестр ресурсов — есть, есть и механизм связывания с оборудованием и корпоративными системами. Часть типов ресурсов (например, базы данных) на серверах дискаверится автоматически. Часть заводится и связывается вручную. С корпоративными системами ресурсы связываются (пока?) вручную.
                            0
                            Может стоило за основу взять: OCS Inventory-NG + GLPI и дописать недостающие фичи/плагины. Например оповещения об заканчивающимся месте на диске, об окончании гарантии, лицинзии умеет делать из каробки.
                              0
                              Полазил по Demo, ну что-то есть, похоже, но у нас уже круче все таки в сравнении (связи с ITSM, системами, людьми, заложена логика некоторых процессов). Отчасти конечно привычка дает о себе знать, но уже по первым шагам были моменты недопонимания, плюс продукт иностранный, непонятно на сколько гибкий, а тут вообще свой и что хочешь в нем допилят, если это обоснованно конечно.
                              0

                              Для маленьких фирм ваш подход вполне оправдан, однако для крупных компаний есть Microsoft System Center Configuration Manager с вполне оправданной методикой внедрения и управления.

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое