В современном мире разработки программного обеспечения мы часто сталкиваемся с парадоксальной ситуацией: чем сложнее становится наша система, тем меньше мы о ней знаем. Это как с современным автомобилем - мы можем ездить на нем годами, но понятия не имеем, как работает его двигатель. Observability - это попытка разорвать этот порочный круг и показать нам, если не "как именно" работает каждый компонент нашего сервиса, то "насколько хорошо".

Почему observability - это не просто мониторинг?

Представьте, что вы врач в отделении интенсивной терапии. У вас есть пациент, подключенный к множеству датчиков. Мониторинг покажет вам, что пульс пациента 120 ударов в минуту. А observability позволит вам понять, почему это происходит - возможно, это реакция на лекарство, а может быть, признак начинающейся инфекции.

В мире программного обеспечения ситуация похожая. Традиционный мониторинг говорит нам: "Сайт работает медленно". Observability отвечает на вопрос: "Почему сайт работает медленно?" и, что еще важнее, "Что мы можем с этим сделать?"

Прошло то время, когда мы довольствовались одной лишь связкой Grafana, Prometheus, Node Exporter. Сейчас в больших современных системах живут десятки и даже сотни экспортеров, которые собирают показатели с каждого компонента системы и не одним способом. Несколько экземпляров Prometheus, огромные горячие и холодные хранилища метрик, которые позволяют обрабатывать и хранить терабайты данных - все это может визуализироваться в одном дашборде или даже на одном графике, который покажет нам доступность и производительность наших сервисов.

SLI и SLO: как измерить неосязаемое?

Давайте рассмотрим пример. У вас есть интернет-магазин. Казалось бы, что может быть проще - сайт либо работает, либо нет. Но на практике всё гораздо сложнее:

• Пользователь может открыть главную страницу за 0.1 секунды
• Но корзина может загружаться 5 секунд
• А оформление заказа может вообще не работать

Как измерить "работает ли сайт"? Вот тут и появляются SLI (Service Level Indicators). Это как медицинские показатели для вашего приложения:

• Доступность (uptime)
• Латентность (время отклика)
• Ошибки (количество 500-х ошибок)
• Пропускная способность (количество успешных запросов)

А SLO (Service Level Objectives) - это цели, которые мы ставим перед собой. Например:

• 99.9% запросов должны обрабатываться быстрее 200мс
• Не более 0.1% запросов должны завершаться ошибкой
• Время восстановления после сбоя не более 5 минут

Почему это важно?

Представьте, что у вас есть сервис доставки еды. Вы можете сказать: "Наш сервис работает хорошо, потому что мы доставляем 95% заказов вовремя". Но что это значит на практике?

• Возможно, 5% заказов опаздывают на 2 часа
• А может быть, 20% заказов опаздывают на 15 минут
• Или, может быть, 1% заказов вообще не доставляются

Без правильных SLI и SLO вы не сможете понять, насколько хорошо работает ваш сервис на самом деле. А без observability вы не сможете быстро понять, почему происходят задержки, на каком компоненте и как их исправить.

Эволюция мониторинга

Давайте проследим эволюцию мониторинга на примере простого веб-приложения:

1. Первый этап: "Сайт работает?"

• Простой пинг каждые 5 минут
• Базовые метрики CPU и памяти
• Логи ошибок в файле 2. Второй этап: "Почему сайт работает медленно?"
• Prometheus собирает детальные метрики
• Grafana показывает графики производительности
• Loki анализирует логи в реальном времени 3. Третий этап: "Как сделать сайт лучше?"
• Thanos хранит исторические данные
• Alertmanager предупреждает о проблемах
• SLI и SLO помогают принимать решения

Observability - это путь от "что происходит?" к "почему это происходит?" и, в конечном итоге, к "как это исправить?". В мире, где системы становятся все сложнее, observability - это не роскошь, а необходимость. Это инструмент, который помогает нам не только выжить в мире сотен микросервисов и десятков инфраструктурных элемнтов, но и быстро понимать, что что-то пошло не так, до того, как это заметят пользователи.