NexTool Solutions

GLPI хранит всю историю службы поддержки, но встроенные отчёты заканчиваются там, где руководство начинает спрашивать «почему». Metabase и Grafana читают одну и ту же базу MariaDB GLPI и превращают эту историю в дашборды - только решают они разные задачи, и неверный выбор оборачивается переделками.

Что меняется, когда вы подключаете BI к GLPI

Прежде чем сравнивать инструменты, нужно понять, что база GLPI не проектировалась под BI. Три детали определяют большую часть работы над любым дашбордом, будь то в Metabase или в Grafana:

• Статус, приоритет и срочность - это числа, а не текст. В glpi_tickets столбец status принимает значения от 1 (Новая) до 6 (Закрыта). Ни один инструмент не знает этого сам - если не перевести коды, руководитель увидит на графике «status 2».
• Ничего не удаляется по-настоящему. GLPI использует логическое удаление: is_deleted = 1 помечает запись как «в корзине». Забудете фильтр is_deleted = 0 - и все подсчёты будут завышены.
• Это мультиорганизационная система. Столбец entities_id разделяет данные по клиентам или подразделениям. Дашборд, который будет видеть клиент, должен фильтровать правильное поддерево организаций - а в чистом SQL это даётся не бесплатно.

Добавьте к этому четвёртый, чисто эксплуатационный момент: направить BI прямо на продуктивную базу в рабочее время с запросами, которые сканируют всю glpi_tickets вместе с glpi_logs, - самый быстрый способ замедлить сам GLPI. К этому мы ещё вернёмся.

Прямое сравнение

Как подключиться, не уронив GLPI

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

-- Usuario so-leitura para o BI (rode no MariaDB/MySQL do GLPI).
-- Aponte, de preferencia, para uma replica ou copia restaurada,
-- nunca para o master de producao com permissao de escrita.
CREATE USER 'bi_ro'@'10.0.0.%' IDENTIFIED BY '${SENHA_FORTE}';
GRANT SELECT ON glpi.* TO 'bi_ro'@'10.0.0.%';
FLUSH PRIVILEGES;

Когда доступ готов, первый артефакт, решающий проблему «голых чисел», - это запрос, переводящий коды статусов. Он годится для обоих: в Metabase он становится «SQL-вопросом», в Grafana - табличной или столбчатой панелью.

-- Chamados abertos por status, com os codigos traduzidos.
-- No GLPI, glpi_tickets.status vai de 1 a 6.
SELECT
  CASE status
    WHEN 1 THEN 'Novo'
    WHEN 2 THEN 'Em atendimento (atribuido)'
    WHEN 3 THEN 'Em atendimento (planejado)'
    WHEN 4 THEN 'Pendente'
    WHEN 5 THEN 'Solucionado'
    WHEN 6 THEN 'Fechado'
  END AS situacao,
  COUNT(*) AS total
FROM glpi_tickets
WHERE is_deleted = 0          -- ignora a lixeira (exclusao logica)
  AND status IN (1, 2, 3, 4)  -- so os que ainda estao abertos
GROUP BY status
ORDER BY status;

В Metabase есть сокращение: вместо CASE можно сопоставить значения столбца прямо в настройках поля (1 - «Новая», 2 - «В работе» и так далее), и подпись будет автоматически появляться на любом графике. Это выигрыш в производительности, которого нет в Grafana - там CASE обязателен.

Grafana: дашборд как код

Преимущество Grafana для тех, кто обслуживает много сред, видно не на экране, а на диске: источник данных и панели - это файлы под версионным контролем. Мы разворачиваем один и тот же дашборд у нескольких клиентов из YAML и JSON в Git, ничего не нажимая.

# /etc/grafana/provisioning/datasources/glpi.yaml
# Fonte de dados versionavel: o mesmo arquivo provisiona N ambientes.
apiVersion: 1
datasources:
  - name: GLPI-MariaDB
    type: mysql
    access: proxy
    url: mariadb.interno:3306
    database: glpi
    user: bi_ro
    jsonData:
      maxOpenConns: 5             # limite as conexoes: nao sufoque o GLPI
      timezone: America/Sao_Paulo
    secureJsonData:
      password: ${GLPI_BI_PASSWORD}

