0 вопросов фон

Благодаря популярности микросервисной архитектуры,Услуги разделены по разным параметрам, запрос часто должен включать несколько служб.Интернет-приложения строятся на разных наборах программных модулей., эти программные модули,Может разрабатываться разными командами, может быть реализован на разных языках программирования, может быть развернут на тысячах серверов в нескольких разных центрах обработки данных.. Следовательно, необходимы инструменты, которые могут помочь понять поведение системы и проанализировать проблемы с производительностью, чтобы при возникновении сбоев можно было быстро обнаружить и устранить проблемы.

Компонент мониторинга полной связи был создан в контексте такой проблемы. Наиболее известно упомянуты в публичной статье GoogleGoogle Dapper.Чтобы понять поведение распределенной системы в этом контексте, необходимо отслеживать связанные действия в разных приложениях и между разными серверами..

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

Затем, в случае непрерывного роста бизнеса, в случае увеличения обслуживания и частых изменений, он принесет ряд вопросов к сложным ссыланиям вызова:

1. Как быстро найти проблемы?
2. Как определить масштаб вины?
3. Как разобраться в сервисных зависимостях и рациональности зависимостей?
4. Как анализировать проблемы с производительностью канала и планирование пропускной способности в реальном времени?

При этом мы будем обращать внимание на различные показатели производительности каждого звонка при обработке запроса., такие как пропускная способность (TPS), время отклика и регистрация ошибок.

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

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

С помощью инструмента полного мониторинга ссылок мы можем достичь:

1. Запросите отслеживание ссылок, быстро найдите неисправности: Вы можете быстро найти информацию об ошибках через цепочку вызовов в сочетании с бизнес-журналом.
2. визуализация: Каждый этап занимает много времени, и выполняется анализ производительности.
3. Оптимизация зависимостей: доступность, объединение зависимостей служб и оптимизация каждой вызывающей ссылки.
4. Анализ данных, оптимизация ссылок: можно получить путь поведения пользователя, а сводный анализ можно применить во многих бизнес-сценариях.

1 Объективные требования

Как упоминалось выше, каковы целевые требования к нашему выбору компонентов полноканального мониторинга? Также упоминается в Google Dapper, резюмируя следующим образом:

1. Стоимость работы зонда

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

2. навязчивый код

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

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

3. Масштабируемость

   Хорошая система отслеживания звонков должна поддерживать распределенное развертывание, хорошую масштабируемость. Чем больше поддержки, тем лучше, конечно, компоненты. Или предоставьте удобный API для разработки плагинов.Для некоторых неконтролируемых компонентов разработчики приложений также могут расширять их самостоятельно.

4. анализ данных

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

2 функциональных модуля

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

1. Скрытые и сгенерированные журналы

   Скрытая точка — это контекстная информация системы в текущем узле, которую можно разделить наВстраивание на стороне клиента, встраивание на стороне сервера и двустороннее встраивание между клиентом и сервером. Журнал скрытых точек обычно содержит следующее содержимое: traceId, spanId, время начала звонка, тип протокола, IP-адрес и порт вызывающего абонента, запрошенное имя службы, время звонка, результат звонка, информация об исключении и т. д. В то же время расширяемый поле зарезервировано для Подготовка к следующему расширению;

   Нет нагрузки на производительность: Значение не было проверено, но это повлияет на выполнение вещей, сложно продвинуть компанию!

   Поскольку журнал необходимо записывать, чем выше число запросов в секунду для бизнеса, тем больше влияние на производительность.Решается путем выборки и асинхронного журнала.

2. Собирать и хранить журналы

   Он в основном поддерживает решение распределенного сбора журналов и в то же время добавляет MQ в качестве буфера;

   1. по одному на каждую машинуdeamonСбор журналов, бизнес-процессы, его собственная трассировка, отправленная демону, демону для отправки трассировки коллекции;
   2. Многоуровневый коллекторподобная архитектуре pub/sub, которая может балансировать нагрузку;
   3. по агрегированным даннымАнализ в реальном времени и автономное хранение;
   4. Автономный анализНам нужно объединиться с цепочкой журнала вызовов вместе;

