Наблюдаемость
Три pillarа: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту — выбор сигнала, cardinality, объём логов, sampling, join-ключи и сдвиг стоимости в observability 2.0.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый отражает решение, которое ты принимаешь в инциденте или при инструментировании — не определение для заучивания, а компромисс по стоимости, который надо взвесить.
Цель
Убедись, что выбираешь правильный сигнал под вопрос, рассуждаешь о его оси стоимости и связываешь три pillarа через join-ключи — тот синтез, к которому вели отдельные уроки.
Викторина
Completed
Продакт хочет per-customer error rate в разбивке по конкретному customer_id для 200k активных клиентов, с запросом за последние 30 дней. В стеке 1.0 какой сигнал несёт эти данные и почему не остальные?
Heads-up customer_id неограничен; 200k значений умножают число серий на 200k и кладут TSDB по OOM. Идентичность клиента живёт в logs или traces, но не в label метрики.
Heads-up Summary считает перцентили per-replica и всё равно требует label на клиента, чтобы их разделить — проблема cardinality не меняется, и summary не агрегируется между репликами.
Heads-up Она полностью возможна в logs и traces, которые сохраняют каждое поле. Только pillar метрик не может позволить себе неограниченные per-customer label.
Викторина
Completed
Два сервиса делят тяжёлый эндпоинт. Сервис A держит стабильный набор label (route × method × status_class = 400 серий), но логирует каждый запрос. Сервис B имеет крошечный объём логов, но добавил user_id в один counter. Кто первым угрожает своему бэкенду и по какой оси?
Heads-up Объём логов задаёт линейный счёт за ingest и задержку запросов, а не резкий обрыв по памяти. Это проблема стоимости, а не OOM-за-минуты, как cardinality-бомба.
Heads-up Это разные оси стоимости: cardinality — память на число серий в TSDB (обрыв); объём логов — байты ingestion и время скана (линейно). Их смешение — главная путаница, которую разбирает юнит.
Heads-up Авто-шардинг помогает ingest логов, но не спасает head-блок Prometheus от миллионов серий; неограниченный label всё равно кладёт TSDB по OOM.
Викторина
Completed
Команда применяет tail-based sampling на коллекторе, оставляя 100% ошибок и 2% успехов. Их счёт за traces почти не падает против 100%-хранения, хотя сохранённый объём резко снизился. Почему?
Heads-up Он работает как задумано. Объём хранилища падает, но коллектор всё равно обязан принять и забуферизовать каждый span, чтобы принять решение по контексту — эта стоимость в tail sampling неустранима.
Heads-up 100% head sampling не экономит ничего; head экономит за счёт отбрасывания в начале трейса. Смысл tail sampling — сохранить редкие ошибки и медленные хвосты, которые head пропустил бы случайно.
Heads-up Ошибки обычно малая доля трафика. Доминирующая оставшаяся стоимость здесь — буферизация всех span в коллекторе, а не сохранённые трейсы ошибок.
Викторина
Completed
Метрики используют route='/checkout', логи — http_path='/checkout', трейсы — http.route='/checkout'. Данные корректны и текут. Что на самом деле ломается и какой фикс?
Heads-up Автоматические пивоты ключуются по ИМЕНИ поля, а не только по значению. Расходящиеся имена означают, что каждый дашборд и runbook несёт хрупкий ручной перевод. Согласованность имён — весь тезис join-ключей.
Heads-up Коллектор форвардит независимо от именования атрибутов. Сбой — операционное трение при triage, а не сломанный пайплайн.
Heads-up Cardinality — про число ЗНАЧЕНИЙ label внутри одной метрики, а не про согласие трёх бэкендов об имени поля. Расхождение имён — проблема join, а не cardinality.
Викторина
Completed
Команда из 40 сервисов тратит ~2 инженеро-недели в квартал на надзор за cardinality-бюджетами и ~3 часа на инцидент на кросс-pillar пивоты. Ещё они держат 5 лет low-cardinality SLO-метрик для комплаенса. Какова senior-рекомендация?
Heads-up 2.0 выигрывает для инцидент-респонса и high-cardinality запросов, но сырые wide events за 5 лет стоят дороже предагрегированных rollup-метрик. «Всегда лучше» — заблуждение, которое урок 6 явно опровергает.
Heads-up Самая дешёвая инфра игнорирует скрытую инженерную стоимость: 2 недели/квартал на гигиену label плюс 3 часа/инцидент на пивоты — это и есть реальный счёт, толкающий к 2.0.
Heads-up Достичь паритета фич с SaaS wide-event бэкендом — 1–2 инженеро-года; это оправдано лишь для очень крупных оргов с выделенной observability-командой, а не для шопа из 40 сервисов.
Викторина
Completed
Во время инцидента on-call обнаруживает, что нужный трейс никогда не семплировался — SDK использует ParentBased(TraceIdRatioBased), но trace_id выводится из хеша пути запроса. Корневая причина и устойчивый фикс?
Heads-up ParentBased явно уважает входящий флаг sampled — это его задача. Дефект — неслучайный seed trace_id, отмеченный в post-mortem Elastic 2024.
Heads-up Head sampling — дешёвая база и нормален, когда trace_id по-настоящему случаен. Фикс — случайный seed плюс tail-политики для интересных случаев, а не отмена head sampling.
Heads-up 100% семплирование убирает экономию, ради которой семплируют, и всё равно не чинит баг корреляции. Случайный seed плюс tail-политики держат стоимость ограниченной и никогда не теряют трейсы ошибок.
Итог
Сквозная линия юнита — одно решение: вопрос выбирает сигнал по его самой дешёвой оси стоимости. Metrics дёшевы в запросе, но гибнут на cardinality; logs сохраняют всё, но платят байтами ingestion; traces сохраняют причинность, но обязаны семплировать (а tail sampling смещает стоимость со storage на коллектор). Join-ключи — service.name, trace_id, http.route через OpenTelemetry Semantic Conventions — это то, что делает три pillarа единой навигационной поверхностью. Модель wide-event 2.0 схлопывает все три, когда инженерная стоимость cardinality-дисциплины и кросс-pillar пивотов превышает счёт за единый бэкенд — это экономический, а не идеологический выбор.