Мониторинг Kubernetes с помощью Zabbix: пошаговая настройка шаблонов и дашбордов | AdminWiki
Logo

Мониторинг Kubernetes с помощью Zabbix: пошаговая настройка шаблонов и дашбордов

26 июля 2026 12 мин. чтения
Содержание статьи

Зачем мониторить Kubernetes через Zabbix: преимущества и архитектура решения

Мониторинг контейнеризированной среды создает специфические трудности. Поды создаются и удаляются динамически, метрики нужно собирать с десятков или сотен эфемерных объектов, а традиционные агенты, завязанные на статичные хосты, не справляются с такой волатильностью. Zabbix решает эту задачу через механизм автообнаружения (low-level discovery) и прокси-архитектуру.

Prometheus сформировался как стандарт де-факто для Kubernetes, но Zabbix дает ощутимые преимущества в двух сценариях. Первый: у вас уже развернут Zabbix-сервер для мониторинга остальной инфраструктуры (виртуальные машины, базы данных, сетевое оборудование) и вы хотите консолидировать все данные в единой панели без внедрения второго независимого стека. Второй: вам нужна централизованная система оповещений с гибкой эскалацией, расписаниями дежурств и интеграцией с корпоративными каналами связи, которые в Zabbix настраиваются без дополнительных компонентов.

Архитектура решения выглядит так. Zabbix-сервер остается снаружи кластера или на выделенной виртуальной машине. Внутри Kubernetes разворачивается Zabbix-прокси в активном режиме: он самостоятельно опрашивает Kubernetes API, собирает метрики через cAdvisor и metrics-server, агрегирует данные и отправляет их на сервер одним сжатым пакетом. Прокси берет на себя всю нагрузку по сбору данных внутри кластера, снижая задержки и разгружая центральный сервер. Автообнаружение через low-level discovery автоматически подхватывает новые узлы и поды без ручного добавления.

В этом руководстве мы пройдем полный цикл: от развертывания прокси в кластере до создания дашбордов и настройки алертов. Все манифесты и конфигурации проверены на Zabbix 6.0 LTS и Kubernetes 1.27+. Если вам нужен альтернативный подход с Prometheus и Grafana, изучите пошаговое руководство по настройке полного стека мониторинга Kubernetes.

Подготовка окружения и развертывание Zabbix прокси в Kubernetes

Для работы потребуется: работающий Zabbix-сервер версии 6.0 или новее с настроенной базой данных, кластер Kubernetes с правами на создание Deployment и ConfigMap, сетевой доступ от прокси к серверу по порту 10051. Прокси будет работать в активном режиме, то есть сам инициирует соединение с сервером.

Сначала зарегистрируйте прокси на стороне Zabbix-сервера. В веб-интерфейсе перейдите в раздел Administration → Proxies, нажмите Create proxy. Укажите имя (например, k8s-proxy), выберите режим Active, задайте интерфейс для подключения. Остальные параметры оставьте по умолчанию. После сохранения система сгенерирует запись, к которой прокси подключится при первом запуске.

Создание конфигурации Zabbix прокси

Конфигурационный файл прокси содержит параметры подключения к серверу и настройки сбора данных. Создайте файл zabbix_proxy.conf со следующим содержимым:

Server=10.10.10.50
Hostname=k8s-proxy
ListenPort=10051
LogType=console
DebugLevel=3
EnableRemoteCommands=0
ProxyMode=0
ProxyLocalBuffer=6
HeartbeatFrequency=60
ConfigFrequency=60
DataSenderFrequency=1
StartPollers=5
StartPollersUnreachable=1
StartTrappers=5
StartPingers=1
StartDiscoverers=3
CacheSize=64M
HistoryCacheSize=16M
Timeout=4
DBName=/var/lib/zabbix/proxy.db

Ключевые параметры: Server задает IP-адрес или DNS-имя Zabbix-сервера, Hostname должно совпадать с именем прокси, зарегистрированным в веб-интерфейсе, DBName указывает путь к файлу SQLite внутри контейнера. Параметр StartDiscoverers=3 важен для работы автообнаружения в Kubernetes: каждый процесс-обнаружитель обрабатывает одно правило LLD, трех процессов хватит для среднего кластера на 20-50 узлов.

