iTop + Zabbix, Active Directory и почта: собираем интеграции и мигрируем учёт из Excel

Стратегия интеграций: что подключать в первую очередь

Меня зовут Семёнов Евгений Сергеевич, я технический директор ITfresh. Это третья статья серии про iTop: в обзоре я объяснял, зачем малому бизнесу CMDB, в гайде по установке мы развернули iTop 3.2 на Ubuntu 24.04. Сегодня — то, без чего любая тикет-система мертва: обвязка. Голый iTop после установки похож на телефон без сим-карты: красивый, но не звонит.

Порядок подключения интеграций у нас выверен по окупаемости:

1. Почта — без приёма заявок с ящика портал не взлетит: пользователи ещё год будут писать «как привыкли».
2. Active Directory — никто не хочет второй пароль; плюс автоматическое заведение людей.
3. Мониторинг — тикеты о падениях до звонка пользователя; у всех наших клиентов это Zabbix.
4. API-обвязка и импорт данных — перенос исторического учёта и регулярная синхронизация.

Важный принцип проектирования: каждая интеграция — отдельный контур отказа. Падение Zabbix не должно класть iTop, недоступность контроллера домена не должна блокировать вход администратора. Поэтому: у админа iTop всегда остаётся локальная учётка, webhook из мониторинга ходит с таймаутами и ретраями, а почтовый коллектор при ошибке просто оставляет письма в ящике до следующего прохода.

Авторизация через Active Directory

Задача двойная: пускать людей по доменному паролю и автоматически заводить их карточки в iTop. Это два разных механизма, и путать их не надо.

Вход по LDAP

За проверку пароля отвечает штатный модуль authent-ldap. В конфигурации iTop (conf/production/config-itop.php) прописываем контроллер домена — обязательно по LDAPS, пароли в открытом виде по сети в 2026 году гонять неприлично:

'authent-ldap' => array(
  'host' => 'ldaps://dc01.corp.example.ru',
  'port' => 636,
  'default_user' => 'CN=svc-itop,OU=Service,DC=corp,DC=example,DC=ru',
  'default_pwd' => '********',
  'base_dn' => 'DC=corp,DC=example,DC=ru',
  'user_query' => '(&(sAMAccountName=%1$s)(memberOf=CN=ITop-Users,OU=Groups,DC=corp,DC=example,DC=ru))',
),

Сервисная учётка svc-itop — обычный доменный пользователь без единой привилегии: ей нужно только читать каталог. Фильтр по группе ITop-Users — осознанное решение: доступ к системе учёта получают не все 50 сотрудников скопом, а те, кого вы туда явно включили.

Синхронизация людей: iTop Data Collector for LDAP

Чтобы карточки Person создавались сами, Combodo выпускает отдельное приложение — Data Collector for LDAP. Это PHP-скрипт, который по расписанию читает нужные OU, сопоставляет атрибуты (имя, фамилия, почта, телефон, подразделение) и через механизм синхронизации данных iTop создаёт и обновляет людей. Работает он снаружи iTop — можно запускать хоть с того же сервера, хоть с отдельной машины с доступом к домену.

Маппинг ролей у нас типовой: члены группы ИТ-отдела получают профиль Support Agent, остальные синхронизированные — Portal User. И обязательная грабля, на которую наступают все: отключённые в AD учётки не исчезают из iTop сами. Коллектор надо настроить так, чтобы disabled-пользователи (в AD это бит в userAccountControl) помечались неактивными и в iTop — иначе уволенный сотрудник ещё год будет висеть в списке согласующих.

Mail to Ticket: заявки с ящика support@

Расширение Mail to Ticket Automation (бесплатное, с iTop Hub) по расписанию опрашивает почтовый ящик по IMAP и превращает письма в заявки. Наша схема на типовом внедрении:

• Ящик support@клиент.ru на почтовом сервере клиента (или нашем, если почту тоже мы обслуживаем).
• В iTop создаётся объект «почтовый ящик» с параметрами IMAP и правилом: новое письмо → User Request от имени отправителя, найденного по e-mail в CMDB.
• Опрос выполняет тот же cron.php, что и остальные фоновые задачи, — отдельного демона не нужно.

