Чтобы перестать работать «вслепую», я решил внедрить стек наблюдаемости. До этого у нас были только системные логи и пара метрик из облачного дашборда — CPU и RAM. Они ничего не говорили о том, что на самом деле происходит с приложением.
Падение API я видел через час после жалобы пользователей. Тогда я понял: нужна система, которая показывает всё в реальном времени — от нагрузки до задержек.
Prometheus — фундамент метрик
Я начал с Prometheus. Это инструмент для сбора и хранения временных рядов (time series). Он периодически опрашивает источники — так называемые targets — и сохраняет метрики в своей базе.
Главная идея проста: каждая метрика имеет имя и набор меток (labels), по которым потом можно фильтровать и строить графики.
Типичный конфиг prometheus.yml у меня выглядит так:
scrape_configs:
- job_name: "kubernetes-nodes"
kubernetes_sd_configs:
- role: node
- job_name: "application"
static_configs:
- targets: ["app-service:8080"]
Prometheus сам идёт в Kubernetes API, находит поды и собирает с них метрики.
Добавил /metrics в наши микросервисы с помощью библиотеки prometheus_client (для Python) и Micrometer (для Java). Теперь у меня есть реальные данные:
- http_request_duration_seconds — задержки по endpoint’ам,
- http_requests_total — общее количество запросов,
- process_cpu_seconds_total — загрузка CPU процессом.
С этого момента любое изменение можно проверить не субъективно, а по числам.
Grafana — визуализация и дашборды
Следующий шаг — Grafana. Она подключается к Prometheus как к источнику данных и превращает метрики в понятные графики.
Настроил несколько панелей:
- Latency (p95) — 95-й перцентиль задержек,
- Error rate — процент ответов 5xx,
- CPU/memory usage per pod,
- Request throughput per service.
Сначала я строил всё вручную, потом сделал шаблонные дашборды — они автоматически подхватывают новые сервисы через label service_name.
Grafana оказалась полезна не только для мониторинга, но и для пост-инцидентного анализа. После релиза можно увидеть, как менялось время ответа и сколько запросов упало.
(пример: дашборд с панелями latency и error rate, фильтр по сервису)
Loki — хранение и поиск логов
Дальше пришла очередь логов. Мы использовали kubectl logs и grep, но при десятках подов это стало неэффективно.
Я развернул Loki — систему логирования от Grafana Labs.
Loki хранит логи не в привычном текстовом виде, а в виде индексированных блоков с метками (labels), аналогично Prometheus.
Это значит, что я могу искать по namespace, pod, service, level и другим тегам.
Запрос в Grafana выглядит, например, так:
{app="api", level="error"} |= "timeout"
Этот фильтр показывает все ошибки уровня error с упоминанием timeout из подов сервиса api.
Сразу видно, какой контейнер шумит и в какой момент.
Loki поддерживает retention, сжатие и горизонтальное масштабирование, поэтому его можно использовать и в production-среде без особых затрат.
Promtail — агент доставки логов
Promtail
Чтобы логи попадали в Loki, нужен агент — Promtail.
Он запускается на каждом узле (или в DaemonSet в Kubernetes) и читает файлы контейнеров из /var/lib/docker/containers.
Вот так примерно настроил promtail-config.yaml :
scrape_configs:
- job_name: containers
static_configs:
- targets:
- localhost
labels:
job: docker
__path__: /var/lib/docker/containers/*/*.log
Promtail парсит JSON-логи Docker, добавляет метки (namespace, pod, container_name) и отправляет всё в Loki по HTTP.
Через несколько минут после запуска я увидел в Grafana связку:
график latency ↑ → лог connection timeout — и стало понятно, где искать причину.
Что даёт этот стек в связке
После настройки я получил сквозную наблюдаемость — от метрик до логов.
Например:
- Увеличилась http_request_duration_seconds? → Смотрю в Loki по тем же меткам.
- Хочу понять, кто потребляет больше CPU? → Grafana + Prometheus с фильтром instance.
- Надо отследить поведение при деплое? → Смотрю изменение latency и количество ошибок в одном графике.
Всё это работает без ручных действий: Prometheus сам собирает метрики, Promtail отправляет логи, Grafana визуализирует.
Данные из стека Prometheus/Grafana/Loki помогают принимать решения на основе фактов, а не предположений.