Другое отличие - время. Grafana нативно понимает временные ряды: с макросами $__timeFilter и $__timeGroup выбор периода и auto-refresh вверху экрана начинают управлять запросом, а переменная шаблона превращается в динамический фильтр по организации.

-- Painel de serie temporal: as macros ligam o seletor de periodo do topo.
SELECT
  $__timeGroup(date, '1d') AS time,    -- agrupa por dia
  COUNT(*)                 AS abertos
FROM glpi_tickets
WHERE is_deleted = 0
  AND entities_id IN (${entidade})      -- variavel de template (filtro por cliente)
  AND $__timeFilter(date)               -- respeita o intervalo escolhido na tela
GROUP BY 1
ORDER BY 1;

-- Consulta que alimenta a variavel de template "entidade":
SELECT name AS __text, id AS __value
FROM glpi_entities
ORDER BY completename;

Компромисс, который проявляется при сопровождении

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

Деталь, которая проявляется только в эксплуатации, - разделение по клиентам. В консалтинге, обслуживающем несколько клиентов в одном GLPI (или в разных GLPI), нужно гарантировать, что панель клиента A никогда не покажет заявку клиента B. В Metabase настоящая row-level security - sandboxing по пользователю - платная функция; в бесплатной версии выход - создавать отдельный вопрос для каждого клиента с фиксированным entities_id в WHERE, что умножает сопровождение. В Grafana мы решаем это переменной шаблона, привязанной к организациям, но контроль того, кто что видит, остаётся на вас. Бесплатного короткого пути к мультиклиентской изоляции нет - мы решаем в каждом случае отдельно, а при сомнениях разделяем по инстансам, а не по запросам.

Вердикт по сценариям

Выбирайте Metabase, когда аудитория - руководство, клиент или аналитик без SQL. Порог входа низкий, отчёт получается навигируемым и экспортируемым, а визуальное сопоставление статусов решает проблему «голых чисел» без написания CASE. Это лучший инструмент, чтобы донести данные службы поддержки до тех, кто не открывает терминал.

Выбирайте Grafana, когда панель операционная и живая - очередь по группам, SLA под угрозой, заявки по часам - для технической команды или NOC. Time picker, auto-refresh, многоканальные оповещения и provisioning как код - реальные преимущества, которые Metabase покрывает плохо.

Используйте оба, когда один и тот же GLPI обслуживает разные аудитории: Grafana на стене операционного отдела, Metabase в руках руководства и клиента. Это распространённо и работает, но примите стоимость сопровождения двух BI - не выбирайте этот путь «на всякий случай».

Стоимость и трудозатраты

Лицензия - не главная ось решения: у обоих есть бесплатная open source-версия, которой хватает для дашбордов GLPI, а платные планы (Metabase Pro/Enterprise, Grafana Enterprise) нужны только в сценариях масштаба или governance. Реальная стоимость - моделирование. Тяжёлая часть не установка, а знание схемы GLPI: сопоставить статусы и приоритеты, помнить про is_deleted, разобраться с деревом организаций и не нагружать продуктив. Честная оценка: несколько операционных панелей в Grafana поднимаются за полдня; набор хорошо смоделированных управленческих отчётов в Metabase с фильтрами по клиентам и переведёнными статусами обычно занимает от двух до четырёх дней работы, пока не станет надёжным. Чтобы понять, какие метрики выводить на каждую панель, пригодится наше руководство по KPI для Service Desk в GLPI.

В NexTool мы внедряем Metabase и Grafana поверх GLPI клиентов в обоих направлениях - управленческие отчёты и операционные панели, - всегда с пользователем только для чтения и без ущерба для продуктива. Если вам нужны правильные дашборды для правильной аудитории без зависимости от BI, который не подходит, наш консалтинг спроектирует этот слой показателей от начала до конца.

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