Экспресс-курс · No. 19
Когда твой код работает на ноутбуке, ты можешь поставить его на паузу и поковыряться. Когда он работает в проде, обслуживая реальных пользователей, — нельзя: ты узнаёшь, что происходит, только из того, что система тебе рассказывает. Наблюдаемость — это ремесло заставить систему объяснять себя через логи, метрики и трейсы, чтобы, когда что-то ломается в три ночи, ты задавал вопросы и получал ответы, а не гадал.
Только суть · Один образ на идею · Выучи слова
Вся область существует из-за одного жёсткого факта: нельзя отлаживать живую продакшен-систему так, как отлаживаешь код на машине. Так что приходится заставить систему рассказывать, что она делает.
К проду нельзя подключить отладчик
Пилот не может вылезти и осмотреть двигатель в полёте — он летит целиком по приборам на панели, доверяя стрелкам рассказывать, что происходит.
На ноутбуке ты ставишь код на паузу, смотришь переменные, шагаешь. В проде (production) — реальные серверы, реальные пользователи, прямо сейчас — нельзя остановить, чтобы посмотреть. Узнать, что происходит, можно только из сигналов, что система излучает на ходу. Это ключевой сдвиг: в проде ты летишь по приборам, и наблюдаемость — это про то, чтобы нужные приборы были на панели до того, как они понадобятся.
Мониторинг отвечает на известные вопросы; наблюдаемость — на новые
Приборка машины показывает те немногие вещи, что ты знал отслеживать, — скорость, топливо, температуру. Но когда начинается странный новый звук, тебе надо мочь исследовать то, под что никто не поставил стрелку.
Мониторинг (monitoring) — это слежение за проблемами, что ты предвидел: дашборды и алерты для известных режимов сбоя. Наблюдаемость (observability) — более глубокое свойство: можешь ли ты ответить на вопросы, что не предвидел, просто из данных, что система производит? Реальные сбои обычно новы — «почему пользователи в Бразилии видят медленные оплаты с двух дня?» — и наблюдаемость это то, излучает ли твоя система достаточно, чтобы дать тебе гнаться за вопросом, что ты никогда не планировал.
Чёрный ящик — это система, о которой можно только гадать
Торговый автомат, что взял чьи-то деньги и не дал ничего, без дисплея и без чека, — всё, что можно, это пожать плечами и гадать, ведь он не говорит ничего.
Система, что излучает мало, — это чёрный ящик (black box): когда она ведёт себя плохо, ты сведён к гаданию и перезапускам. Цена проявляется в худший момент — продакшен-инцидент, где каждая минута важна, а ты понятия не имеешь, куда смотреть. Наблюдаемость оплачивается заранее, инструментируя систему, пока она спокойна, чтобы, когда она в огне, у тебя был свет, чтобы видеть. Время добавить её — до того, как она понадобится.
Нельзя поставить прод на паузу, чтобы осмотреть. Наблюдаемость — это строить систему так, чтобы она объясняла себя, — чтобы отвечать на непредвиденные вопросы, а не только следить за предвиденными.
Старейший и самый детальный сигнал — лог: текущий дневник того, что система сделала. Это первое, к чему тянешься, и самое лёгкое в злоупотреблении.
Лог — это дневник системы
Судовой журнал: записи с отметкой времени о том, что случилось и когда — «10:42, вошли в гавань» — чтобы любой потом мог восстановить плавание.
Лог (log) — это запись события с отметкой времени: «пользователь 42 вошёл», «платёж упал: карта отклонена», «начал обработку заказа 91». Каждая строка — маленькая, детальная заметка о чём-то, что случилось, написанная по ходу работы кода. Логи — богатейший сигнал, потому что несут конкретику: ровно что, ровно когда, с приложенными деталями. Когда надо узнать, что реально случилось в одном случае, смотришь в логи.
Структурированные логи можно искать
Разница между коробкой рукописных заметок и таблицей — обе держат факты, но только одна даёт мгновенно отфильтровать всё про клиента 42.
Строку свободного текста трудно искать по миллионам записей. Структурированные логи (structured logs) пишут каждое событие как данные — поля вроде user_id: 42, status: failed, duration_ms: 230, — чтобы по ним можно было запрашивать: «покажи каждый упавший платёж дольше 500 мс сегодня». Это превращает логи из стены текста, что ты пролистываешь, в базу, что можно допрашивать. Структура — вот что делает логи пригодными в масштабе прода.
Уровни отделяют сигнал от шума
Дневник, где рутинные записи карандашом, а ЧП красными чернилами, — чтобы в кризис можно было пролистать сразу к красному и игнорировать остальное.
У каждого лога есть уровень (level), отмечающий важность: DEBUG и INFO для рутинной детали, WARN для чего-то не так, ERROR для реального сбоя. Уровни дают прибавить громкость при расследовании и убавить в нормальной работе, и прыгнуть сразу к ошибкам в потоке записей. Использованные хорошо, уровни — это как держать важные строки находимыми; проигнорированные, каждый лог выглядит одинаково срочным, и ни один не выделяется.
Слишком много логов так же бесполезно, как слишком мало
Дневник, что записывает каждый вдох, так же нечитаем, как пустой, — нужный сигнал погребён в шуме, что никто не просеет.
Логи соблазнительно переусердствовать, и чрезмерное логирование имеет реальную цену: дорого хранить, медленно искать, и оно хоронит важные строки под шумом. Навык — логировать то, что реально захочешь позже: решения, сбои, ключевые события — с достаточной деталью, чтобы быть полезным, и не такой, чтобы сигнал утонул. Логируй нарочно, а не рефлекторно.
Логи — детальный дневник того, что случилось. Сделай их структурированными, чтобы запрашивать, с уровнями, чтобы фильтровать, и сфокусированными, чтобы сигнал не терялся в шуме.
Логи рассказывают об отдельных событиях. Метрики рассказывают о целом, во времени, — числа, что показывают с одного взгляда, здорова ли система или сползает.
Метрика — это число во времени
Больничный график, отслеживающий пульс через ночь, — не каждое биение, а число, снимаемое ровно, чтобы растущий тренд бросался в глаза.
Метрика (metric) — это измерение, отслеживаемое во времени: запросов в секунду, доля ошибок, время ответа, использованная память. В отличие от лога, она не про одно событие — это агрегат, снимаемый непрерывно, так что ты видишь тренды и всплески. Метрики дёшевы собирать и хранить, потому что это просто числа, а значит, их можно держать по всему, всё время, и смотреть, как форма твоей системы движется.
Счётчики растут; датчики идут вверх и вниз
Одометр только лезет вверх, считая общий пробег; спидометр поднимается и падает с тем, как быстро ты едешь прямо сейчас.
Две базовые формы покрывают большинство метрик. Счётчик (counter) только растёт — всего обслужено запросов, всего ошибок — и ты смотришь его скорость изменения. Датчик (gauge) ходит вверх-вниз, показывая текущее значение — память в использовании, активные соединения, длину очереди. Знать, на что из них смотришь, говорит, как это читать: у счётчика наклон — это история; у датчика — текущая высота.
Дашборды делают тренды видимыми
Стена датчиков в диспетчерской: с одного взгляда оператор видит, что всё зелёное и ровное, или что одна стрелка лезет к красному.
Метрики обычно смотрят на дашборде (dashboard) — графиках ключевых чисел во времени, бок о бок. Хороший дашборд даёт увидеть здоровье системы за секунды и заметить миг, когда линия согнулась не туда. Здесь метрики отрабатывают своё содержание: не в каком-то одном значении, а в видимом тренде, что говорит «что-то начало идти не так в два дня» раньше, чем пользователи дожалуются.
Четыре золотых сигнала
Быстрая проверка жизненных показателей у врача — пульс, температура, давление, дыхание — крошечный набор, что ловит большинство неполадок, не измеряя всё.
Не нужна тысяча метрик, чтобы начать. Четыре золотых сигнала (four golden signals) покрывают бо́льшую часть здоровья системы: latency (задержка — сколько занимают запросы), traffic (трафик — сколько спроса), errors (ошибки — сколько запросов падает) и saturation (насыщение — насколько полны ресурсы). Следи за этими четырьмя — и поймаешь подавляющее большинство проблем рано. Это жизненные показатели сервиса — первые стрелки, что ставишь на панель.
Метрики — числа во времени: счётчики, что лезут вверх, датчики, что качаются, — показанные на дашбордах. Начни с четырёх золотых сигналов: задержка, трафик, ошибки, насыщение.
В системе из многих сервисов один запрос пользователя касается многих из них. Трейс следует за этим единственным запросом до конца — отвечая на вопрос, что логи и метрики не могут: где, через всё, случилась задержка или сбой?
Трейс следует за одним запросом через сервисы
История трекинга посылки: забрана здесь, отсортирована там, перевезена, доставлена — весь путь одной посылки через каждые руки, что её касались.
В современных системах один запрос скачет через много сервисов — шлюз зовёт сервис заказов, что зовёт платежи, что зовут базу. Трейс (trace) записывает весь этот путь для одного запроса, сшитый так, чтобы видеть каждый скачок, что он сделал. Он отвечает на вопрос, что ни логи, ни метрики не могут: не «что случилось» или «сколько», а «каков был путь этого конкретного запроса через всю систему?»
Спаны показывают, куда ушло время
Маршрут поездки, разбитый на отрезки, у каждого своя длительность, — и мгновенно видно, что трёхчасовая пересадка, а не перелёты, съела день.
Трейс состоит из спанов (spans) — по одному на шаг, каждый замеряет, сколько занял тот кусок. Разложенные водопадом, спаны показывают ровно, где медленный запрос провёл своё время: спан базы занял 900 мс, пока всё остальное заняло 50. Без этого «запрос был медленным» — загадка через много сервисов; с этим ты указываешь прямо на виновника. Спаны превращают смутную медлительность в точное место.
Трейсинг — это как отлаживают распределённые системы
Проследить одну упавшую палочку назад через эстафету, чтобы найти ровно, какая передача сбоила, — невозможно увидеть из одного финального результата.
Когда запрос падает или ползёт, а работа размазана по сервисам, трейс часто единственный способ найти где. Метрики говорят, что система медленна; логи говорят, что сказал каждый сервис; трейс связывает путь одного запроса вместе и указывает на точный сервис и шаг, что сломался. Для всего распределённого трейсинг — инструмент, что превращает «где-то там пошло не так» в «вот здесь».
Трейс следует за одним запросом через каждый сервис, разбитый на замеренные спаны, — чтобы увидеть ровно, где в распределённой системе реально случилась задержка или сбой.
Логи, метрики и трейсы зовут тремя столпами наблюдаемости, потому что каждый отвечает на свой вопрос. Мощь — в использовании их вместе, а не в выборе одного.
Каждый столп отвечает на свой вопрос
Расследование проблемы тремя инструментами: график, что показывает, когда всё изменилось, карта, что показывает где, и детальный отчёт, что показывает ровно что, — каждый бесполезен один, решающи вместе.
Три столпа делят работу. Метрики отвечают «есть ли что-то не так и каков тренд?» — дешёвый, всегда-включённый обзор. Трейсы отвечают «где, через все сервисы, проблема?» — сужая до шага. Логи отвечают «что именно там случилось?» — полная деталь на месте. Ни один сам по себе не достаточен; каждый подхватывает там, где другие останавливаются.
Естественный поток: заметить, локализовать, объяснить
Врач видит жар на графике, осматривает, чтобы найти, какой орган, потом гонит конкретный тест, что называет болезнь, — широкий сигнал, потом узкий, потом точный.
На практике ты движешься через них по порядку. Метрика или алерт говорит, что что-то не так (доля ошибок подскочила). Трейс показывает где (шаг сервиса платежей падает). Лог в той точке говорит ровно что (платёжный провайдер вернул таймаут). От широкого к узкому к точному: метрика замечает, трейс локализует, лог объясняет. Знать этот поток — бо́льшая часть знания, как отлаживать прод.
Корреляция связывает их вместе
Номер дела, написанный на каждом документе, фото и отчёте, — чтобы следователь мог стянуть всё об одном инциденте вместе, а не искать в каждой стопке отдельно.
Столпы куда сильнее, когда связаны. Прикрепление общего request ID (или trace ID) к метрикам, трейсу и каждой строке лога для запроса даёт прыгнуть от «этот запрос упал» прямо к его трейсу и его точным логам. Без корреляции у тебя три отдельных стога; с ней один рывок стягивает всю историю инцидента вместе. Связи между столпами — вот что делает их системой, а не тремя инструментами.
Метрики замечают, трейсы локализуют, логи объясняют — от широкого к узкому к точному. Свяжи их общими request ID, и три инструмента станут одной историей о том, что пошло не так.
Наблюдаемость даёт расследовать; алертинг говорит, когда начать. Сложная часть не в обнаружении проблем — в решении, какие из них стоят того, чтобы будить человека.
Алертить на то, что чувствуют пользователи
Дымовой датчик должен сработать на настоящий пожар, а не каждый раз, как кто-то делает тосты, — иначе люди вырывают батарейку и пропускают настоящий.
Алерт (alert) — это автоматическое уведомление, когда что-то пересекает черту. Искусство — алертить на симптомы, что пользователи реально чувствуют: падающие оплаты, медленный сайт, — а не на каждое внутреннее подёргивание. Сервер на 80% памяти — не проблема, если пользователям хорошо; всплеск упавших заказов — да, даже если каждый сервер выглядит здоровым. Алерть на обращённый к пользователю исход, и будешь будить людей ради того, что правда важно.
SLI, SLO, SLA: определить «достаточно хорошо»
Служба доставки, обещающая «99% посылок приходят за два дня», — ясная, измеримая планка того, что считается приемлемым сервисом, согласованная заранее.
Три аббревиатуры формализуют «насколько хорошо достаточно хорошо». SLI — это измерение (доля запросов, обслуженных под 300 мс). SLO — цель, что ты ставишь для него (должно быть 99,9%). SLA — договорное обещание клиенту, с последствиями при провале. Поставить явный SLO превращает надёжность из смутного ощущения в число, к которому можно держать систему, — и ясную черту, когда действовать.
Усталость от алертов — тихий убийца
Машина, что постоянно пищит на ерунду, приучает водителя игнорировать все писки, — так что одно предупреждение, что было важно, отсеивается со всеми остальными.
Слишком много алертов — это свой сбой: когда людей будят ради того, что не важно, они начинают игнорировать алерты целиком, и настоящий теряется в шуме — усталость от алертов (alert fatigue). Каждый алерт должен быть действенным и стоить человеческого внимания прямо сейчас; если нет — ему место на дашборде, а не в пейджере. Меньше, острее алертов бьёт поток, потому что алерт, которому никто не доверяет, хуже, чем никакого.
Алерть на симптомы, что чувствуют пользователи, определи «достаточно хорошо» через SLO и защищайся от усталости от алертов — потому что алерт, которому никто не верит, хуже, чем никакого.
Наблюдаемость встраивают, а не прикручивают. Навык — инструментировать по ходу, держать сигнал чистым и тратить внимание на те немногие вещи, что раскрывают больше всего.
Инструментируй, пока строишь, а не после пожара
Провести дымовые датчики, пока строишь дом, — а не стоять в дыму, жалея, что не провёл.
Худшее время добавить наблюдаемость — во время сбоя, когда обнаруживаешь, что система не говорит ничего. Так что встраивай её по ходу: излучи метрику для новой фичи, логируй её ключевые решения, убедись, что запрос можно протрейсить через неё. Чуть инструментирования, добавленного, пока код свеж, экономит часы слепого гадания позже. Относись к «как я увижу это в проде?» как к части постройки, а не как к мысли вдогонку.
Начни с золотых сигналов и расти
Новый владелец магазина сперва следит за теми немногими числами, что важны, — продажи, проходимость, жалобы, — и добавляет более тонкое отслеживание, лишь когда возникают конкретные вопросы.
Не нужно полное покрытие в первый день. Начни с четырёх золотых сигналов и горстки логов в ключевых точках решений, потом добавляй деталь там, где реальные инциденты покажут тебе слепое пятно. Каждый сбой — урок о том, что ты жалеешь, что не записывал, — так дай своей наблюдаемости расти по контурам того, где система реально тебя удивляет, а не инструментируй всё заранее.
- Что он может мне рассказать в проде — или это чёрный ящик, когда ломается? - Золотые сигналы — отслеживаю ли я задержку, трафик, ошибки и насыщение? - Логи — структурированы, с уровнями и сфокусированы на важных решениях и сбоях? - Трейсинг — могу ли я проследить один запрос через сервисы, что он касается? - Корреляция — делят ли метрики, логи и трейсы request ID? - Алерты и SLO — будит ли меня то, что чувствуют пользователи, против определённой цели?
- observability / monitoring — отвечать на непредвиденные вопросы против слежения за известными. - log / structured / level — детальный дневник, сделанный запрашиваемым и фильтруемым. - metric / counter / gauge / dashboard — числа во времени, две формы и как ты их смотришь. - trace / span — путь одного запроса через сервисы, разбитый на замеренные шаги. - четыре золотых сигнала — задержка, трафик, ошибки, насыщение. - alert / SLI / SLO / SLA — уведомление, мера, цель, обещание. - alert fatigue / корреляция (request ID) — ловушка шума и нить, что вяжет всё вместе.
- Когда что-то ломается, система говорит, куда смотреть, а не оставляет гадать. - Ты движешься метрика → трейс → лог, от «заметить» к «локализовать» к «объяснить». - Общий request ID вяжет сигналы одного инцидента вместе. - Твои алерты срабатывают на обращённые к пользователю симптомы, и люди им всё ещё доверяют. - У тебя есть явные SLO, и ты инструментировал пока строил, а не во время сбоя.
Хорошая наблюдаемость встроена: золотые сигналы с самого начала, структурированные логи, трейсируемые запросы, скоррелированные по ID, и пара алертов, которым доверяешь, против реального SLO.