Инвентаризация серверов без отвращения

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

Это именно история в стиле success story, a не инструкция по установке. Так как пошаговых how to в интернете и на данном сайте для этого продукта предостаточно. Но все они рассказывают про инвентаризацию ПК, а с серверами есть свои нюансы. GLPI не смотря на существующий серверный функционал и плагины специализируется на инвентаризации ПК. Но в умелых руках можно заточить его под нужды серверных Администраторов (сетевых между прочим тоже). Возможно используемые методы у программистов вызовут нарекания, но напомню сделано это админами и для админов.

Предистория

Наверное не нужно объяснять как важно иметь в оперативном доступе актуальную информацию про подопечный зоопарк техники. Особенно это становится важно когда количество начинает переваливает за сотню. Наверняка все проходят через exel файлик с необходимыми полями. С такой же вероятностью у всех возникало чувство отвращения от этого метода при забивании или модифицировании десятка строк.

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

В одной статье было упоминание про использования связки FusionInventory + GLPI для сбора информации по устанавливаемым серверам. В связи с большим уважением к остальным применяемым в статье технологиям я решил опробовать эту в нашей среде.

Реализация

Пару слов о продуктах:

• GLPI — система для организации heldesk в предприятии с базой данных по оборудованию
• FusionInventory — автоматизация сбора данных и выполнения задач

Оба продукта Open Source, оба периодически обновляются и дополняются новыми фичами. Но от обоих продуктов нам понадобится только часть функционала:

• Хранение основной информации по серверам и виртуальным машинам:
• Автоматический сбор этих данных с серверов
• Отслеживание запросов во внешние ТехПоддержки
• Хранение информации о ТП (кто оказывает поддержку, на каком уровне и когда она кончиться)
• Ассоциация серверов с бизнес сервисами предоставляемыми ИТ
• Отслеживание местоположения сервера в стойке
• Создание отчётов

После изучения функционала и понимания что потребуется что нет, урезаем в интерфейсе всё лишнее. Это отлично отробатываеться через гибкую систему управления профилями. Создав профиль для администраторов серверов и внимательно пройдясь по доступным галочкам беспощадно выкосил весь неиспользуемый функционал. В таком виде вы и ваши коллеги не будете отвлекаться от основной задачи данного ресурса — кропотливый сбор информации.

Поверхностный тюнинг

Суровое наследство GLPI как helpdesk инструмента придётся вырезать залезая в код. Моих навыков в PHP на котором написана система хватает на интуитивное пониманием кода, но несмотря на это можно сделать достаточно много. Сперва рекомендую поправить локализацию для того чтобы элементы инвентаризации назывались не компьютерами, а серверами. Вроде не особо значимый пункт, но помогает в правильном позиционировании продукта внутри компании.

Файл с русской локализации по умолчанию хранится здесь: /usr/share/glpi/locales/ru_RU.php. Сделайте бэкап и смело правьте названия.

Следом рекомендую сменить страницу по умолчанию на список серверов. Это сократит на пару кликов доступ к самой востребованной информации и уберёт лишние вопросы:

cp /usr/share/glpi/front/central.php /usr/share/glpi/front/central.php.b
cp /usr/share/glpi/front/computer.php /usr/share/glpi/front/central.php

Дальше определим набор полей которые мы хотим видеть для серверов. В нашем случае это вылилось в такой список:

• Имя сервера
• Серийный номер
• Модель
• ОС
• Адрес консоли управления
• Статус
• Местоположение
• Контакт ответственного за приложения на сервере: человек и подразделение

