Про наблюдаемость обычно говорят: логи, метрики и трассировка. Небольшой команде это стоит недель настройки и счёта за хранение. В статье рассматриваем, с чего лучше начать, а в конце подборка книг и курсов для тех, кто захочет разобраться глубже.
Про наблюдаемость обычно говорят: логи, метрики и трассировка. Небольшой команде это стоит недель настройки и счёта за хранение. В статье рассматриваем, с чего лучше начать, а в конце подборка книг и курсов для тех, кто захочет разобраться глубже.
В статье есть ссылки партнеров. Это значит, что если вы что-то покупаете с нашей помощью — вы также поддерживаете dev.by. (Вот другой способ).
При этом редакция и авторы независимы в выборе темы, концепции материала, фокуса описания, подхода к услугам или товарам. Прежде чем что-то советовать, мы много читаем и смотрим по теме, говорим с экспертами.
Редакция может выражать свое мнение и пробовать всё на себе.
Если рекомендательный материал обновляется, мы указываем, что и когда поменялось, в самом начале.
Открываете любой гайд по наблюдаемости, а там «три столпа» (логи, метрики и распределённая трассировка) и совет поставить всё сразу. Команда поменьше на этом обычно застревает: инженеры неделями возятся с инфраструктурой, а счета за хранение растут.
Дело ещё и в неудобстве. Когда что-то падает, дежурный открывает Grafana, потом вкладку с логами в Elastic или Loki, потом Jaeger и сводит всё это руками по времени. Чарити Мейджорс, сооснователь Honeycomb, пишет, что при таком подходе у вас «много источников истины, рассыпанных по разным инструментам и форматам». И платите вы за хранение одного и того же события несколько раз.
Если коротко: каждый отвечает на свой вопрос.
С чего начинать, зависит от того, как устроена ваша система.
Лучше начать с логов, потом добавить метрики, а трассировку отложить. Мейджорс считает, что основа всего — «широкие структурированные события», из которых можно вывести все остальные типы данных, и метрики получаются из них, а не наоборот. Поэтому сначала стоит привести логи в порядок.
Трассировка в монолите, как правило, не нужна: всё происходит в одном процессе, и ошибку находят по логам. Большие монолиты вполне живут без неё. Shopify работает на монолите Ruby on Rails, где больше 2,8 млн строк кода, и, по их описанию на 2020 год, держит порядок за счёт модулей. Раз монолит такого размера обходится без распила на сервисы, значит, и трассировка ему пока не обязательна. Это вывод из их примера.
Тогда порядок другой: метрики по каждому сервису и трассировка нужны почти сразу. Логи при этом остаются с первого дня, иначе трасса покажет, где тормозит, но не объяснит, что случилось внутри сервиса. Это тоже вывод, а не цитата.
Пример для масштаба: Netflix в 2008 году на три дня остался без возможности отправлять DVD из-за повреждённой базы данных. Потом за семь лет компания переехала в облако и распилила монолит на сотни микросервисов, как рассказывал один из её вице-президентов.
Тогда начните с метрик, и даже раньше логов. Если о поломках вы узнаёте от пользователей, хватит самого простого: считать запросы и долю ошибок по каждому сервису и поставить один алерт на рост ошибок. Когда нужна планка, можно взять SLO (цель по надёжности) вроде «99% запросов отвечают быстрее полсекунды за месяц». Логи всё равно пригодятся, но уже после алерта, чтобы найти причину.
OpenTelemetry. Адам Уилсон, principal SRE компании ComplyAdvantage, рассказывал на ObservabilityCon 2023, что его команда за два года дважды меняла платформу наблюдаемости: сначала с Grafana OSS на Datadog, потом с Datadog на Grafana Cloud. Вторая миграция получилась, по описанию доклада, потому что команда широко использовала OpenTelemetry. Отсюда совет: ставьте OpenTelemetry сразу, тогда смена бэкенда не потребует переписывать код.
Если хочется разобраться глубже, вот подборка. Начать можно и без покупок: для старта хватит логов, которые вы уже пишете, и одного дашборда с ошибками.
Курс «OpenTelemetry for Unified Observability» на Coursera, средний уровень, около пяти часов. Инструментируете ASP.NET Core и отправляете данные в Jaeger, Prometheus и Azure Monitor. OTel Collector в программе нет, а для других стеков курс мало подойдёт.
Курс «Observability with Grafana, Prometheus, Loki, Alloy and Tempo» на Udemy: метрики, логи и трассы в одном стеке.
Интенсив «OpenTelemetry Foundations: Hands-On Observability» на Udemy.
Книга «Observability Engineering: Achieving Production Excellence» Charity Majors, Liz Fong-Jones и George Miranda, сотрудников Honeycomb. О том, что такое хорошая наблюдаемость и как уйти от старых инструментов вроде мониторинга метрик и управления логами.
Книга «Distributed Tracing in Practice: Instrumenting, Analyzing, and Debugging Microservices» Остина Паркера и соавторов. Как поставить трассировку в код, собрать данные и понять, что с ними делать.
Если после падения непонятно, что сломалось, наведите порядок в логах. Если о проблемах вы узнаёте от пользователей, поставьте метрики и один алерт на ошибки. А трассировку добавляйте, когда сервисов станет много и вы начнёте часами искать, какой из них завис.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.