Тонкости, которые делают связку рабочей, а не игрушечной. Ответы пользователей цепляются к существующему тикету — по номеру заявки в теме письма, поэтому шаблоны уведомлений трогаем аккуратно и номер из темы не убираем. Вложения из письма попадают в тикет автоматически — скриншоты «вот такая ошибка» доезжают без потерь. Письма от неизвестных отправителей мы направляем в отдельную очередь на разбор, а не отбрасываем: у клиента всегда найдётся подрядчик, пишущий с личной почты.

Zabbix → iTop: тикеты из мониторинга раньше звонка пользователя

Классика жанра: диск заполнен на 95%, Zabbix это видит, а тикет заводится руками — если дежурный не проспал алерт в Telegram. Соединяем напрямую: триггер Zabbix создаёт Incident в iTop с привязкой к нужному CI, восстановление — закрывает.

Архитектура связки

Старые статьи по этой теме (легендарный хабровский сценарий 2017 года) предлагали самописные демоны-прослойки. В 2026 году всё проще: у Zabbix 7.0 LTS есть штатный механизм webhook — JavaScript-скрипт прямо в типе оповещения, который дёргает REST-API iTop. Никаких промежуточных сервисов.

Поток такой: триггер срабатывает → webhook шлёт core/create в iTop, передавая имя хоста, важность и текст проблемы → iTop ищет CI по имени хоста и вешает инцидент на него → инженер видит тикет с графом зависимостей: что за сервер и какие сервисы под ударом. При восстановлении триггера webhook шлёт core/update и переводит инцидент в решённые с комментарием «восстановлено мониторингом».

Сердце webhook: запрос к API

Внутри webhook-скрипта Zabbix — обычный HTTP POST на webservices/rest.php?version=1.3. JSON-операция создания инцидента выглядит так:

{
  "operation": "core/create",
  "comment": "Zabbix trigger #{TRIGGER.ID}",
  "class": "Incident",
  "output_fields": "id, friendlyname",
  "fields": {
    "org_id": "SELECT Organization WHERE name = 'Клиент'",
    "title": "{HOST.NAME}: {EVENT.NAME}",
    "description": "{EVENT.SEVERITY}. {EVENT.OPDATA}",
    "functionalcis_list": [{
      "functionalci_id": "SELECT FunctionalCI WHERE name = '{HOST.NAME}'"
    }]
  }
}

Обратите внимание на конструкции SELECT — это OQL, язык запросов iTop: вместо числовых идентификаторов мы передаём условия поиска, и сервер сам находит организацию и CI. Значит, единственное требование к порядку в хозяйстве: имена хостов в Zabbix должны совпадать с именами CI в CMDB. У нас это достигается просто — CMDB и наполняется из тех же источников, что мониторинг.

Ключ дедупликации кладём в поле тикета: повторные срабатывания того же триггера не плодят дубли, а дописывают журнал существующего инцидента. На стороне Zabbix ставим таймаут 10 секунд и три попытки — если iTop недоступен, алерт всё равно уйдёт дежурному обычным каналом.

REST/JSON API: универсальный клей

API iTop — это один эндпоинт и набор операций: core/get (выборка по OQL), core/create, core/update, core/delete, плюс операции по вложениям. Аутентификация — сервисным пользователем, которому назначен профиль REST Services User: без этого профиля API вернёт отказ, сколько бы прав администратора у учётки ни было.

Живой пример из нашей практики — еженедельный отчёт «у каких серверов кончается гарантия» (поле мы добавляли в статье про установку). Python, стандартный requests, тридцать строк:

import requests, json

ITOP = "https://itop.example.ru/webservices/rest.php?version=1.3"
AUTH = {"auth_user": "svc-rest", "auth_pwd": "********"}

query = {
    "operation": "core/get",
    "class": "Server",
    "key": "SELECT Server WHERE warranty_end < DATE_ADD(NOW(), INTERVAL 60 DAY)",
    "output_fields": "name, warranty_end, org_id_friendlyname",
}
r = requests.post(ITOP, data={**AUTH, "json_data": json.dumps(query)}, timeout=30)
objects = r.json().get("objects") or {}
lines = [
    f"{o['fields']['name']} — гарантия до {o['fields']['warranty_end']}"
    for o in objects.values()
]
if lines:
    print("Серверы с истекающей гарантией:\n" + "\n".join(lines))

Дальше — дело вкуса: у нас вывод уходит ботом в Telegram-канал дежурных. По той же схеме делается всё что угодно: выгрузка тикетов в BI, автосоздание заявок из внутренних скриптов, сверка CMDB с гипервизором. OQL в поле key — полноценный язык с JOIN-ами, так что «все виртуалки на гипервизорах без договора поддержки» — это один запрос.

Миграция учёта из Excel в CMDB

У каждого клиента к моменту внедрения есть «учёт»: три-пять Excel-файлов разной степени свежести. Типовой набор: «Компьютеры.xlsx» (последнее обновление — год назад), «Лицензии», «Договоры» и легендарный файл «У кого какой монитор» с вкладками по этажам. Задача — перенести это в CMDB, не утонув.

Порядок работ

1. Инвентаризация файлов. Собираем всё, что ведётся, включая заметки админа в блокноте. Спрашиваем не «где ваш реестр», а «куда вы смотрите, когда надо узнать серийник».
2. Нормализация. Приводим к классам CI: компьютеры → PC, серверы → Server, программы → Software/ApplicationSolution, договоры → Contract. Чистим дубли (один и тот же ноутбук под тремя именами — норма жизни), выравниваем справочники: «Иванов И.», «Иванов Иван» и «ivanov» — один человек.
3. CSV-импорт с симуляцией. Штатный импорт iTop умеет маппить колонки на атрибуты, а главное — ключи сверки: скажите ему «идентифицируй по имени и организации», и повторный прогон того же файла обновит записи, а не создаст дубли. Режим симуляции показывает, что будет создано и изменено, до записи в базу — пользуйтесь всегда.
4. Связи. Часть связей грузится теми же CSV (колонка с именем пользователя у рабочего места), сложные — руками на выборочных объектах.

Реальный кейс: юридическая фирма, 4 Excel-файла, копившиеся шесть лет. За один рабочий день получили 340 конфигурационных единиц с сохранением связей «сотрудник — рабочее место — монитор» и договорами по каждому подрядчику. Что сознательно не потащили: историю ремонтов пятилетней давности и списанную технику — археология в живой CMDB только мешает.

Миграция с GLPI: когда и как

Отдельный частый вопрос: «у нас GLPI, хотим iTop». Честный ответ: автоматического конвертера нет. Путь — выгрузка сущностей GLPI в CSV (или по его API) и импорт в iTop с ремаппингом полей; железо и люди переезжают за день, а вот историю тикетов мы обычно не переносим вовсе — оставляем GLPI в режиме read-only на год для справок. И главный фильтр: если в GLPI вам не хватает именно связей, SLA по договорам и мультиарендности — переезд оправдан; если просто «надоел интерфейс» — не тратьте время, это худшая причина для миграции.

Инвентаризационный агент: чем заменить «из коробки»

У iTop нет своего агента сбора данных с рабочих станций — и это осознанная позиция Combodo: CMDB хранит модель, а собирать сырые данные должны специализированные инструменты. Варианты замены, от тяжёлого к лёгкому:

• GLPI Agent / FusionInventory + прослойка, перекладывающая данные в iTop, — вариант для тех, у кого агенты уже раскатаны.
• iTop Data Collector — фреймворк коллекторов Combodo: готовые сборщики для vSphere, Azure и других источников; свой коллектор пишется по шаблону.
• Наш вариант для сетей до 50 машин: PowerShell-скрипт инвентаризации, раскатанный через GPO. Раз в сутки каждая машина пишет строку CSV (имя, пользователь, модель, серийник, ОС, память, диск) в сетевую папку, а небольшой скрипт на сервере склеивает файлы и заливает в iTop через API с ключами сверки. Полсотни строк кода, нулевая стоимость, данные в CMDB всегда не старше суток.

Выбор зависит от масштаба, но принцип один: данные о железе должны попадать в CMDB автоматически. Всё, что обновляется руками, врёт уже через квартал.

Итог: карта интеграций типового клиента на 50 РМ

Соберём картину целиком. В CMDB типового клиента данные стекаются четырьмя потоками:

Все дороги ведут в CMDB, и она перестаёт быть музеем: люди актуальны, железо свежее, инциденты привязаны к узлам, заявки — к людям. Трудозатраты на всю обвязку — три-четыре дня инженера, который делает это не в первый раз. Если делаете впервые — закладывайте неделю-полторы и начинайте с почты.

Эта связка — ровно то, что мы собираем клиентам под ключ: iTop на наших серверах в дата-центре МТС или на вашей площадке, интеграции с доменом, мониторингом и почтой, перенос учёта из Excel. Дальше в серии — эксплуатация: бэкапы, обновления и регламент актуализации CMDB.