Мониторинг и поиск неисправностей в распределённых высоконагруженных системах

Рудометкин Василий Андреевич Эксперт в разработке сервисов "Геолокация", ПАО МТС 109382, Россия, Москва область, г. Москва, ул. Краснодонская, 36, кв. 120 Rudometkin Vasilii Андреевич Expert in the development of services "Geolocation", MTS 109382, Russia, Moskva oblast', g. Moscow, ul. Krasnodonskaya, 36, kv. 120 vasiliy.rudometkin@gmail.com

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

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

В статье «Актуальность современных систем удаленного мониторинга вычислительных ресурсов»¹ Сильнов Д.С. рассмотрел проблему мониторинга с точки зрения активного и пассивного мониторинга и подробно описывает необходимые компоненты системы для мониторинга, но рассматривает инструменты для мониторинга поверхностно и опирается на ОС Windows, которое накладывает ограничения на проектирование системы.

Рассмотрим подробнее основные направления в мониторинге:

• Black-box
• White-box

White-box мониторинг основан на показателях, отображаемых внутренними компонентами системы, включая журналы, метрики профилирования виртуальной машины Java или обработчика HTTP, которые генерируют внутреннюю статистику.

Рис 1. White-box мониторинг²

На рисунке 1 изображена схема взаимодействия компонентов для White-box мониторинга. Инфраструктура для мониторинга является отдельно стоящей для приложения, чтобы не создавать дополнительную нагрузку. Все компоненты системы отправляют метрики в logstash, где они форматируются и отправляются в elasticksearch. При построении архитектуры мониторинга, любой компонент может быть заменен на аналог.

Для снижения нагрузки на систему мониторинга рекомендуется взаимодействовать с ней при помощи сервера очередей, например kafka. Такое взаимодействие позволит быстро освобождать сервис и снимет требования ко времени обработки метрик.

Наиболее важные характеристики, за которыми необходимо следить - сеть, загрузка ОЗУ и ЦП. Такие параметры могут предоставлять сами сервисы, но не стоит собирать метрики слишком часто, так как это создает дополнительную и довольно высокую нагрузку на сервис.

Одним из самых первых требований к системе является логирование - отслеживание цепочек происходящих событий с целью поиска неисправностей. Но события нужно складывать и обрабатывать и для этого существует большое количество инструментов, таких как Sphinx, Algolia и другие, но наиболее популярным является elasticksearch. Это поисковые инструменты, которые хранят, обрабатывают и предоставляют API к данным в системе.

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

Для отображения данных в системе хранения используются инструменты, которые позволяют легко интегрироваться с системой хранения и быстро выдавать результаты, такие как Graylog, Graphite, но одним из самым популярных является Kibana.

При построении системы мониторинга стоит выбрать между EFK (elastic + fluentDb + Kibana) и ELK (elastic + logstash + Kibana)³, так как эти два подхода являются наиболее популярными в настоящее время и информации по ним сейчас очень много, поэтому создание хорошей системы мониторинга не займет много времени, но позволит быстро находить и устранять проблемы.

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

Рис. 2 Black-box мониторинг

На рисунке 2 изображена схема Black-box мониторинга, на которой приборная панель отображает состояние системы в целом и показывает актуальный статус системы. Необходимый набор метрик для данного мониторинга является - сетевая нагрузка на сервисы, количество подключений к инстансам сервиса, количество инстансов каждого сервиса и история изменения метрик.

Такие системы развиваются довольно давно, поэтому их большое количество. Одни из самых популярных это Graphite, Zabbix, Grafana. В большинстве случаев приборные панели являются сложными решениями, поэтому позволяют интегрировать в себя дополнительные расширения, которые могут нести полезную информацию в зависимости от требований, которые выставлены системе Black-box мониторинга.

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

В высоконагруженной системе с большим количеством сервисов проблема отслеживания запроса с целью оптимизации является сложной задачей, а зачастую невыполнимой стандартными инструментами. Для решения это проблемы используются технологии, которые позволяют отслеживать запрос - OpenTracing. Это решение добавляет метаинформацию при взаимодействии сервисов, в которой содержится сквозной идентификатор. В качестве более удобного решения можно использовать технологии, основанные на OpenTracing, например Spring Boot Sleuth совместно с Zipkin. Такое решение позволяется отслеживать маршрутизацию запросов, предоставляет подробную информацию по нему (рис. 3).

Рис. 3. Архитектура Spring Boot Sleuth совместно с Zipkin.

На рисунке 3 изображена архитектура мониторинга запросов при использовании Spring Boot Sleuth совместно с Zipkin:

• В каждом сервисе на кластере присутствует модуль Spring Boot Sleuth
• И используя http или сервер очередей данные запросов попадают в Zipkin(collector)
• Collector складывает данные в базу данных
• При обращении пользователя в Zipkin UI, query server формирует запросы к базе данные, что позволяет отображать необходимые данные пользователю

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

Наиболее эффективные технологии применены на проекте МТС ПОИСК⁴. В настоящий момент на обработку поступает около 5000 событий в секунду, что создает довольно высокую нагрузку на систему, поэтому проблема мониторинга крайне остро стояла на проекте. Старое решение на ELK стеке создавало высокую нагрузку на систему мониторинга и зачастую блокировала работу приложения. Замена Logstash на Kafka позволило решить эту проблему.

Так как обработка каждого события в системе затрагивает большое количество компонентов системы, то в случае некорректного поведения в системе найти неисправность было невозможно. Внедрение Spring Boot Sleuth позволила сократить время на поиск до десяти минут.

Анализируя выборы технологий ведущих IT компаний мира, то можно сделать несколько вывод об используемых технологиях мониторинга - в большинстве случаев компании используют ELK или, реже, EFK стек технологий. Большинство технологий для мониторинга разработаны крупнейшими компаниями, такими как, Facebook⁵.

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