Самый неприятный инцидент - не тот, где логов нет.

Гораздо хуже, когда логов много. В них есть ошибки, ретраи, таймауты, названия сервисов. Только они, к сожалению, не отвечают на вопрос «что произошло с конкретной операцией?».

Обычно проблема не в уровне логирования. Она в том, что события логов нельзя собрать в одну цепочку.

Если у входящего запроса нет correlation id (метка, которая связывает разрозненные записи в логах в единую историю), а у сообщения в очереди нет понятной связи с ним, то HTTP-ошибка, запись в базу и обработчик через две минуты живут в логах отдельными жизнями. Формально наблюдаемость есть. Практически - открыт поиск по времени.

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

И важны границы операции. Лог на старте, лог на успешном завершении и лог на ошибке часто полезнее десяти сообщений внутри каждого метода. Особенно если из них видно, куда именно ушло управление и сколько занял каждый внешний шаг.

Логи не обязаны быть подробным дневником приложения. Их задача - достаточно быстро ответить на вопрос, что случилось с конкретной работой.

Если для этого нужно читать полчаса выдачу из нескольких сервисов, то логов, скорее всего, уже достаточно. Не хватает структуры.