3. Анализ и статистика данных о ссылках на вызовы и своевременность

   Анализ трассировки цепочки вызовов: Соберите промежутки одного и того же TraceID и отсортируйте их по времени, которое является временной шкалой.Связывание ParentID вместе — это стек вызовов..

   Выдает исключение или тайм-аут и печатает TraceID в журнале. Используйте TraceID, чтобы запросить цепочку вызовов и найти проблему.

   Зависимость:

   1. сильная зависимость: сбой вызова напрямую прерывает основной процесс
   2. очень зависимый: Вероятность вызова зависимости в ссылке высока
   3. частая зависимость: Ссылка называет той же зависимостью много раз

   Автономный анализ: Суммировать по TraceID, восстановить связь вызова по Span ID и ParentID и проанализировать форму ссылки.

   анализ в реальном времени: Непосредственный анализ одного журнала без его суммирования и реорганизации. Получить текущий QPS, задержка.

4. Презентация и поддержка принятия решений

3 Google Dapper

3.1 Span

основная единица работы, Вызов ссылки (который может быть без RPC, например, с конкретным ограничением БД) для создания диапазона, он идентифицируется 64-битным идентификатором, более удобным uuid, есть другие данные диапазона, такие как информация описания, отметка времени, ключ- пары значений (аннотации) теговой информации, parent_id и т.п., где диапазон может представлять источник ссылки вызова parent-id.

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

Структура данных Span:

type Span struct {
    TraceID    int64 // 用于标示一次完整的请求id
    Name       string
    ID         int64 // 当前这次调用span_id
    ParentID   int64 // 上层服务的调用span_id  最上层服务parent_id为null
    Annotation []Annotation // 用于标记的时间戳
    Debug      bool
}

3.2 Trace

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

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

3.3 Annotation

Аннотация, запрос на запись определенного информации о событиях (например, время), будет множество аннотационного промежутка, описанные аннотации. Обычно содержат четыре аннотации:

(1) cs: запуск клиента, указывающий, что клиент инициирует запрос (2)sr: Server Receive, указывающий, что сервер получил запрос (3)ss: Server Send, указывающий, что сервер завершает обработку и отправляет результат клиенту. (4)cr: Client Received, указывающий, что клиент получает информацию, возвращенную сервером.

Структура данных аннотации:

type Annotation struct {
    Timestamp int64
    Value     string
    Host      Endpoint
    Duration  int32
}

3.4 Пример вызова

1. Пример вызова запроса

   1. Когда пользователь инициирует запрос, он сначала достигает внешней службы A, а затем выполняет RPC-вызовы службы B и службы C соответственно;
   2. Служба B отвечает на A после обработки, но служба C должна взаимодействовать с серверной службой D и службой E, прежде чем вернуть ее службе A, и, наконец, служба A отвечает на запрос пользователя;

   

2. Трассировка процесса вызова

   1. Приходит запрос на создание глобального TraceIDTraceID может вызвать всю серию из цепи, трассид от имени запроса.
   2. В дополнение к TraceID,SpanID также требуется для записи отношений родитель-потомок.. Каждая служба будет записывать родительский идентификатор и идентификатор диапазона,Отношения родитель-потомок, посредством которых может быть организована полная цепочка вызовов.
   3. Диапазон без родительского идентификатора становится корневым диапазоном, который можно рассматривать как запись цепочки вызовов.
   4. Всем этим доступен глобально уникальный идентификатор 64-битного целого числа;
   5. Каждый запрос должен передаваться по TraceID и разделяться на протяжении всего звонка..
   6. Каждая служба записывает TraceID и SpanID, прикрепленные к запросу в качестве родительского идентификатора, и записывает созданный ею SpanID.
   7. Чтобы просмотреть полный вызовПросто найдите все записи вызовов в соответствии с TraceID, а затем организуйте все отношения родитель-потомок вызова с помощью идентификатора родителя и идентификатора диапазона..

   

3. Основная работа по цепочке вызовов

   1. Генерация данных цепочки вызовов, внедрять точки для всех приложений во весь вызывающий процесс и выводить логи.
   2. Сбор данных цепочки вызовов, для сбора данных журнала в каждом приложении.
   3. Хранение данных цепочки вызовов и запрос, для хранения собранных данных.Поскольку объем данных журнала, как правило, велик, необходимо не только их хранить, но и обеспечивать быстрый запрос.
   4. Индекс вычисления, хранения и запросы, выполнять различные операции с индексами для собранных данных журнала и сохранять результаты операций.
   5. Функция будильника, обеспечивая различные функции порогового предупреждения.