Запакуйте конфигурацию в ConfigMap:

kubectl create namespace monitoring
kubectl create configmap zabbix-proxy-config \
  --from-file=zabbix_proxy.conf=./zabbix_proxy.conf \
  -n monitoring

Запуск прокси в кластере: Deployment и Service

Создайте манифест deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: zabbix-proxy
  namespace: monitoring
  labels:
    app: zabbix-proxy
spec:
  replicas: 1
  selector:
    matchLabels:
      app: zabbix-proxy
  template:
    metadata:
      labels:
        app: zabbix-proxy
    spec:
      containers:
      - name: zabbix-proxy
        image: zabbix/zabbix-proxy-sqlite3:6.0-ubuntu-latest
        ports:
        - containerPort: 10051
          protocol: TCP
        volumeMounts:
        - name: config
          mountPath: /etc/zabbix/zabbix_proxy.conf
          subPath: zabbix_proxy.conf
        - name: data
          mountPath: /var/lib/zabbix
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "512Mi"
            cpu: "500m"
      volumes:
      - name: config
        configMap:
          name: zabbix-proxy-config
      - name: data
        emptyDir: {}

Обратите внимание на образ: zabbix/zabbix-proxy-sqlite3 использует SQLite для локального буфера, что упрощает развертывание, так как не требует отдельной базы данных. Для production-сред с высокой нагрузкой замените его на образ с поддержкой PostgreSQL и подключите внешнюю базу.

Примените манифест и проверьте логи:

kubectl apply -f deployment.yaml -n monitoring
kubectl logs -f deployment/zabbix-proxy -n monitoring

В логах вы должны увидеть строки: "Zabbix Proxy started", "sending configuration request to server", "received configuration data from server". Если прокси успешно подключился, в веб-интерфейсе Zabbix в разделе Administration → Proxies статус изменится на "Active".

Service для прокси создавать не обязательно, если сервер находится вне кластера и прокси сам к нему подключается. Однако для отладки или если вы планируете использовать пассивный режим, добавьте Service типа ClusterIP на порт 10051.

Настройка автообнаружения и сбора метрик Kubernetes

Zabbix получает метрики Kubernetes через два канала: Kubernetes API для статусов и метаданных объектов, и cAdvisor/metrics-server для метрик потребления ресурсов. Прокси внутри кластера имеет доступ к API через ServiceAccount, который мы настроим.

Создайте ServiceAccount и ClusterRole с правами на чтение подов и узлов:

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

Привяжите ServiceAccount к поду прокси, добавив в Deployment поле serviceAccountName: zabbix-proxy. После перезапуска прокси получит токен для доступа к API.

Создание шаблона для узлов кластера

В веб-интерфейсе Zabbix перейдите в Data collection → Templates, создайте шаблон "Kubernetes Node Monitoring". Добавьте правило автообнаружения (Discovery rule) с типом "Zabbix agent (active)" и ключом:

