Карта: 22 понятия в семи группах

Карта метро: сначала видишь линии целиком, потом едешь по станциям.

Сначала три основы — почему в проде летишь по приборам, чем мониторинг отличается от наблюдаемости и что такое чёрный ящик. Дальше шесть групп, по одной на главу: логи, метрики, трейсы, как три столпа работают вместе, алертинг и как применять хорошо.

У каждого понятия дальше одно и то же: английское название (запомни его — это термин), образ из жизни, схема и карточка с полями: проблема, идея, пример, цена или подвох, когда брать и связи.

Flying by Instruments — к проду нельзя подключить отладчик

Пилот не может вылезти и осмотреть двигатель в полёте — он летит целиком по приборам на панели, доверяя стрелкам рассказывать, что происходит.

На ноутбуке ты ставишь код на паузу, смотришь переменные, шагаешь. В проде (production) — реальные серверы, реальные пользователи, прямо сейчас — нельзя остановить, чтобы посмотреть. Узнать, что происходит, можно только из сигналов (signals), что система излучает на ходу.

Это ключевой сдвиг: в проде ты летишь по приборам, и наблюдаемость — это про то, чтобы нужные приборы были на панели до того, как они понадобятся.

Monitoring vs Observability — известные и новые вопросы

Приборка машины показывает те немногие вещи, что ты знал отслеживать, — скорость, топливо, температуру. Но когда начинается странный новый звук, тебе надо мочь исследовать то, под что никто не поставил стрелку.

Мониторинг (monitoring) — это слежение за проблемами, что ты предвидел: дашборды и алерты для известных режимов сбоя. Наблюдаемость (observability, часто пишут o11y) — более глубокое свойство: можешь ли ты ответить на вопросы, что не предвидел, просто из данных, что система производит?

Реальные сбои обычно новы — «почему пользователи в Бразилии видят медленные оплаты с двух дня?» — и наблюдаемость это то, излучает ли твоя система достаточно, чтобы дать тебе гнаться за вопросом, что ты никогда не планировал.

Black Box — система, о которой можно только гадать

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

Система, что излучает мало, — это чёрный ящик (black box): когда она ведёт себя плохо, ты сведён к гаданию и перезапускам. Цена проявляется в худший момент — продакшен-инцидент, где каждая минута важна, а ты понятия не имеешь, куда смотреть.

Наблюдаемость оплачивается заранее, инструментируя (instrumenting) систему, пока она спокойна, чтобы, когда она в огне, у тебя был свет, чтобы видеть.

Log — дневник системы

Судовой журнал: записи с отметкой времени о том, что случилось и когда — «10:42, вошли в гавань» — чтобы любой потом мог восстановить плавание.

Лог (log) — это запись события с отметкой времени: «пользователь 42 вошёл», «платёж упал: карта отклонена», «начал обработку заказа 91». Каждая строка — маленькая, детальная заметка о чём-то, что случилось, написанная по ходу работы кода.

Логи — богатейший сигнал, потому что несут конкретику: ровно что, ровно когда, с приложенными деталями. Когда надо узнать, что реально случилось в одном случае, смотришь в логи.

Structured Logging — логи, которые можно искать

Разница между коробкой рукописных заметок и таблицей — обе держат факты, но только одна даёт мгновенно отфильтровать всё про клиента 42.

Строку свободного текста трудно искать по миллионам записей. Структурированные логи (structured logs) пишут каждое событие как данные — поля вроде user_id: 42, status: failed, duration_ms: 230, — чтобы по ним можно было запрашивать: «покажи каждый упавший платёж дольше 500 мс сегодня».

Это превращает логи из стены текста, что ты пролистываешь, в базу, что можно допрашивать. Структура — вот что делает логи пригодными в масштабе прода.

Log Levels — уровни отделяют сигнал от шума

Дневник, где рутинные записи карандашом, а ЧП красными чернилами, — чтобы в кризис можно было пролистать сразу к красному и игнорировать остальное.

У каждого лога есть уровень (level), отмечающий важность: DEBUG и INFO для рутинной детали, WARN для чего-то не так, ERROR для реального сбоя. Уровни дают прибавить громкость при расследовании и убавить в нормальной работе, и прыгнуть сразу к ошибкам в потоке записей.

Использованные хорошо, уровни — это как держать важные строки находимыми; проигнорированные, каждый лог выглядит одинаково срочным, и ни один не выделяется.

Log Volume — слишком много логов так же бесполезно, как слишком мало

Дневник, что записывает каждый вдох, так же нечитаем, как пустой, — нужный сигнал погребён в шуме, что никто не просеет.

Логи соблазнительно переусердствовать, и чрезмерное логирование (over-logging) имеет реальную цену: дорого хранить, медленно искать, и оно хоронит важные строки под шумом.

Навык — логировать то, что реально захочешь позже: решения, сбои, ключевые события — с достаточной деталью, чтобы быть полезным, и не такой, чтобы сигнал утонул. Логируй нарочно, а не рефлекторно.

