引言：最近在调研与选型分布式调用链监控组件。选了主要的三种APM组件进行了实践与比较。本来打算一篇文章写完的，篇幅太长，打算分两篇。 расстояниепервый разПрошел почти месяц, в основном из-за загруженности работой в последнее время, а обновление идет очень медленно. В этой статье мы поговорим о сравнении и тестировании производительности нескольких вариантов APM.
1. Предыдущий обзор
В предыдущей статье в основном говорилось о практике трех компонентов мониторинга распределенной цепочки вызовов. Предыстория проблемы развивается микросервисной архитектурой.Преимущества микросервисов упоминать не нужно.После того,как много микросервисов,то много потоков.Часто используется следующая картина.
Таким образом, сложность системы увеличивается. Чем сложнее система, тем сложнее не устранить проблемы, такие как сбои системы или проблемы с производительностью. Не слишком сложно найти решение в трехуровневой архитектуре, нужно только анализировать 3 компонента, такие как веб-сервер, сервер приложений и базу данных, а количество серверов не так много. Однако, если проблема возникает в архитектуре N-уровня, необходимо изучить большое количество компонентов и серверов. Другая проблема заключается в том, что просто анализируя отдельные компоненты, указывают на большую картину; когда возникает проблема с низким видимостью, тем более сложна система, тем дольше требуется, чтобы найти причину. Хуже всего, в некоторых случаях мы даже не сможем найти это.
По сути, существующая проблема локализации ошибок была упомянута выше.Проблемы, существующие в бизнес-системе, построенной на основе микросервисной системы, в основном делятся на три категории:
- Ошибки локализовать сложно, за простой операцией может стоять более десятка микросервисов, и за эти микросервисы тоже отвечают разные команды. Как только возникает проблема, в худшем случае нам может понадобиться эта дюжина команд для совместного решения проблемы.
- Связи разобрать сложно, приложение не формирует топологию приложения, и неизвестно, кто повлияет на нижестоящую его службу.
- Существует много растраты ресурсов, и оценка емкости затруднена. Для некоторых сервисов cpm и потребление памяти могут быть меньше 10%, что далеко не полностью использует физическую машину. На самом деле это связано с оценкой производительности: слишком большая или слишком маленькая предполагаемая пиковая производительность машины — это пустая трата времени.
Основная цель APM состоит в том, чтобы решить четыре проблемы, упомянутые выше.Основной метод заключается в том, чтобы помочь разработчикам и эксплуатационному персоналу в диагностике неисправностей, оценке производительности и обнаружении узких мест производительности путем сбора, хранения, анализа и вызова данных о событиях в распределенных системах. И прочесывать ссылку вызова. В первой статье фактически говорилось о требованиях к компоненту мониторинга ссылок:
- навязчивый код
- Стоимость производительности зонда
- Комплексный анализ данных о ссылках на звонки
- Масштабируемость
Вот некоторые моменты, упомянутые pinpoint в своей вики:
- Распределенное отслеживание транзакций, отслеживание сообщений в распределенных приложениях
- Автоматически определять топологию приложения, чтобы помочь вам понять архитектуру приложения
- Горизонтальное масштабирование для поддержки больших кластеров серверов
- Обеспечьте видимость на уровне кода, чтобы легко найти точки сбоя и узкие места.
- Используйте методы улучшения байт-кода, чтобы добавлять новые функции без изменения кода.
Давайте рассмотрим эти компоненты мониторинга распределенной цепочки вызовов в соответствии с этими требованиями.
2. Сравнение AMP
Требования перечислены выше, но они не являются достаточно общими, автор выделит пункты, которые необходимо сравнить:
- Производительность зонда
В основном влияние агента на пропускную способность, ЦП и память службы. Масштаб и динамичный характер микросервисов значительно удорожают сбор данных. - Расширяемость коллекторов
Возможность горизонтального масштабирования для поддержки больших кластеров серверов. - Комплексный анализ данных о ссылках на звонки
Обеспечивает видимость на уровне кода, чтобы легко обнаруживать точки сбоя и узкие места. - Прозрачный для разработки, легко переключаемый
Добавляйте новые функции, не изменяя код, и легко включайте или отключайте их. - Полная топология приложения цепочки вызовов
Автоматически определять топологию приложения, чтобы помочь вам понять архитектуру приложения
В соответствии с основными потребностями автор выделил вышеперечисленные пять пунктов.
2.1 Характеристики зонда
На самом деле автор тоже уделяет больше внимания производительности зонда.Ведь APM позиционирование это все таки инструмент.Если включить компонент мониторинга ссылок, то он напрямую снизит пропускную способность более чем в два раза, что недопустимо. Автор провел нагрузочные тесты на прыжки с парашютом, зипкин и пинпойнт и сравнил их с исходным уровнем (без зондов).
Выбирается обычное приложение на основе Spring, которое включает Spring Boot, Spring MVC, клиент Redis и mysql. Отслеживайте это приложение, каждую трассировку, зонд захватит 5 диапазонов (1 Tomcat, 1 SpringMVC, 2 Jedis, 1 Mysql). В основном здесьskywalkingtestТестовое приложение аналогично.
Три одновременного пользователей моделировались: 500, 750, 1000. Испытано с JMeter, каждый поток отправляет 30 запросов и устанавливает время в 10 мс. Используемая частота дискретизации составляет 1, что на 100%, что может отличаться от производственной линии. Скорость отбора проб по умолчанию Pinpoint составляет 20, то есть 50%, которая может быть изменена на 100%, установив файл конфигурации агента. Zipkin также 1 по умолчанию. Сочетание, всего 12 типов. Смотрите сводную таблицу ниже.
Как видно из приведенной выше таблицы, среди трех компонентов мониторинга каналов наименьшее влияние на пропускную способность оказывает probe of skywalking, а пропускная способность zipkin находится посередине. Влияние пинпоинт-зонда на пропускную способность очевидно: при наличии 500 одновременных пользователей пропускная способность тестового сервиса снижается с 1385 до 774, что оказывает большое влияние. Затем посмотрите на влияние процессора и памяти, автор провел стресс-тест на внутреннем сервере, и влияние на процессор и память было почти в пределах 10%.
2.2 Масштабируемость коллекторов
Масштабируемость коллектора обеспечивает горизонтальное масштабирование для поддержки крупномасштабных серверных кластеров.
- zipkin
В предыдущей статье мы разрабатывали zipkin-Server (фактически, поставляемый готовый пакет), zipkin-agent связывается с zipkin-Server через http или mq, и http-связь влияет на нормальный доступ, поэтому по-прежнему рекомендуется общаться на основе асинхронного режима mq, а zipkin-Server использует подписку на определенные темы. Это, конечно, масштабируемо, и несколько экземпляров zipkin-Server асинхронно потребляют информацию мониторинга в mq.
- skywalking
Сборщик Skywalking поддерживает два режима развертывания: автономный и кластерный режим. Связь между сборщиком и агентом использует gRPC. - pinpoint
Точно так же точно определяйте кластеры, а также поддерживает автономное развертывание. Агент точного определения бережливости через коммуникационную рамку передает информацию о канале сборщику.
2.3 Комплексный анализ данных о звонках
Комплексный анализ данных цепочки вызовов обеспечивает видимость на уровне кода, что позволяет легко обнаруживать сбои и узкие места.
- zipkin
- skywalking
Skywalking также поддерживает более 20 промежуточных программ, фреймворков, библиотек классов, таких как основной dubbo, Okhttp, а также промежуточное ПО для баз данных и сообщений. Анализ и перехват вызовов по небу на приведенном выше рисунке относительно прост. Шлюз вызывает пользовательскую службу. Поскольку он поддерживает множество промежуточного программного обеспечения, анализ вызовов по небесным ссылкам является более полным, чем zipkin.
- pinpoint
APM должен точно определить эти три компонента, наиболее полные компоненты анализа данных. Обеспечьте видимость на уровне кода, чтобы легко найти точки сбоя и узкие места на карте, которую вы можете увидеть для выполнения операторов SQL, это было записано. Он также может настроить правила сигнализации, лицо, ответственное за каждый набор, соответствующий приложению, в соответствии с правилами настроенной сигнализацией, поддерживаемой структурой промежуточного программного обеспечения, а также более полной.
2.4 Прозрачный для разработки, легко переключаемый
Прозрачный для разработки, легко включать и выключать, добавлять новые функции без изменения кода, легко включать и отключать. Мы ожидаем, что функции будут работать без модификации кода, и нам нужна видимость на уровне кода.
Для этого Zipkin использует модифицированную библиотеку классов и собственный контейнер (Finagle), чтобы обеспечить функциональность распределенной трассировки транзакций. Однако при необходимости требуется модификация кода. Как Skywalk, так и Pinpoint основаны на улучшении байт-кода, разработчикам не нужно изменять код, и они могут собирать более точные данные, поскольку в байт-коде содержится больше информации.
2.5 Полная топология приложения цепочки вызовов
Автоматически определяйте топологию приложения, чтобы помочь вам определить архитектуру вашего приложения.
На трех рисунках выше показаны соответствующие топологии вызовов компонентов APM, каждый из которых может реализовать полную топологию приложения цепочки вызовов. Условно говоря, интерфейс пинпоинта отображается более обильно.Что касается имени БД звонка, то топология зипкина ограничена обслуживанием между сервисами.
3. Резюме
В этой статье рассказывается о сравнении трех компонентов мониторинга распределенной цепочки вызовов, в основном по пяти аспектам, и автор сравнивает каждый пункт. Что касается того, какой компонент выбрать, вы можете выбрать модель в соответствии с реальными потребностями и сценариями бизнеса.Данные, приведенные выше, приведены только для справки. Все эти три модели являются проектами с открытым исходным кодом.Как правило, компании выполняют некоторые вторичные разработки в соответствии с реальной ситуацией, такие как добавление поддержки некоторых компонентов, стыковка с существующими платформами больших данных и т. д.
Наконец, прочитав соответствующее введение в eagleEye, я хочу упомянуть, как система мониторинга трансформируется из пассивной тревоги в активное обнаружение, что на самом деле очень близко к AIOps. Объем данных мониторинга канала огромен, и хотя объем передаваемых данных может быть уменьшен за счет степени сжатия, действительно ли нам нужно хранить каждый канал? Нужно ли только выявлять нештатную ситуацию в каждом звене? Аномальные точки в показателях временного ряда нам необходимо выявить в этот момент времени. После завершения идентификации исключения сопоставляются, чтобы найти окончательную проблему. Конечно, это касается уровня бизнеса и прикладных систем, что очень сложно, но автор считает, что это общий тренд AIOps в будущем.
Рекомендуемое чтение
Несколько распределенных практик и сравните компонент мониторинга цепочки вызовов (A)