uveon / termidesk-zabbix
CI/CD
Реестр контейнеров и пакетов
konstantin
Fix Zabbix 7.0 XML format and UUIDv4 requirement - Switch XML format version from 6.4 to 7.0 for Zabbix 7.0 LTS templates - Replace UUIDv5 with UUIDv4 (override version nibble to '4') to satisfy Zabbix 7.0 API validation ("UUIDv4 is expected") - Store UUIDs as 32 hex chars without hyphens (Zabbix XML format) - Use <template_groups> at top level for Zabbix 7.0 (keep <groups> for 6.0) - Remove <date> tag for Zabbix 7.0 - Move <triggers> and <graphs> to top level (siblings of <templates>) in both 6.0 and 7.0 - Replace <params> with <parameters><parameter> in preprocessing steps - Use FLOAT/UNSIGNED value types instead of NUMERIC_FLOAT/NUMERIC_UNSIGNED - Use ZABBIX_PASSIVE item type instead of deprecated ZABBIX_AGENT - Use string constants for graph type/drawtype/ymin_type (NORMAL/STACKED, SINGLE_LINE, CALCULATED) and add <sortorder> to graph items - Add <master_item> to all DEPENDENT LLD item prototypes - Fix PROMETHEUS_PATTERN preprocessing to use 3 parameters - Update changelog with [1.0.1] section All 40 templates verified to import successfully into both Zabbix 6.0 LTS and Zabbix 7.0 LTS via Docker-based test instances.
4 дня назад История
README.md

Шаблоны мониторинга Termidesk для Zabbix

Шаблоны для мониторинга продуктов линейки Termidesk через REST API и HTTP:

  • Termidesk VDI (диспетчер + агрегратор + ретранслятор + удалённый помощник + менеджер рабочих мест) — Termidesk 6.1 / 7.0 / 7.1
  • TermideskMQ (TMQ) — экспериментальный брокер очереди сообщений (замена RabbitMQ)
  • Termidesk Connect (балансировщик нагрузки / ADC) — Connect 1.3 / 1.4, включая режим Шлюза для Termidesk VDI

Поддерживаются Zabbix 6.0 LTS и 7.0 LTS.

Оглавление

Состав

Шаблоны разделены по типу сбора метрик:

  • http_agent/ — опрос через HTTP(S), не требует Zabbix agent на хосте (Zabbix server сам обращается к API Termidesk).
  • zabbix_agent/ — требует Zabbix agent на мониторимом хосте (systemd, процессы). Дополняют HTTP Agent шаблоны: мониторят состояние systemd-юнитов и количество процессов. TMQ, STAL и Агент узла виртуализации — шаблоны без HTTP API (monitoring только через agent + TCP).
Файл Назначение
externalscripts/termidesk_api.sh Внешний скрипт для Zabbix (login, LLD, метрики) — только для VDI
templates/zabbix-{6.0,7.0}/http_agent/template_termidesk_dispatcher.xml Termidesk VDI: Диспетчер
templates/zabbix-{6.0,7.0}/http_agent/template_termidesk_aggregator.xml Termidesk VDI: Агрегатор
templates/zabbix-{6.0,7.0}/http_agent/template_termidesk_repeater.xml Termidesk VDI: Ретранслятор (Fluent Bit-style API)
templates/zabbix-{6.0,7.0}/http_agent/template_termidesk_assistant.xml Termidesk VDI: Удалённый помощник (availability check)
templates/zabbix-{6.0,7.0}/http_agent/template_termidesk_workplace_manager.xml Termidesk VDI: Менеджер рабочих мест (celery-beat/worker health)
templates/zabbix-{6.0,7.0}/http_agent/template_termidesk_connect.xml Termidesk Connect: инстанс ADC (WUI + /metrics + HA)
templates/zabbix-{6.0,7.0}/http_agent/template_termidesk_gateway.xml Termidesk Connect в режиме Шлюза для VDI
templates/zabbix-{6.0,7.0}/http_agent/template_termidesk_session_agent.xml Termidesk: Сессионный Агент (health + Prometheus metrics)
templates/zabbix-{6.0,7.0}/http_agent/template_termidesk_vdi_agent.xml Termidesk: Агент ВРМ (health + Prometheus metrics, UUID в URL)
templates/zabbix-{6.0,7.0}/zabbix_agent/template_termidesk_tmq.xml TermideskMQ: брокер очереди сообщений (Zabbix agent + TCP)
templates/zabbix-{6.0,7.0}/zabbix_agent/template_termidesk_dispatcher.xml Termidesk VDI: Диспетчер (systemd + порталы, Zabbix agent)
templates/zabbix-{6.0,7.0}/zabbix_agent/template_termidesk_aggregator.xml Termidesk VDI: Агрегатор (systemd + порталы, Zabbix agent)
templates/zabbix-{6.0,7.0}/zabbix_agent/template_termidesk_assistant.xml Termidesk VDI: Удалённый помощник (systemd, Zabbix agent)
templates/zabbix-{6.0,7.0}/zabbix_agent/template_termidesk_gateway.xml Termidesk Connect: Шлюз (systemd, Zabbix agent)
templates/zabbix-{6.0,7.0}/zabbix_agent/template_termidesk_repeater.xml Termidesk VDI: Ретранслятор (systemd, Zabbix agent)
templates/zabbix-{6.0,7.0}/zabbix_agent/template_termidesk_workplace_manager.xml Termidesk VDI: Менеджер рабочих мест (systemd ×2, Zabbix agent)
templates/zabbix-{6.0,7.0}/zabbix_agent/template_termidesk_stal.xml Termidesk STAL: сервер терминалов (systemd ×2 + RDP порт, Zabbix agent)
templates/zabbix-{6.0,7.0}/zabbix_agent/template_termidesk_session_agent.xml Termidesk: Сессионный Агент (systemd, Zabbix agent)
templates/zabbix-{6.0,7.0}/zabbix_agent/template_termidesk_vdi_agent.xml Termidesk: Агент ВРМ (systemd, Zabbix agent)
templates/zabbix-{6.0,7.0}/zabbix_agent/template_termidesk_vmsd_agent.xml Termidesk: Агент узла виртуализации (systemd + RPC порт, Zabbix agent)

Что мониторится

Диспетчер Termidesk (Server_Termidesk)

Здоровье сервера (через /api/health/check и /api/health/metrics):

Метрика Описание
Health status Общий статус: pass / warn / fail
Server uptime Время работы сервера, с
CPU total Загрузка процессора, %
Memory total / available / used Оперативная память, байт
User sessions Количество активных пользовательских сессий
Admin sessions Количество активных админских сессий
Total VMs Всего виртуальных рабочих мест
Failed to start VMs ВРМ с ошибкой запуска
Stuck VMs Зависшие ВРМ
Unregistered agents Незарегистрированные агенты
Server version Версия сервера Termidesk

Фонды рабочих мест — автообнаружение через /api/webui/server/servicespools:

Метрика Описание
State Состояние фонда (A — активен, R — restrained, I — inactive)
Cache L1 / L2 Размер кэша ВРМ (горячий / холодный)
Max VMs Максимальное количество ВРМ в фонде
User services Назначенные пользователям ВРМ
In preparation ВРМ в процессе подготовки

Узлы инфраструктуры — автообнаружение через /api/webui/server/appnodes/brokers:

Метрика Описание
Status Статус узла (ok, unknown, fail)

Сессии — автообнаружение через /api/webui/server/spsessions: обнаруживаются все активные пользовательские сессии (ID, ВРМ, владелец).

Лицензия — через /api/webui/server/license/info:

Метрика Описание
License quantity Количество лицензий
Subscription Тип подписки
Start / End date Срок действия
Is expiring Флаг истечения
Features Remote Assistant, Repeater, Scheduler, Branding

Веб-порталы (опционально, через HTTP Agent):

Метрика Описание
Admin portal check Доступность портала администратора (GET на {$TERMIDESK.PORTAL.ADMIN.URL})
User portal check Доступность пользовательского портала (GET на {$TERMIDESK.PORTAL.USER.URL})

Порталы — это веб-UI, не REST API. Мониторятся как HTTP-сервисы: Zabbix делает GET-запрос на URL и проверяет, что есть ответ. Если URL портала не задан — айтем переходит в Not supported (см. раздел «Мониторинг порталов за балансировщиком»).

Триггеры (11 шт.):

Триггер Приоритет Условие
Health check FAILED HIGH status = fail
Health check WARNING WARNING status = warn
CPU usage critical HIGH CPU > 90% в течение 5 мин
CPU usage high WARNING CPU > 80% в течение 5 мин
Available memory critical HIGH Доступная память < 5%
VMs failed to start WARNING failed_to_start > 0
Stuck VMs detected WARNING stuck_vms > 0
Unregistered agents WARNING unregistered_agents > 0
Server restarted INFO uptime < 300 с
Admin portal unreachable WARNING нет данных 5 мин от портала администратора
User portal unreachable WARNING нет данных 5 мин от пользовательского портала

Агрегатор Termidesk (Aggregator)

Здоровье сервера (через /aggregator/health/check и /aggregator/health/metrics):

Метрика Описание
Health status Общий статус: pass / warn / fail
Server uptime Время работы, с
CPU total Загрузка процессора, %
Memory total / available Оперативная память, байт
User / Admin sessions Активные сессии
Farms count Количество ферм
Sites count Количество сайтов
Servers count Количество серверов
Server version Версия агрегатора

Фермы агрегатора — автообнаружение через /api/webui/aggregator/farms:

Метрика Описание
Is active Ферма активна
On maintenance Режим обслуживания
Dispatcher count Количество привязанных диспетчеров
Priority Приоритет фермы

Сайты и фонды — автообнаружение через /api/webui/aggregator/sites и /api/webui/aggregator/servicespools.

Сайты обнаруживаются как инвентаризационные сущности (ID, имя) — API не отдаёт URL/hostname сайта, поэтому HTTP-проверка каждого сайта отдельно не настраивается. Для проверки доступности конкретного сайта используйте отдельный хост Zabbix с шаблоном «Website by HTTP» или укажите URL сайта в {$TERMIDESK.PORTAL.USER.URL} (если сайт — это пользовательский портал).