4. Общая архитектура развертывания

   

   1. Создавайте журналы цепочки вызовов через АГЕНТ.
   2. Собирать логи к кафке через logstash.
   3. Kafka отвечает за предоставление данных нижестоящим потребителям.
   4. Storm вычисляет результат индекса агрегации и попадает в ES.
   5. Storm извлекает данные трассировки и переходит к es, что позволяет выполнять более сложные запросы.. Например, запрашивая цепочку вызовов по измерению времени, можно быстро запросить все совпадающие идентификаторы трассировки.Идите снова по этим traceIDHbaseПроверьте данные в ближайшее время.
   6. Logstash тянет кафка необработанные данные в HBASE.Строка hbase — это traceID, и запрос, основанный на traceID, выполняется очень быстро..

5. АГЕНТ неинвазивное развертывание

   Благодаря ненавязчивому развертыванию агента AGENT измерение производительности и бизнес-логика полностью разделены, и можно измерить время выполнения любого метода любого класса, что значительно повышает эффективность сбора данных и снижает затраты на эксплуатацию и обслуживание.В зависимости от срока службы он в основном делится на две категории: АГЕНТ:

   1. Агент по обслуживанию, этот способ выполняетсяJavaМеханизм агента используется для сбора данных об уровне вызова метода внутри службы, таких как время вызова метода, входные и выходные параметры.

   2. Межсервисный АГЕНТ, для которого требуется бесшовная поддержка в виде подключаемых модулей для основных сред RPC. И для размещения пользовательских фреймворков RPC путем предоставления стандартных спецификаций данных:

      （1）Dubbo支持；
      
      （2）Rest支持；
      
      （3）自定义RPC支持；
      

6. Преимущества мониторинга цепочки вызовов

   1. Точно понимать развертывание передовых приложений в рабочей среде;
   2. С точки зрения производительности всего процесса цепочки вызовов,Определите критические цепочки вызовов и оптимизируйте их;
   3. Предоставляет отслеживаемые данные о производительности, количественно оценить бизнес-ценность отдела эксплуатации и обслуживания ИТ;
   4. Быстрое обнаружение проблем с производительностью кодаЧтобы помочь разработчикам оптимизировать непрерывность кода;
   5. Помощь разработчикам в тестировании белого ящика, сократить период онлайн стабильности системы;

4 Сравнение схем

Большинство теоретических моделей полносвязного мониторинга на рынке основаны на документах Google Dapper.Эта статья посвящена следующим трем компонентам APM:

1. Zipkin: Распределенная система отслеживания с открытым исходным кодом от Twitter, используемая для сбора данных о времени сервисов для решения проблемы задержки в архитектуре микросервисов, включая: сбор, хранение, поиск и представление данных.
2. Pinpoint: инструмент APM для крупномасштабных распределенных систем, написанный на Java, компонент распределенного отслеживания с открытым исходным кодом, созданный корейцами.
3. Skywalking: отличный отечественный компонент APM, представляющий собой систему для отслеживания, оповещения и анализа бизнес-операций распределенных кластеров приложений JAVA.

Элементы, которые необходимо сравнить в трех вышеупомянутых решениях для полноканального мониторинга, извлекаются.:

1. Производительность зонда

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

2. Расширяемость коллекторов

   Возможность горизонтального масштабирования для поддержки больших кластеров серверов.

3. Комплексный анализ данных о ссылках на звонки

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

4. Прозрачный для разработки, легко переключаемый

   Добавляйте новые функции, не изменяя код, и легко включайте или отключайте их.

5. Полная топология приложения цепочки вызовов

   Автоматически определять топологию приложения, чтобы помочь вам понять архитектуру приложения

4.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%, что может отличаться от производственной. Частота дискретизации пинпоинта по умолчанию равна 20, то есть 50%, которую можно изменить на 100%, установив файл конфигурации агента. zipkin также равен 1 по умолчанию. В совокупности насчитывается 12 типов. Взгляните на сводную таблицу ниже:

