Как не надо логировать работу сервиса на реальном примере.

Логи, как много в этом звуке для сердца программиста слилось. Я уже однажды писал на эту тему. Почему я к ней вернулся? На прошлой неделе я снова занимался их разгребанием. Причиной послужило обращение администраторов промышленного сервера баз данных с жалобой о росте размера базы на 200 гигабайт в месяц. Если, кажется что это не много, то добавлю парочку фактов. Во – первых у нас всего около пары сотен тысяч клиентов сервиса. Это не много, учитывая, что основная масса просто регистрируется и раз в месяц заходит совершить необходимые манипуляции. Во-вторых - это только логи. Представьте что вы, как владелец сервиса, оплачиваете пол терабайта дискового пространства (ну мы же иногда чистим логи) и процессорное время на логирование, анализом которого никто не занимается. Это не законодательное требования хранения переписки, это внутренняя кухня для упрощения анализа работы сервиса в случае сбоя или для оценки производительности. Но если эту работу никто не проводит, то зачем тратить на нее время и средства? Ну и что же мы так много логируем?

1) Обработанные в рамках бизнес-логики исключения. Я не эксперт в области архитектуры приложений, но я считаю что приложение нужно реализовывать так что бы ошибки не возникали. Если бизнес-логика уже и так обрабатывает возникающие ошибки, то на кой черт их логировать? Для себя я нашел ответ – чтобы проанализировать, какие возникают ошибки и доработать логику для их исключения, но этого оказалось недостаточно. Подавляющее количество обработанных исключений – ошибка авторизации пользователя (прокисшие токены, например). Подскажите что с этим делать? На выходе получаем по паре миллионов записей в месяц информации, с которой вы в принципе ничего не можете сделать.

2) Моя любимая часть – замер продолжительности запроса к внутренним сервисам. Вот кажется – здравая вещь. По идее мы могли бы передавать информацию о слишком долгих запросах разработчикам этих сервисов. Но погодите ка – они сами и так на своем уровне собирают эту информацию. Причем раз в день присылают отчет об этом. Вопрос «Зачем?» снова повисает в воздухе.

3) Процесс авторизации и аутентификации (нет, пароль не логируем).Самое страшное что это вообще было моё детище. Данный процесс реализован по требованию тех.поддержки. Чтобы определять как пользователь пытался войти в систему и чем дело кончилось. Этот сценарий даже использовался по назначению. Проблема в том, что это было реализовано как пучок записей с громадным набором данных, большая часть которых, на практике, оказалось бесполезной.

Мне поднадоело ворчать в пустую, и я решил для разнообразия предложить хоть какое-то решение подобных проблем. Проблемные сценарии я описал и в принципе все они решаются банальным APM мониторингом. Поверхностный поиск вывел в хабр на статью содержащую 51 продукт для мониторинга. В своем сервисе мы выбрали new relic. Если покопаться – можно найти даже бесплатные варианты.

Итог? Да как всегда – если человек не понимает что и зачем он делает, то получается всегда ерунда. И никто не застрахован от ошибки. Остается лишь эти ошибки признавать, исправлять и стараться не допустить в будущем.