Поприветствуйте Observability 3.0

Было два часа ночи. В платёжной системе резко возросла задержка. Панели управления выглядели нормально, но клиенты отваливались. Наша команда SRE работала в авральном режиме: логи в ELK, метрики в Prometheus, трассировки в Jaeger. Спустя несколько часов мы сообразили: медленный вызов во время маркетинговой кампании заблокировал конвейер. Знакомо?

Именно этот опыт стал причиной развития Observability — и именно поэтому вы сейчас слышите о Observability 3.0 .

Если вы разработчик, SRE или инженер DevOps, вам интересно, что все это значит и с чего начать, то эта статья станет для вас введением для новичков в эволюцию наблюдаемости — от версии 1.0 до сегодняшнего более интеллектуального, экономически обоснованного и взаимосвязанного с бизнесом мира.

* Что такое наблюдаемость?

По своей сути, наблюдаемость заключается в ответе на следующие вопросы:

«Что происходит внутри моей системы — без добавления нового кода каждый раз, когда что-то ломается?»

Речь идёт не просто о мониторинге бесперебойности работы. Речь идёт о понимании поведения системы, её производительности и сбоев в режиме реального времени.

* Наблюдаемость 1.0: логи, метрики и трассировки в хранилищах

Основные характеристики:

• Три отдельных инструмента: логи (ELK), метрики (Prometheus), трассировки (Jaeger)
• Ручная корреляция: чтобы увидеть всё, приходилось переключаться между инструментами.
• Высокие накладные расходы: множество переключений контекста, решений по индексации и игра в угадайку.

Общие инструменты:

• Логи: стек ELK, Splunk, Graylog, Fluentd
• Метрики: Prometheus, Graphite, InfluxDB
• Трейсы: Jaeger, Zipkin
• Дашборды: Grafana, Kibana
• Оповещения: PagerDuty, AlertManager

Проблемы:

• Куда вообще в первую очередь смотреть?
• Мы не настроили инструментацию этого эндпоинта.
• Для устранения одной проблемы понадобится пять инструментов.
• Переключение контекста — проверка логов в ELK, затем метрик в Prometheus, затем трассировок в Jaeger.

Короче говоря, видимость была фрагментарной. Полезной, но болезненной.

* Observability 2.0: унифицированная телеметрия

Observability 2.0 объединил все сигналы — логи, метрики, трассировки — в единое коррелированное представление .

Что изменилось:

• Данные из разных источников могут быть связаны автоматически
• Широкие, структурированные события как единственный источник правды
• Вы можете отслеживать путь пользователя от начала до конца , через микросервисы.
• Такие инструменты, как Datadog, Grafana Cloud и Elastic Observability
• OpenTelemetry упростил кросс-языковое инструментирование

Преимущества :

• Задавайте более глубокие вопросы после инцидентов
• Отладка быстрее с меньшим количеством инструментов
• Лучшее взаимодействие компонентов — мы все просматриваем одни и те же данные в одном месте.

Проблемы:

• Проблемы со стоимостью — мы отправляем слишком много данных, и это дорого.
• Сложность реализации — сложно правильно реализовать OpenTelemetry
• Значимость для бизнеса: инженерам это нравится, но бизнес не видит в этом ценности.

Короче говоря, по мере роста систем росли и данные. А вместе с ними росли затраты и сложность .

* Наблюдаемость 3.0: умная, экономичная, ориентированная на бизнес

Сейчас мы вступаем в эпоху Observability 3.0. Речь идёт не только о том, чтобы видеть всё, но и о том, чтобы разумно подходить к тому, что вы собираете и почему.

Что нового:

• Сохраняйте все локально, отправляйте в облако только то, что важно
• Инструменты AI/ML автоматически обнаруживают закономерности и аномалии
• Наблюдаемость становится значимой для бизнеса — связана с доходом, пользовательским опытом, соглашениями об уровне обслуживания
• Готовность к работе с периферийными устройствами: отлично подходит для мобильных устройств, интернета вещей и сред с ограниченной пропускной способностью
• Архитектура озера данных: объединение наблюдаемости с бизнес-аналитикой

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

• Сокращение расходов без потери видимости
• Согласуйте инженерные работы с влиянием на бизнес
• Заблаговременно устраняйте проблемы до того, как они затронут клиентов

Инструменты, воплощающие Наблюдаемость 3.0:

Вот две реальные платформы, помогающие командам совершить этот шаг:

🔹 Bitdrift

• Хранит телеметрию локально и отправляет ее только при соблюдении определенных правил.
• Идеально подходит для периферийных и высокопроизводительных систем
• «1000x телеметрии за 0,01x стоимости»

🔹 Honeycomb

• Создан для исследования многомерных данных (таких как идентификатор пользователя, сеанс)
• Отлично подходит для отладки неизвестных компонентов в сложных системах.
• Структурированные представления событий в реальном времени с контекстом трассировки

Локальное хранилище Bitdrift с панелью управления

Проще говоря, подход Bitdrift можно сравнить с установкой в ​​автомобиле умного видеорегистратора, который:

• Записывает все непрерывно (представьте себе DVR, который записывает постоянно)
• Сохраняет и загружает кадры только тогда, когда происходит что-то интересное (например, авария)
• Можно удаленно приказать изменить то, что он считает «интересным» (например, обновить программное обеспечение)
• Предпринимает особые действия при возникновении определенных закономерностей (например, автоматически зовет на помощь)

Для DevOps и SRE это означает:

• Вы настраиваете свой код для сбора ВСЕХ телеметрических данных (логов, метрик, трейсов и т. д.)
• Вместо того, чтобы отправлять все данные на платформу наблюдения, вы временно сохраняете их в локальном буфере.
• Вы определяете правила относительно того, какие события должны запускать загрузку данных.
• Когда происходят эти события, вы загружаете только соответствующие данные с контекстом.

Это значительно снижает затраты, поскольку вы платите только за передачу и хранение важных данных, а не за все.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Эволюция от Observability 1.0 к 3.0 отражает развитие в нашей отрасли представлений о видимости системы и ее целях:

- 1.0: Давайте соберем некоторые данные, которые помогут отладить проблемы

- 2.0: Давайте соберем унифицированные данные для понимания наших систем

- 3.0: Давайте разумно подходить к сбору данных и использовать их для повышения ценности бизнеса.