Как видно из приведенной выше таблицы, среди трех компонентов мониторинга каналовСкайуминовый зонд Минимальное воздействие на пропускную способность, пропускной способность Zipkin. Приводное влияние на пропускную способность зонда очевидно, при 500 одновременных пользователях пропускная способность тестового сервиса снижается с 1385 до 774, что оказывает большое влияние. Затем посмотрите на влияние ЦП и памяти.Тест давления, проведенный на внутреннем сервере, показывает, что влияние на ЦП и память находится почти в пределах 10%.

4.2 Масштабируемость коллекторов

Масштабируемость коллектора обеспечивает горизонтальное масштабирование для поддержки крупномасштабных серверных кластеров.

1. zipkin

   Разработать zipkin-Server (по сути это готовый пакет), zipkin-agent общается с zipkin-Server через http или mq,HTTP-связь повлияет на нормальный доступ, поэтому рекомендуется использовать асинхронную связь mq.Zipkin-Server использует подписку на определенную тему. Конечно, его можно расширить.Несколько экземпляров zipkin-Server асинхронно потребляют информацию мониторинга в mq.

   

2. skywalking

   Сборщик Skywalking поддерживает два метода развертывания:Автономный и кластерный режимы. Связь между сборщиком и агентом использует gRPC..

3. pinpoint

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

4.3 Комплексный анализ данных о звонках

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

1. zipkin

   

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

2. skywalking

   

   Skywalking также поддерживает более 20 промежуточных программ, фреймворков, библиотек., такие как: основной dubbo, Okhttp и промежуточное ПО для баз данных и сообщений. Анализ и перехват вызовов по линии Skywalking на приведенном выше рисунке относительно прост: шлюз вызывает службу пользователя,Благодаря поддержке многих промежуточных программ анализ вызовов по ссылкам Skywalking является более полным, чем zipkin..

3. pinpoint

   

   pinpoint должен быть среди этих трех компонентов APM,Самый полный компонент для анализа данных. Обеспечивает видимость на уровне кода, чтобы легко обнаруживать точки сбоя и узкие места, как видно из приведенного выше рисунка, все выполненные операторы SQL регистрируются. Вы также можете настроить правила сигналов тревоги и т. д., назначить ответственного за каждое приложение и подать сигнал тревоги в соответствии с настроенными правилами.Поддерживаемое промежуточное программное обеспечение и структура также относительно полны.

4.4 Для разработки прозрачного, легко переключиться

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

Для этого,Zipkin использует модифицированную библиотеку классов и собственный контейнер (Finagle) для предоставления возможностей распределенной трассировки транзакций.. Однако при необходимости требуется модификация кода.И Skywalking, и Pinpoint основаны на улучшении байт-кода, разработчикам не нужно изменять код, и они могут собирать более точные данные, поскольку в байт-коде содержится больше информации..

4.5 Полная топология приложения цепочки вызовов

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

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

4.6 Сравнение уточнения Pinpoint и Zipkin

4.6.1 Различия между Pinpoint и Zipkin

1. PinePoint - это полное решение для мониторинга производительности: Существует полная система из зонда, коллектора, хранения к веб-интерфейсу;Zipkin фокусируется только на услугах по сбору и хранению, хотя пользовательский интерфейс тоже есть, но его функциональность не на том же уровне, что и у Пинпоинта.Вместо этого Zipkin предоставляет интерфейс запросов., более мощный пользовательский интерфейс и возможности системной интеграции, которые могут быть реализованы на основе вторичного развития этого интерфейса.
2. Zipkin официально предоставляет интерфейс на основе фреймворка Finagle (язык Scala)., в то время как интерфейсы других фреймворков предоставляются сообществом и в настоящее время могут поддерживать основные языки и фреймворки разработки, такие как Java, Scala, Node, Go, Python, Ruby и C#; ноВ настоящее время Pinpoint официально предоставляет только зонды Java Agent., другие запрашивают поддержку сообщества (см.#1759 и #1760).
3. Pinpoint предоставляет зонды Java Agent, которые реализуют перехват вызовов и сбор данных посредством внедрения байт-кода.Это может обеспечить невмешательство в реальный код, просто добавьте некоторые параметры при запуске сервера, чтобы завершить развертывание зонда.;иJava-интерфейс Zipkin реализует Brave, предоставляет только базовый операционный API, если вам нужно интегрироваться с фреймворком или проектом,Вам нужно вручную добавить файлы конфигурации или добавить код.
4. Серверное хранилище Pinpoint основано на HBase, а Zipkin — наCassandra.

