Zabbix 6.4: включаем нативный HA и автообнаружение Kubernetes у клиентов

Zabbix 6.4 вышел в марте 2023-го, но активно обновлять клиентов под нашим управлением начали ближе к концу года - после того как версия отлежалась, набрала патчи и перестала удивлять неожиданными поведением в нестандартных конфигурациях. К декабрю картина достаточно понятная, чтобы написать про два конкретных кейса.

Что вообще привлекло в 6.4

Zabbix 6.4 - не LTS в классическом смысле (LTS у них 6.0), но релиз достаточно зрелый, чтобы ставить в прод. Из заявленного нас интересовали два пункта:

• Нативный HA-режим - появился ещё в 6.2, в 6.4 доведён до вменяемого состояния. Раньше высокую доступность мониторинга строили через внешние инструменты - Corosync/Pacemaker, keepalived, ручные скрипты переключения. Теперь это встроено.
• Kubernetes discovery - не просто шаблоны, а нативная интеграция через Zabbix Kubernetes discovery, которая умеет автоматически добавлять узлы кластера при их появлении.

Business service monitoring тоже переработали, но это история для клиентов с SOA-структурой - к нашему типичному окружению относится меньше.

HA: как выглядит на практике

У одного из клиентов Zabbix стоял в конфигурации «один сервер + внешний PostgreSQL». Отказоустойчивости на уровне сервера мониторинга не было - при падении ноды мониторинг просто останавливался до ручного вмешательства. Исторически всех это более-менее устраивало, пока инфраструктура была небольшой. Сейчас хосты под наблюдением выросли, и простой мониторинга даже на час - уже заметная проблема.

Нативный HA в Zabbix 6.4 работает через shared PostgreSQL-базу. Несколько серверных нод подключаются к одной БД, одна из них становится active, остальные - standby. Переключение при падении активной ноды происходит автоматически, без внешнего координатора.

Поднимали на двух нодах. Конфиг минимальный - в zabbix_server.conf добавляется HANodeName и NodeAddress, больше ничего особенного:

HANodeName=zabbix-node1
NodeAddress=192.168.10.11:10051

Для балансировки клиентского трафика (агенты, прокси) перед серверами поставили keepalived с виртуальным IP - сам Zabbix с этим не помогает, VIP надо делать отдельно. Это немного раздражает, потому что создаётся иллюзия «встроенного HA» при том что агентам всё равно нужен единый адрес для подключения. Но в целом схема рабочая и заметно проще, чем Pacemaker с CRM-скриптами.

Переключение между нодами проверяли принудительным выключением активной - standby подхватывала через 30-40 секунд. Для мониторинга это приемлемо: агенты буферизуют метрики локально и доотправляют после восстановления связи.

Kubernetes discovery: автообнаружение узлов

Второй кейс - клиент с Kubernetes-кластером на базе Deckhouse, про который мы писали раньше. До 6.4 мониторинг k8s-узлов у них был полуручным: добавить worker node - зайди, добавь хост в Zabbix, привяжи шаблон. Раздражало, потому что при автоскейлинге это превращается в ручную работу, которую забывают делать.

Zabbix Kubernetes discovery работает через HTTP API кластера. Нужен ServiceAccount с правами на чтение nodes, pods и endpoints:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: zabbix-monitoring
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: zabbix-monitoring-reader
rules:
  - apiGroups: [""]
    resources: ["nodes", "pods", "endpoints", "namespaces"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: zabbix-monitoring-reader
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: zabbix-monitoring-reader
subjects:
  - kind: ServiceAccount
    name: zabbix-monitoring
    namespace: kube-system

Токен ServiceAccount передаётся в Zabbix как макрос {$KUBE.API.TOKEN}, хост с API-endpoint кластера добавляется вручную один раз - дальше discovery создаёт прототипы хостов для каждого узла автоматически. При появлении новой ноды в кластере Zabbix обнаруживает её в рамках следующего цикла discovery (по умолчанию час, можно укоротить).

Шаблоны из коробки дают базовые метрики: состояние узлов, статус подов, использование ресурсов. Для детального мониторинга workload'ов этого мало - там нужно либо Prometheus + Grafana, либо кастомные Items через HTTP Agent. Но для «все ли узлы живы и не деградирует ли кластер» - вполне.

Одна неочевидная вещь: discovery в Zabbix создаёт хосты с именами из API кластера. Если у клиента нейминг узлов сделан через UUID или внутренние идентификаторы облачного провайдера - в интерфейсе Zabbix это выглядит неразборчиво. Пришлось настраивать alias через Inventory, чтобы в хостлисте было человеческое имя, а не ip-10-0-3-247.eu-central-1.compute.internal.

Итог декабря

На конец года несколько managed-клиентов переведены на 6.4. HA работает без нареканий - за несколько недель одно плановое переключение при обновлении ОС на активной ноде, прошло штатно. Kubernetes discovery закрыл больную точку с ручным добавлением хостов.

Обновление с 6.0 LTS прошло без сюрпризов на уровне агентов - совместимость сохранена, агенты продолжают работать без переустановки. База данных потребовала стандартного прогона скриптов миграции, ничего нетипичного.

На следующий год у ряда клиентов стоит вопрос про business service monitoring - но это уже отдельная задача со своим моделированием зависимостей. Пока смотрим, насколько новый интерфейс BSM в 6.4 вменяем для реальных сервисных карт.

Если среди клиентов на управляемой инфраструктуре есть желающие попробовать HA или Kubernetes discovery - это уже не эксперимент, конфигурация обкатана.