Веб-порталы (опционально, через HTTP Agent):

Метрика Описание
Admin portal check Доступность портала администратора (GET на {$TERMIDESK.PORTAL.ADMIN.URL})
User portal check Доступность пользовательского портала (GET на {$TERMIDESK.PORTAL.USER.URL})

Триггеры (8 шт.):

Триггер Приоритет Условие
Health check FAILED HIGH status = fail
Health check WARNING WARNING status = warn
CPU usage critical HIGH CPU > 90% в течение 5 мин
CPU usage high WARNING CPU > 80% в течение 5 мин
Available memory critical HIGH Доступная память < 5%
Server restarted INFO uptime < 300 с
Admin portal unreachable WARNING нет данных 5 мин от портала администратора
User portal unreachable WARNING нет данных 5 мин от пользовательского портала

Termidesk Repeater (ретранслятор VDI)

Ретранслятор — компонент Termidesk VDI, обеспечивающий проксирование потоков данных между компонентами системы. Входит в лицензию VDI как feature Repeater (наряду с Remote Assistant, Scheduler, Branding). Настраивается через диспетчер (/api/webui/server/* — поля address, port, repeater_tag).

Ретранслятор предоставляет HTTP-сервер мониторинга в стиле Fluent Bit (порт 2020 по умолчанию). Шаблон Termidesk Repeater by HTTP опрашивает:

Endpoint Что возвращает
GET / Build info: версия, edition, flags (JSON)
GET /api/v1/uptime Uptime в секундах ({"uptime_sec": N})
GET /api/v1/metrics Метрики по плагинам: входы (input.*) и выходы (output.*) — master для LLD
GET /api/v1/storage Метрики storage layer: chunks (total/mem/fs/up/down)
GET /api/v2/health Health в JSON: status (ok/error), errors, retries_failed

Источник схемы: Fluent Bit Monitoring. Endpoint /api/v1/storage требует включённой опции storage.metrics в конфигурации SERVICE. Если опция выключена — storage-айтемы будут в состоянии Not supported (это ожидаемо).

Метрика Описание
Version Версия Repeater (Fluent Bit)
Health status ok / error
Errors Количество ошибок выходных плагинов
Retries failed Количество чанков, превышших лимит ретраев
Uptime Время работы, с
Storage: total / mem / fs / fs_up / fs_down Состояние буфера чанков

LLD: 2 правила — автообнаружение входных и выходных плагинов через $.input.keys() / $.output.keys(). Для каждого входа — records, bytes; для каждого выхода — proc_records, proc_bytes, errors, retries, retries_failed.

Триггеры (5 шт.):

Триггер Приоритет Условие
Health check FAILED HIGH status ≠ ok (HTTP 500 или status=error)
Output errors detected HIGH errors > {$REPEATER.ERRORS.CRIT} (по умолчанию 0 — любая ошибка)
Retries expired WARNING retries_failed > {$REPEATER.RETRIES_FAILED.WARN}
Restarted INFO uptime < {$REPEATER.UPTIME.MIN} (по умолчанию 300 с)
Filesystem chunks not loaded WARNING fs_chunks_down > 0 — backlog после рестарта

Шаблон не требует termidesk_api.sh — все опросы через HTTP Agent. JSONPath-выражения для dependent items фиксированы под схему Fluent Bit; при отклонениях скорректируйте preprocessing в Zabbix UI.

Termidesk Remote Assistant (удалённый помощник VDI)

Удалённый помощник — компонент Termidesk VDI для организации remote-ассистанса (подключения оператора helpdesk к сеансу пользователя). Входит в лицензию VDI как feature Remote Assistant (наряду с Repeater, Scheduler, Branding). Представляет собой Django-приложение с REST API.

В отличие от других компонентов VDI, у Remote Assistant ограниченный API: нет эндпоинтов /api/health/*, /api/health/metrics, licence info — только управление сессиями и список модулей. Аутентификация — Django CSRF-токен (временный, генерируется Django; статический токен невозможен).

Источник: SLET.10001-01 91 01 — API компонентов Termidesk VDI (раздел «Удалённый помощник», стр. 69).

Шаблон Termidesk Remote Assistant by HTTP мониторит доступность сервиса через два эндпоинта:

Endpoint Auth Что возвращает
GET /assistant/api/docs/ нет Swagger UI (HTML) — основная проверка доступности
GET /api/discover/ X-CSRFToken Список модулей API (JSON) — best-effort, опционально
Метрика Описание
Swagger UI check Тело страницы /assistant/api/docs/ (нет данных = сервис недоступен)
API discover Ответ /api/discover/ (список модулей при валидном CSRF, 403 — без него)
API modules count Количество модулей API (dependent, только при валидном CSRF-токене)

Триггеры (3 шт.):

Триггер Приоритет Условие
Service unreachable HIGH нет данных от /assistant/api/docs/ 5 мин
API discover endpoint unreachable WARNING нет данных от /api/discover/ 10 мин (403 из-за CSRF — не ошибка)
API modules count changed INFO количество модулей изменилось (только при валидном CSRF)

Шаблон не требует termidesk_api.sh — все опросы через HTTP Agent. CSRF-токен Django — временный (ограниченное время жизни). Макрос {$ASSISTANT.CSRF_TOKEN} опционален: без него шаблон мониторит только доступность через Swagger UI. Для мониторинга количества модулей API периодически обновляйте CSRF-токен (получается из cookie при GET любой страницы Django).

Termidesk Workplace Manager (менеджер рабочих мест VDI)

Менеджер рабочих мест — компонент Termidesk VDI, отвечающий за взаимодействие с поставщиком ресурсов и управление жизненным циклом РМ (создание, настройка, запуск, отключение, удаление). Является обработчиком фоновых задач. Устанавливается из пакета termidesk-vdi; состоит из двух служб systemd: termidesk-celery-beat (планировщик) и termidesk-celery-worker (исполнитель).

Каждая служба экспонирует health-endpoint, аналогичный Диспетчеру:

  • GET /api/health/check на порту 8103 (celery-beat)
  • GET /api/health/check на порту 8104 (celery-worker)
  • Auth: Authorization: Token <HEALTH_CHECK_ACCESS_KEY> (из termidesk.conf, тот же ключ что у Диспетчера)
  • Ответ: {"status":"pass|warn|fail","version":"...","description":"termidesk-celery","output":"..."}

Источник: Рекомендации по отслеживанию состояния компонентов Termidesk Конфиг: /etc/opt/termidesk-vdi/termidesk.conf — параметры CELERY_BEAT_HEALTH_CHECK_PORT (8103), CELERY_WORKER_HEALTH_CHECK_PORT (8104), HEALTH_CHECK_ACCESS_KEY, HEALTH_CHECK_CERT, HEALTH_CHECK_KEY.

Примечание: Менеджер рабочих мест не экспонирует /metrics endpoint (только health). Метрики узлов (CPU, RAM, disk) собираются celery-worker при опросе других компонентов и видны в UI Диспетчера, но не доступны напрямую через API Менеджера.

Метрика Описание
celery-beat health status pass / warn / fail (порт 8103)
celery-beat version Версия компонента
celery-beat health output Описание ошибки (при warn/fail)
celery-worker health status pass / warn / fail (порт 8104)
celery-worker version Версия компонента
celery-worker health output Описание ошибки (при warn/fail)

Триггеры (6 шт.):

Триггер Приоритет Условие
celery-beat unreachable HIGH нет данных от health check (8103) 5 мин
celery-beat health FAILED HIGH status = fail
celery-beat health WARNING WARNING status = warn
celery-worker unreachable HIGH нет данных от health check (8104) 5 мин
celery-worker health FAILED HIGH status = fail
celery-worker health WARNING WARNING status = warn

Шаблон не требует termidesk_api.sh — все опросы через HTTP Agent. Токен {$WM.HEALTH_TOKEN} — тот же HEALTH_CHECK_ACCESS_KEY из termidesk.conf, что используется для Диспетчера.

TermideskMQ (TMQ, брокер очереди сообщений)

TermideskMQ (TMQ) — экспериментальная собственная реализация брокера очереди сообщений от Termidesk (замена RabbitMQ в произвольной установке). Служба: termidesk-tmq. Протокол: tmqp:// (вместо amqp://). Порт по умолчанию: 6669 (настраивается через TMQ_BASE_PORT). Кластер из 1–3 узлов с mTLS.

В отличие от других компонентов Termidesk, TMQ не имеет HTTP health/metrics endpoint. Мониторинг через:

  • Zabbix agent: статус systemd-службы, количество процессов
  • Simple check: TCP-доступность порта 6669 с Zabbix server

Статусы узлов TMQ (Active/Down) видны в admin-UI Диспетчера: /admin/infrastructure/message-brokers (требует auth Диспетчера).

Метрика Тип Описание
Service ActiveState Zabbix agent systemd ActiveState: active / inactive / failed
Service SubState Zabbix agent systemd SubState: running / dead / failed
Service LoadState Zabbix agent systemd LoadState: loaded / not-found / masked
Process count Zabbix agent Количество процессов termidesk-tmq (fallback)
Broker port check Simple check TCP-доступность порта 6669 (1 = открыт, 0 = закрыт)
Broker port response time Simple check Время TCP-подключения к порту 6669 (с)

Триггеры (5 шт.):

Триггер Приоритет Условие
Service not active HIGH ActiveState ≠ active
Service FAILED HIGH SubState = failed
Broker port unreachable HIGH TCP-порт 6669 закрыт
No processes running HIGH Количество процессов = 0
Service not installed INFO LoadState = not-found (TMQ не установлен)

Внимание: TMQ использует mTLS — успешное TCP-подключение к порту 6669 не гарантирует что брокер здоров, только что он слушает порт. Для полной проверки статуса узлов (Active/Down) и сертификатов используйте admin-UI Диспетчера или мониторинг broker.log.

Требуется Zabbix agent на хосте с TMQ (для systemd/process checks). TCP-проверки (Simple checks) выполняются с Zabbix server.

Шаблон не требует termidesk_api.sh.

Termidesk Connect (балансировщик нагрузки / ADC)

Termidesk Connect — отдельный продукт линейки Termidesk: контроллер доставки приложений (ADC), обеспечивающий балансировку нагрузки, высокую доступность, SSL-терминирование, геобалансировку (GSLB/RHI) и защиту от DDoS. Может работать в режимах: балансировщик, шлюз (см. ниже), глобальный балансировщик. Поддерживаются Connect 1.3 / 1.4.

Шаблон Termidesk Connect by HTTP мониторит сам инстанс Connect (а не балансируемые им бэкенды). Источники метрик:

  • WUI (веб-интерфейс управления): https://<IP-управления>/ — проверка HTTP-доступности.
  • Статистика по HTTP: https://<IP-управления>/metrics?format=json — метрики в JSON (мастер-айтем для dependent items и LLD). Альтернативно — https://<IP-управления>/metrics (OpenMetrics, для Prometheus).
  • SNMP и API конфигурации — дополнительные опции, не используются в шаблоне напрямую (можно привязать стандартные SNMP-шаблоны Zabbix).
Метрика Описание
WUI check Доступность веб-интерфейса управления
Metrics raw Сырой JSON с /metrics (master item)
Uptime Время работы, с
CPU total Загрузка процессора, %
Memory total / available Оперативная память, байт
Version Версия Connect
HA status / role Статус кластера HA и роль узла (active/standby)

Точная JSON-схема /metrics публично не документирована. Dependent items используют JSONPath «best-effort» ($.uptime_seconds, $.cpu_total_percent и т.п.). Если ваша версия Connect отдаёт другую структуру — скорректируйте JSONPath в preprocessing в Zabbix UI (Configuration → Hosts → <хост> → Items → → Preprocessing).

LLD: автообнаружение виртуальных серверов Connect (статус, количество соединений) через $.virtual_servers[*] — также best-effort; при несовпадении схемы поправьте lld_macro_paths в правиле обнаружения.

Триггеры (6 шт.):

Триггер Приоритет Условие
WUI unreachable WARNING нет данных 5 мин от WUI
CPU usage critical HIGH CPU > 90% в течение 5 мин
CPU usage high WARNING CPU > 80% в течение 5 мин
Available memory critical HIGH Доступная память < 5%
HA not active WARNING HA status ≠ active/ok
Restarted INFO uptime < 300 с

Termidesk Gateway (Шлюз для VDI — в Connect)

Шлюз — это режим работы Termidesk Connect, в котором он выступает единой точкой входа для Termidesk VDI: SSL-терминирование, аутентификация пользователей, маршрутизация подключений к ВРМ через RabbitMQ.

Шаблон Termidesk Gateway by HTTP опрашивает health-эндпоинты Шлюза, которые совпадают по структуре с Termidesk VDI:

  • GET /api/health — статус (pass/warn/fail), заголовок Authorization: Token <HEALTH_CHECK_ACCESS_KEY>
  • GET /api/health/metrics — детальные метрики, заголовок Authorization: Token <METRICS_ACCESS_KEY>

Токены берутся из /etc/opt/termidesk-vdi/termidesk.conf диспетчера Termidesk, перед которым стоит Шлюз (параметры HEALTH_CHECK_ACCESS_KEY и METRICS_ACCESS_KEY — те же, что использует шаблон диспетчера). Источник: документация Connect — Сбор статистики Шлюза.

Метрика Описание
Health check GET /api/health (статус)
Health metrics GET /api/health/metrics (мастер-айтем)
Health status pass / warn / fail
Server uptime Время работы Шлюза, с
CPU total Загрузка процессора, %
Memory total / available / used Оперативная память, байт
User / Admin sessions Активные сессии
Gateway version Версия

Триггеры (6 шт.):

Триггер Приоритет Условие
Health check FAILED HIGH status = fail
Health check WARNING WARNING status = warn
CPU usage critical HIGH CPU > 90% в течение 5 мин
CPU usage high WARNING CPU > 80% в течение 5 мин
Available memory critical HIGH Доступная память < 5%
Restarted INFO uptime < 300 с

Шаблон Шлюза не требует termidesk_api.sh — все опросы идут через HTTP Agent напрямую. Это полезно, когда Connect стоит перед диспетчером и вы хотите отдельно видеть состояние точки входа (Connect/Шлюз) и бэкенда (Диспетчер).

Графики

Шаблоны включают готовые графики для всех числовых метрик — всего 39 графиков в 15 шаблонах. Графики доступны в Zabbix UI: Monitoring → Hosts → Graphs (или Latest data → график у конкретного элемента).

Типы графиков:

  • normal — обычный линейный график (по умолчанию).
  • stacked — график с накоплением; несколько значений складываются в общую картину (удобно для счётчиков сессий, chunks хранения, дискового I/O).

HTTP Agent шаблоны

Шаблон Графиков Графики
Dispatcher by HTTP 6 CPU usage; Memory usage (total/used/available); Virtual machines (total/failed/stuck); Active sessions, stacked (user/admin); Server uptime; License quantity
Aggregator by HTTP 5 CPU usage; Memory usage (total/available); Active sessions, stacked (user/admin); Infrastructure counts (farms/sites/servers); Server uptime
Repeater by HTTP 3 Storage chunks, stacked (total/mem/fs/fs_up/fs_down); Errors & retries (errors/retries_failed); Uptime
Connect by HTTP 3 CPU usage; Memory usage (total/available); Uptime
Gateway by HTTP 4 CPU usage; Memory usage (total/used/available); Active sessions, stacked (user/admin); Uptime
Session Agent by HTTP 7 CPU usage; Memory usage (total/used/available/free); Disk space (total/used/free); Disk I/O operations, stacked (read/write); Disk I/O bytes, stacked (read/write); Sessions; Uptime
VDI Agent by HTTP 7 CPU usage; Memory usage (total/used/available/free); Disk space (total/used/free); Disk I/O operations, stacked (read/write); Disk I/O bytes, stacked (read/write); Sessions; Uptime

Zabbix agent шаблоны

Шаблон Графиков Графики
Dispatcher by Zabbix agent 1 Process count
Aggregator by Zabbix agent 1 Process count
Remote Assistant by Zabbix agent 1 Process count
Gateway by Zabbix agent 1 Process count
Repeater by Zabbix agent 1 Process count
Workplace Manager by Zabbix agent 1 Process counts, 2 службы (celery-beat + celery-worker)
Session Agent by Zabbix agent 1 Process count
VDI Agent by Zabbix agent 1 Process count
Virtualization Node Agent by Zabbix agent 2 Process count; RPC port response time
STAL by Zabbix agent 2 Process counts, 2 службы (stal-service + stal-session-manager); RDP port response time
TermideskMQ by Zabbix agent 2 Process count; Broker port response time

Шаблоны Workplace Manager by HTTP и Remote Assistant by HTTP графиков не содержат — в них только текстовые метрики (health status, version, output), которые не отображаются на графиках.

Графики Zabbix agent-шаблонов можно комбинировать с графиками HTTP Agent-шаблонов на одном хосте (ключи элементов уникальны, конфликтов нет). Например, на хосте Dispatcher’а будут видны и CPU usage (из HTTP шаблона), и Process count (из agent-шаблона).

Установка

Шаг 1. Установка внешнего скрипта

Скопируйте termidesk_api.sh на сервер Zabbix в директорию externalscripts:

cp externalscripts/termidesk_api.sh /usr/lib/zabbix/externalscripts/
chmod +x /usr/lib/zabbix/externalscripts/termidesk_api.sh

Проверьте зависимости на сервере Zabbix:

curl --version    # обычно уже установлен
python3 --version # нужен для парсинга JSON

Шаг 2. Получение токенов здоровья

На каждом сервере Termidesk (диспетчер и агрегатор) выполните:

sudo cat /etc/opt/termidesk-vdi/termidesk.conf | grep -E 'HEALTH_CHECK|METRICS_ACCESS'

Запишите значения HEALTH_CHECK_ACCESS_KEY и METRICS_ACCESS_KEY — они потребуются для макросов шаблона.

Если ключей в конфиге нет, добавьте их:

HEALTH_CHECK_ACCESS_KEY = <произвольная_строка>
METRICS_ACCESS_KEY = <произвольная_строка>

и перезапустите сервис:

sudo systemctl restart termidesk-vdi

Шаг 3. Определение auth_id (только для входа по логину/паролю)

Если вы планируете использовать готовый X-Auth-Token (Шаг 3а) — этот шаг можно пропустить: auth_id нужен только для запроса /login, который в режиме токена скрипт не выполняет.

auth_id — это идентификатор домена аутентификации, который используется для входа в REST API. Узнайте его, выполнив запрос на сервере Termidesk:

curl -sk https://<URL_ТЕРМИДЕСКА>/api/auth/v7.0/authenticators

Ответ:

[
  {"authId": 1, "authSmallName": "builtin", "auth": "Встроенный", ...},
  {"authId": 2, "authSmallName": "rad", "auth": "RADIUS", ...}
]

Запомните authId для нужного домена (обычно 1 для «Встроенного»).

Шаг 3а. Получение X-Auth-Token (рекомендуется)

X-Auth-Token — это идентификатор HTTP-сессии Termidesk, который скрипт будет передавать в заголовке запросов к /api/webui/*. Получить его можно одноразовым запросом к /login:

curl -sk -X POST -H "Content-Type: application/json" \
  -d '{"username":"<логин>","password":"<пароль>","auth":1}' \
  https://<URL_ТЕРМИДЕСКА>/api/auth/v7.0/login

Ответ:

{"result":"ok","token":"<токен_аутентификации>","suid":"<id_сессии>"}

Значение поля token запишите в макрос {$TERMIDESK.AUTH_TOKEN}.

Срок действия токена определяется политикой сессий Termidesk. По истечении получите новый токен и обновите макрос. Альтернатива — оставить {$TERMIDESK.AUTH_TOKEN} пустым и заполнить USERNAME/PASSWORD/AUTH_ID: скрипт будет логиниться сам и кэшировать токен на 5 минут.

Шаг 4. Импорт шаблона в Zabbix

  1. Откройте Zabbix UI: Configuration → Templates → Import.
  2. Выберите файл template_termidesk_dispatcher.xml или template_termidesk_aggregator.xml из директории, соответствующей вашей версии Zabbix (zabbix-6.0/http_agent или zabbix-7.0/http_agent).
  3. Поставьте галочку Update existing (для обновления в будущем).
  4. Нажмите Import.

Шаг 5. Создание хоста и настройка макросов

  1. Configuration → Hosts → Create host.
  2. Укажите имя хоста (например, Termidesk Dispatcher).
  3. В поле Templates выберите Termidesk Dispatcher by HTTP (или Termidesk Aggregator by HTTP).
  4. В разделе Macros задайте:
Макрос Значение Пример
{$TERMIDESK.URL} Базовый URL Termidesk https://disp.termidesk.local
{$TERMIDESK.AUTH_TOKEN} Готовый X-Auth-Token (предпочтительно) <токен_из_ответа_/login>
{$TERMIDESK.USERNAME} Логин администратора (опционально, если задан AUTH_TOKEN) <логин_администратора>
{$TERMIDESK.PASSWORD} Пароль администратора (опционально, если задан AUTH_TOKEN) <пароль_администратора>
{$TERMIDESK.AUTH_ID} ID домена аутентификации (только для login) 1
{$TERMIDESK.API_VERSION} Версия auth API (только для login) v7.0
{$TERMIDESK.HEALTH_TOKEN} HEALTH_CHECK_ACCESS_KEY <ключ_из_termidesk.conf>
{$TERMIDESK.METRICS_TOKEN} METRICS_ACCESS_KEY <ключ_из_termidesk.conf>
{$TERMIDESK.PORTAL.ADMIN.URL} URL портала администратора (опционально) https://disp.termidesk.local/admin/
{$TERMIDESK.PORTAL.USER.URL} URL пользовательского портала (опционально) https://portal.termidesk.local/

Аутентификация для /api/webui/* выбирается автоматически: если задан {$TERMIDESK.AUTH_TOKEN} — он используется напрямую как X-Auth-Token (без запросов к /login). Если пустой — скрипт логинится по USERNAME/PASSWORD/AUTH_ID и кэширует токен на 5 минут. Подробнее — см. раздел «Аутентификация по X-Auth-Token».

Макросы PORTAL.*.URL опциональны. Если оставить их пустыми — соответствующие айтемы перейдут в Not supported, а триггеры нужно отключить вручную (см. раздел «Мониторинг порталов за балансировщиком»).

  1. Нажмите Add.

Шаг 6. Проверка

  1. Откройте Monitoring → Latest data, выберите созданный хост.
  2. Через 1–2 минуты должны появиться данные:
    • Termidesk: Health status = pass
    • Termidesk: Server uptime = число секунд
    • Termidesk: Pools count = количество ферм
  3. Откройте Configuration → Hosts → Discovery, убедитесь что LLD-правила нашли фермы, узлы и сессии.

Если данные не появились — см. раздел «Устранение неисправностей» ниже.

Установка шаблонов Termidesk Connect и Шлюза

Шаблоны Termidesk Connect by HTTP и Termidesk Gateway by HTTP не требуют termidesk_api.sh — все опросы выполняются через HTTP Agent напрямую из Zabbix-сервера.

Импорт

  1. Configuration → Templates → Import.
  2. Выберите template_termidesk_connect.xml и/или template_termidesk_gateway.xml из директории вашей версии Zabbix (zabbix-6.0/http_agent или zabbix-7.0/http_agent).
  3. Галочка Update existing — для обновления в будущем.
  4. Import.

Настройка хоста Connect

  1. Configuration → Hosts → Create host, имя — например Termidesk Connect.
  2. Привяжите шаблон Termidesk Connect by HTTP.
  3. Макросы:
Макрос Значение Пример
{$CONNECT.URL} URL управления Connect (WUI) https://connect-mgmt.termidesk.local
{$CONNECT.CPU.CRIT} порог CPU %, HIGH 90
{$CONNECT.CPU.WARN} порог CPU %, WARNING 80
{$CONNECT.MEM.AVAIL.CRIT} порог доступной памяти %, HIGH 5
{$CONNECT.MEM.AVAIL.WARN} порог доступной памяти %, WARNING 10
  1. Проверьте: через 1–2 минуты в Latest data должны появиться Termidesk Connect: WUI check и Termidesk Connect: Metrics raw.
  2. Если dependent-айтемы (CPU, memory, HA) показывают Not supported — откройте Metrics raw, посмотрите структуру JSON и скорректируйте JSONPath в preprocessing соответствующих dependent items.

Настройка хоста Шлюза

  1. Configuration → Hosts → Create host, имя — например Termidesk Gateway.
  2. Привяжите шаблон Termidesk Gateway by HTTP.
  3. Макросы:
Макрос Значение Пример
{$GATEWAY.URL} URL управления Шлюзом https://gw.termidesk.local
{$GATEWAY.HEALTH_TOKEN} HEALTH_CHECK_ACCESS_KEY из termidesk.conf диспетчера <ключ_из_termidesk.conf>
{$GATEWAY.METRICS_TOKEN} METRICS_ACCESS_KEY из termidesk.conf диспетчера <ключ_из_termidesk.conf>
{$GATEWAY.CPU.CRIT} порог CPU %, HIGH 90
{$GATEWAY.CPU.WARN} порог CPU %, WARNING 80
{$GATEWAY.MEM.AVAIL.CRIT} порог доступной памяти %, HIGH 5
{$GATEWAY.MEM.AVAIL.WARN} порог доступной памяти %, WARNING 10
  1. Проверьте: Termidesk Gateway: Health status должен показать pass.

Токены HEALTH_CHECK_ACCESS_KEY и METRICS_ACCESS_KEY совпадают с теми, что используются в шаблоне диспетчера Termidesk VDI — Шлюз и диспетчер делят эти ключи. Не путать с токенами самого Connect (для его /metrics-эндпоинта токен не требуется — он открытый, если не настроена аутентификация через AAA).

Комбинирование с шаблонами VDI

Типовая схема мониторинга полного стека Termidesk:

Хост Zabbix Шаблон Что контролирует
Termidesk Connect Connect by HTTP Инстанс ADC: WUI, /metrics, HA
Termidesk Gateway Gateway by HTTP Режим Шлюза: /api/health/* (точка входа VDI)
Termidesk Dispatcher Dispatcher by HTTP Бэкенд VDI: пулы, сессии, лицензия
Termidesk Aggregator Aggregator by HTTP Агрегатор VDI: фермы, сайты

Если Connect работает только как Шлюз (без отдельных функций балансировки), достаточно одного хоста Termidesk Gateway. Если Connect одновременно балансирует порталы и работает как Шлюз — создайте два хоста на один IP с разными шаблонами, либо используйте один хост с обоими шаблонами (макросы {$CONNECT.URL} и {$GATEWAY.URL} могут совпадать).

Установка шаблона Termidesk Repeater

Шаблон Termidesk Repeater by HTTP не требует termidesk_api.sh — все опросы через HTTP Agent.

Предварительная настройка Repeater

На стороне ретранслятора должен быть включён HTTP-сервер мониторинга. В конфигурации Fluent Bit (SERVICE-секция):

[SERVICE]
  HTTP_Server  On
  HTTP_Listen  0.0.0.0
  HTTP_Port    2020
  storage.metrics  On

storage.metrics On — опционально, но включена для работы storage-айтемов. Без неё /api/v1/storage вернёт пустой ответ, и dependent items перейдут в Not supported.

Проверьте доступность с сервера Zabbix:

curl -s http://<IP_ретранслятора>:2020/api/v2/health
# Ожидаемый ответ: {"status":"ok","errors":0,"retries_failed":0,...}

curl -s http://<IP_ретранслятора>:2020/api/v1/uptime
# Ожидаемый ответ: {"uptime_sec": 12345}

Импорт и настройка хоста

  1. Configuration → Templates → Import — выберите template_termidesk_repeater.xml из директории вашей версии Zabbix (zabbix-6.0/http_agent или zabbix-7.0/http_agent).
  2. Configuration → Hosts → Create host, имя — например Termidesk Repeater.
  3. Привяжите шаблон Termidesk Repeater by HTTP.
  4. Макросы:
Макрос Значение Пример
{$REPEATER.URL} URL HTTP-сервера мониторинга http://repeater.termidesk.local:2020
{$REPEATER.ERRORS.CRIT} порог errors для HIGH-триггера 0 (любая ошибка)
{$REPEATER.RETRIES_FAILED.WARN} порог retries_failed для WARNING 0
{$REPEATER.UPTIME.MIN} минимальный uptime для INFO-триггера 300
  1. Проверьте: через 1–2 минуты в Latest data должны появиться Termidesk Repeater: Health status = ok, Uptime, Version.
  2. В Discovery убедитесь, что LLD нашли input/output плагины.

Если LLD не находит плагины — откройте Metrics raw и сверьте структуру JSON. Имена ключей могут отличаться в разных версиях Fluent Bit; скорректируйте lld_macro_paths ($.input.keys() / $.output.keys()) в правиле обнаружения.

Установка шаблона Termidesk Remote Assistant

Шаблон Termidesk Remote Assistant by HTTP не требует termidesk_api.sh — все опросы через HTTP Agent.

Предварительная настройка

Remote Assistant — Django-приложение. Для мониторинга достаточно, чтобы веб-сервис был доступен с сервера Zabbix по HTTPS.

Проверьте доступность Swagger UI (без аутентификации):

curl -sk https://assistant.termidesk.local/assistant/api/docs/
# Ожидается: HTML-страница Swagger UI

Для опционального мониторинга списка модулей API получите CSRF-токен:

# CSRF-токен устанавливается в cookie при GET любой страницы Django
curl -sk -c /tmp/cookies.txt https://assistant.termidesk.local/assistant/api/docs/
grep csrftoken /tmp/cookies.txt | awk '{print $7}'
# Полученный токен вставьте в макрос {$ASSISTANT.CSRF_TOKEN}

CSRF-токен Django — временный (ограниченное время жизни). Если токен истёк, /api/discover/ вернёт 403 — шаблон продолжит мониторить доступность через Swagger UI. Dependent item API modules count перейдёт в Not supported (ожидаемо).

Импорт и настройка хоста

  1. Configuration → Templates → Import — выберите template_termidesk_assistant.xml из директории вашей версии Zabbix (zabbix-6.0/http_agent или zabbix-7.0/http_agent).
  2. Configuration → Hosts → Create host, имя — например Termidesk Remote Assistant.
  3. Привяжите шаблон Termidesk Remote Assistant by HTTP.
  4. Макросы:
Макрос Обязательный Значение Пример
{$ASSISTANT.URL} да Базовый URL компонента https://assistant.termidesk.local
{$ASSISTANT.CSRF_TOKEN} нет X-CSRFToken для /api/discover/ (из cookie Django)
  1. Проверьте: через 1–2 минуты в Latest data должен появиться Termidesk Assistant: Swagger UI check (тело HTML-страницы). Если задан {$ASSISTANT.CSRF_TOKEN} — также API discover и API modules count.

Установка шаблона Termidesk Workplace Manager

Шаблон Termidesk Workplace Manager by HTTP не требует termidesk_api.sh — все опросы через HTTP Agent.

Предварительная настройка

Менеджер рабочих мест состоит из двух служб: termidesk-celery-beat (планировщик, порт 8103) и termidesk-celery-worker (исполнитель, порт 8104). Health-check endpoint включается в /etc/opt/termidesk-vdi/termidesk.conf:

CELERY_BEAT_HEALTH_CHECK_PORT=8103
CELERY_BEAT_HEALTH_CHECK_IP='0.0.0.0'
CELERY_WORKER_HEALTH_CHECK_PORT=8104
CELERY_WORKER_HEALTH_CHECK_IP='0.0.0.0'
HEALTH_CHECK_ACCESS_KEY="<секретный_ключ>"
HEALTH_CHECK_CERT=/etc/opt/termidesk-vdi/healthcheck.pem
HEALTH_CHECK_KEY=/etc/opt/termidesk-vdi/healthcheck-decrypted.key

После изменения конфигурации перезапустите службы:

sudo systemctl restart termidesk-celery-beat termidesk-celery-worker

Проверьте доступность с сервера Zabbix:

# celery-beat (порт 8103)
curl --insecure -s "https://wm.termidesk.local:8103/api/health/check" \
  -H 'accept: application/json' \
  -H "Authorization: Token <HEALTH_CHECK_ACCESS_KEY>"
# Ожидаемый ответ: {"status":"pass","version":"...","description":"termidesk-celery","output":""}

# celery-worker (порт 8104)
curl --insecure -s "https://wm.termidesk.local:8104/api/health/check" \
  -H 'accept: application/json' \
  -H "Authorization: Token <HEALTH_CHECK_ACCESS_KEY>"

Источник: Рекомендации по отслеживанию состояния компонентов Termidesk

Импорт и настройка хоста

  1. Configuration → Templates → Import — выберите template_termidesk_workplace_manager.xml из директории вашей версии Zabbix (zabbix-6.0/http_agent или zabbix-7.0/http_agent).
  2. Configuration → Hosts → Create host, имя — например Termidesk Workplace Manager.
  3. Привяжите шаблон Termidesk Workplace Manager by HTTP.
  4. Макросы:
Макрос Обязательный Значение Пример
{$WM.URL} да Базовый URL узла Менеджера https://wm.termidesk.local
{$WM.HEALTH_TOKEN} да HEALTH_CHECK_ACCESS_KEY из termidesk.conf 9944b09199c62bcf9418ad846dd0e4bbdfc6ee4b
{$WM.BEAT.PORT} нет Порт celery-beat 8103 (по умолчанию)
{$WM.WORKER.PORT} нет Порт celery-worker 8104 (по умолчанию)
  1. Проверьте: через 1–2 минуты в Latest data должны появиться celery-beat health status = pass и celery-worker health status = pass.

{$WM.HEALTH_TOKEN} — тот же HEALTH_CHECK_ACCESS_KEY из termidesk.conf, что используется для Диспетчера. Если Диспетчер и Менеджер РМ на одном хосте — токен общий.

Установка шаблона TermideskMQ

Шаблон TermideskMQ by Zabbix agent требует Zabbix agent на хосте с TMQ (для systemd/process checks). TCP-проверки порта выполняются с Zabbix server.

Предварительная настройка

TMQ — экспериментальный компонент, устанавливается ролью TERMQ в произвольной установке Termidesk. Служба: termidesk-tmq.service.

Проверьте что служба запущена и порт доступен:

# На хосте с TMQ
sudo systemctl status termidesk-tmq.service
# Active: active (running) — служба работает

# Порт брокера (по умолчанию 6669)
ss -tlnp | grep 6669
# Ожидается: LISTEN 0.0.0.0:6669 (или 127.0.0.1:6669)

Если порт отличается от 6669 (параметр TMQ_BASE_PORT в termidesk.conf) — переопределите макрос {$TMQ.PORT} на уровне хоста.

Импорт и настройка хоста

  1. Configuration → Templates → Import — выберите template_termidesk_tmq.xml из директории вашей версии Zabbix (zabbix-6.0/zabbix_agent или zabbix-7.0/zabbix_agent).
  2. Configuration → Hosts → Create host, имя — например TermideskMQ.
  3. Привяжите шаблон TermideskMQ by Zabbix agent.
  4. Настройте интерфейс Zabbix agent на хосте:
    • Agent interface: IP/FQDN хоста с TMQ, порт 10050 (по умолчанию).
  5. Макросы:
Макрос Обязательный Значение Пример
{$TMQ.HOST} да IP/FQDN хоста с TMQ (для TCP-проверок) 127.0.0.1 или tmq.termidesk.local
{$TMQ.PORT} нет TCP-порт брокера (TMQ_BASE_PORT) 6669 (по умолчанию)
  1. Проверьте: через 1–2 минуты в Latest data должны появиться:
    • Service ActiveState = active
    • Service SubState = running
    • Broker port check = 1
    • Process count ≥ 1

Внимание: TMQ использует mTLS — успешная TCP-проверка порта не гарантирует здоровье брокера. Для полной диагностики проверяйте broker.log на ошибки TLS/DB и используйте admin-UI Диспетчера (/admin/infrastructure/message-brokers) для просмотра статусов узлов (Active/Down) и сертификатов.

Если TMQ не установлен (используется RabbitMQ) — снимите шаблон с хоста или отключите. Триггер Service not installed (INFO) сработает, если служба не обнаружена.

Настройка порогов

Пороги срабатывания триггеров настраиваются через макросы хоста или шаблона:

Макрос По умолчанию Описание
{$TERMIDESK.CPU.CRIT} 90 CPU %, критический уровень (HIGH)
{$TERMIDESK.CPU.WARN} 80 CPU %, повышенный уровень (WARNING)
{$TERMIDESK.MEM.AVAIL.CRIT} 5 Доступная память %, критический уровень
{$TERMIDESK.MEM.AVAIL.WARN} 10 Доступная память %, повышенный уровень

Для изменения переопределите макросы на уровне хоста: Configuration → Hosts → <хост> → Macros.

Версии API Termidesk

Шаблон поддерживает Termidesk 6.1 / 7.0 / 7.1 через макрос {$TERMIDESK.API_VERSION}. Версия определяет путь auth-эндпоинта: /api/auth/{версия}/login.

Termidesk Рекомендуемая версия API Макрос
6.1 v6.1 {$TERMIDESK.API_VERSION} = v6.1
7.0 v7.0 {$TERMIDESK.API_VERSION} = v7.0
7.1 v7.0 или v7.1 {$TERMIDESK.API_VERSION} = v7.0

Health-эндпоинты (/api/health/*) не версионированы и работают на всех версиях.

Аутентификация по X-Auth-Token

Для доступа к модулям раздела webui (/api/webui/server/*, /api/webui/aggregator/*) Termidesk использует схему userTokenAuth (на v6.1 — legacyTokenAuth): API-key в HTTP-заголовке X-Auth-Token: <значение>. Это идентификатор HTTP-сессии пользователя, получаемый через модуль auth по URL /login.

Параметр схемы Значение
Имя схемы (OpenAPI) userTokenAuth (v7.x) / legacyTokenAuth (v6.1)
Тип apiKey
Имя заголовка X-Auth-Token
Расположение header
Где действует только модули раздела webui

Важно: X-Auth-Token не применяется к health-эндпоинтам. Для /api/health/check и /api/health/metrics используется схема healthTokenAuth / metricTokenAuth — заголовок Authorization: Token <HEALTH_CHECK_ACCESS_KEY> или Token <METRICS_ACCESS_KEY> (см. Шаг 2 установки).

Получение токена

Токен выдаётся эндпоинтом POST /api/auth/{api_version}/login:

curl -sk -X POST -H "Content-Type: application/json" \
  -d '{"username":"<логин>","password":"<пароль>","auth":1}' \
  https://<URL_ТЕРМИДЕСКА>/api/auth/v7.0/login

Тело запроса (LegacyLoginRequest):

Поле Тип Обязательное Описание
username string да Логин пользователя
password string да Пароль пользователя
auth string нет Название домена аутентификации
authId string (uuid) нет UUID домена аутентификации
authSmallName string нет Короткое название домена аутентификации

Один из идентификаторов домена (auth / authId / authSmallName) передаётся в макросе {$TERMIDESK.AUTH_ID}. Скрипт termidesk_api.sh подставляет его в поле auth как число (например, 1 для встроенного домена — authId из GET /api/auth/{api_version}/authenticators).

Успешный ответ 200 OK (LegacyLoginSuccess):

{
  "result": "ok",
  "token": "<токен_аутентификации>",
  "suid": "8f3c1b2a-..."
}
Поле Описание
result Статус ответа (ok)
token Токен аутентификации — подставляется в заголовок X-Auth-Token
suid Уникальный идентификатор сессии

Двухфакторная аутентификация (2FA)

Если на домене включён 2FA, ответ на /login будет 202 Accepted с указанием, что требуется второй фактор. Для завершения входа выполните POST /api/auth/{api_version}/login/2fa с телом FactorRequest (одноразовый код / второй фактор). Успешный ответ 200 OK возвращает ту же структуру с token и suid.

Скрипт termidesk_api.sh не поддерживает 2FA. Для мониторинга используйте домен аутентификации с отключённым 2FA (обычно встроенный домен builtin с authId=1).

Использование токена

Полученный token передаётся во всех последующих запросах к разделу webui:

curl -sk -H "X-Auth-Token: <ТОКЕН>" \
  https://<URL>/api/webui/server/servicespools?page_size=500

Скрипт termidesk_api.sh делает это в функции api_get() — подставляет токен в заголовок X-Auth-Token для всех вызовов /api/webui/*.

Время жизни токена и кэширование

Срок действия токена определяется сервером Termidesk (политика сессий HTTP). Скрипт кэширует токен в /tmp/termidesk_token_<hash>.cache с локальным TTL 300 с — то есть переиспользует его в течение 5 минут, после чего перевыпускает через /login. Это уменьшает нагрузку на auth-модуль и не создаёт лишних сессий. Подробнее — см. раздел «Кэширование токена».

При ошибке 401 Unauthorized (токен отозван / истекла сессия на стороне сервера) достаточно удалить файл кэша:

rm /tmp/termidesk_token_*.cache

и скрипт перевыпустит токен при следующем вызове.

Мониторинг порталов за балансировщиком

Веб-порталы администратора и пользователя Termidesk часто скрыты за балансировщиком нагрузки. В качестве балансировщика может выступать Termidesk Connect (родной продукт линейки Termidesk — решение для балансировки нагрузки и обеспечения высокой доступности), либо сторонний LB (HAProxy, NGINX, REngine и т.п.).

Шаблон поддерживает этот сценарий через макросы {$TERMIDESK.PORTAL.ADMIN.URL} и {$TERMIDESK.PORTAL.USER.URL} — они указывают на любой URL (виртуальный IP балансировщика или прямой сервер), а Zabbix делает к ним обычный GET-запрос.

Termidesk Connect — это отдельный продукт, не входящий в REST API Termidesk VDI. Помимо балансировки порталов он может выступать как Шлюз для Termidesk VDI, выполнять SSL Offload, предаутентификацию и т.п. У Connect есть собственный интерфейс мониторинга — см. Сценарий 4.

Сценарий 1. Порталы за балансировщиком (один виртуальный IP)

Типовая конфигурация: балансировщик (Termidesk Connect или сторонний) терминирует TLS и раскладывает запросы по нескольким нодам Termidesk.

                    ┌──────────────────────────┐
   пользователи ──► │  LB: portal.example       │ ──► нода 1 (Termidesk VDI)
                    │  Termidesk Connect / HAProxy│ ──► нода 2 (Termidesk VDI)
                    └──────────────────────────┘ ──► нода N (Termidesk VDI)
                              │
                              ├─ /admin/  → портал администратора
                              └─ /        → пользовательский портал

В этом случае:

  • {$TERMIDESK.URL} — прямой URL одной ноды для API-опроса (health + webui). Health-токены берутся с этой конкретной ноды.
  • {$TERMIDESK.PORTAL.ADMIN.URL} — URL балансировщика для портала администратора, например https://portal.example/admin/.
  • {$TERMIDESK.PORTAL.USER.URL} — URL балансировщика для пользовательского портала, например https://portal.example/.

Мониторинг будет показывать сквозную доступность: LB + бэкенд. Если упадёт конкретная нода за LB, но балансировщик это компенсирует — портал останется «доступным» с точки зрения Zabbix. Для поузлового контроля создайте отдельные хосты Zabbix (см. Сценарий 2).

Сценарий 2. Поузловой мониторинг порталов (без LB)

Если нужно видеть состояние каждой ноды Termidesk отдельно:

  • Создайте по хосту Zabbix на каждую ноду Termidesk.
  • На каждом хосте в {$TERMIDESK.PORTAL.ADMIN.URL} / {$TERMIDESK.PORTAL.USER.URL} укажите прямой URL ноды.
  • {$TERMIDESK.URL} тоже указывает на прямую ноду.

Этот вариант даёт гранулярность по нодам, но не проверяет балансировщик. Для полноты комбинируйте: один хост мониторит LB (Сценарий 1), плюс по хосту на каждую ноду (Сценарий 2), плюс один хост мониторит сам Connect (Сценарий 4).

Сценарий 3. Портал администратора и пользователя на разных URL

В Termidesk админский и пользовательский порталы могут быть разнесены по разным поддоменам/портам/путям (разные виртуальные серверы на балансировщике). Макросы независимы — задайте каждый URL отдельно:

Макрос Пример
{$TERMIDESK.PORTAL.ADMIN.URL} https://admin.termidesk.local/
{$TERMIDESK.PORTAL.USER.URL} https://vdi.termidesk.local/

Сценарий 4. Мониторинг самого Termidesk Connect

Termidesk Connect — это балансировщик, и его нужно мониторить как отдельный сервис. В шаблоне Termidesk VDI для него нет отдельных макросов, но Connect предоставляет собственный интерфейс статистики по HTTP:

  • https://<IP-адрес_управления>/metrics — метрики в формате OpenMetrics (для Prometheus-совместимых систем);
  • https://<IP-адрес_управления>/metrics?format=json — метрики в формате JSON.

Также Connect поддерживает SNMP и имеет веб-интерфейс управления (WUI) с панелью мониторинга и производительности.

Варианты мониторинга Connect из Zabbix:

Вариант A. Отдельный хост с шаблоном «Website by HTTP» (базовая проверка). Создайте хост Zabbix Termidesk Connect, привяжите стандартный шаблон «Website by HTTP» (поставляется с Zabbix). В макросе {$WEBSITE.URL} укажите адрес WUI Connect, например https://connect-mgmt.example/. Это даст базовый контроль: «жив ли веб-интерфейс Connect», время ответа, код HTTP.

Вариант B. Сбор метрик через /metrics (рекомендуется). На отдельном хосте Termidesk Connect создайте HTTP Agent item:

  • key: connect.metrics
  • URL: https://<IP-адрес_управления>/metrics?format=json
  • тип: TEXT, интервал 1m

Из полученного JSON через Dependent items + JSONPath预处理 можно собрать детальные метрики: состояние виртуальных серверов, реальных серверов, профилей, сессий, балансировки. Либо используйте формат OpenMetrics (/metrics без ?format=json) вместе с Zabbix-шаблоном для Prometheus («Prometheus by HTTP» — если в вашей инсталляции Zabbix он доступен).

Вариант C. SNMP. Connect поддерживает SNMP — можно привязать к хосту стандартный шаблон «Generic by SNMP» / «Network Generic Device by SNMP» и собирать системные метрики (трафик интерфейсов, аптайм и т.п.).

Вариант D. Дополнительный HTTP Agent item на хосте Termidesk VDI. Если хостов плодить не хочется, на существующем хосте Termidesk создайте item типа HTTP Agent:

  • key: termidesk.connect.check
  • URL: https://<IP-адрес_управления_Connect>/
  • триггер: nodata(/Host by HTTP/termidesk.connect.check,5m)=1.

Это не переживает реимпорт шаблона (item ручной), но быстро даёт базовую проверку «жив ли Connect».

Termidesk Connect Manager (экспериментальный компонент для управления несколькими инстансами Connect) также может быть мониторен через его собственный веб-интерфейс как обычный HTTP-сервис.

Если портал не мониторится

Оставьте соответствующий макрос пустым. Айтем перейдёт в состояние Not supported (Bad URL), а триггер nodata через 5 минут сработает ложно. Чтобы этого избежать: 1. Configuration → Hosts → <хост> → Triggers, 2. Найдите Admin portal unreachable / User portal unreachable, 3. Отключите триггер (Disable).

Альтернатива — задать в макросе заведомо отвечающий URL (например, тот же {$TERMIDESK.URL}), тогда проверка будет дублировать health-check; это может быть полезно, если вы хотите контролировать именно HTTP-слой отдельно от /api/health/*.

Какую метрику собирает портал-айтем

Айтем termidesk.portal.*.check — типа HTTP Agent, делает GET, возвращает тело ответа (HTML). Триггер строится на nodata(...,5m)=1 — срабатывает, когда за 5 минут не получено ни одного ответа (сервер недоступен, TLS-ошибка, таймаут). Это базовая проверка «жив ли портал»; содержимое ответа не анализируется. Для проверки содержимого (например, наличие строки входа) добавьте в айтем preprocessing REGEX или JAVASCRIPT в Zabbix UI.

Как это работает

Два канала сбора данных

Шаблон использует два независимых канала для получения данных из Termidesk:

Канал 1 — Health API (HTTP Agent) Zabbix напрямую обращается к /api/health/check и /api/health/metrics с заголовком Authorization: Token <HEALTH_CHECK_ACCESS_KEY>. Это быстрый и лёгкий канал — не требует логина, не создаёт сессий, работает даже при высокой нагрузке. Отсюда берутся: CPU, память, аптайм, сессии, ВРМ, агенты, версия. Опрос — раз в минуту.

Канал 2 — WebUI API (External check) Zabbix вызывает скрипт termidesk_api.sh, который для каждого запроса:

если задан {$TERMIDESK.AUTH_TOKEN} (предпочтительный режим): 1. Берёт токен из макроса напрямую. 2. Вызывает /api/webui/server/* (или /api/webui/aggregator/*) с заголовком X-Auth-Token: <token>. 3. Возвращает JSON для LLD или числовое значение для метрики. Запросов к /login нет — снижает нагрузку на auth-модуль Termidesk.

если {$TERMIDESK.AUTH_TOKEN} пустой (fallback на логин/пароль): 1. Логинится через POST /api/auth/vX/login (если нет кэшированного токена). 2. Кэширует токен в /tmp/termidesk_token_<hash>.cache (TTL 300 с). 3. Вызывает /api/webui/server/* с заголовком X-Auth-Token: <token>. 4. Возвращает JSON для LLD или числовое значение для метрики.

Отсюда берутся: список ферм, метрики фондов, сессии, лицензия, узлы инфраструктуры. Опрос — раз в 5–15 минут (настраивается).

Автообнаружение (LLD)

Zabbix автоматически обнаруживает фермы, узлы и сессии при каждом опросе. Для каждой обнаруженной фермы создаются элементы данных и триггеры по прототипам. Удалённые фермы автоматически исчезают из мониторинга после истечения lifetime (7 дней по умолчанию).

Кэширование токена

Кэширование применяется только в режиме входа по логину/паролю (когда {$TERMIDESK.AUTH_TOKEN} пустой). Скрипт кэширует токен сессии в /tmp/ с TTL 300 секунд. Это означает:

  • Первые 5 минут после входа скрипт переиспользует токен (без запроса к /login).
  • После истечения TTL скрипт логинится заново.
  • Кэш привязан к URL Termidesk (хэш в имени файла), поэтому разные серверы не конфликтуют.

В режиме готового X-Auth-Token кэш не используется — токен берётся напрямую из макроса при каждом вызове. Это позволяет:

  • не хранить пароль в Zabbix (только одноразово полученный токен);
  • управлять сроком жизни сессии централизованно через политику Termidesk;
  • при отзыве токена просто обновить макрос без очистки кэша.

Устранение неисправностей

Нет данных в Latest data

  1. Проверьте, что скрипт установлен и исполняется:

    /usr/lib/zabbix/externalscripts/termidesk_api.sh pool_count \
 "https://<URL>" "<логин>" "<пароль>" "1" "v7.0"

    Должно вывести число.

  2. Проверьте макросы хоста — все ли заполнены: {$TERMIDESK.URL}, {$TERMIDESK.USERNAME}, {$TERMIDESK.PASSWORD}.

  3. Проверьте сетевую доступность с сервера Zabbix:

    curl -sk https://<URL>/api/auth/v7.0/authenticators

Health metrics показывают 0 или пусто

  1. Проверьте {$TERMIDESK.HEALTH_TOKEN} и {$TERMIDESK.METRICS_TOKEN} — они должны содержать значения из termidesk.conf.

  2. Проверьте токен вручную:

    curl -sk -H "Authorization: Token <ТОКЕН>" https://<URL>/api/health/check
  3. Если ключей в termidesk.conf нет — добавьте их (см. Шаг 2 установки).

Ошибка «Учётные данные не были предоставлены» (401)

Неверный auth_id или api_version. Проверьте:

curl -sk https://<URL>/api/auth/v7.0/authenticators

Сверьте authId и убедитесь, что версия в URL совпадает с макросом {$TERMIDESK.API_VERSION}.

Эта ошибка возникает только в режиме логина/пароля. В режиме готового токена скрипт не вызывает /login — 401 от /api/webui/* означает, что {$TERMIDESK.AUTH_TOKEN} пустой или отозван (см. ниже).

Ошибка 401 от /api/webui/* в режиме токена

{$TERMIDESK.AUTH_TOKEN} пустой, отозван или истёк. Проверьте вручную:

curl -sk -H "X-Auth-Token: <ТОКЕН_ИЗ_МАКРОСА>" \
  https://<URL>/api/webui/server/servicespools?page_size=1
  • Если отвечает 401 — токен недействителен. Перевыпустите его (Шаг 3а) и обновите макрос {$TERMIDESK.AUTH_TOKEN}.
  • Если отвечает 200 — проблема в Zabbix: проверьте, что макрос задан на уровне хоста (а не только шаблона) и не содержит лишних пробелов/кавычек.

Ошибка «Недопустимый токен» (401) на health-эндпоинтах

Токен в макросе не совпадает с ключом в termidesk.conf. Проверьте, что {$TERMIDESK.HEALTH_TOKEN} = HEALTH_CHECK_ACCESS_KEY, а {$TERMIDESK.METRICS_TOKEN} = METRICS_ACCESS_KEY.

LLD не находит фермы

  1. Убедитесь, что на сервере Termidesk созданы и опубликованы фонды ВРМ.

  2. Проверьте ответ API вручную. Токен для ручной проверки можно получить одним из способов:

    • Если используется {$TERMIDESK.AUTH_TOKEN} — взять его прямо из макроса хоста.

    • Если используется логин/пароль — запросить через /login:

      curl -sk -X POST -H "Content-Type: application/json" \
 -d '{"username":"<логин>","password":"<пароль>","auth":1}' \
 https://<URL>/api/auth/v7.0/login

      и затем вызвать WebUI API:

      curl -sk -H "X-Auth-Token: <ТОКЕН>" \
https://<URL>/api/webui/server/servicespools?page_size=10
  3. Проверьте, что в макросе хоста {$TERMIDESK.AUTH_TOKEN} действительно есть токен, либо {$TERMIDESK.USERNAME}/{$TERMIDESK.PASSWORD} заданы (один из двух способов аутентификации).

Триггер «Server restarted» срабатывает ложно

Если сервер часто перезапускается по расписанию (например, ночью), можно увеличить порог или отключить триггер. Порог uptime < 300 зашит в выражении — для изменения отредактируйте триггер в Zabbix UI (Configuration → Hosts → Triggers).

Безопасность

  • Рекомендуемый режим аутентификации — готовый X-Auth-Token в макросе {$TERMIDESK.AUTH_TOKEN}. В этом режиме пароль не хранится в Zabbix: токен одноразово получается администратором через /login и при необходимости отзывается перевыпуском сессии в Termidesk.
  • При использовании логина/пароля пароль хранится в макросе Zabbix и виден пользователям с правами на хост. Используйте отдельную учётную запись Termidesk только для мониторинга с минимальными правами (просмотр), либо переключитесь на режим токена.
  • Токены HEALTH_CHECK_ACCESS_KEY и METRICS_ACCESS_KEY — это не пароли пользователей, а служебные ключи для health-эндпоинтов. Они не дают доступ к админскому API.
  • Кэш токена в /tmp/termidesk_token_*.cache создаётся с правами 600 (только владелец — пользователь zabbix). В режиме готового AUTH_TOKEN кэш-файл не создаётся вообще.
  • Все запросы к Termidesk выполняются по HTTPS с проверкой сертификата, отключённой по умолчанию (curl -sk). Для продакшена рекомендуется включить проверку — уберите флаг -k в termidesk_api.sh и установите CA-сертификат Termidesk на сервер Zabbix.

Обновление шаблонов

При выходе новой версии шаблонов:

  1. Обновите файлы в репозитории:

    git pull

  2. Скопируйте свежий externalscripts/termidesk_api.sh на сервер Zabbix:

    cp externalscripts/termidesk_api.sh /usr/lib/zabbix/externalscripts/
chmod +x /usr/lib/zabbix/externalscripts/termidesk_api.sh

    Перезапуск Zabbix-сервера не требуется — внешние скрипты читаются при каждом вызове.

  3. Импортируйте XML в Zabbix UI: Configuration → Templates → Import, выберите нужный файл, поставьте галочку Update existing и нажмите Import. Существующие хосты автоматически получят изменения.
  4. После импорта проверьте, что новые макросы/элементы появились на хостах: Configuration → Hosts → <хост> → Latest data.
  5. Если в новой версии добавились обязательные макросы — задайте их на уровне хоста, иначе соответствующие элементы данных перейдут в состояние Not supported.

UUID элементов детерминированы (UUID5), поэтому реимпорт не создаёт дубликатов — существующие элементы обновляются по совпадению UUID.

Массовое развёртывание

Если у вас несколько инстансов Termidesk (несколько диспетчеров, агрегаторов или кластеров), развёртывание делается так:

  1. Импортируйте шаблон один раз (см. Шаг 4 установки).
  2. Создайте отдельный хост под каждый инстанс Termidesk (Configuration → Hosts → Create host).
  3. На каждом хосте задайте свои макросы {$TERMIDESK.*} — URL, учётные данные, токены, версию API. Кэш токена у каждого хоста изолирован (хэш URL в имени файла /tmp/termidesk_token_<hash>.cache), поэтому конфликты исключены.
  4. Для однообразных настроек (пороги CPU/памяти) задайте значения на уровне шаблона — они применятся ко всем хостам сразу. Переопределяйте на хосте только там, где нужны индивидуальные пороги.

Рекомендуется завести отдельную service-account учётную запись в Termidesk с правами только на чтение и использовать её для всех хостов.

Настройка оповещений

Шаблон содержит триггеры с приоритетами INFO / WARNING / HIGH. Чтобы получать уведомления:

  1. Administration → Media types — убедитесь, что включён нужный канал (Email, Telegram и т.п.).
  2. Administration → Users → <ваш пользователь> → Media — добавьте адрес доставки и укажите, какие приоритеты отправлять (по умолчанию WARNING и выше).
  3. Configuration → Actions → Trigger actions — создайте действие:
    • Conditions: Template = Termidesk Dispatcher by HTTP (или Aggregator), Severity >= Warning.
    • Operations: Send message to <ваш пользователь> через выбранный media type.
  4. Для критических триггеров (Health FAILED, CPU critical, Memory critical) можно задать эскалацию — повторное уведомление через N минут, если триггер не подтверждён.

Приоритеты, заданные в шаблоне:

Приоритет Триггеры
HIGH Health FAILED, CPU critical, Memory critical
WARNING Health WARNING, CPU high, VMs failed/stuck, Agents unregistered
INFO Server restarted

Сводная таблица макросов

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

Termidesk VDI (Диспетчер / Агрегатор)

Макрос Обязательный По умолчанию Описание
{$TERMIDESK.URL} да — Базовый URL инстанса (https://...)
{$TERMIDESK.AUTH_TOKEN} да* — Готовый X-Auth-Token для /api/webui/* (предпочтительно)
{$TERMIDESK.USERNAME} да* — Логин администратора (fallback, если нет AUTH_TOKEN)
{$TERMIDESK.PASSWORD} да* — Пароль администратора (fallback, если нет AUTH_TOKEN)
{$TERMIDESK.AUTH_ID} нет 1 ID домена аутентификации (только для login)
{$TERMIDESK.API_VERSION} нет v7.0 Версия auth API: v6.1 / v7.0 / v7.1 (только для login)
{$TERMIDESK.HEALTH_TOKEN} да — HEALTH_CHECK_ACCESS_KEY из termidesk.conf
{$TERMIDESK.METRICS_TOKEN} да — METRICS_ACCESS_KEY из termidesk.conf
{$TERMIDESK.CPU.CRIT} нет 90 CPU %, порог HIGH-триггера
{$TERMIDESK.CPU.WARN} нет 80 CPU %, порог WARNING-триггера
{$TERMIDESK.MEM.AVAIL.CRIT} нет 5 Доступная память %, порог HIGH
{$TERMIDESK.MEM.AVAIL.WARN} нет 10 Доступная память %, порог WARNING
{$TERMIDESK.PORTAL.ADMIN.URL} нет — URL портала администратора (для LB — URL балансировщика)
{$TERMIDESK.PORTAL.USER.URL} нет — URL пользовательского портала (для LB — URL балансировщика)

* Достаточно задать либо {$TERMIDESK.AUTH_TOKEN}, либо связку USERNAME + PASSWORD. Если задан AUTH_TOKEN — USERNAME/PASSWORD игнорируются.

Termidesk Connect

Макрос Обязательный По умолчанию Описание
{$CONNECT.URL} да — URL управления Connect (WUI и база для /metrics)
{$CONNECT.CPU.CRIT} нет 90 CPU %, порог HIGH
{$CONNECT.CPU.WARN} нет 80 CPU %, порог WARNING
{$CONNECT.MEM.AVAIL.CRIT} нет 5 Доступная память %, порог HIGH
{$CONNECT.MEM.AVAIL.WARN} нет 10 Доступная память %, порог WARNING

Termidesk Gateway

Макрос Обязательный По умолчанию Описание
{$GATEWAY.URL} да — URL управления Шлюзом
{$GATEWAY.HEALTH_TOKEN} да — HEALTH_CHECK_ACCESS_KEY из termidesk.conf диспетчера
{$GATEWAY.METRICS_TOKEN} да — METRICS_ACCESS_KEY из termidesk.conf диспетчера
{$GATEWAY.CPU.CRIT} нет 90 CPU %, порог HIGH
{$GATEWAY.CPU.WARN} нет 80 CPU %, порог WARNING
{$GATEWAY.MEM.AVAIL.CRIT} нет 5 Доступная память %, порог HIGH
{$GATEWAY.MEM.AVAIL.WARN} нет 10 Доступная память %, порог WARNING

Termidesk Repeater

Макрос Обязательный По умолчанию Описание
{$REPEATER.URL} да — URL HTTP-сервера мониторинга (по умолчанию порт 2020)
{$REPEATER.ERRORS.CRIT} нет 0 Порог errors для HIGH (0 = любая ошибка)
{$REPEATER.RETRIES_FAILED.WARN} нет 0 Порог retries_failed для WARNING
{$REPEATER.UPTIME.MIN} нет 300 Минимальный uptime (с) для INFO-триггера

Termidesk Remote Assistant

Макрос Обязательный По умолчанию Описание
{$ASSISTANT.URL} да — Базовый URL компонента (https://...)
{$ASSISTANT.CSRF_TOKEN} нет — X-CSRFToken для /api/discover/ (Django, временный)

Termidesk Workplace Manager

Макрос Обязательный По умолчанию Описание
{$WM.URL} да — Базовый URL узла Менеджера (https://...)
{$WM.HEALTH_TOKEN} да — HEALTH_CHECK_ACCESS_KEY из termidesk.conf (тот же что у Диспетчера)
{$WM.BEAT.PORT} нет 8103 Порт termidesk-celery-beat (CELERY_BEAT_HEALTH_CHECK_PORT)
{$WM.WORKER.PORT} нет 8104 Порт termidesk-celery-worker (CELERY_WORKER_HEALTH_CHECK_PORT)

TermideskMQ

Макрос Обязательный По умолчанию Описание
{$TMQ.HOST} да — IP/FQDN хоста с TMQ (для TCP-проверок порта)
{$TMQ.PORT} нет 6669 TCP-порт брокера (TMQ_BASE_PORT)

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

Можно ли использовать один хост для диспетчера и агрегатора? Нет. Диспетчер и агрегатор — разные инстансы Termidesk с разными URL. Создайте два хоста и привяжите соответствующий шаблон к каждому.

Нужно ли открывать порт Termidesk на сервер Zabbix? Да. Zabbix-сервер обращается к Termidesk по HTTPS (обычно порт 443 или внешний порт Termidesk). Обратного соединения не требуется — Termidesk никогда не инициирует запросы к Zabbix.

Что будет, если пароль администратора изменится? Если используется {$TERMIDESK.AUTH_TOKEN} — ничего не сломается, пока токен валиден (пароль не используется для готового токена). При использовании USERNAME/PASSWORD метрики через WebUI API перестанут собираться (ошибка 401). Обновите макрос {$TERMIDESK.PASSWORD} на хосте; устаревший кэш токена вычищается автоматически по истечении TTL (300 с), либо удалите файл /tmp/termidesk_token_<hash>.cache вручную для мгновенного сброса.

Как переключиться с логина/пароля на готовый токен? Заполните {$TERMIDESK.AUTH_TOKEN} (см. Шаг 3а) и очистите {$TERMIDESK.USERNAME}/{$TERMIDESK.PASSWORD} (или оставьте — они будут проигнорированы). Удалите /tmp/termidesk_token_*.cache, чтобы избежать повторного использования устаревшего токена. Сбор метрик не прервётся.

Истёк срок действия X-Auth-Token — что делать? Метрики WebUI API вернут 401, LLD-элементы перейдут в Not supported. Получите новый токен (Шаг 3а) и обновите {$TERMIDESK.AUTH_TOKEN}. Health-метрики продолжат работать — они используют отдельные токены из termidesk.conf.

Можно ли мониторить несколько диспетчеров через один агрегатор? Агрегатор отдаёт метрики по всем подключённым к нему диспетчерам через /api/webui/aggregator/*. Отдельный шаблон агрегатора это и делает. Для детального мониторинга каждого диспетчера создавайте отдельные хосты с шаблоном диспетчера.

Почему LLD-элементы в состоянии Not supported? Чаще всего причина — не заданы обязательные макросы ({$TERMIDESK.URL}, {$TERMIDESK.USERNAME}, {$TERMIDESK.PASSWORD}) или невалидный токен. Проверьте Latest data — если мастер-элемент (например pool_metrics) возвращает ошибку, все зависимые LLD-прототипы станут Not supported.

Поддерживается ли Zabbix-прокси? Да. Внешний скрипт termidesk_api.sh нужно установить на каждом Zabbix-прокси, который мониторит Termidesk. HTTP Agent items (health) проксируются стандартным образом. Кэш токена создаётся на стороне прокси.

Как изменить интервал опроса? Интервалы заданы в шаблоне: health — 60 с, WebUI API метрики — 300–900 с. Чтобы изменить, отредактируйте Update interval у нужного элемента в Configuration → Hosts → <хост> → Items, либо через массовое обновление у шаблона.

Безопасно ли хранить пароль в макросе? Пароль виден пользователям Zabbix с правами на хост. Используйте отдельную учётную запись Termidesk только для мониторинга с минимальными правами. Также можно включить шифрование макросов типа Secret на уровне шаблона.

Глоссарий

Термин Описание
Диспетчер (Dispatcher) Сервер Termidesk VDI, управляющий фондами ВРМ
Агрегатор (Aggregator) Компонент Termidesk, агрегирующий несколько диспетчеров
ВРМ Виртуальное рабочее место
Фонд (services pool) Группа ВРМ, назначаемых пользователям
Ферма (aggregator farm) Группа диспетчеров в агрегаторе
Termidesk Connect Балансировщик нагрузки линейки Termidesk (отдельный продукт, ADC); режимы: балансировщик, Шлюз, глобальный балансировщик (GSLB)
Шлюз (Gateway) Режим работы Termidesk Connect: единая точка входа для Termidesk VDI (SSL-терминирование, аутентификация, маршрутизация к ВРМ)
ADC Application Delivery Controller — контроллер доставки приложений (класс продуктов, к которому относится Connect)
WUI Web User Interface — веб-интерфейс управления Connect
HA High Availability — отказоустойчивая конфигурация (Active/Standby)
Repeater (ретранслятор) Компонент Termidesk VDI для проксирования потоков данных; мониторится через Fluent Bit-style API (порт 2020)
Remote Assistant (удалённый помощник) Компонент Termidesk VDI для remote-ассистанса (подключение helpdesk к сеансу пользователя); Django-приложение с ограниченным REST API
Workplace Manager (менеджер рабочих мест) Компонент Termidesk VDI (celery-beat + celery-worker); обработчик фоновых задач, управление жизненным циклом РМ; health на портах 8103/8104
TermideskMQ (TMQ) Экспериментальный брокер очереди сообщений Termidesk (замена RabbitMQ); служба termidesk-tmq, протокол tmqp://, порт 6669, mTLS
CSRF-токен Временный токен Django для защиты от CSRF; используется в заголовке X-CSRFToken (время жизни ограничено)
Chunk Единица буфера Fluent Bit (пакет записей, отслеживаемый как одно целое)
LLD Low-Level Discovery — автообнаружение элементов в Zabbix
External check Тип элемента Zabbix, вызывающий внешний скрипт
HTTP Agent Тип элемента Zabbix, делающий HTTP-запрос напрямую
Health API Неавторизуемый API состояния Termidesk (по токену)
WebUI API Авторизуемый admin-API Termidesk (по логину/паролю)
Описание
Readme
0 Форки
2 Звезд
1 Наблюдатели
Посмотреть файловое дерево
Конвейеры
0 успешных
0 с ошибкой
Разработчики