Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-03-10

1 <p>Теги: devops, системы логирования, логи, graylog, elk, loggy, splunk, mongodb, микросервисы</p>

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

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

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

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

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

7 <h2>Что эта система даёт администраторам?</h2>

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

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

10 <h2>Что эта система даёт программистам?</h2>

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

12 <h2>Что эта система даёт Q/A?</h2>

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

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

15 <h2>Микросервисы</h2>

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

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

18 <p><em>Есть вопрос? Напишите в комментариях!</em></p>