CC BY-NC
26Кибернетика и программирование
Правильная ссылка на статью:
Рудометкин В.А — Мониторинг и поиск неисправностей в распределённых высоконагруженных системах // Кибернетика и программирование. - 2020. - № 2. DOI: 10.25136/2644-5522.2020.2.32996 URL: https;//nbpublish.com'library_read_article.php?id=32996
Мониторинг и поиск неисправностей в распределённых высоконагруженных системах
Рудометкин Василий Андреевич
Эксперт в разработке сервисов "Геолокация", ПАО МТС 109382, Россия, Москва область, г. Москва, ул. Краснодонская, 36, кв. 120
vasiliy.rudo metki n@g mail.com Статья из рубрики "Автоматизированные системы управления технологическими процессами"
DOI:
10.25136/2644-5522.2020.2.32996
Дата направления статьи в редакцию:
26-05-2020
Дата публикации:
10-08-2020
Аннотация.
Предметом исследования является проблема мониторинга и поиска неисправностей в распределённых высоконагруженных системах. Описываются наиболее распространенные ошибки при проектировании и разработки, способы их прогнозирования и решений. В данной статье автор описывается наиболее популярные инструменты, которые используются в настоящее время при разработке высоконагруженных систем и основные ошибки при работе с ними с точки зрения разработчика. В данной статье описывается набор инструментов, внедрение которых позволяет существенно сократить время на поиск уязвимостей, описаны сложности при выборе набора технологий метрик - ELK/EFK, описываются их преимущества и недостатки. Подробно разбираются аналоги используемых инструментов. Основными выводами в работе являются: - необходимость разработки инфраструктуры мониторинга системы с начала разработки проекта, благодаря чему можно исправить высокую сложность проекта на этапе его разработки.- необходимо использовать наиболее популярные инструменты, по которым имеется большое количество информации в открытых источниках, например, в Интернет. Данный подход позволит сократить время на исправления ошибок, которые могут быть вызваны специфическим набором инструментов.- компании необходимо не экономить на высококвалифицированном персонале, который в будущем позволит сэкономить большое количество времени на
исправлении проблем, снизит время на разработку нового функционала и позволит уделять минимум времени для поддержки и тестирования уже разработанного функционала. - при анализе проблем стоит обратить внимание на публичные ресурсы, в которых другие компании, скорее всего, решали уже подобные проблемы. Например, компания Facebook долгое время занимается проблемой мониторинга и разработало большое количество инструментов для решения этой задачи. Так же собирают большое количество системных записей, которые позволяют анализировать поведения системы при любых ситуациях.
Ключевые слова: мониторинг, высоконагруженная система, метрики, ELK, EFK, белый ящик, черный ящик, тестирование, контроль качества, архитектура
В настоящее время информационные системы становятся все крупнее и сложнее, включают в себя большое количество инфраструктурных компонентов, такие как сервера очередей, базы данных и сами сервисы, количества которых может достигать десятков штук, а если рассматривать масштабируемые системы, то количество инстансов сервисов может достигать нескольких тысяч. В такой системе поиск ошибок ставится проблемой, если не уделить должного внимания инструментам мониторинга.
Мониторинг высоконагруженной системы является основной обязанностью оперативных групп и зачастую разработчиков. На сегодня существует множество стратегий и инструментов для мониторинга серверов, сбора важных данных и реагирования на ошибки и изменения условий в различных средах. Однако по мере развития программных методов и проектов инфраструктуры мониторинг должен адаптироваться для решения новых задач и освещения относительно незнакомой территории.
В статье «Актуальность современных систем удаленного мониторинга вычислительных ресурсов»1 Сильнов Д.С. рассмотрел проблему мониторинга с точки зрения активного и пассивного мониторинга и подробно описывает необходимые компоненты системы для мониторинга, но рассматривает инструменты для мониторинга поверхностно и опирается на ОС Windows, которое накладывает ограничения на проектирование системы.
Рассмотрим подробнее основные направления в мониторинге:
• Black-box
• White-box
White-box мониторинг основан на показателях, отображаемых внутренними компонентами системы, включая журналы, метрики профилирования виртуальной машины Java или обработчика HTTP, которые генерируют внутреннюю статистику.
Рис 1. White-box мониторинг
2
На рисунке 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 мониторинге, который должен в режиме реального времени отображать работоспособность системы. Данный мониторинг является первый стадией для анализа проблемы, поэтому необходимо выводить на него как можно больше информации по сервисам, сетевому взаимодействию компонентов, количестве пользователей и их активностях.
сервис 1 сервис 2
1 г
сервис 3 сервис п
Рис. 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 стек технологий. Большинство технологий для
мониторинга разработаны крупнейшими компаниями, такими как, Facebook5.
Таким образом, благодаря правильно разработанному инструменту мониторинга высоконагруженных систем получится появляется возможность оперативного выявления несоответствия системы заявленным требованиям, что позволяет оперативно исправлять необходимые компоненты системы, а большой набор анализируемых данных позволяет анализировать работу системы со стороны клиента, что способствует правильному развитию системы с точки зрения надежности и качества функционирования и захвата большего сегмента рынка, удовлетворяя потребности большего количества польз ов а те ле й.
Библиография
1. Сильнов Д.С. Актуальность современных систем удаленного мониторинга вычислительных ресурсов [ТЕКСТ]/Сильнов Д.С. - Санкт-Петербург, известия РГПУ им. а.и. Герцена, 2020, 55-59
2. Электронный ресурс, Системное администрирование, режим доступа
https ://serveradmin.ru/ustanovka-i-nastroyka-elasticsearch-logstash-kibana-elk-stack/
3. Петров В.В. Сбор, Анализ и филтрация больших данных с помощью стека ELK [ТЕКСТ]/ Петров В.В. - Colloquium-journal, 2019 - Украина, Голая Пристань, Colloquium-journal, 2020
https ://cyberleninka.ru/artide/n/sbor-filtratsiya-i-analiz-bolshih-dannyh-s-pomoschyu-steka-elk/viewer
4. Электронный ресурс, официальный сайт МТС ПОИСК, режим доступа https ://poisk.mts.ru/
5. Электронный ресурс, официальный сайт github - разработки Facebook, режим доступа https://github.com/facebook
6. Электронный ресурс, журнал пользовательских публикаций, статья мониторинга в Google https://habr.com/ru/post/484246/
7. Электронный ресурс, официальный сайт Zabbix, режим доступа https ://www.zabbix.com/ru/
8. Электронный ресурс, официальный сайт Kibana, режим доступа https ://www.elastic.co/kibana
9. Электронный ресурс, официальный сайт ElasticSearch, режим доступа https ://www.elastic.co/
10. Электронный ресурс, официальный сайт Istio, режим доступа https://istio.io
11. Методы и средства метамониторинга распределенных вычислительных сред [ТЕКСТ]/Сидоров И.А., Новопашин А.П., Опарин Г.А., Скоров В.В. - Челябинск, Вестник ЮУрГ,2014,1-39
Результаты процедуры рецензирования статьи
В связи с политикой двойного слепого рецензирования личность рецензента не раскрывается.
Со списком рецензентов издательства можно ознакомиться здесь.
Рецензируемая статья посвящена мониторингу и поиску неисправностей в распределённых высоконагруженных системах с большим количеством инстансов. Актуальность обобщения подходов к поиску ошибок в крупных масштабных и сложных информационных системах со значительным числом инфраструктурных компонентов обусловлена, с одной стороны, усложнением современных информационных систем, с другой стороны, связана с наличием множества инструментов для мониторинга и сбора важных данных, а также стратегий реагирования на ошибки различных средах программных разработок. Методология исследования базируется на анализе основных направлений мониторинга и описании используемых для его проведения инструментов. По мнению рецензента, в статье содержатся элементы приращения научного знания в виде результатов обобщения используемых технологий мониторинга распределённых высоконагруженных информационных систем. В работе рассматриваются основные направления мониторинга сложных информационных систем: White-box мониторинг и Black-box мониторинг, излагаются используемые при каждом из подходов средства снижения нагрузки на систему мониторинга, взаимодействия между ними. К положительным моментам рецензируемой статьи следует отнести описание использования современных популярных инструментов Sphinx, Algolia, Elasticksearch, Fluentd, Graphite, Logstash, Graylog, Graphite, Kibana, Zabbix, Grafana, Istio и технологий OpenTracing, Spring Boot Sleuth, Zipkin. К сожалению, текст работы четко не структурирован, в нем не выделены принятые в научных публикациях рубрики: введение, материалы и методы, полученные результаты и их обсуждение, выводы (заключение). Стиль изложения в целом приемлем для научных публикаций, однако рисунки, судя по качеству их представления, заимствованы из уже опубликованных источников, без указания конкретных ссылок на первоисточники. К тому же корректировки требует нумерация рисунков, поскольку в представленном тексте два рисунка с номером 1. Отсутствие ссылок по тексту работы на приводимые в библиографии источники должно быть устранено в процессе доработки статьи. Сам перечень использованных материалов вряд ли стоит ограничивать пятью электронными ресурсами - преимущественно материалами официальных сайтов разработчиков инструментариев для специалистов в большими данными - целесообразно сослаться и на публикации в официально зарегистрированных научных журналах и монографии с указанием имен авторов и времени опубликования материалов. Поэтому приходится констатировать отсутствие в статье какой-либо апелляции к оппонентам. По результатам проделанной работы автором не сформулированы выводы или заключение, что создает впечатление незавершенности исследования. Узким местом представляется и отсутствие ссылок на опыт проведения автором мониторинга или собственных разработок высоконагруженных систем. Статья может вызвать определенный интерес у читателей, интересующихся вопросами разработки сложных многокомпонентных информационных систем и обеспечением проведения надлежащего мониторинга и поиска неисправностей в информационных системах. Резюмируя изложенное выше, можно сделать вывод об актуальности исследования, его соответствия тематике журнала, наличии элементов приращения научного знания. Однако отсутствие ссылок, как на собственные разработки, так и на научные публикации других авторов, погрешности в оформлении рисунков не позволяют рекомендовать статью к публикации в представленном виде, требуется ее доработка. Замечания главного редактора от 28.07.2020: "Автор доработал статью после рецензирования. Материал рекомендуется к публикации".
