Alex.Popov
New member
Пару лет назад я искренне считал, что логи — это побочный продукт работы сервиса. Пишешь что-нибудь вроде «ошибка при обработке», добавляешь print там, где страшно, и живёшь спокойно. А потом наступает ночь, падает прод, ты открываешь Grafana, а там двадцать семь панелей, три алерта в телефоне и абсолютная пустота в голове: непонятно, что именно сломалось, у кого, когда и почему. Я просидел над этим до пяти утра, пролистал гигабайты текста и не нашёл ни одного внятного ответа. Именно тогда я понял, что проблема не в Grafana и не в системе алертов, а в том, что мы сами туда пишем.
Самое неприятное осознание было таким: логи — это не архив событий, это инструмент ответа на конкретные вопросы. Я задал себе простой тест — если бы я дежурил ночью и мне прилетел алерт, какой вопрос я хочу закрыть за минуту? Например: какой пользователь пострадал, какой сервис виноват, что именно вернуло внешнее API, повторяется ли это и сколько людей затронуто. Всё, что не помогает ответить на эти вопросы, превращается в шум. И вот этот шум как раз и топит в Grafana — не объём данных, а их бесполезность.
После этого я переписал подход к записи событий. Во-первых, структурированные логи вместо свободного текста: JSON или хотя бы стабильные пары ключ-значение, чтобы по ним можно было фильтровать и строить графики без боли. Во-вторых, единый идентификатор запроса, который протягивается через все сервисы, — именно он превращает разрозненные строки в одну историю. В-третьих, осмысленный уровень: error оставляю только для того, что реально требует человека, warn — для деградации, info — для ключевых переходов в бизнес-процессе. И, в-четвёртых, я перестал логировать данные, которые нельзя логировать: пароли, токены, номера карт, персональные данные. Это и безопасность, и, как ни странно, спасение от мусора.
Отдельная боль — имена событий. Раньше у нас было привет, Hello world, стартуем, начинаем обработку и запуск, и всё это означало одно и то же. Теперь есть словарь событий, и любая новая строка должна в него вписываться. Звучит скучно, но именно это сделало поиск в Grafana мгновенным: я знаю, что искать, и знаю, что найду. Плюс я держу в каждой записи контекст: версию релиза, окружение, идентификатор тенанта, длительность операции. Контекст — это то, что отличает полезный лог от красивой, но бесполезной строки.
С алертами вышло ещё интереснее. Раньше у нас был алерт на каждое сообщение с уровнем error, и телефон вибрировал так, что я перестал на него смотреть. Классический alarm fatigue: когда алертов слишком много, человек перестаёт реагировать даже на настоящий пожар. Мы перешли на алерты по симптомам, а не по строкам логов: растёт доля ошибок, упала пропускная способность, превышен бюджет задержки, недоступен критичный внешний сервис. Всё остальное живёт в дашбордах и разбирается спокойно днём. Количество алертов сократилось в разы, а польза от них выросла на порядок.
Про дашборды скажу отдельно, потому что это моя личная слабость. Красивая панель с двадцатью графиками успокаивает, но не помогает. Я оставил в Grafana три уровня: общий обзор на один экран для дежурного, детальные панели по сервисам и отдельные разборы под конкретные инциденты, которые создаю руками во время проблемы и потом выбрасываю. Дашборд должен отвечать на вопрос за десять секунд, иначе это не дашборд, а декорация. И обязательно правило: если алерт сработал, в описании должна быть ссылка на панель и короткая инструкция, что делать. Дежурный не должен искать истину в темноте.
Если коротко, вот что я советую всем, кто сейчас тонет в логах и уведомлениях. Пишите логи для человека, который вас разбудит ночью, а не для галочки. Делайте их структурированными и единообразными. Всегда добавляйте идентификатор запроса и контекст. Держите уровни честными. Не логируйте то, что не имеет права попасть в хранилище. Стройте алерты по симптомам, а не по каждой строке. И пересматривайте свою схему логирования хотя бы раз в квартал — сервисы меняются быстрее, чем нам кажется.
А теперь вопрос к вам, коллеги с форума: какие приёмы в логировании и алертинге реально спасли вашу ночь — что вы однажды добавили, и после этого дежурства стали спокойнее? Делитесь опытом, у каждого в этом деле найдётся своя находка, о которой другим стоит узнать.
Самое неприятное осознание было таким: логи — это не архив событий, это инструмент ответа на конкретные вопросы. Я задал себе простой тест — если бы я дежурил ночью и мне прилетел алерт, какой вопрос я хочу закрыть за минуту? Например: какой пользователь пострадал, какой сервис виноват, что именно вернуло внешнее API, повторяется ли это и сколько людей затронуто. Всё, что не помогает ответить на эти вопросы, превращается в шум. И вот этот шум как раз и топит в Grafana — не объём данных, а их бесполезность.
После этого я переписал подход к записи событий. Во-первых, структурированные логи вместо свободного текста: JSON или хотя бы стабильные пары ключ-значение, чтобы по ним можно было фильтровать и строить графики без боли. Во-вторых, единый идентификатор запроса, который протягивается через все сервисы, — именно он превращает разрозненные строки в одну историю. В-третьих, осмысленный уровень: error оставляю только для того, что реально требует человека, warn — для деградации, info — для ключевых переходов в бизнес-процессе. И, в-четвёртых, я перестал логировать данные, которые нельзя логировать: пароли, токены, номера карт, персональные данные. Это и безопасность, и, как ни странно, спасение от мусора.
Отдельная боль — имена событий. Раньше у нас было привет, Hello world, стартуем, начинаем обработку и запуск, и всё это означало одно и то же. Теперь есть словарь событий, и любая новая строка должна в него вписываться. Звучит скучно, но именно это сделало поиск в Grafana мгновенным: я знаю, что искать, и знаю, что найду. Плюс я держу в каждой записи контекст: версию релиза, окружение, идентификатор тенанта, длительность операции. Контекст — это то, что отличает полезный лог от красивой, но бесполезной строки.
С алертами вышло ещё интереснее. Раньше у нас был алерт на каждое сообщение с уровнем error, и телефон вибрировал так, что я перестал на него смотреть. Классический alarm fatigue: когда алертов слишком много, человек перестаёт реагировать даже на настоящий пожар. Мы перешли на алерты по симптомам, а не по строкам логов: растёт доля ошибок, упала пропускная способность, превышен бюджет задержки, недоступен критичный внешний сервис. Всё остальное живёт в дашбордах и разбирается спокойно днём. Количество алертов сократилось в разы, а польза от них выросла на порядок.
Про дашборды скажу отдельно, потому что это моя личная слабость. Красивая панель с двадцатью графиками успокаивает, но не помогает. Я оставил в Grafana три уровня: общий обзор на один экран для дежурного, детальные панели по сервисам и отдельные разборы под конкретные инциденты, которые создаю руками во время проблемы и потом выбрасываю. Дашборд должен отвечать на вопрос за десять секунд, иначе это не дашборд, а декорация. И обязательно правило: если алерт сработал, в описании должна быть ссылка на панель и короткая инструкция, что делать. Дежурный не должен искать истину в темноте.
Если коротко, вот что я советую всем, кто сейчас тонет в логах и уведомлениях. Пишите логи для человека, который вас разбудит ночью, а не для галочки. Делайте их структурированными и единообразными. Всегда добавляйте идентификатор запроса и контекст. Держите уровни честными. Не логируйте то, что не имеет права попасть в хранилище. Стройте алерты по симптомам, а не по каждой строке. И пересматривайте свою схему логирования хотя бы раз в квартал — сервисы меняются быстрее, чем нам кажется.
А теперь вопрос к вам, коллеги с форума: какие приёмы в логировании и алертинге реально спасли вашу ночь — что вы однажды добавили, и после этого дежурства стали спокойнее? Делитесь опытом, у каждого в этом деле найдётся своя находка, о которой другим стоит узнать.