Несколько дней новогоднего волшебства:
Успейте начать обучение в 2018-ом году со скидкой до 30%!
Выбрать курс

Системы логирования

VKDevOpsDeep.png

К логам сервисов и приложений обращаются абсолютно все: администраторы читают логи, чтобы выяснить причину сбоя сервиса; программисты ищут в них исключения; «безопасники» проверяют, что в них нет каких-нибудь необычных записей, характерных для взлома.

Пока у вас один сервер, всё хорошо: каждый специалист может открыть файлы в vim и посмотреть, что ему нужно. А что если серверов у вас много? А что если по этим серверам разбросаны кучи сервисов и приложений? Как людям читать логи со всего этого?

Придётся же читать логи каждого сервиса, каким-то сложным методом находить логи того запроса, что сломался, и искать где именно что-то пошло не так. Как решить эти проблемы?

Существуют популярные системы логирования: Graylog, ELK, Loggy или Splunk

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

Что эта система даёт администраторам?

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

Мы предполагаем, что где-то возникла ошибка, поэтому добавляем фильтр по полю. Указываем, что «критичность логов» должна быть «ERROR», после чего система нам покажет все ошибки с заданной критичностью. Если администратор не исправляет ошибку, а пишет «постмортем» по вчерашней аварии, он также может добавить фильтр по времени и посмотреть логи за весь вчерашний день, за конкретные его часы и т.д.

Что эта система даёт программистам?

В некоторых компаниях программистам не дают доступ к серверам, с этой системой они могут смотреть все интересующие их логи, не заходя в них! Частой проблемой является поиск сервера, на котором произошло исключение. Мы можем просто написать исключение в строке поиска, найти, на каком сервере это произошло, и посмотреть весь его журнал в считанные секунды. Поверх логов с исключениями можно построить график количества исключений в час/день/и т.д., чтобы отследить возрастание ошибок после деплоя и вовремя откатиться на предыдущий релиз.

Что эта система даёт Q/A?

Во-первых, они по логам могут проанализировать, состояние сервисов после прогона тестов – не появилось ли там новых ошибок. Если же ошибки появились, можно передать программисту ссылку на все эти сообщения.

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

Микросервисы

Это особенный случай. Тут серверов много, на одном сервере может быть несколько одинаковых микросервисов. Какой запрос где сломался, вообще не поймёшь. В таких сложных ситуациях прибегают к практике сквозного логирования, при которой каждому запросу присваивается ID, передающийся от сервиса к сервису на протяжении всей жизни запроса. Этот ID так же добавляют в логи, и когда мы получаем исключение, мы видим не только ошибку, но и в каком конкретно запросе оно произошло.

Вбиваем этот ID в систему логирования и видим полное развитие событий: от начала до конца. Ага, вот запрос прошёл балансировку, вот произошла авторизация пользователя, вот он начал собирать данные, обходя множество микросервисов, и вот тут конкретный микросервис вернул ошибку. Дальше можно проследить и обратную цепочку того, как ошибка прошла весь этот путь обратно и показалась пользователю, но, как правило, это уже не так важно.

Есть вопрос? Напишите в комментариях!

Автор
0 комментариев
Для комментирования необходимо авторизоваться