Metric — число во времени

Больничный график, отслеживающий пульс через ночь, — не каждое биение, а число, снимаемое ровно, чтобы растущий тренд бросался в глаза.

Метрика (metric) — это измерение, отслеживаемое во времени: запросов в секунду, доля ошибок, время ответа, использованная память. В отличие от лога, она не про одно событие — это агрегат (aggregate), снимаемый непрерывно, так что ты видишь тренды и всплески.

Метрики дёшевы собирать и хранить, потому что это просто числа, а значит, их можно держать по всему, всё время, и смотреть, как форма твоей системы движется.

Counter vs Gauge — счётчик растёт, датчик качается

Одометр только лезет вверх, считая общий пробег; спидометр поднимается и падает с тем, как быстро ты едешь прямо сейчас.

Две базовые формы покрывают большинство метрик. Счётчик (counter) только растёт — всего обслужено запросов, всего ошибок — и ты смотришь его скорость изменения. Датчик (gauge) ходит вверх-вниз, показывая текущее значение — память в использовании, активные соединения, длину очереди.

Знать, на что из них смотришь, говорит, как это читать: у счётчика история — это наклон; у датчика — текущая высота.

Dashboard — тренды становятся видны

Стена датчиков в диспетчерской: с одного взгляда оператор видит, что всё зелёное и ровное, или что одна стрелка лезет к красному.

Метрики обычно смотрят на дашборде (dashboard) — графиках ключевых чисел во времени, бок о бок. Хороший дашборд даёт увидеть здоровье системы за секунды и заметить миг, когда линия согнулась не туда.

Здесь метрики отрабатывают своё содержание: не в каком-то одном значении, а в видимом тренде, что говорит «что-то начало идти не так в два дня» раньше, чем пользователи дожалуются.

Four Golden Signals — четыре жизненных показателя

Быстрая проверка жизненных показателей у врача — пульс, температура, давление, дыхание — крошечный набор, что ловит большинство неполадок, не измеряя всё.

Не нужна тысяча метрик, чтобы начать. Четыре золотых сигнала (four golden signals) покрывают бо́льшую часть здоровья системы: latency (задержка — сколько занимают запросы), traffic (трафик — сколько спроса), errors (ошибки — сколько запросов падает) и saturation (насыщение — насколько полны ресурсы).

Следи за этими четырьмя — и поймаешь подавляющее большинство проблем рано. Это жизненные показатели сервиса — первые стрелки, что ставишь на панель.

Trace — путь одного запроса через сервисы

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

В современных системах один запрос скачет через много сервисов — шлюз зовёт сервис заказов, что зовёт платежи, что зовут базу. Трейс (trace) записывает весь этот путь для одного запроса, сшитый так, чтобы видеть каждый скачок, что он сделал.

Он отвечает на вопрос, что ни логи, ни метрики не могут: не «что случилось» или «сколько», а «каков был путь этого конкретного запроса через всю систему?»

Span — куда ушло время

Маршрут поездки, разбитый на отрезки, у каждого своя длительность, — и мгновенно видно, что трёхчасовая пересадка, а не перелёты, съела день.

Трейс состоит из спанов (spans) — по одному на шаг, каждый замеряет, сколько занял тот кусок. Разложенные водопадом (waterfall), спаны показывают ровно, где медленный запрос провёл своё время: спан базы занял 900 мс, пока всё остальное заняло 50.

Без этого «запрос был медленным» — загадка через много сервисов; с этим ты указываешь прямо на виновника. Спаны превращают смутную медлительность в точное место.

Distributed Tracing — как отлаживают распределённые системы

Проследить одну упавшую палочку назад через эстафету, чтобы найти ровно, какая передача сбоила, — невозможно увидеть из одного финального результата.

Когда запрос падает или ползёт, а работа размазана по сервисам, трейс часто единственный способ найти где. Это и есть распределённый трейсинг (distributed tracing).

Метрики говорят, что система медленна; логи говорят, что сказал каждый сервис; трейс связывает путь одного запроса вместе и указывает на точный сервис и шаг, что сломался. Для всего распределённого трейсинг — инструмент, что превращает «где-то там пошло не так» в «вот здесь».

Three Pillars — каждый столп отвечает на свой вопрос

Расследование проблемы тремя инструментами: график, что показывает, когда всё изменилось, карта, что показывает где, и детальный отчёт, что показывает ровно что, — каждый бесполезен один, решающи вместе.

Три столпа наблюдаемости (three pillars of observability) делят работу. Метрики отвечают «есть ли что-то не так и каков тренд?» — дешёвый, всегда-включённый обзор. Трейсы отвечают «где, через все сервисы, проблема?» — сужая до шага. Логи отвечают «что именно там случилось?» — полная деталь на месте.

Ни один сам по себе не достаточен; каждый подхватывает там, где другие останавливаются.

Notice → Locate → Explain — естественный поток

