Системы логирования: на что обратить внимание при выборе | OTUS
⚡ Подписка на курсы OTUS!
Интенсивная прокачка навыков для IT-специалистов!
Подробнее

Курсы

Программирование
Backend-разработчик на PHP Алгоритмы и структуры данных Team Lead Архитектура и шаблоны проектирования Разработчик IoT C# Developer. Professional HTML/CSS
-11%
C# ASP.NET Core разработчик
-5%
Kotlin Backend Developer
-8%
iOS Developer. Professional
-8%
Symfony Framework Unity Game Developer. Basic JavaScript Developer. Professional Android Developer. Basic JavaScript Developer. Basic Java Developer. Professional Highload Architect Reverse-Engineering. Professional Java Developer. Basic Web-разработчик на Python Framework Laravel Cloud Solution Architecture Vue.js разработчик Интенсив «Оптимизация в Java» Супер - интенсив по паттернам проектирования Супер - интенсив по Kubernetes Супер-интенсив "Tarantool" PHP Developer. Basic
Инфраструктура
Мониторинг и логирование: Zabbix, Prometheus, ELK Administrator Linux. Professional Дизайн сетей ЦОД Разработчик IoT PostgreSQL Экспресс-курс "Версионирование и командная работа с помощью Git"
-30%
Microservice Architecture Highload Architect MS SQL Server Developer Разработчик программных роботов (RPA) на базе UiPath и PIX Разработчик голосовых ассистентов и чат-ботов Administrator Linux. Advanced Infrastructure as a code Супер-практикум по использованию и настройке GIT Administrator Linux.Basic Экспресс-курс «IaC Ansible» Экспресс-курс «CI/CD или Непрерывная поставка с Docker и Kubernetes» Основы Windows Server
Корпоративные курсы
Безопасность веб-приложений IT-Recruiter Дизайн сетей ЦОД Компьютерное зрение Разработчик IoT Вебинар CERTIPORT Machine Learning. Professional
-6%
NoSQL Пентест. Практика тестирования на проникновение Java QA Engineer. Базовый курс Руководитель поддержки пользователей в IT
-8%
SRE практики и инструменты Cloud Solution Architecture Внедрение и работа в DevSecOps Супер-практикум по работе с протоколом BGP Infrastructure as a code Супер-практикум по использованию и настройке GIT Промышленный ML на больших данных Экспресс-курс «CI/CD или Непрерывная поставка с Docker и Kubernetes» BPMN: Моделирование бизнес-процессов Основы Windows Server
Специализации Курсы в разработке Подготовительные курсы
+7 499 938-92-02

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

VKDevOpsDeep.png

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

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