4.6.2 Сходство между точностью и Zipkin

И Pinpoint, и Zipkin основаны на документе Google Dapper, поэтому теоретическая основа примерно одинакова.Оба разбивают вызов службы на несколько спанов с каскадными отношениями и используют SpanId и ParentSpanId для каскадирования отношений вызовов; наконец, все спаны, проходящие через всю цепочку вызовов, объединяются в трассировку и сообщаются службе. сбор и хранение.

Даже на этом этапе концепции, используемые Pinpoint, не полностью согласуются с этой статьей. Например, он использовалTransactionId заменяет TraceId, а реальный TraceId представляет собой структуру, которая содержит TransactionId, SpanId и ParentSpanId.. И PinPoint добавляет структуру spanevent под span для записи сведений о вызове внутри SPAN (например, вызовы определенных методов и т. д.), поэтомуОтслеживание точного определения по умолчанию записывает больше данных, чем Zipkin. Однако теоретически нет предела детализации Span, поэтому вызов службы может быть Span, тогда вызов метода в каждой службе также может быть Span, в этом случаеНа самом деле Brave тоже может отслеживать уровень вызова метода, но конкретная реализация этого не делает..

4.6.3 Внедрение байт-кода и вызов API

Pinpoint реализует зонд Java-агента на основе внедрения байт-кода, в то время как платформа Zipkin Brave предоставляет только API-интерфейсы уровня приложения, но проблема далеко не проста.Подключение к байтекоде является простой и неочищенный раствор, теоретически независимо от любых вызовов метода, перехват может быть достигнут с помощью кодовой инъекции, что нельзя добиться не только для достижения.但 Brave 则不同，API уровня приложения, который он предоставляет, также нуждается в поддержке базового драйвера фреймворка для обеспечения перехвата.. Например, драйвер MySQL JDBC предоставляет метод для внедрения перехватчика, поэтому необходимо только реализовать интерфейс StatementInterceptor и настроить его в строке подключения, чтобы легко реализовать связанный перехват; в отличие от более низкой версии драйвера MongoDB или реализации Spring Data MongoDB не имеет такого интерфейса, и реализовать функцию перехвата операторов запросов сложнее.

Поэтому на данный момент Brave является недостатком.Как бы ни было сложно использовать инъекцию байткода, она по крайней мере достижима, но у Brave нет возможности запуститься, и можно ли ее инжектить, до какой степени ее можно инжектить и многое другое Зависит от API фреймворка, а не от его собственных возможностей.

4.6.4 Сложность и стоимость

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

Инкапсуляция кода Pinpoint также очень хороша, особенно инкапсуляция API верхнего уровня для внедрения байт-кода очень хороша, но это все еще требует от читателей некоторого понимания внедрения байт-кода, хотя его основной API для внедрения кода не так уж много, но если вы хотите разобраться досконально, боюсь, вам придется углубиться в соответствующий код агента.Например, трудно понять разницу между addInterceptor и addScopedInterceptor с первого взгляда, и эти два метода находятся в соответствующих типах агента.

Поскольку инъекция Brave должна полагаться на базовую структуру для предоставления соответствующих интерфейсов, нет необходимости иметь всестороннее понимание структуры, вам нужно только знать, куда ее можно внедрить и какие данные можно получить во время инъекции.. Как и в приведенном выше примере, нам не нужно знать, как реализован драйвер JDBC MySQL, чтобы иметь возможность перехватывать SQL. Но это не относится к Pinpoint, потому что Pinpoint может внедрить практически любой код в любом месте, что требует от разработчиков очень глубокого понимания реализации кода библиотеки, которую необходимо внедрить, что может быть полезно, если взглянуть на реализацию его плагины MySQL и Http Client, конечно, это также показывает с другого уровня, что возможности Pinpoint действительно могут быть очень мощными, и многие плагины, реализованные по умолчанию, достигли очень мелкозернистого перехвата.