Попробуем убрать лишнее с нашей вэбформы отображения сервера. Для этого нужно подредактировать класс computer: /usr/share/glpi/inc/computer.class.php. Находим функцию showForm( и комментируем вывод полей.

При удачной компановке переносами оставшихся полей получаем подобную форму:

Советую создать шаблоны с предварительно заданными полями для уменьшения отвращения от заполнения инвентаризации.

Hint 1: Добавив пару строк в эту же функцию можно получить удобную ссылку на элемент в системе мониторинга nagios в котором есть обратная ссылка в инвентаризацию (см скриншот выше):

      echo "<tr class='tab_bg_1'>";
      echo "<td></td><td></td>";
      echo "<td></td>";
      echo "<td><a href=http://nagios/check_mk/view.py?view_name=host&site=&host=".$this->fields["name"]."> Server monitoring in NAGIOS </a> </td>";

Hint 2: Переименовав неиспользуемое нашей командой поле «инвентарный номер» в «адрес консоли» и сменив тип на url получили возможность прямо из списка серверов перейти на SP консоль. Помогает оперативно решать проблемы со сбойным сервером.

Так же дабы не отвлекать наших администраторов лишними элементами рекомендую закомментировать данные вкладки в том же файле (часть из них может быть убрана зарезанием прав через профиль):

#      $this->addStandardTab('ComputerVirtualMachine', $ong, $options);
#      $this->addStandardTab('RegistryKey', $ong, $options);
#      $this->addStandardTab('Item_Problem', $ong, $options);
#      $this->addStandardTab('Link', $ong, $options);
#      $this->addStandardTab('Reservation', $ong, $options);
#      $this->addStandardTab('OcsLink', $ong, $options);
#      $this->addStandardTab('Computer_SoftwareVersion', $ong, $options);
#      $this->addStandardTab('Note', $ong, $options);
#      $this->addStandardTab('Document', $ong, $options); 

Сбор данных

Для того чтобы не вбивать информацию по компонентам воспользовались плагином FusionInventory. Очень хорошая статья по его установке уже есть на хабре. Могу лишь добавить от себя что было изменено в нашем случае.

Агенты ставить не хотелось в виду и так большого количества постороннего по на серверах. Тем более чаше всего достаточно одного запуска для сбора данных. Не каждый же день у вас меняется ОС или компоненты на сервере. Шара в сети (CIFS и NFS) и распакованный на ней дистрибутив агента FusionInventory под каждую ОС используемую в компании позволяет в одну команду собрать данные:

• \shareFusionInventoryWindowsfusioninventory-agent.bat
• /net/share/FusionInventory/RHEL/fusioninventory-agent

Как запустить данную процедуру массово в вашей компании решать вам самим. После запуска мы либо получим новый объект в инвентаризации либо обновим данные существующего (уникальность проверяется по серийнику/МАC/IP/имени) с забитыми данными:

В настройках плагина FusionInventory отключаем сбор той информации которая вам не нужна.

Hint: результат работы агента можно выгрузить в файл, а потом импортировать в GLPI. Данный механизм создаёт идиальный API для автоматической загрузки любых данных. Мы реализовали на этой возможности импорт данных по виртуальным машинам из нашей фермы VMware.
У плагина FusionInventory для данных задач есть свой инструмент, но он добавляет компоненты к серверу, вместо создания полноценного элементы списка серверов. Что не так удобно. В последней версии вышедшей пару месяцев назад появился выбор, создавать элемент для виртуалок или компонент к ESXi серверу.

Отслеживаем внешние заявки

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

Решение заложено в GLPI — заявки, но в данном случае они подразумевают заявку наружу, а не внутрь ИТ команды. Для упрощения процедуры заявок было сделано аналогичное урезание функционала:

Получаем список открытых или закрытых тикетов:

Дополнение

Собственно на этом инвентаризация серверов закончена, дальше в зависимости от необходимости дополняем функционал плагинами. Я рекомендую данные дополнения:

• Appliances — возможность объединять сервера сервисом которые они предоставляют
• Bays Management — управление серверными стойками, их электропитанием, расположением серверов в стойке
• Custom Fields — добавление кастомных полей к существующим элементам
• Databases — Инвентаризация баз данных, ассоциация с сервисами и серверами
• File injection — Импорт элементов из csv файла
• Objects management — Создание кастомных объектов

Собственно на этом всё. Если у читателей появится интерес к дополнениям и тому как мы их используем я напишу отдельную статью про имплементацию данных плагинов, но для понимания как это выглядит кидаю скриншоты:
Кастомные элементы — storages

ИТ сервисы

Стойки

Автор: Gorer

Источник