Как стать автором
Обновить

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

В Zabbix CMDB – практически нет. Для мониторинга — достойный продукт и тоже бесплатный :)
Ну как сказать. Практически, даже с готовыми макросами — возможностей для инвентаризации больше, чем у вас.
www.zabbix.com/documentation/3.0/ru/manual/config/hosts/inventory
www.zabbix.com/documentation/3.0/ru/manual/appendix/macros/supported_by_location
Поправьте плз в тексте TashSheduler. Трижды подряд написано
Вендерных CMDB-продуктов много. Каждый имеет свои плюсы и минусы. И основной минус – это стоимость решения, лицензий и кастомизация. IMS же позволять легко интегрироваться с любыми решениями и выступать в роли поставщика инвентаризационных данных.


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

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

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

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

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий