Диагностика правил, применённых к заявкам в GLPI

Хватит отлаживать правила заявок GLPI, открывая их по одному. Модуль Rule Inspector от NexTool показывает прямо в заявке, какие правила были применены, какие совпали, но не выполнились, и какие не прошли, — со справочным SQL, сравнением с ручным методом и экспортом в CSV для аудита.

В этой статьеРазделов: 8

Когда правило для заявок в GLPI делает не то, что должно, диагностика обычно отнимает часы у администратора среды. Модуль Rule Inspector от NexTool переворачивает эту работу: вместо того чтобы открывать правила по одному в менеджере правил, он показывает прямо в заявке, какие правила для заявок были проверены, какие совпали и почему.

Проблема

Бизнес-правила для заявок — одна из самых мощных возможностей GLPI: они назначают специалистов, задают категорию и SLA, отправляют уведомления и даже закрывают заявки. Но когда что-то не работает — заявка пришла без специалиста, категория не применилась, SLA так и не прикрепился, — диагностика ведётся вручную. Администратор открывает менеджер правил, читает критерий за критерием, проверяет порядок выполнения и пытается восстановить в голове, что произошло в тот момент, когда поступила эта заявка. В средах с десятками или сотнями правил, накопленных за годы эксплуатации, это превращается в поиск сокровищ.

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

Как работает Rule Inspector

После установки и включения модуля в каждой заявке появляется вкладка Rules Inspector. Из неё вам доступны:

  • Проверка правил — один щелчок проверяет все активные правила для заявок в организации заявки и показывает, какие были применены, какие совпали, но не выполнились, и какие не прошли по критериям, с подробностями по каждому проверенному критерию.
  • Сохранение по заявке — результат сохраняется в заявке. При повторном открытии кнопка меняется на «Повторить проверку», показывая, что уже есть предыдущая проверка для сравнения.
  • Проверка по ID — на отдельной странице модуля вкладка «Тест» позволяет указать любой номер заявки и увидеть, какие правила для неё истинны, не открывая саму заявку.
  • История с фильтром по организациям — вкладка «История» показывает 100 последних проверок, ограниченных организациями, которые пользователь имеет право видеть. Утечки данных между организациями нет.
  • Экспорт в CSV — результат выгружается в CSV с правилом, ID, рангом, режимом совпадения, статусом, оценкой и числом истинных, ложных и неподдерживаемых критериев, а также с подробностями каждого критерия (criteria | condition | value) и действиями — готово для аудита и отчётов.

Проверка охватывает до 1000 активных правил за раз, упорядоченных по рангу; на вкладке заявки выводится предупреждение, когда этот предел достигнут, — это важно для сред, где правила накапливались годами.

Что GLPI хранит внутри

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

-- Regras de ticket ativas, por ranking, com seus criterios.
-- criteria e condition sao codigos numericos, nao texto legivel.
SELECT r.ranking,
       r.name              AS regra,
       rc.criteria         AS criterio_cod,
       rc.condition        AS condicao_cod,
       rc.pattern          AS valor
FROM glpi_rules r
JOIN glpi_rulecriterias rc ON rc.rules_id = r.id
WHERE r.sub_type = 'RuleTicket'
  AND r.is_active = 1
ORDER BY r.ranking, rc.id;

Результат сразу объясняет проблему: criteria указывает на внутреннее поле правила, а condition — это код (например, «равно», «не равно», «регулярное выражение»). Чтобы прочитать это вручную, нужно расшифровывать таблицу за таблицей и ещё сопоставлять с порядком рангов. Rule Inspector выдаёт ту же информацию уже в расшифрованном виде и, что важнее, проверенной на реальной заявке.

Ручная диагностика и Rule Inspector

КритерийРучная диагностика в GLPIRule Inspector
Где вы расследуетеМенеджер правил, по одному правилу, или прямой SQLВкладка Rules Inspector прямо в заявке
КонтекстВы мысленно моделируете значения заявкиПроверка на реальной заявке, открытой на экране
Чтение критериевЧисловые коды, которые нужно расшифроватьЧитаемый формат criteria | condition | value
Совпадение и выполнениеТрудно отличить одно от другогоРазделяет применённые, совпавшие без выполнения и не прошедшие
Порядок / рангВосстанавливать в головеПроверка по рангу, с сигналом о достижении предела
АудитРучной экспорт, случай за случаемЭкспорт в CSV и история с фильтром по организациям

Как включить

  1. Установите плагин NexTool в ваш GLPI.
  2. Откройте Настройки > NexTool > Модули.
  3. Включите модуль Rule Inspector.
  4. Синхронизируйте права через панель NexTool, чтобы нужные профили увидели вкладку Rules Inspector в заявке.

Кому это подходит — и когда не стоит использовать

Rule Inspector предназначен для тех, кто настраивает и сопровождает правила для заявок: администраторов, проверяющих новое правило, аналитиков качества, контролирующих автоматические назначения, руководителей службы поддержки, выясняющих, почему некоторые заявки не получают категорию или SLA, и команд, которые только что обновили версию и должны убедиться, что правила по-прежнему действуют.

Это не тот инструмент, если в вашей среде не используются правила для заявок или если вопрос касается другого типа правил GLPI — словарей выпадающих списков, правил импорта активов, назначения прав через LDAP. Модуль сосредоточен на том, что выполняется при создании или изменении заявки.

Что мы узнали на сопровождении

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

Совместимость

  • GLPI: 10.x и 11.x
  • План: FREE
  • Плагин: NexTool 6.9.1+

Rule Inspector входит в NexTool — модульный плагин для GLPI. Познакомьтесь с другими модулями или свяжитесь с командой для демонстрации.


Проверено командой NexTool Solutions.

Часто задаваемые вопросы

Модуль Rule Inspector от NexTool проверяет активные правила для заявок в организации заявки и показывает прямо в ней, какие были применены, какие совпали, но не выполнились, и какие не прошли по критериям, с подробностями по каждому критерию.

В большинстве случаев правило даже совпало, но правило с меньшим рангом, проверенное раньше, имело действие остановки обработки и оборвало очередь. Другая частая причина — область действия организации. Rule Inspector показывает, что именно было заблокировано для этой заявки.

Да. Вкладка «Тест» принимает любой ID заявки и показывает, какие правила для неё истинны, «История» собирает последние проверки с фильтром по организациям, которые пользователь имеет право видеть, а результат проверки можно экспортировать в CSV с критериями в формате criteria | condition | value.

Да. Rule Inspector — бесплатный (FREE) модуль NexTool, совместимый с GLPI 10.x и 11.x; требуется плагин NexTool 6.9.1 или выше.

Нужна помощь?