Мониторинг производительности информационных систем при обновлениях: настройка Zabbix и Prometheus

Развертывание обновлений без мониторинга в реальном времени - это работа вслепую. Вы узнаете о проблеме только тогда, когда пользователи начнут писать в поддержку или сервис упадет. Практика показывает: до 65% инцидентов на проде происходят в первые часы после деплоя. Причина - незамеченная деградация: утечка памяти в новой версии приложения, аномальный рост дисковых операций из-за миграций, внезапное увеличение сетевых задержек между сервисами.

Решение - настроить систему, которая покажет состояние инфраструктуры на каждом этапе обновления: до старта, во время rolling update и после его завершения. В этом руководстве мы разберем настройку двух основных инструментов - Zabbix и Prometheus. Вы получите готовые конфигурации для сбора метрик CPU, памяти, диска и сети, создадите дашборды для визуального контроля и настроите алерты, которые сработают при аномалиях до того, как они затронут пользователей.

Если вы уже работаете с Kubernetes и контейнеризированными приложениями, обратите внимание на наше руководство по наблюдаемости для высоконагруженных систем, где детально разобраны метрики уровня приложения и бизнес-логики. А для тех, кто только строит инфраструктуру, будет полезен материал по оценке эффективности инфраструктуры после запуска.

Зачем мониторить производительность во время обновлений

Обновление меняет поведение системы. Новая версия может запрашивать больше памяти, генерировать дополнительные запросы к базе данных или создавать неоптимальные сетевые соединения. Без мониторинга эти изменения остаются невидимыми до критического сбоя.

Типичные сценарии, которые выявляет мониторинг:

• Рост потребления RAM на 30-40% после деплоя из-за изменения алгоритма кеширования. Без контроля это приводит к OOM Kill и перезапускам подов.
• Увеличение IO wait с 2% до 15% во время выполнения миграций базы данных. Сервис продолжает работать, но время ответа API вырастает втрое.
• Сетевые ретрансмиты между микросервисами после смены версии gRPC-библиотеки. Пользователи видят таймауты, хотя CPU и память в норме.

Мониторинг в процессе обновления работает как страховка. Вы фиксируете baseline до старта, наблюдаете за отклонениями во время деплоя и сравниваете показатели после его завершения. Zabbix и Prometheus решают эту задачу с разных архитектурных подходов, и выбор зависит от вашей инфраструктуры.

Zabbix vs Prometheus: что выбрать для мониторинга обновлений

Оба инструмента способны обеспечить контроль производительности при обновлениях, но их архитектура определяет сценарии применения. Zabbix использует pull-модель с возможностью активных проверок от агентов, хранит данные в реляционной базе и поставляет сотни готовых шаблонов. Prometheus работает по pull-модели, собирает метрики с экспортеров, хранит временные ряды в собственной TSDB и предоставляет гибкий язык запросов PromQL.

Критерии выбора: когда Zabbix, а когда Prometheus

Практическая рекомендация: если у вас парк виртуальных машин и вы обновляете монолитное приложение - начинайте с Zabbix. Если инфраструктура построена на Kubernetes и вы практикуете CI/CD с частыми деплоями - Prometheus будет эффективнее. Во многих проектах инструменты дополняют друг друга: Zabbix мониторит хосты и сеть, Prometheus собирает метрики контейнеров, а Grafana объединяет данные в единый дашборд. Подробный разбор этой связки есть в нашем руководстве по мониторингу кластеров серверов.

Ключевые метрики для отслеживания на каждом этапе обновления

Мониторинг без четкого списка метрик превращается в поток данных, из которого сложно извлечь сигнал. Для контроля обновлений мы выделяем три группы показателей, соответствующих этапам деплоя.

Метрики инфраструктуры: CPU, память, диск, сеть

Базовый уровень, с которого начинается диагностика. Вот конкретные счетчики, которые нужно собирать:

• CPU: общая утилизация (system, user, iowait), троттлинг в контейнерах. Ключевой индикатор - резкий рост iowait при неизменной вычислительной нагрузке, что указывает на проблемы с диском.
• Память: доступная память (MemAvailable, а не MemFree), использование swap, OOM kills. Swap activity выше нуля на сервере приложений - сигнал о нехватке RAM.
• Диск: IOPS чтения/записи, latency (await), queue depth, утилизация устройства. Рост очереди запросов выше 5 на одно устройство - предвестник деградации.
• Сеть: throughput по интерфейсам, количество ошибок и дропов, TCP-ретрансмиты. Ретрансмиты выше 0.1% от общего трафика указывают на проблемы на уровне сети.

В Zabbix эти метрики собираются шаблоном Template OS Linux by Zabbix agent. В Prometheus - через node_exporter, который отдает метрики в формате node_cpu_seconds_total, node_memory_MemAvailable_bytes, node_disk_io_time_seconds_total, node_network_receive_bytes_total.

