Какие инструменты вы использовали для мониторинга инфраструктуры и приложений?

«Какие инструменты вы использовали для мониторинга инфраструктуры и приложений?» — вопрос из категории Мониторинг и логирование, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Стек мониторинга строился вокруг Prometheus как основного сборщика метрик и Grafana для визуализации. Zabbix применял в legacy-средах.

Prometheus + Grafana (современный стек):

  • Prometheus – pull-модель. Настраивал scrape_configs для сбора метрик с:
    • Нод Kubernetes – через node_exporter (CPU, memory, disk I/O).
    • Приложений – instrumented на клиентах Prometheus (Go, Java, Python) или через exporters (например, nginx-exporter для метрик Nginx).
    • Сервисовkube-state-metrics для метрик объектов Kubernetes (статусы подов, реплик).
    • Blackbox мониторинг – проверка доступности эндпоинтов (HTTP, TCP, ICMP) с помощью blackbox_exporter.
  • Alertmanager – конфигурировал маршрутизацию алертов (группировка, подавление) и отправку в Slack, Email, PagerDuty.
  • Grafana – создавал дашборды с использованием PromQL. Например, дашборд для микросервиса включал: rate HTTP-запросов (5xx ошибок), latency (p95, p99), потребление памяти и CPU, бизнес-метрики (количество обработанных заказов).

Пример PromQL запроса для вычисления rate HTTP 500 ошибок за 5 минут:

sum(rate(http_requests_total{status="500", job="my-api"}[5m])) by (endpoint)

Пример конфигурации Prometheus для мониторинга приложения в Kubernetes через ServiceMonitor (часть Prometheus Operator):

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: myapp-monitor
spec:
  selector:
    matchLabels:
      app: myapp
  endpoints:
  - port: web
    interval: 30s
    path: /metrics

Zabbix (в legacy-проектах):

  • Использовал для мониторинга физических серверов, сетевого оборудования (через SNMP) и базовых метрик виртуальных машин, где не было возможности внедрить Prometheus.
  • Настраивал триггеры (например, "Свободное место на диске < 10% за 5 минут") и сложные action-ы, включающие выполнение remote-команд для автоматического очищения логов.

Для логирования параллельно использовал EFK Stack (Elasticsearch, Fluentd/Fluent Bit, Kibana). Fluent Bit в качестве DaemonSet в Kubernetes собирал логи со всех подов, парсил их, обогащал метаданными (namespace, pod name) и отправлял в Elasticsearch для индексации и поиска через Kibana.