Наблюдаемость
Структурное логирование: тест с краткими ответами
Воспроизведение по памяти бьёт перечитывание. На каждый промпт скажи или запиши полный ответ из памяти до того, как откроешь эталон — именно усилие припоминания закрепляет материал к 03:00, когда он понадобится.
Восстанови хребет юнита — что делает лог структурным, контракт level-к-маршрутизации, рычаги sampling и стоимости, защиту PII у источника и на коллекторе, корреляцию по trace и подсистему audit — не подглядывая в уроки.
- 01Что делает лог-строку структурной, а не свободным текстом, и где проявляется отдача?
- 02Назови core-поля production-схемы лога и объясни, почему важны имена полей из OTel Semantic Conventions.
- 03Что значит каждая ступень лестницы log level, как она задаёт маршрутизацию алертов и почему неправильная классификация опасна?
- 04Опиши три стратегии sampling и почему sampling живёт на коллекторе, а не в приложении.
- 05Объясни два слоя защиты PII и структурную профилактику log injection (CWE-117).
- 06Как trace_id попадает в лог-строку автоматически, какой режим отказа и как его детектить?
Если ты смог восстановить каждый ответ по памяти, ты держишь хребет юнита: структурный значит адресуемые типизированные поля, дающие отдачу на запросе; схема OTel и конвенциональные имена делают логи соединяемыми между сервисами; лестница log level — это контракт маршрутизации, где неправильная классификация даёт alert fatigue или невидимый сбой; sampling держит стоимость пропорциональной инцидентам, сохраняя все WARN/ERROR на коллекторе; PII защищается у источника и на коллекторе, а injection предотвращается структурно передачей ввода типизированными полями; trace_id автоинжектится из контекста исполнения и ломается на async-границах; а audit-логам нужен свой pipeline, retention, immutability и доступ. Лог-строка — это API-контракт и для твоего on-call, и для твоего аудитора.