Ответ
В моей практике процесс мониторинга строится на стеке, который включает сбор, хранение, визуализацию и алертинг.
1. Сбор метрик: Использую Prometheus как основу для сбора временных рядов. Для системных метрик с серверов запускаю node-exporter. Конфигурация Prometheus для этого выглядит так:
scrape_configs:
- job_name: 'node'
static_configs:
- targets: ['node-exporter-1:9100', 'node-exporter-2:9100']Для прикладных метрик добавляю в код приложения инструментацию с помощью клиентских библиотек Prometheus.
2. Хранение: Для долгосрочного хранения и работы с большими объемами данных использую VictoriaMetrics или Thanos, что решает проблему масштабируемости и долговременного хранения Prometheus.
3. Визуализация и дашборды: Все метрики визуализирую в Grafana. Создаю дашборды для разных команд: общий обзор инфраструктуры (CPU, память, диск, сеть), дашборды по конкретным сервисам (латентность, ошибки, RPS) и бизнес-метрики.
4. Логирование: Для логов применяю архитектуру ELK (Elasticsearch, Logstash, Kibana) или более легкий стек Loki с Promtail. Loki удобен тем, что использует те же метки, что и Prometheus, и позволяет коррелировать логи с метриками.
5. Алертинг: Настраиваю правила алертинга в Alertmanager. Правила пишу в PromQL. Например, алерт на высокую загрузку CPU:
- alert: HighCpuUsage
expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
for: 5m
labels:
severity: warning
annotations:
summary: "High CPU usage on {{ $labels.instance }}"Уведомления настраиваю в Slack, Telegram или PagerDuty. Ключевой принцип — алерты должны быть actionable, то есть указывать на конкретную проблему и требовать действия, а не просто информировать о состоянии.