1. Введение
В этой части учебного пособия будут завершены дискуссии о наблюдаемости путем анализа его последнего столпа — распределенной трассировки.
Распределенная трассировка, также называемая распределенной трассировкой запросов, — это метод, используемый для профилирования и мониторинга приложений, особенно тех, которые построены с использованием архитектуры микросервисов. Распределенная трассировка помогает точно определить, где происходят сбои и что приводит к снижению производительности. — https://opentracing.io/docs/overview/what-is-tracing/
В распределенных системах, таких как типичная микросервисная архитектура , запрос может проходить через десятки или даже сотни служб, прежде чем ответ будет собран и отправлен обратно. Но откуда тебе это знать? В некоторой степени журналы могут предоставить такую информацию, но они по своей сути плоские: становится трудно понять причинно-следственную связь между вызовами или событиями, извлечь задержки и восстановить полный путь, по которому запрос прошел через систему. Это как раз тот случай, когда на помощь приходит распределенная трассировка.
История распределенной трассировки (как мы ее знаем в наши дни) началась в 2010 году , когда Google опубликовал знаменитую статью Dapper, инфраструктуру отслеживания крупномасштабных распределенных систем . Хотя Dapper никогда не был открытым исходным кодом, документ послужил вдохновляющим планом для ряда проектов с открытым исходным кодом и коммерческих проектов, разработанных после него. Итак, давайте подробнее рассмотрим распределенную трассировку.
Содержание
2. Инструментарий + Инфраструктура = Визуализация
Прежде чем мы углубимся в детали, важно понять, что хотя распределенная трассировка является потрясающей технологией, она не волшебна. По сути, он состоит из трех ключевых компонентов:
- Инструментарий : специфичные для языка библиотеки, которые помогают обогатить приложения и сервисы возможностями трассировки.
- Инфраструктура : промежуточное программное обеспечение для отслеживания (сборщики, серверы и т. Д.) Вместе с механизмом (ами) хранилища, где следы отправляются, собираются, сохраняются и становятся доступными для запросов в дальнейшем.
- Визуализация : интерфейсы для изучения, визуализации и анализа собранных следов.
Практически это означает, что развертывание распределенной поддержки трассировки по всему флоту микросервисов требует не только разработки, но и затрат на эксплуатацию. По сути, он становится еще одним элементом инфраструктуры для управления и мониторинга. Хорошей новостью является то, что это вне критического пути, большинство библиотек инструментальных средств спроектированы так, чтобы быть устойчивыми к отслеживанию сбоев промежуточного программного обеспечения. В конце концов, производственные потоки не должны быть затронуты в любом случае, хотя некоторые следы могут быть потеряны.
Для многих реальных приложений запись и сохранение трассировок для каждого отдельного запроса может быть чрезмерно дорогой. Например, это может привести к значительным накладным расходам в системах, сильно оптимизированных для производительности, или оказать большое давление на хранилище в случае систем с очень большим объемом запросов. Чтобы смягчить воздействие и все же получить полезную информацию, широко используются различные методы отбора проб.
3. TCP, HTTP, gRPC, обмен сообщениями,…
Одной из проблем, с которыми сталкиваются современные реализации распределенной трассировки, является широкий спектр средств связи, используемых архитектурами микросервисов (и распределенными системами в целом). Стратегии распространения контекста сильно отличаются не только из-за протоколов, но и из-за стилей общения. Например, добавить инструментарий трассировки для сервисов, которые используют обмен запросами / ответами по протоколу HTTP , гораздо проще, чем инструктировать производителей и потребителей Apache Kafka или сервисы gRPC .
Распределенная трассировка как платформа работает через языки программирования и границы времени выполнения. Единственными языковыми компонентами являются библиотеки инструментов, которые объединяют приложения, сервисы и платформы распределенной трассировки. К счастью, в настоящее время искомые инструменты отслеживания уже доступны либо от сообщества, поставщиков или сопровождающих. Тем не менее, в редких случаях, особенно при использовании самых современных технологий, вам может потребоваться свернуть свои собственные.
4. OpenZipkin
Zipkin — один из первых проектов с открытым исходным кодом, реализованных после публикации Dapper инженерами Twitter . Он быстро набрал обороты и вскоре перешел на OpenZipkin .
Zipkin — это распределенная система отслеживания. Это помогает собирать временные данные, необходимые для устранения проблем с задержками в сервисных архитектурах. Возможности включают как сбор, так и поиск этих данных. — https://github.com/openzipkin/zipkin
В настоящее время Zipkin является ведущей платформой распределенной трассировки с большим количеством интеграций, доступных для многих разных языков. Платформа JCG Car Rentals собирается использовать Zipkin для сбора и запроса трассировок всех своих микросервисов .
Давайте посмотрим на типичный интеграционный поток. Например, в случае с Платежным сервисом , который мы решили внедрить в Go , мы могли бы использовать инструментарий zipkin-go .
|
01
02
03
04
05
06
07
08
09
10
11
12
13
|
defer reporter.Close()// create our local service endpointendpoint, err := zipkin.NewEndpoint("payment-service", "localhost:29080")if err != nil { log.Fatalf("unable to create local endpoint: %+v\n", err)}tracer, err := zipkin.NewTracer(reporter, zipkin.WithLocalEndpoint(localEndpoint))if err != nil { log.Fatalf("unable to create tracer: %+v\n", err)} |
Zipkin-go не только предоставляет необходимые примитивы, но и обладает выдающимися инструментальными возможностями для сервисов на основе gRPC , как и Платежный сервис .
|
1
2
3
4
5
6
|
func Run(ctx context.Context, tracer *zipkin.Tracer) *grpc.Server { s := grpc.NewServer(grpc.StatsHandler(zipkingrpc.NewServerHandler(tracer))) payment.RegisterPaymentServiceServer(s, newPaymentServer()) reflection.Register(s) return s} |
5. OpenTracing
Zipkin был одним из первых, но число различных распределенных платформ трассировки, вдохновленных его успехом, начало быстро расти, каждая из которых продвигала свои собственные API. Инициатива OpenTracing возникла на ранней стадии как попытка найти общий язык между всеми этими реализациями.
OpenTracing состоит из спецификации API, платформ и библиотек, которые реализовали спецификацию, и документации для проекта. OpenTracing позволяет разработчикам добавлять инструментарий в код своего приложения с помощью API, которые не привязывают их к какому-либо конкретному продукту или поставщику. — https://opentracing.io/docs/overview/what-is-tracing/
К счастью, преимущества таких усилий были в целом понятны, и на сегодняшний день список распределенных трассировщиков, поддерживающих OpenTracing, включает в себя, в основном, всех основных игроков.
6. Храбрый
Brave — одна из наиболее широко используемых библиотек инструментов трассировки для приложений на основе JVM, которая обычно используется вместе с платформой трассировки OpenZipkin .
Brave — это распределенная библиотека инструментов трассировки. Храбрый обычно перехватывает производственные запросы для сбора данных о времени, корреляции и распространения контекстов трассировки. — https://github.com/openzipkin/brave
Количество контрольно-измерительных приборов, предоставленных Brave из коробки, очень впечатляет. Хотя он может быть интегрирован напрямую, многие библиотеки и фреймворки предоставляют удобные абстракции поверх Brave для упрощения идиоматического инструментария. Давайте посмотрим, что это значит для различных услуг JCG Car Rentals .
Поскольку служба резервирования построена на основе Spring Boot , она может выиграть от превосходной интеграции с Brave, предоставляемой Spring Cloud Sleuth .
|
1
2
3
4
5
6
7
8
9
|
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-sleuth</artifactId></dependency><dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zipkin</artifactId></dependency> |
Большинство параметров интеграции могут быть настроены через свойства конфигурации.
|
01
02
03
04
05
06
07
08
09
10
|
spring: sleuth: enabled: true sampler: probability: 1.0 zipkin: sender: type: WEB baseUrl: http://localhost:9411 enabled: true |
С другой стороны, Служба поддержки клиентов использует встроенные инструменты Brave , следуя соглашениям Project Hammock . Ниже приведен фрагмент кода, иллюстрирующий его настройку.
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
|
@ApplicationScopedpublic class TracingConfig { @Inject private String uri; @Produces public Brave brave() { return new Brave.Builder("customer-service") .reporter(AsyncReporter.create(OkHttpSender.create(uri))) .traceSampler(Sampler.ALWAYS_SAMPLE) .build(); } @Produces public SpanNameProvider spanNameProvider() { return new DefaultSpanNameProvider(); }} |
Веб-интерфейсы, входящие в состав дистрибутива Zipkin- сервера, позволяют визуализировать отдельные трассировки для всех участвующих микросервисов .
Очевидно, что наиболее полезным применением платформ распределенной трассировки является ускорение поиска и устранения неисправностей. Правильная визуализация играет здесь очень важную роль.
Наконец, что не менее важно , как и многие другие распределенные платформы отслеживания, Zipkin продолжает развиваться и вводить новшества. Одним из недавних дополнений к этому инструменту является новый альтернативный веб-интерфейс под названием Zipkin Lens , показанный на рисунке ниже.
7. Егер
Jaeger является еще одной популярной платформой распределенной трассировки, которая была разработана в Uber и открыта позже.
Jaeger , вдохновленный Dapper и OpenZipkin , представляет собой распределенную систему отслеживания, выпущенную Uber Technologies в качестве открытого источника . Его можно использовать для мониторинга распределенных систем на основе микросервисов — https://github.com/jaegertracing/jaeger
Помимо размещения под зонтиком Cloud Native Computing Foundation ( CNCF ), Jaeger изначально поддерживает спецификацию OpenTracing, а также обеспечивает обратную совместимость с Zipkin . Практически это означает, что контрольно-измерительные приборы, которые мы сделали для услуг JCG Car Rentals, будут беспрепятственно работать с платформой трассировки Jaeger .
8. OpenSensus
OpenCensus происходит от Google, где он использовался для автоматического сбора трассировок и метрик из огромного количества сервисов.
OpenCensus — это набор библиотек для различных языков, которые позволяют собирать метрики приложений и распределенные трассировки , а затем переносить данные в выбранный бэкэнд в режиме реального времени. — https://opencensus.io/
В общем , OpenCensus — это инструментальный слой, который совместим (среди многих других ) с бэкэндами трассировки Jaeger и Zipkin .
9. OpenTelemetry
Мы говорили об инициативе OpenTelemetry в предыдущей части урока, касаясь только темы метрик . Но, по правде говоря, OpenTelemetry — это результат объединения двух хорошо зарекомендовавших себя проектов Jaeger и OpenSensus под одной крышей, обеспечивающих полноценную, надежную и портативную платформу телеметрии.
Руководство OpenTracing и OpenCensus собрались вместе, чтобы создать OpenTelemetry, и он заменит оба проекта. — https://opentelemetry.io/
На момент написания этой статьи работа над первым официальным выпуском OpenTelemetry все еще продолжается, но первые планы по плану появятся очень скоро .
10. Хейстек
Haystack , родившийся в Expedia , является примером платформы распределенной трассировки, которая выходит за рамки простого сбора и визуализации трасс. Он сосредоточен на анализе тенденций работы, графиках обслуживания и обнаружении аномалий.
Haystack — это проект распределенной трассировки с открытым исходным кодом, поддерживаемый Expedia, для облегчения обнаружения и устранения проблем на микросервисах и веб-сайтах. Он сочетает в себе совместимый с OpenTracing механизм трассировки с компонентной серверной архитектурой, разработанной для обеспечения высокой отказоустойчивости и высокой масштабируемости. Haystack также включает в себя инструменты анализа для визуализации данных трассировки, отслеживания трендов в данных трассировки и установки сигналов тревоги, когда тренды данных трассировки превышают установленные вами пределы. — https://expediadotcom.github.io/haystack/docs/about/introduction.html
Стог сена — это модульная платформа, которую можно использовать по частям или в целом. Одним из исключительно полезных и мощных компонентов является Haystack UI . Даже если вы еще не используете Haystack , вы можете использовать Haystack UI вместе с Zipkin в качестве замены своего внешнего интерфейса.
При использовании только с Zipkin доступны не все компоненты, но даже в этом случае много аналитики доступно из коробки.
Haystack , вероятно, является самой продвинутой платформой распределенного отслеживания с открытым исходным кодом на данный момент. Мы увидели лишь небольшое подмножество того, что возможно, еще одна его особенность, адаптивное оповещение , собирается вернуться в следующей части урока.
11. Apache SkyWalking
Apache SkyWalking — это еще один замечательный пример зрелой платформы для наблюдения с открытым исходным кодом, где распределенная трассировка играет ключевую роль.
SkyWalking : платформа с открытым исходным кодом для наблюдения, сбора, анализа, агрегирования и визуализации данных из сервисов и облачной инфраструктуры. — https://github.com/apache/skywalking/blob/master/docs/en/concepts-and-designs/overview.md
Стоит отметить, что API инструментов Apache SkyWalking полностью соответствуют спецификации OpenTracing . На уровне бэкенда Apache SkyWalking также поддерживает интеграцию с Zipkin и Jaeger , хотя существуют некоторые ограничения .
В случае с платформой JCG Car Rentals замена Zipkin на Apache SkyWalking проходит без проблем, и все существующие контрольно-измерительные приборы продолжают функционировать, как и ожидалось.
12. Оркестровка
Как мы уже говорили ранее, оркестраторы и сервисные сетки глубоко внедряются в развертывание современных микросервисных архитектур . Быть невидимым и просто делать свою работу — это моджо за сетками обслуживания . Но когда что-то идет не так, важно знать, является ли виновником сервисная сетка или оркестратор.
К счастью, каждая крупная сервисная сетка построена и спроектирована с учетом наблюдаемости , включая все три столпа: журналы , метрики и распределенное отслеживание. Istio является настоящим лидером здесь и поставляется с поддержкой Jaeger или Zipkin , тогда как Linkerd предоставляет только некоторые функции , которые часто связаны с распределенной трассировкой. С другой стороны, Consul with Connect полностью полагается на возможности распределенной трассировки Envoy и не выходит за рамки этого.
Распространение контекста от сетки сервисов до отдельных сервисов позволяет увидеть полную картину того, как запрос проходит через систему, с момента его ввода до момента отправки последнего байта ответа.
13. Первая миля
Как вы могли заметить, распределенная трассировка часто сужается до контекста серверных служб или серверных приложений; внешние интерфейсы почти полностью игнорируются. Такая небрежность, безусловно, удаляет некоторые важные части головоломки, поскольку в большинстве случаев внешние интерфейсы являются именно тем местом, где инициируется большинство взаимодействий на стороне сервера. Существует даже черновой вариант спецификации W3C под названием Trace Context, чтобы устранить этот пробел, так почему же это так?
Инструментарий приложения JavaScript предоставляется многими платформами распределенной трассировки, например, у OpenSensus есть такая же, как и у OpenZipkin и OpenTracing . Но любой из них требует, чтобы некоторые части инфраструктуры распределенной трассировки были общедоступными для фактического сбора трассировок, отправленных из браузера. Хотя такая практика широко применяется, например, для аналитических данных, она все же создает проблемы безопасности и конфиденциальности, поскольку довольно часто трассировки действительно могут содержать конфиденциальную информацию.
14. Облако
Раньше было сложно интегрировать распределенную трассировку в облачные развертывания, но в настоящее время большинство поставщиков облачных услуг предлагают специальные предложения.
Мы собираемся начать с AWS X-Ray, который обеспечивает сквозное представление запросов при их прохождении через систему и показывает карту базовых компонентов. В общем, приложения и службы должны использовать X-Ray SDK для инструментов распределенной трассировки, но некоторые платформы, например, OpenZipkin или OpenSensus , имеют расширения для интеграции с AWS X-Ray .
В облаке Google распределенную трассировку выполняет Stackdriver Trace , член набора наблюдаемых Stackdriver . Языковые SDK предоставляют низкоуровневые интерфейсы для непосредственного взаимодействия со Stackdriver Trace, но вместо этого у вас есть возможность использовать OpenSensus или Zipkin .
Распределенная трассировка в Microsoft Azure поддерживается Application Insights , частью более крупного предложения Azure Monitor . Он также предоставляет специальные SDK Application Insights, с которыми должны интегрироваться приложения и сервисы, чтобы раскрыть возможности распределенной трассировки. Что удивляет, так это то, что Application Insights также поддерживает распределенную трассировку через OpenSensus .
Как вы можете видеть, у каждого облачного провайдера есть свое мнение относительно распределенной трассировки, и в большинстве случаев у вас нет выбора, как использовать их SDK. К счастью, ведущие платформы распределенной трассировки с открытым исходным кодом снимают с вас эту нагрузку, поддерживая такие интеграции.
15. Без сервера
Все больше организаций стремятся к безсерверным вычислениям , чтобы либо сократить расходы, либо ускорить развертывание новых функций или предложений. Правда состоит в том, что безсерверные системы кричат о наблюдаемости , в противном случае устранение неполадок больше похоже на поиск иголки в стоге сена. Может быть довольно трудно определить, где в сильно распределенной безсерверной системе что-то пошло не так, особенно в случае каскадных сбоев.
Это ниша, где распределенная трассировка действительно сияет и чрезвычайно полезна. Облачные серверные предложения опираются на инструментарий распределенной трассировки для конкретного поставщика , однако безсерверные платформы с открытым исходным кодом пытаются их здесь догнать. В частности, Apache OpenWhisk поставляется с интеграцией OpenTracing, тогда как Knative использует Zipkin . Для других, таких как OpenFaas или Serverless , вам может потребоваться настроить ваши функции вручную в данный момент.
16. Выводы
В этой части урока мы поговорили о третьем столпе наблюдаемости , распределенной трассировке. Мы охватили только необходимый минимум, однако есть тонны материалов для чтения и просмотра на эту тему, если вам интересно узнать ее дальше.
В наши дни в области распределенного отслеживания происходит много инноваций. Новые интересные инструменты и интеграции находятся в работе (сравнение трасс, анализ латентности, трассировка JFR и т. Д.), И, надеюсь, мы сможем использовать их в производстве очень скоро.
17. Что дальше
В следующей, заключительной части руководства мы поговорим о мониторинге и предупреждениях.