Наблюдаемость
Структурное логирование: тест с выбором ответа
Суть Тест с выбором на синтез по всему юниту — контракт схемы, маршрутизация по log level, экономика sampling, защита от утечки PII и log injection, корреляция по trace, и разделение audit-логов.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов поперёк всего юнита. Каждый — это решение, которое ты принимаешь, пока сервис горит в 03:00: не определение для заучивания, а компромисс между счётом, алертом, аудитом и расследованием.
Цель
Убедись, что связываешь контракт схемы, лестницу log level, экономику sampling, защиту от PII и injection, корреляцию по trace и разделение audit-логов — тот синтез, к которому вели отдельные уроки.
Викторина
Completed
Два сервиса одной команды пишут JSON-логи, но один называет поле http.response.status_code, а другой — status. Оба валидный JSON. Почему это всё равно ломает on-call?
Heads-up Оба структурные: стабильные сериализованные записи с адресуемыми полями. Дефект — это schema drift, а не отсутствие структуры. Оба запрашиваемые, просто не по одному и тому же имени.
Heads-up Сшивать drift регуляркой — значит обнулять смысл структурных логов, и это гниёт с появлением новых вариантов. Фикс — общая схема (OTel Semantic Conventions), которую проверяют до выкатки кода, лучше через общий wrapper-логгер.
Heads-up Backend индексирует те имена полей, которые получает; он не придумывает каноническое соответствие. status и http.response.status_code — это два разных индексируемых поля.
Викторина
Completed
Хелпер ретраев пишет ERROR на каждой из 5 попыток, включая 3 успешные. Канал on-call стал шумом, а реальный ERROR на прошлой неделе пропустили. Какой правильный фикс и почему?
Heads-up Исходы ретраев операционно значимы для capacity и надёжности и должны быть видны в проде; DEBUG в проде по умолчанию выключен, так что это прячет их целиком, а не маршрутизирует правильно.
Heads-up Пороги замазывают баг классификации и проглотят и настоящие всплески ошибок. Log level — это контракт о том, какое действие подразумевается; чинить надо уровень, а не обвязку алерта.
Heads-up Sampling ERROR молча выбрасывает forensics сбоев; надо держать 100% WARN и ERROR. Проблема в неправильной классификации, а не в объёме.
Викторина
Completed
Один сервис на 1000 req/s с JSON-логами по 1 КБ стоит ~$260/мес на ingest. Какой первый рычаг, чтобы срезать ~90% без потери возможности расследовать сбои?
Heads-up Равномерный sampling теряет 90% ERROR-строк и делает расследование инцидента невозможным. Sampling всегда обязан сохранять 100% WARN и ERROR.
Heads-up Retention tiering управляет тем, как долго ты хранишь данные, а не сколько ингестишь в день. Стоимость ingest — это объём на скорость; sampling режет скорость, retention лишь меняет горизонт хранения.
Heads-up Per-service sampling фрагментирует политику по всему флоту без центральной видимости и делает tail sampling непрактичным. Sampling живёт на уровне коллектора ради централизованного контроля.
Викторина
Completed
Хендлер интерполирует присланный пользователем текст комментария прямо в строку лог-сообщения. Пользователь шлёт комментарий с переводом строки, за которым идёт поддельный ERROR-объект JSON. Какой это класс сбоя и какой структурный фикс?
Heads-up Дефект структурный — перевод строки как разделитель записей, — а не вопрос кодировки символов. Нормализация UTF-8 никак не останавливает поддельную лог-строку.
Heads-up Поддельные лог-строки приводили к реальным манипуляциям с audit-trail и обходу SIEM-правил. Содержимое лог-сообщения — это поверхность ввода; Log4Shell был крайней версией того же урока.
Heads-up Блок-лист символов хрупок и пропускает структурную JSON-инъекцию. Надёжный фикс — никогда не интерполировать ввод в строку сообщения, а передавать его типизированным атрибутом и дать сериализатору его экранировать.
Викторина
Completed
Node-сервис сообщает, что ~5% лог-строк несут trace_id = '00000000000000000000000000000000'. Как это читать?
Heads-up Глобальная ошибка конфигурации обнулила бы почти 100% строк, а не 5%. Малая конкретная доля указывает на отдельные async-пути, теряющие контекст исполнения.
Heads-up Sampling выбрасывает целые записи, а не отдельные поля внутри записи. trace_id отсутствует потому, что его так и не заполнили, а не убрали ниже по потоку.
Heads-up Backend не переписывает trace ID. Все нули — это эмитируемое значение, когда логгер не находит активного контекста: пробел в async-пропагации на стороне кода, а не баг ingest.
Викторина
Completed
Команда хранит операционные логи и audit-логи (логины, выдача ролей, доступ к регулируемым данным) в одном индексе с retention 30 дней. Почему это сбой комплаенса, а не вопрос аккуратности?
Heads-up JSON для audit-логов нормален — они разделяют схему и trace_id. Нарушение — это свойства retention, immutability и доступа общего индекса, а не кодировка.
Heads-up Производительность вторична. Сбой комплаенса в том, что audit-события удаляются раньше обязательного retention и читаемы слишком широкой аудиторией.
Heads-up Audit-логи используют тот же формат trace_id; корреляция работает. Отличаются retention, immutability и слой доступа backend — маршрутизируй через атрибут category=audit в отдельный pipeline.
Итог
Сквозная линия юнита — это один конвейер решений: стабильная схема (имена полей OTel) делает логи запрашиваемыми и соединяемыми; лестница log level маршрутизирует объём в хранилище, а severity — к людям; sampling держит счёт пропорциональным инцидентам, всегда сохраняя WARN/ERROR; дисциплина PII и защита от CWE-117 injection — это заботы безопасности первого порядка, решаемые у источника и на коллекторе; trace_id делает лог-строку узлом графа observability, а не островом; и audit-логи разделяют JSON-схему, но требуют своего pipeline, retention, immutability и доступа. Каждый ответ сводится к тому, чтобы относиться к лог-строке как к API-контракту, на который полагаются и твой on-call, и твой аудитор.