system.run[curl -s --header "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt https://kubernetes.default.svc/api/v1/nodes | jq -r '.items[].metadata.name']

Этот ключ выполняет запрос к Kubernetes API внутри пода прокси и возвращает список имен узлов в формате JSON. Настройте фильтры LLD: создайте item prototype с типом "Dependent item" и master-элементом данных, который будет парсить JSON. Для каждого обнаруженного узла создайте элементы данных:

  • CPU usage: запрос к metrics-server через curl к /apis/metrics.k8s.io/v1beta1/nodes/{#NODE_NAME}
  • Memory usage: аналогичный запрос, парсинг поля usage.memory
  • Disk pressure condition: проверка статуса узла через API
  • Network bytes received/transmitted: доступно только при установленном Zabbix agent на узлах

Если Zabbix agent установлен на узлах кластера, используйте стандартные ключи system.cpu.util и vm.memory.size, привязав их к обнаруженным хостам через интерфейс агента.

Создание шаблона для подов и контейнеров

Создайте шаблон "Kubernetes Pod Monitoring". Добавьте правило обнаружения с ключом:

system.run[curl -s --header "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt https://kubernetes.default.svc/api/v1/pods?limit=500 | jq -r '.items[] | .metadata.namespace + ":" + .metadata.name']

Для каждого обнаруженного пода создайте элементы данных:

  • Pod status phase: значение из поля .status.phase (Running, Pending, Failed)
  • Container restarts: суммарное количество перезапусков всех контейнеров в поде
  • CPU usage per pod: запрос к metrics-server
  • Memory usage per pod: запрос к metrics-server

Пример элемента данных для получения статуса пода:

Тип: Dependent item
Ключ: pod.status[{#POD_NAMESPACE},{#POD_NAME}]
Master item: k8s.pod.discovery
Предобработка: JSONPath $.items[?(@.metadata.namespace=="{#POD_NAMESPACE}" && @.metadata.name=="{#POD_NAME}")].status.phase

Метрики CPU и памяти из metrics-server возвращаются в формате "нанокоры" и "кибибайты". Добавьте шаги предобработки для конвертации в проценты и мегабайты через пользовательские множители (Custom multiplier) в настройках элемента данных.

Настройка правил автообнаружения

Правила LLD в Zabbix работают по циклу: discovery rule выполняется с заданным интервалом, возвращает JSON-массив объектов, фильтры отбирают нужные, а item prototypes и trigger prototypes создают элементы данных и триггеры для каждого объекта.

Для узлов настройте интервал обнаружения 300 секунд (5 минут). Узлы редко добавляются или удаляются, частый опрос API не нужен. Для подов интервал 60 секунд оправдан: поды могут появляться и исчезать в течение минут при автомасштабировании.

Фильтры LLD помогают исключить системные поды из мониторинга. Добавьте условие: namespace NOT IN (kube-system, kube-public, kube-node-lease). Это сократит количество отслеживаемых объектов и снизит нагрузку на прокси.

Привязка шаблонов к обнаруженным объектам происходит автоматически через действие (Action) с условием "Discovery rule equals ..." и операцией "Link template". Настройте два действия: одно для узлов, другое для подов.

Визуализация данных: создание дашбордов в Zabbix

Zabbix 6.0+ предоставляет модуль Dashboards с набором виджетов: графики, таблицы, одиночные значения, карты. Для мониторинга Kubernetes создадим два дашборда: обзорный для оперативного контроля и детализированный для поиска проблемных подов.

Дашборд «Обзор кластера»

Создайте новый дашборд в разделе Monitoring → Dashboards. Добавьте виджеты:

  • "Текущая нагрузка CPU по узлам" - тип Graph, источник: элемент данных CPU usage из шаблона узлов, сгруппированный по имени узла. Показывает утилизацию процессора в процентах за последний час.
  • "Использование памяти по узлам" - тип Graph, аналогично для метрик памяти. Помогает выявить узлы с риском ухода в OOM Kill.
  • "Распределение подов по статусам" - тип Pie chart, источник: агрегированные данные о статусах подов. Сегменты: Running, Pending, Failed, Unknown. Позволяет мгновенно оценить здоровье кластера.
  • "Топ-10 подов по потреблению CPU" - тип Top hosts, сортировка по убыванию CPU usage. Быстро показывает, какие приложения создают наибольшую нагрузку.
  • "Количество перезапусков за час" - тип Single value, отображает суммарное число рестартов контейнеров. Пороговые значения: зеленый до 5, желтый 5-20, красный более 20.

Настройте фильтр по времени на последние 15 минут для оперативного мониторинга. Если вам нужна более глубокая аналитика с гибкими панелями, рассмотрите интеграцию Zabbix с Grafana через плагин. В нашей базе знаний есть руководство по развертыванию Prometheus и Grafana для кластерной инфраструктуры, где описана настройка готовых дашбордов.

Дашборд «Детализация по подам»

Этот дашборд предназначен для поиска конкретного проблемного пода. Добавьте виджеты:

  • "Таблица подов" - тип Table, столбцы: Namespace, Pod Name, Status, CPU %, Memory MB, Restarts. Включите сортировку по столбцу Restarts по убыванию, чтобы проблемные поды были вверху.
  • "График потребления ресурсов подом" - тип Graph, с фильтром по конкретному поду. При клике на строку таблицы график обновляется для выбранного пода.
  • "История статусов" - тип Graph, отображает изменение статуса пода во времени. Полезно для анализа нестабильных подов, которые переходят из Running в CrashLoopBackOff и обратно.

Для связи таблицы и графика используйте механизм Dashboard tags и фильтрацию по host name. Каждый под регистрируется в Zabbix как отдельный хост с именем в формате namespace:podname, что позволяет использовать стандартные фильтры виджетов.

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

Сбор метрик без оповещений не предотвращает инциденты. Настроим триггеры, которые срабатывают при отклонении метрик от нормы, и действия для доставки уведомлений.

Ключевые триггеры для Kubernetes

Создайте триггеры в шаблонах узлов и подов. Минимальный набор для production-среды:

  • "Узел недоступен" - условие: nodata(5m) для элемента данных статуса узла. Срабатывает, если прокси не может получить метрики узла в течение 5 минут. Приоритет: High.
  • "Высокая загрузка CPU на узле" - условие: avg(/host/cpu_usage, 5m) > 90. Срабатывает при sustained нагрузке выше 90% за 5-минутный интервал. Приоритет: Warning.
  • "Критическое использование памяти на узле" - условие: last(/host/mem_usage) > 95. Срабатывает мгновенно при достижении порога, так как OOM Kill может произойти за секунды. Приоритет: High.
  • "Под в статусе CrashLoopBackOff" - условие: find(/pod/status, "like", "CrashLoopBackOff") = 1. Срабатывает при обнаружении пода в проблемном статусе. Приоритет: Average.
  • "Частые перезапуски пода" - условие: change(/pod/restarts) > 5 за последний час. Сигнализирует о нестабильном приложении. Приоритет: Warning.
  • "Под в статусе Failed" - условие: find(/pod/status, "like", "Failed") = 1. Приоритет: High.

Добавьте зависимость триггеров: если узел недоступен, подавляйте триггеры подов на этом узле, чтобы избежать лавины оповещений при одной корневой причине. Настройте это через поле "Dependencies" в форме триггера.

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

Zabbix поддерживает множество медиатипов из коробки: email, SMS через GSM-модем, webhook-интеграции. Для оперативного реагирования настройте Telegram и email.

Для Telegram создайте бота через @BotFather, получите токен и ID чата. В Zabbix перейдите в Administration → Media types, создайте новый тип "Telegram" с типом Webhook. Параметры:

URL: https://api.telegram.org/bot{ALERT.SENDTO}/sendMessage
Method: POST
Body: chat_id={ALERT.SUBJECT}&text={ALERT.MESSAGE}

Параметр {ALERT.SENDTO} будет содержать ID чата, {ALERT.SUBJECT} - ID чата получателя, {ALERT.MESSAGE} - текст уведомления. Создайте пользователя в Zabbix, в его профиле добавьте медиа с типом Telegram и укажите ID чата в поле "Send to".

Для email используйте встроенный тип Email. Настройте SMTP-сервер в Administration → Media types → Email: укажите SMTP server, порт, логин и пароль. Протестируйте отправку через кнопку "Test".

Создайте действие (Action) в Configuration → Actions. Условие: Trigger severity >= Warning. Операции: отправка сообщения через Telegram и email с шаблоном:

Проблема: {TRIGGER.NAME}
Хост: {HOST.NAME}
Статус: {TRIGGER.STATUS}
Значение: {ITEM.LASTVALUE}
Время: {EVENT.TIME}
Дата: {EVENT.DATE}

Настройте шаги эскалации: если проблема не решена за 10 минут, отправьте повторное уведомление с повышенным приоритетом. Если за 30 минут нет реакции, отправьте уведомление на резервный канал (email администратора).

Типовые проблемы и их решение

При интеграции Zabbix с Kubernetes возникают повторяющиеся ошибки. Разберем частые случаи и способы их устранения.

Прокси не подключается к серверу. Проверьте логи пода: kubectl logs deployment/zabbix-proxy -n monitoring. Сообщение "cannot connect to server" указывает на сетевую проблему. Убедитесь, что с узла, где запущен прокси, доступен IP сервера по порту 10051: kubectl exec -it deployment/zabbix-proxy -n monitoring -- nc -zv 10.10.10.50 10051. Если соединения нет, проверьте NetworkPolicy в кластере и правила файрвола на стороне сервера.

Нет данных от подов. Самая вероятная причина - отсутствие прав у ServiceAccount. Выполните команду внутри пода прокси: kubectl exec deployment/zabbix-proxy -n monitoring -- curl -s --header "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt https://kubernetes.default.svc/api/v1/pods?limit=5. Если возвращается 403 Forbidden, проверьте ClusterRole и ClusterRoleBinding. Если возвращается пустой список, проверьте, что в namespace есть поды и они не фильтруются правилами LLD.

Проблемы с правами доступа к Kubernetes API. Токен ServiceAccount монтируется в под автоматически, но некоторые дистрибутивы Kubernetes (OpenShift, Rancher с жесткими политиками) требуют явного создания SecurityContextConstraints. Добавьте в Deployment поле automountServiceAccountToken: true и убедитесь, что SCC разрешает запуск пода с указанным ServiceAccount.

Высокая нагрузка на прокси. Если прокси потребляет больше 500m CPU, уменьшите интервал опроса правил LLD. Для подов интервал 120 секунд достаточен для большинства сред. Увеличьте CacheSize до 128M в конфигурации прокси. Если в кластере более 200 подов, рассмотрите запуск нескольких экземпляров прокси с разделением по namespace через фильтры LLD.

Метрики CPU и памяти не совпадают с kubectl top. Zabbix получает данные из того же metrics-server, что и kubectl top, но предобработка может искажать значения. Проверьте шаги предобработки в элементах данных: для CPU делите нанокооры на 1 000 000 000 для получения ядер, для памяти делите кибибайты на 1 048 576 для получения мегабайт.

Заключение: дальнейшие шаги и лучшие практики

Вы развернули Zabbix-прокси в Kubernetes, настроили автообнаружение узлов и подов, создали дашборды для визуализации и триггеры для оповещений. Эта связка закрывает базовые потребности мониторинга контейнеризированной среды.

Для масштабирования мониторинга обновляйте шаблоны при выходе новых версий Kubernetes API. Версии API эволюционируют: v1beta1 metrics.k8s.io может быть выведен из эксплуатации, отслеживайте deprecation notices в релизных заметках. Храните шаблоны в системе контроля версий и экспортируйте их через API Zabbix для автоматического развертывания.

Zabbix эффективен для инфраструктурного мониторинга, но для визуализации с гибкими панелями и сложными запросами используйте его в связке с Grafana. Плагин Zabbix для Grafana позволяет строить графики на основе данных из Zabbix без дублирования сбора метрик. Если вы еще не работали с Grafana, начните с руководства по настройке мониторинга Kubernetes с Prometheus и Grafana.

Расширяйте мониторинг на уровень приложений: отслеживайте коды ответов HTTP, задержки, количество соединений. Для этого добавьте кастомные элементы данных, которые опрашивают эндпоинты приложений или парсят логи через Zabbix agent. При диагностике проблем используйте методику поиска корневой причины через метрики мониторинга - это сократит время восстановления с часов до минут.

Для production-сред настройте резервирование прокси: запустите два экземпляра с разными именами и одинаковой конфигурацией, зарегистрируйте оба на сервере. Если один под упадет, второй продолжит сбор данных. Мониторинг собственного мониторинга - правило, которое спасает от ложного чувства контроля.

Поделиться:
Сохранить гайд? В закладки браузера