Большинство людей сразу прыгают в Prometheus и Grafana, не понимая, какую именно задачу они на самом деле решают.

Я постоянно вижу это на собеседованиях. Человек говорит: «Мы используем Prometheus для мониторинга», но при этом не может объяснить, почему логи и метрики требуют разных пайплайнов, или что вообще происходит, когда CloudWatch перестаёт справляться на масштабе.

В observability вы решаете две принципиально разные проблемы.

Логи отвечают на вопрос "что произошло". Произошла ошибка. Пришёл запрос. Упал запрос к базе данных.
Это события - истории, которые рассказывает ваше приложение.

Метрики отвечают на вопрос "как система чувствует себя прямо сейчас". Латентность 200 мс. CPU 75%. 500 запросов в минуту. Это измерения.

Разные типы данных. Разные способы сбора. Разное хранение. И именно здесь большинство людей путается.

В прошлом месяце на моём DevOps-буткемпе мы собрали полноценную систему observability для микросервисов в Kubernetes.

Логи

Для логов мы использовали Fluentd sidecar-контейнеры, которые шарят volume с основным контейнером приложения:
- приложение пишет логи в volume;
- Fluentd читает их и отправляет дальше;
- чёткое разделение ответственности;
- на небольшом масштабе логи просто улетают напрямую в CloudWatch.

Но когда у вас тысячи строк логов в секунду, приходится добавлять слои:
- Lambda для форматирования.
- Kinesis для буферизации.
- OpenSearch для быстрых запросов по петабайтам данных.
- S3 для долгосрочного бэкапа.

Мы держали 7 дней в OpenSearch для активных расследований. 30 дней — в CloudWatch. Годы — в S3 для комплаенса. У каждого слоя разные характеристики по цене и производительности.

Метрики

Для метрик Prometheus скрейпит application endpoints каждые 30 секунд:
- разработчики инструментируют код клиентскими библиотеками Prometheus;
- экспонируют /metrics endpoint;
- Prometheus сам подтягивает данные.

Мы создали ServiceMonitor’ы, которые говорят Prometheus, какие pod’ы скрейпить на основе label’ов:
- Как только поднимаются новые pod’ы, Prometheus их обнаруживает и начинает скрейпить.
- Дальше Grafana визуализирует всё это.
- Мы импортировали готовые дашборды с grafana.com для мониторинга Kubernetes.
- И также собрали кастомные панели под метрики конкретного приложения.

Логи и метрики идут параллельно.

Когда что-то ломается, метрики показывают вам всплеск: error rate подпрыгнул в PM. Латентность выросла со 100 мс до 2 секунд.

Дальше вы идёте в логи: фильтруете по тому же окну времени, находите stack trace’ы и видите, что именно упало.

Нельзя нормально дебажить, имея только один тип данных. Нужны обе перспективы.

Мы всё это реализовали и оттраблшутали в лайв-созвоне: нагенерили метрики и логи и собрали дашборды в Grafana

Прочитать подробный пост можно здесь: https://open.substack.com/pub/akhileshmishra/p/youre-not-ready-for-kubernetes-observability

👉 DevOps Portal