Врач видит жар на графике, осматривает, чтобы найти, какой орган, потом гонит конкретный тест, что называет болезнь, — широкий сигнал, потом узкий, потом точный.

На практике ты движешься через них по порядку. Метрика или алерт говорит, что что-то не так (доля ошибок подскочила). Трейс показывает где (шаг сервиса платежей падает). Лог в той точке говорит ровно что (платёжный провайдер вернул таймаут).

От широкого к узкому к точному: метрика замечает, трейс локализует, лог объясняет. Знать этот поток — бо́льшая часть знания, как отлаживать прод.

Correlation ID — нить, что связывает всё вместе

Номер дела, написанный на каждом документе, фото и отчёте, — чтобы следователь мог стянуть всё об одном инциденте вместе, а не искать в каждой стопке отдельно.

Столпы куда сильнее, когда связаны. Прикрепление общего request ID (или trace ID) к метрикам, трейсу и каждой строке лога для запроса даёт прыгнуть от «этот запрос упал» прямо к его трейсу и его точным логам. Это и есть корреляция (correlation).

Без корреляции у тебя три отдельных стога; с ней один рывок стягивает всю историю инцидента вместе. Связи между столпами — вот что делает их системой, а не тремя инструментами.

Symptom-based Alerting — алертить на то, что чувствуют пользователи

Дымовой датчик должен сработать на настоящий пожар, а не каждый раз, как кто-то делает тосты, — иначе люди вырывают батарейку и пропускают настоящий.

Алерт (alert) — это автоматическое уведомление, когда что-то пересекает черту. Искусство — алертить на симптомы, что пользователи реально чувствуют (symptoms): падающие оплаты, медленный сайт, — а не на каждое внутреннее подёргивание.

Сервер на 80% памяти — не проблема, если пользователям хорошо; всплеск упавших заказов — да, даже если каждый сервер выглядит здоровым. Алерть на обращённый к пользователю исход, и будешь будить людей ради того, что правда важно.

SLI / SLO / SLA — определить «достаточно хорошо»

Служба доставки, обещающая «99% посылок приходят за два дня», — ясная, измеримая планка того, что считается приемлемым сервисом, согласованная заранее.

Три аббревиатуры формализуют «насколько хорошо достаточно хорошо». SLI (service level indicator) — это измерение (доля запросов, обслуженных под 300 мс). SLO (service level objective) — цель, что ты ставишь для него (должно быть 99,9%). SLA (service level agreement) — договорное обещание клиенту, с последствиями при провале.

Поставить явный SLO превращает надёжность из смутного ощущения в число, к которому можно держать систему, — и ясную черту, когда действовать.

Alert Fatigue — усталость от алертов, тихий убийца

Машина, что постоянно пищит на ерунду, приучает водителя игнорировать все писки, — так что одно предупреждение, что было важно, отсеивается со всеми остальными.

Слишком много алертов — это свой сбой: когда людей будят ради того, что не важно, они начинают игнорировать алерты целиком, и настоящий теряется в шуме — это усталость от алертов (alert fatigue).

Каждый алерт должен быть действенным (actionable) и стоить человеческого внимания прямо сейчас; если нет — ему место на дашборде, а не в пейджере. Меньше, острее алертов бьёт поток, потому что алерт, которому никто не доверяет, хуже, чем никакого.

Instrument as You Build — инструментируй, пока строишь, а не после пожара

Провести дымовые датчики, пока строишь дом, — а не стоять в дыму, жалея, что не провёл.

Худшее время добавить наблюдаемость — во время сбоя, когда обнаруживаешь, что система не говорит ничего. Так что встраивай инструментирование (instrumentation) по ходу: излучи метрику для новой фичи, логируй её ключевые решения, убедись, что запрос можно протрейсить через неё.

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

Start Small and Grow — начни с золотых сигналов и расти

Новый владелец магазина сперва следит за теми немногими числами, что важны, — продажи, проходимость, жалобы, — и добавляет более тонкое отслеживание, лишь когда возникают конкретные вопросы.

Не нужно полное покрытие в первый день. Начни с четырёх золотых сигналов и горстки логов в ключевых точках решений, потом добавляй деталь там, где реальные инциденты покажут тебе слепое пятно (blind spot).

Каждый сбой — урок о том, что ты жалеешь, что не записывал, — так дай своей наблюдаемости расти по контурам того, где система реально тебя удивляет, а не инструментируй всё заранее.

Как понятия связаны

Приборная панель самолёта: десяток стрелок, но все про один полёт — и пилот читает их вместе.

Всё в курсе — части одной панели. Работающая система излучает три сигнала: метрики замечают, трейсы локализуют, логи объясняют. Correlation ID связывает все три к одному запросу. Из метрик и золотых сигналов строятся SLI и SLO, а по ним — алерты на симптомы, немногие и точные, чтобы не было alert fatigue. А сама панель растёт, если инструментировать по ходу и добавлять детали по реальным инцидентам.