Когда базовая структура не предоставляет API, Brave не совсем беспомощен Мы можем использовать АОП для внедрения соответствующего перехвата в указанный код, и, очевидно, применение АОП намного проще, чем внедрение байт-кода..

Вышеперечисленное напрямую связано со стоимостью реализации мониторинга, в официальной технической документации Pinpoint приведены справочные данные.Если интеграция системы, то затраты на разработку Pinpoint plug 100 интегрирован в систему, стоимость этого плагина 0; но Brave, разработка плагина стоила всего 20, 10 и затраты на интеграцию. С этого момента видно, что официальные справочные данные о стоимости составляют 5:1. Но чиновник также подчеркнул, что если необходимо интегрировать 10 систем, то общая стоимость составляет 10 * 10 + 20 = 120, что превышает стоимость разработки Pinpoint в 100 раз, и чем больше сервисов необходимо интегрировать, тем больше разрыв.

4.6.5 Универсальность и расширяемость

Очевидно, что на данный момент Pinpoint находится в невыгодном положении, что видно из интегрированных интерфейсов, разработанных сообществом.

В интерфейсе данных Pinpoint отсутствует документация, он не очень стандартен (см. ветку обсуждения на форуме) и требует прочтения большого количества кода для реализации собственного зонда (например, Node или PHP). И команда использовала Thrift в качестве стандарта протокола передачи данных из соображений производительности, что намного сложнее, чем HTTP и JSON.

4.6.6 Поддержка сообщества

Излишне говорить, что Zipkin разработан Twitter и может считаться звездной командой, в то время как команда Naver — это просто малоизвестная небольшая команда (от  #1759Это можно увидеть в обсуждении). Хотя этот проект с меньшей вероятностью исчезнет или перестанет обновляться в краткосрочной перспективе, он не так хорош, как первый. И больше нет вставок, разработанных сообществом.Pinpoint сложно завершить интеграцию многих фреймворков только силами самой команды, и в настоящее время их внимание по-прежнему сосредоточено на повышении производительности и стабильности..

4.6.7 Прочее

Pinpoint учитывал проблемы с производительностью в начале своего внедрения.Некоторые сервисы на серверной части веб-сайта www.naver.com обрабатывают более 20 миллиардов запросов в день, поэтому они будут выбирать двоичный формат кодирования Thrift с переменной длиной и использовать UDP в качестве передачи.ссылки и попробуйте использовать справочный словарь данных при передаче констант, передавать число вместо прямой передачи строки и т. д. Эти оптимизации также увеличивают сложность системы: в том числе сложность использования интерфейса Thrift, проблема передачи данных UDP, проблема регистрации словаря констант данных и т. д.

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

Кроме тогоВ Pinpoint отсутствует возможность выборки запросов. Очевидно, что в производственной среде с высоким трафиком невозможно записать все запросы. Это требует выборки запросов, чтобы определить, какие запросы мне нужно записать.. И Pinpoint, и Brave поддерживают проценты выборки, то есть какой процент запросов будет записан. Однако кроме тогоBrave также предоставляет интерфейс Sampler, с помощью которого можно настроить стратегию сэмплирования., особенно при проведении A/B-тестирования, такая функция имеет большой смысл.

4.6.8 Резюме

Что касается краткосрочных целей, у Pinpoint есть подавляющее преимущество:Зонды могут быть развернуты без каких-либо изменений в коде проекта, детализация данных трассировки вплоть до уровня вызова метода, мощный пользовательский интерфейс и почти полная поддержка среды Java.. Но в долгосрочной перспективе изучение интерфейса разработки Pinpoint и стоимость реализации интерфейсов для разных фреймворков в будущем пока неизвестны. Напротив,Освоить Brave относительно легко, а сообщество Zipkin сильнее и с большей вероятностью разработает больше интерфейсов в будущем.. В худшем случае мы также можем добавить подходящий для себя код мониторинга через АОП, не внедряя слишком много новых технологий и концепций. И когда бизнес изменится в будущем, трудно сказать, смогут ли отчеты, предоставляемые Pinpoint, соответствовать требованиям.Добавление новых отчетов также приведет к непредсказуемым трудностям и нагрузке.

5 Разница между трассировкой и мониторингом

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

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

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