Метрики приложений и сервисов

Инфраструктурные метрики показывают симптомы, но причина часто лежит на уровне приложения. Для полноты картины добавьте экспортеры:

• Nginx: prometheus_nginx_exporter - код ответа 5xx, время обработки запросов, количество соединений. Рост 502 ошибок после деплоя бэкенда - мгновенный сигнал к откату.
• PostgreSQL: postgres_exporter - количество активных соединений, время выполнения запросов, число блокировок. Если connections достигают максимума, новые запросы встают в очередь.
• Кастомные метрики: в коде приложения на Python через библиотеку prometheus_client. Вы экспортируете счетчики бизнес-операций, время ответа эндпоинтов, количество ошибок конкретного типа.

Привязка к этапам обновления выглядит так: за 5 минут до деплоя фиксируете baseline по всем метрикам. Во время rolling update отслеживаете отклонения на обновляемых экземплярах. Через 10 минут после завершения сравниваете показатели с baseline и принимаете решение о стабильности релиза.

Пошаговая настройка Zabbix для мониторинга обновлений

Разберем настройку Zabbix с нуля до готового дашборда, который покажет состояние системы в момент деплоя.

Установка и базовая конфигурация Zabbix

Для быстрого старта используйте Docker. Создайте файл docker-compose.yml:

version: '3.8'
services:
  postgres-server:
    image: postgres:14
    environment:
      POSTGRES_USER: zabbix
      POSTGRES_PASSWORD: zabbix_pwd
      POSTGRES_DB: zabbix
    volumes:
      - ./pgdata:/var/lib/postgresql/data

  zabbix-server:
    image: zabbix/zabbix-server-pgsql:alpine-6.4-latest
    environment:
      DB_SERVER_HOST: postgres-server
      POSTGRES_USER: zabbix
      POSTGRES_PASSWORD: zabbix_pwd
      POSTGRES_DB: zabbix
    ports:
      - "10051:10051"
    depends_on:
      - postgres-server

  zabbix-web:
    image: zabbix/zabbix-web-nginx-pgsql:alpine-6.4-latest
    environment:
      ZBX_SERVER_HOST: zabbix-server
      DB_SERVER_HOST: postgres-server
      POSTGRES_USER: zabbix
      POSTGRES_PASSWORD: zabbix_pwd
      POSTGRES_DB: zabbix
    ports:
      - "8080:8080"
    depends_on:
      - zabbix-server

Запустите стек командой docker compose up -d. Веб-интерфейс доступен на порту 8080, логин Admin, пароль zabbix. После входа смените пароль.

Настройка сбора метрик с агентов

На каждом целевом хосте установите Zabbix agent:

apt install zabbix-agent
# или для версии 6.4:
wget https://repo.zabbix.com/zabbix/6.4/ubuntu/pool/main/z/zabbix/zabbix-agent_6.4.0-1+ubuntu22.04_amd64.deb
dpkg -i zabbix-agent_6.4.0-1+ubuntu22.04_amd64.deb

В файле /etc/zabbix/zabbix_agentd.conf укажите:

Server=IP_вашего_zabbix_server
ServerActive=IP_вашего_zabbix_server
Hostname=имя_хоста_как_в_веб_интерфейсе

Перезапустите агент: systemctl restart zabbix-agent. В веб-интерфейсе Zabbix перейдите в Configuration → Hosts, создайте новый хост с именем, совпадающим с Hostname в конфиге агента. Привяжите шаблон Template OS Linux by Zabbix agent. Через 1-2 минуты в Monitoring → Latest data появятся метрики CPU, памяти, дисков и сети.

Создание дашборда для отслеживания обновлений в Zabbix

Перейдите в Monitoring → Dashboards → Create dashboard. Добавьте виджеты:

1. Graph: CPU utilization (item: system.cpu.util[,system], system.cpu.util[,user], system.cpu.util[,iowait])
2. Graph: Memory usage (item: vm.memory.size[available])
3. Graph: Disk IO (item: vfs.dev.read.ops, vfs.dev.write.ops)
4. Graph: Network traffic (item: net.if.in, net.if.out)
5. Problems: текущие триггеры по выбранным хостам

Для каждого графика настройте временной диапазон «Last 30 minutes» и автообновление каждые 30 секунд. Во время деплоя этот дашборд на отдельном мониторе даст мгновенную картину состояния инфраструктуры.

Пошаговая настройка Prometheus и Grafana для мониторинга обновлений

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

Развертывание Prometheus и экспортеров

Создайте docker-compose.yml:

