Назад

Эксплуатация · База

Добавить структурированные логи

Логировать важные события с request id, пользователем, операцией и контекстом ошибки.

Эксплуатация: визуальный контекст этапа
Аудиопересказ пунктаПолная версия материала для прослушивания
Прослушано 0%
Скачать

Быстро понять за 2 минуты

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

Главная пользаСтруктурированные логи позволяют быстро расследовать инциденты и связывать действия между сервисами.
Первое действиеДобавьте correlation id.
Готово, когдаЛоги можно фильтровать.

Контекст

Пункт относится к этапу «Эксплуатация». Его задача — сделать сервис понятным и безопасным в эксплуатации. Он нужен до передачи результата разработчикам, QA и команде эксплуатации: иначе команда рискует логировать только текст без полей.

ЦельСтруктурированные логи позволяют быстро расследовать инциденты и связывать действия между сервисами.
ДействиеДобавьте correlation id.
ПроверкаЛоги можно фильтровать.

Что это дает

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

Как выполнить

  1. Добавьте correlation id.
  2. Логируйте бизнес-события и ошибки.
  3. Исключите персональные данные и секреты.

Критерии приемки

  • Логи можно фильтровать.
  • Есть request/correlation id.
  • Чувствительные данные не попадают в лог.

Типичные ошибки

  • Логировать только текст без полей.
  • Писать слишком много шума.
  • Логировать токены, карты или пароли.

Инструменты

ELKLokiMonologADRAPI contractлогированиемониторингрепозиторий

Рабочий артефакт

Runbook

Эксплуатация: документ с выводом, доказательствами, ответственным и следующим действием

Пример для разработки сервиса заказов: специалист начинает с действия «Добавьте correlation id». Результат прикладывают к рабочей задаче и передают следующему участнику. Пункт закрывают не по факту обсуждения, а когда выполнено условие: «Логи можно фильтровать».

  • Logs
  • Metrics
  • Alerts
  • Rollback

Контроль качества

Артефакт

Операционная готовность сервиса

Метрика проверки

Логи можно фильтровать.

Когда пересматривать

После изменения контрактов, релизов, инцидентов, роста нагрузки и пересмотра архитектурных решений.

Что передать дальше

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

Перед отметкой выполнено: Логи можно фильтровать.

Как применять

Начинайте с границ ответственности и пользовательского сценария, который обслуживает система. Затем проверьте контракт, данные, отказоустойчивость, безопасность и наблюдаемость. Хороший backend-пункт фиксирует, что именно меняется, как это проверить и какие метрики покажут стабильность решения.

Режим обучения

Тест по теме

Проверка понимания

Ответьте на вопросы по материалу и получите итоговый отчет: что понято хорошо, а что стоит перечитать.

0/4ответов выбрано
1. Какой главный результат должен дать пункт «Добавить структурированные логи»?
2. С какого действия логично начать выполнение?
3. Как понять, что тема действительно закрыта?
4. Какой ошибки стоит избегать в этой теме?
Материал подготовлен командойAriol.by