Распределенная трассировка: что нам о ней не сказали

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

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

Команды реализуют еще одно ведение журнала

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

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

Подумайте об этом… в дополнение к следующему знакомому логлайну:

{ "ip": "127.0.0.1", "user": "-", "date": "06/Dec/2023:12:30:45 +0000", "method": " GET", "url": "/example-page", "http_version": "HTTP/1.1", "status_code": 200, "response_size": 1234

Приложение начинает отправлять следующие диапазоны в серверную часть распределенной трассировки:

{

"traceId": "8a4da9f548267ea8",

"spanId": "bc8d7a6c12345a",

"parentSpanId": "a2a7b5c6123456",

"name": "HTTP GET /example-page",

"вид": "СЕРВЕР",

"метка времени": 1638760245000,

"длительность": 1500

"атрибуты": {

"http.method": "GET",

"http.status_code": 200,

"http.url": "/example-page",

"ip": "127.0.0.1",

"user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, например Gecko) Chrome/96.0.4664.45 Safari/537.36"

},

"статус": {

"code": "ОК",

"сообщение": "HTTP 200"

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

Как этого избежать?

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

Никто не говорил нам, что стоимость отслеживания растет непропорционально.

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

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

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

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

Как этого избежать?

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

А выборка означает, что будет сохранена только часть трасс, и то незначительная; Я имею в виду не 50 %… а скорее 10–15 % или даже меньше для приложений с высокой пропускной способностью.

Поставщики предложили нам идею о том, что трассировка снижает MTTR и MTTD, но это не так из-за ограничений выборки трассировки.

Подобный текст часто можно встретить в бумагах продавцов:

Если клиент сообщает, что какая-то функция в приложении работает медленно или не работает, группа поддержки может просмотреть распределенные трассировки, чтобы определить, является ли это проблемой серверной части. Затем инженеры могут проанализировать следы, созданные затронутой службой, чтобы быстро устранить проблему.

Что ж, часто умалчивается о том, что распределенная трассировка не может быть панацеей от всех типов сбоев. Давайте уже договоримся, что нам не избежать выборки трасс, и до вендора доходит лишь меньшая часть данных. Что бы это значило? Это означает, что отслеживание становится менее эффективным для:

* поиск конкретных проблем клиента

* выявление редких проблем, которые трудно выявить

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

Как этого избежать?

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

Автоматическое инструментирование не всегда является автоматическим

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

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

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

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

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

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

Самый большой провал распределенной трассировки: обязательства и культура

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

Более того, нет никакой гарантии, что проект будет успешным и что все усилия приведут к улучшению MTTR и MTTD.

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

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

Заключение

Распределенный проект — это чрезвычайно огромный и сложный ИТ-проект, который должен выполняться на организационном уровне. Здесь возникает множество ошибок и соображений, и даже если вы настроены скептически, основываясь на моем опыте, очень важно помнить об этих моментах.