version: '3.8'
services:
  prometheus:
    image: prom/prometheus:v2.45.0
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    ports:
      - "9090:9090"

  node_exporter:
    image: quay.io/prometheus/node-exporter:v1.6.1
    ports:
      - "9100:9100"

  grafana:
    image: grafana/grafana:10.0.0
    ports:
      - "3000:3000"
    volumes:
      - grafana_data:/var/lib/grafana

volumes:
  prometheus_data:
  grafana_data:

Файл конфигурации prometheus.yml:

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['node_exporter:9100']

Запустите docker compose up -d. Prometheus доступен на порту 9090, Grafana на 3000 (логин admin/admin).

Написание PromQL запросов для метрик обновления

Для контроля деплоя используйте запросы, которые показывают изменения за короткий промежуток:

• CPU utilization по всем ядрам: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)
• Доступная память в гигабайтах: node_memory_MemAvailable_bytes / 1024 / 1024 / 1024
• Дисковая латентность: rate(node_disk_io_time_seconds_total[5m]) * 100
• Сетевой трафик (Mbps): rate(node_network_receive_bytes_total[5m]) * 8 / 1000000
• Выявление аномалии по CPU: (rate(node_cpu_seconds_total{mode="iowait"}[1m]) / rate(node_cpu_seconds_total{mode="iowait"}[1h] offset 1h)) > 2 - покажет хосты, где iowait вырос вдвое по сравнению с часом назад.

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

В Grafana перейдите в Dashboards → Import и введите ID 1860 для загрузки Node Exporter Full. Это даст полный набор панелей по CPU, памяти, дискам и сети. Для кастомного дашборда обновлений создайте новый и добавьте панели:

1. CPU по ядрам - визуализация Graph, запрос из примера выше
2. Дисковая латентность - Heatmap, запрос rate(node_disk_io_time_seconds_total[5m])
3. Сетевые ошибки - Stat, запрос rate(node_network_receive_drop_total[5m])

Настройте переменную $host для выбора сервера. Это позволит переключаться между обновляемыми экземплярами без создания отдельных дашбордов. Для Kubernetes-инфраструктуры используйте готовый дашборд ID 315 (Kubernetes cluster monitoring), который показывает состояние подов, деплойментов и PVC. Детальная инструкция по настройке мониторинга в Kubernetes - в нашем пошаговом руководстве по Prometheus, Grafana и Alertmanager.

Настройка алертов, реагирующих на аномалии при обновлениях

Дашборд требует внимания оператора. Алерты работают автоматически и оповещают команду при отклонениях от нормы. Принцип настройки: определяете baseline, задаете порог отклонения, настраиваете канал доставки.

Алерты в Zabbix: триггеры и действия

Перейдите в Configuration → Hosts → ваш хост → Triggers → Create trigger. Примеры триггеров для сценария обновления:

• Резкий рост iowait: выражение avg(/host/system.cpu.util[,iowait],5m) > 20 - сработает, если средний iowait за 5 минут превысит 20%.
• Нехватка памяти: last(/host/vm.memory.size[available]) < 500M
• Заполнение диска: last(/host/vfs.fs.size[/,pused]) > 85

Для отправки уведомлений настройте действие: Alerts → Actions → Create action. Укажите условия (триггер сработал), операцию (отправить сообщение) и медиа-тип (Telegram, Slack, email). Добавьте эскалацию: если проблема не решена за 10 минут, отправить повторное уведомление с повышенным приоритетом.

Алерты в Prometheus: правила и Alertmanager

Создайте файл alerting_rules.yml:

groups:
  - name: deployment_alerts
    rules:
      - alert: HighCPUDuringDeploy
        expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "CPU выше 90% на {{ $labels.instance }}"
          description: "Утилизация CPU превысила 90% в течение 5 минут. Проверьте процесс обновления."

      - alert: HighDiskLatency
        expr: rate(node_disk_io_time_seconds_total[5m]) * 100 > 50
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Высокая дисковая латентность на {{ $labels.instance }}"

Подключите файл в prometheus.yml:

rule_files:
  - 'alerting_rules.yml'

Настройте Alertmanager для отправки в Slack. В файле alertmanager.yml:

receivers:
  - name: 'slack'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/YOUR/WEBHOOK/URL'
        channel: '#alerts'
        title: '{{ .GroupLabels.alertname }}'
        text: '{{ .CommonAnnotations.description }}'

Группировка алертов (group_by: ['alertname']) предотвращает флуд: вместо 50 сообщений о высокой нагрузке на каждом поде вы получите одно с перечислением затронутых экземпляров.

Интеграция мониторинга в процесс CI/CD

Ручной контроль дашборда при каждом деплое не масштабируется. Автоматизируйте проверку метрик в пайплайне.

Добавьте шаг в GitLab CI или Jenkins, который делает запрос к API Prometheus до старта обновления, во время и после:

