Catchpoint спонсировал этот пост.
Синтетическая трассировка может стать альтернативой для современных групп наблюдения, помогая им избежать затрат на отслеживание каждого клика. Лучше данные, меньше счета — что может не нравиться?
В современных практиках наблюдения распределенная трассировка стала ставкой на стол. Большинство платформ мониторинга производительности приложений (APM) поддерживают подход «инструментировать все»: разверните SDK или агент, подключайтесь к каждому вызову службы и фиксируйте каждое взаимодействие пользователя в любом масштабе. На бумаге это звучит как полная видимость. На практике это может превратиться в дорогостоящий поток данных с уменьшающейся отдачей. Для сравнения: если у вас уровень отказов 0,1%, вы все равно собираете 99,99% данных трассировки и регистрации, которые, скорее всего, никогда не будете использовать.
Honeycomb приводит убедительный аргумент: «Каждый новый хост, модуль, узел или сервис увеличивает счет за APM… Поскольку они используют пользовательские метрики, индексируют данные в дополнительных форматах, таких как трассировки и журналы, а также распределяют доступ к местам, покупатели сталкиваются с компромиссом между затратами и видимостью. Команды либо переплачивают за возможность наблюдения, либо жертвуют прозрачностью ради контроля затрат».
Введите синтетическую трассировку — целенаправленный упреждающий подход, который переворачивает модель с ног на голову. Вместо отслеживания каждого реального запроса пользователя синтетическая трассировка выполняет контролируемые непрерывные тестовые транзакции, которые отражают реальные действия пользователей. Эти синтетические транзакции можно отслеживать сквозным образом по всему распределенному стеку. Результат: снижение затрат, более чистые данные и более быстрое обнаружение значимых проблем.
Давайте разберемся, почему синтетическая трассировка заслуживает серьезного рассмотрения, особенно учитывая, что затраты на наблюдаемость и разрастание данных продолжают расти.
Что такое синтетическая трассировка в APM?
Синтетическая трассировка — это практика создания контролируемых транзакций по сценарию для вашего приложения, а затем инструментирование этих тестовых взаимодействий с помощью распределенной трассировки. Это все равно, что отправить робота для тестирования вашего приложения, прежде чем его начнут использовать реальные люди. Этот робот выполняет ряд шагов, таких как вход в систему и осуществление платежа, чтобы убедиться, что все работает как положено. Вместо того, чтобы ждать, пока реальные пользователи инициируют промежуток или транзакцию, синтетические запросы позволяют обнаружить проблемы на ранней стадии, подобно канарейке, используемой для предупреждения майнеров об опасном воздухе.
Например, вы можете настроить синтетическую трассировку для:
- Войдите в приложение с тестовой учетной записью.
- Выполните серию вызовов API (поиск, оформление заказа, оплата), которые представляют собой критический пользовательский поток.
- По мере распространения синтетического запроса захват охватывает службы, базы данных, кэши и внешние зависимости.
Чем синтетическая трассировка отличается от трассировки реальных пользователей
Ключевым отличием от отслеживания реальных пользователей является контроль:
- Последовательность: одна и та же транзакция выполняется повторно с заданным вами интервалом из одного и того же места, даже если пользователи неактивны. При традиционной распределенной трассировке данные часто загрязняются большим количеством ботов, которые добавляют шум и потенциально маскируют реальные проблемы.
- Предсказуемость: Поскольку тестовые входные данные фиксированы, любые изменения в выходных данных трассировки указывают на настоящие изменения или деградацию системы.
- Полнота: каждый синтетический запрос гарантированно проходит через весь интернет-стек в соответствии со сценарием, каждый раз предоставляя вам сквозную трассировку этого пути.
Слои интернет-стека
Для групп по проектированию надежности сайтов (SRE)/DevOps это означает, что вы можете определить базовую производительность критически важных рабочих процессов, выявить узкие места и активно проверять исправления, не дожидаясь, пока пользователь первым наткнется на проблему. При необходимости вы всегда можете добавить такие инструменты, как OpenTelemetry, для регистрации всех ошибок, в том числе ошибок реальных пользователей и/или образцов.
Подход «Отслеживать все»: полезно, но дорого
Традиционная трассировка APM опирается на SDK или агенты для захвата каждого запроса, проходящего через ваше приложение. Каждый вызов API, каждый запрос к базе данных, каждый переход между службами фиксируется и отправляется на агрегацию. Как заявляет Мезмо, «большинство команд постоянно фиксируют все, что приводит к образованию дорогостоящих, огромных и зачастую ненужных объемов данных». Хотя это обеспечивает огромные объемы данных, это также создает несколько проблем:
- Взрыв стоимости: Больше данных означает более высокие затраты на хранение и обработку. Многие команды в конечном итоге сталкиваются с неожиданным перерасходом ресурсов, поскольку объемы трассировки и журналов превышают прогнозы.
- Шум против сигнала: При перехвате каждого запроса значимые аномалии могут быть погребены под горой здоровых транзакций.
- Пороги оповещения: Чтобы не утонуть в оповещениях, APM обычно требуют пороговые значения отказа (X% неудачных запросов), прежде чем инициировать инцидент. Это означает, что проблема уже затрагивает нескольких пользователей еще до того, как вы узнаете о ее существовании.
- Реактивная поза: вы всегда ждете, пока реальный пользователь столкнется с проблемой, прежде чем она появится в ваших трассировках.
Инвестиции могут быть приемлемыми для некоторых приложений уровня 1, где каждая транзакция критически важна, или для новых выпусков в циклах контроля качества, но для приложений уровня 2 и уровня 3 окупаемость инвестиций становится сомнительной. Хуже того, философия «чем больше данных, тем лучше» часто приводит к обратным результатам, перегружая как бюджеты, так и команды.
Кроме того, объем данных создает иллюзию, что ответ должен быть где-то в стоге сена из логов, событий и трассировок. Однако «слепые зоны» все еще существуют: значительная часть стека современных распределенных сервис-зависимых приложений остается неотслеживаемой. Чтобы смягчить это, часто используют удаление журналов этих служб, но часто этого недостаточно, потому что, когда эти службы не работают или работают неправильно; в журналах, которые они предоставляют, нет ничего полезного.
Синтетическое отслеживание: контролируемое, непрерывное, экономичное
Синтетическая трассировка идет по другому пути. Вместо того, чтобы фиксировать все взаимодействия с пользователем, вы сами контролируете, когда и как происходит отслеживание:
- Настраиваемая частота: вы сами решаете, как часто будут выполняться синтетические транзакции (каждую минуту, каждые пять минут и т. д.). Каденция уравновешивает видимость и стоимость, она полностью предсказуема и находится под контролем с точки зрения затрат.
- Немедленные оповещения: поскольку каждый синтетический запуск представляет собой контролируемый тест, любой сбой или ухудшение качества может немедленно вызвать предупреждение. Нет необходимости достигать порога неудачных взаимодействий с реальными пользователями. В случае сомнений можно вызвать мгновенную проверку, чтобы подтвердить неисправность за считанные секунды.
- Проактивный мониторинг: Синтетические тесты выполняются непрерывно, даже если ни один пользователь не активен. Это означает, что вы можете обнаружить сбои или сбои в работе в нерабочее время до того, как с ними столкнутся клиенты. Это также означает, что вы можете заранее тестировать крайние случаи и пути взаимодействия пользователей, которые менее распространены, но все же важны. Не нужно ждать, пока пользователи столкнутся с проблемой.
- Более чистые данные: каждая трасса соответствует известному тестовому примеру, что исключает шум. Устранение неполадок становится проще, поскольку вы точно знаете, что было проверено, когда и при каких условиях.
- Реальный контекст: Поскольку синтетическая трассировка является частью мониторинга производительности Интернета (IPM), тесты можно запускать с тысяч точек обзора по всему миру: последней мили, беспроводной сети, магистральной сети и облачных локаций, которые отражают реальные условия пользователей. Он также обеспечивает видимость не только серверной части вашего приложения, но и реального контекста производительности: DNS, сетей, CDN, интернет-провайдеров, глобальных сетей, облачных сервисов, сторонних зависимостей, API и всего, что между ними.
- Корпоративные агенты: у вас есть возможность развернуть в своей инфраструктуре агентов, которые могут свободно работать за брандмауэром и осуществлять мониторинг с большей частотой при очень низких затратах.
Синтетическая трассировка обеспечивает такую же подробную видимость и карты трассировки, как и традиционная трассировка, поэтому вы можете отслеживать сбои и производительность всей системы, не упуская при этом полезную информацию.
Почему это важно для многоуровневых приложений
Для критически важных бизнес-систем уровня 1 полная распределенная трассировка может оставаться непреложным требованием. Но многие организации обнаруживают, что синтетической трассировки более чем достаточно для приложений уровня 2 и уровня 3, где:
- Влияние отдельной транзакции на бизнес ниже.
- Объем запросов делает отслеживание всего происходящего непомерно дорогим.
- Необходимо, прежде всего, проактивное обеспечение, а не судебно-медицинское повторение каждого действия пользователя.
Со временем даже приложения уровня 1 смогут получить выгоду от гибридного подхода: используйте синтетическую трассировку для непрерывной проверки базовой производительности и доступности, сохраняя при этом полную трассировку APM для ценных транзакций или сложных расследований инцидентов.
Для некоторых организаций синтетическое отслеживание может быть правильным подходом. Особенно если учесть стоимость операций компании-разработчика программного обеспечения, где 10% себестоимости реализованной продукции (COGS) приходится на инфраструктуру и 5% на персонал, а тратить 5% на мониторинг может быть неприемлемо. Мониторинг не должен составлять более 1–2 % дохода от продукта; в противном случае компании будет трудно поддерживать операционную рентабельность.
Почему более качественные данные важнее большего количества данных
Мантра отрасли уже давно гласит: «Больше данных — больше видимости». Синтетическая трассировка бросает вызов этому предположению. На самом деле, чем лучше данные, тем лучше.
Целевые трассировки фиксируют правильный контекст в нужное время. Контролируемые условия тестирования исключают изменчивость и догадки, а, что крайне важно, глобальные точки обзора гарантируют, что вы поймете не только то, что выполнял сервер, но и как это почувствовал конечный пользователь в Сан-Паулу, Сингапуре или Сан-Франциско.
Мониторинг исключительно из сред гипермасштабирования упускает важные реальные переменные, такие как перегрузка последней мили, маршрутизация интернет-провайдера, NAT операторского уровня, разрешение локального DNS и жизнеспособность периферии/кэша. Это не теоретические пробелы; они оказывают существенное влияние на то, как пользователи ежедневно взаимодействуют с приложениями.
Такая точность означает, что команды тратят меньше времени на анализ зашумленных данных трассировки и больше времени на решение реальных проблем.
Синтетическая трассировка не заменит APM повсюду, да и не должна. Но для организаций, страдающих от затрат на наблюдение и усталости от оповещений, он предлагает мощное дополнение — и во многих случаях более разумный и устойчивый путь вперед.
Иногда меньше на самом деле значит больше. Или, скорее: лучше, значит лучше.
Современный цифровой мир требует устойчивости и исключительной производительности. Цифровые предприятия обращаются к платформе и опыту Catchpoint IPM, чтобы активно выявлять и решать проблемы в Интернет-стеке до того, как они повлияют на клиентов или сотрудников. Интернет полагается на Catchpoint. Узнайте больше Последние новости от Catchpoint. ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Херардо Дада — директор по маркетингу и главный технический директор в Catchpoint. Он опытный технолог с более чем 20-летним опытом работы в области цифровых стратегий и веб-технологий и был в центре Интернета,… Читать далее от Херардо Дада
