Расскажи про опыт работы с Prometheus

В моей практике Prometheus был основным инструментом для мониторинга микросервисной архитектуры на Kubernetes. Я настраивал его для сбора метрик с приложений, написанных на Go и Java, используя клиентские библиотеки (client_golang, Micrometer) и экспортеры для сторонних систем (Node Exporter для хостов, cAdvisor для контейнеров).

Конкретные задачи, которые я решал:

• Настройка сбора метрик: Создание и документирование эндпоинтов /metrics для сервисов. Инструментация бизнес-логики (счетчики запросов, гистограммы длительности).
• Конфигурация в Kubernetes: Использование ServiceMonitor CRD от Prometheus Operator для автоматического обнаружения подов.
• Создание правил алертинга: Писал правила на PromQL для отслеживания SLA. Например, алерт на высокую задержку 95-го перцентиля или увеличение количества 5xx ошибок.

# Пример правила из моего опыта (alertmanager.yml)
groups:
- name: backend-services
  rules:
  - alert: HighErrorRate
    expr: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.05
    for: 2m
    labels:
      severity: warning
      team: backend
    annotations:
      description: "Error rate for {{ $labels.service }} is {{ $value }}. Instance: {{ $labels.instance }}"
      runbook: "https://wiki.internal/runbooks/high-error-rate"

• Интеграция с Grafana: Создание дашбордов для команд разработки, отображающих ключевые метрики приложений (RPS, latency, error rate) и потребление ресурсов.
• Масштабирование: Для долговременного хранения и высокой доступности настраивал связку Prometheus + Thanos (Sidecar, Querier, Store Gateway).

Основные сложности и решения:

• Кардинальность метрик: Следил за высоким уровнем кардинальности из-за лейблов типа user_id, использовал агрегацию в правилах записи (recording rules).
• Потребление ресурсов: Настраивал интервалы скрейпинга (scrape_interval) в зависимости от критичности сервиса и объема метрик.