# Сохранение baseline до деплоя
curl -s 'http://prometheus:9090/api/v1/query?query=100%20-%20(avg%20by%20(instance)%20(rate(node_cpu_seconds_total{mode%3D"idle"}[5m]))%20*%20100)' | jq '.data.result[0].value[1]' > baseline_cpu.txt

# Проверка через 5 минут после деплоя
CURRENT_CPU=$(curl -s 'http://prometheus:9090/api/v1/query?query=...' | jq '.data.result[0].value[1]')
BASELINE_CPU=$(cat baseline_cpu.txt)
if (( $(echo "$CURRENT_CPU > $BASELINE_CPU * 1.5" | bc -l) )); then
  echo "CPU вырос более чем на 50% относительно baseline. Запускаем откат."
  kubectl rollout undo deployment/myapp
fi

Этот скрипт сравнивает текущую утилизацию CPU с baseline и автоматически откатывает деплой при превышении порога в 1.5 раза. Аналогичные проверки добавляются для памяти, дискового IO и количества ошибок приложения.

Мониторинг контейнеризированных приложений в Kubernetes при обновлениях

Kubernetes добавляет уровень абстракции, который требует отдельных метрик. При rolling update важно отслеживать не только ресурсы подов, но и состояние деплоймента.

Сбор метрик Kubernetes с Prometheus

Установите kube-prometheus-stack через Helm:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install monitoring prometheus-community/kube-prometheus-stack

Стек включает node_exporter, kube-state-metrics и cadvisor. Ключевые метрики для обновлений:

• kube_deployment_status_replicas_updated - количество обновленных реплик
• kube_deployment_status_replicas_available - количество доступных реплик
• kube_pod_container_status_restarts_total - перезапуски контейнеров

Отслеживание состояния StatefulSet и PVC

Для баз данных в Kubernetes критичны метрики постоянных томов. В материале S3 описан сценарий с PostgreSQL в StatefulSet с одним PVC. Одна реплика на одном PVC сохраняет данные при перезапуске пода, но не обеспечивает высокую доступность. Мониторинг должен отслеживать:

• kube_statefulset_status_replicas_ready - готовность реплик StatefulSet
• kube_persistentvolumeclaim_status_phase - статус PVC (Bound, Pending, Lost)
• kubelet_volume_stats_used_bytes - использование места на томе

Алерт на заполнение PVC: kubelet_volume_stats_used_bytes / kubelet_volume_stats_capacity_bytes > 0.85. При срабатывании увеличивайте размер тома до того, как база данных остановится.

Быстрое выявление проблем: корреляция метрик и логов

Метрика показывает, что проблема есть. Лог объясняет, почему она возникла. Grafana Loki интегрируется с Prometheus и позволяет на одном дашборде видеть график метрики и связанные логи.

Пример настройки: на панели Grafana разместите график HTTP-ошибок 5xx из prometheus_nginx_exporter, а под ним - таблицу с логами из Loki, отфильтрованными по тому же временному диапазону и хосту. При клике на всплеск ошибок вы видите конкретные сообщения из логов приложения.

Для сбора логов в Kubernetes используйте promtail как DaemonSet. Конфигурация promtail автоматически подхватывает логи всех подов и отправляет в Loki. В Grafana создайте data source Loki и используйте запрос {app="myapp"} |= "error" для фильтрации.

Заключение: чек-лист для мониторинга обновлений

Перед каждым деплоем выполните шесть шагов. Это займет 10 минут, но сэкономит часы на разборе инцидентов.

1. Проверьте работу агентов и экспортеров. В Zabbix: Monitoring → Hosts → статус агента должен быть зеленым. В Prometheus: Status → Targets → все эндпоинты в состоянии UP.
2. Снимите baseline. Зафиксируйте средние значения CPU, памяти, дискового IO и сетевого трафика за последний час до деплоя. Сохраните скриншот дашборда или значения API-запроса.
3. Настройте дашборд. Убедитесь, что графики показывают данные за последние 30 минут с автообновлением. Откройте дашборд на отдельном мониторе или вкладке.
4. Проверьте алерты. Отправьте тестовое уведомление в Telegram/Slack. Убедитесь, что пороги триггеров соответствуют ожидаемой нагрузке при обновлении.
5. Интегрируйте в CI/CD. Добавьте шаг с запросом к API мониторинга и автоматическим откатом при превышении порогов.
6. После обновления сравните метрики с baseline. Если отклонения в пределах 10-15% - релиз стабилен. При росте ошибок или задержек запускайте откат.

Для углубленного изучения темы рекомендуем руководство по мониторингу дискового пространства в Linux, где разобраны специфичные сценарии для Zabbix с LLD и Prometheus с Node Exporter. Если ваша инфраструктура требует масштабирования, обратите внимание на облачные серверы Timeweb Cloud, которые предоставляют гибкие ресурсы для размещения систем мониторинга и целевых приложений.