Какие системы и практики логирования ты используешь?

Слушай, я тут настраиваю логирование, а то без него как слепой кот — нихуя не видно, что в системе творится. Решил замутить structured logging, это когда логи не просто текст, а нормальные структурированные данные, чтобы их машина могла легко жрать и анализировать. Ёпта, раньше гребаные логи парсить — это был пиздец, а теперь красота.

Чем буду пользоваться, чтоб не вышло говно:

• Сборщик и пересылка: Беру Fluentd или Vector. Это такие ребята, которые будут собирать логи со всех сервисов и аккуратно пихать их дальше. Без них — терпения ноль ебать, самому везде бегать.
• Хранилище: Тут два пути. Либо Elasticsearch в классической связке ELK — мощно, но жрёт ресурсов овердохуища. Либо Grafana Loki — полегче, специально под логи заточена, мне сейчас больше нравится.
• Чтоб смотреть: Для Elasticsearch — Kibana, для Loki — Grafana. Там искать, строить графики, дашборды всякие. Без визуализации это просто куча текста, в рот меня чих-пых.
• Трассировка: Отдельно для распределенных трейсов — Jaeger или Grafana Tempo. Чтобы если запрос по пяти сервисам прошел, можно было всю цепочку, как на ладони, развернуть.

Как именно делаю, чтоб не было распиздяйства:

1. Уровни. Использую стандартные: DEBUG, INFO, WARN, ERROR. В продакшене обычно стоит INFO, а DEBUG включаю только для конкретного сервиса, который глючит. Иначе отладочных логов будет — хуй с горы, засрут всё.
2. Структура — главное! Каждая строчка лога — это JSON. Не просто «ой, ошибка», а нормальный объект.

   {
     "timestamp": "2023-10-05T14:30:00Z",
     "level": "ERROR",
     "service": "payment-service",
     "trace_id": "abc123",
     "message": "Failed to process payment",
     "error": "Connection timeout to PSP",
     "user_id": "user_456",
     "order_id": "order_789"
   }

   Видишь? Есть trace_id, есть user_id. Теперь можно не гадать, а искать по полям. Красота, ёпта.

3. Связывание событий. Самый важный пункт, блядь. Весь код, который работает в рамках одного запроса, должен добавлять в логи один и тот же trace_id или request_id. Потом в Kibana или Loki вбиваешь этот ID — и тебе вываливается ВСЁ, что происходило с этим запросом в каждом микросервисе. Волнение ебать, как удобно! Раньше бы час рылся, а теперь за пять секунд root cause находишь.
4. Уборка за собой. Обязательно настраиваю rotation логов на самих серверах (старый добрый logrotate), и задаю политики хранения в Elasticsearch или Loki. Типа «храним 30 дней, потом нахуй удаляем». А то диск забьётся — будет тебе хиросима, а не логи.

В общем, такая схема превращает логи из кучи мусора в реальный инструмент. Проблемы искать в разы быстрее, можно даже дашборды для мониторинга бизнес-метрик нарисовать. Главное — не лениться и сразу писать структурированно, а не как попало.