Применение АппОптима / Сервисы / Распределенная трассировка по технологии PurePath® /
Адаптивное управление и контроль трафика
Ключевой особенностью АппОптима является возможность распределенной трассировки PurePath® . Одна распределенная трассировка PurePath представляет собой полную сквозную распределенную трассировку.
В отличие от других технологий трассировки распределенные трассировки в АппОптима автоматически перехватываются ЕдинымАгентом. В дополнение к трассировкам на уровне служб и времени отклика распределенные трассировки также обеспечивают глубокую аналитику на уровне кода, что позволяет проводить анализ горячих точек методов, атрибутов запросов, запросов и баз данных, а также подробный анализ ошибок.
Все это предоставляется автоматически, без дополнительной настройки, с распределенной трассировкой АппОптима. Трассировка на основе технологии PurePath также является одним из основных компонентов, позволяющих Davis®, АппОптима AI, выполнять автоматическое базовое определение и анализ первопричин. В поддержку этого распределенная трассировка АппОптима обеспечивает высочайший уровень детализации и точности данных на рынке.
Высокоточная распределенная трассировка АппОптима
ЕдиныйАгент АппОптима отслеживает каждую распределенную транзакцию от начала до конца. ЕдиныйАгент фиксирует большее количество распределенных трассировок, чем любая другая технология трассировки на рынке. При стандартной настройке каждый агент ЕдиныйАгент АппОптима ежеминутно фиксирует определенное количество новых сквозных распределенных трассировок в рамках каждого отслеживаемого процесса. Каждая сквозная распределенная трассировка содержит информацию на уровне кода и бизнес-аналитику. Распределенная трассировка может содержать множество вызовов службы на множество уровней. Благодаря полному сквозному захвату для каждой трассировки уровни второго и третьего уровней часто фиксируют больше общих вызовов службы, чем процессы точки входа.
Благодаря высокой точности отслеживания АппОптима в большинстве случаев фиксирует каждую распределенную транзакцию. В частности, при больших объемах обращений уровни с одной точкой входа могут обрабатывать больше запросов, чем это. Постоянный захват всех трассировок в таких ситуациях может привести к увеличению требований к пропускной способности сети. Для этого АппОптима ЕдиныйАгент предоставляет встроенный ограничитель. Каждому контролируемому ЕдиномуАгенту процессу разрешается запускать заданное количество распределенных трассировок в минуту. Этот лимит можно назвать квотой.
Как только квота распределенных трассировок достигнута, ЕдиныйАгент применяет интеллектуальный механизм, который максимально эффективно использует отслеживаемый трафик. Такой подход называется «адаптивное управление трафиком».
Адаптивное управление трафиком версии 1 и версии 2
АппОптима On-Premise
В версии 1 адаптивного управления трафиком каждому процессу разрешено запускать фиксированное количество 1000 новых распределенных трассировок в минуту. Эта версия в настоящее время используется по умолчанию и активна для большинства управляемых кластеров АппОптима . Это хорошо работает, но имеет недостаток. Если в вашей архитектуре есть точка входа с большим объемом (например, балансировщик нагрузки или NGINX), которая превышает это значение, ваш трафик будет ограничен там. Кроме того, такое поведение также приводит к отправке трафика в АппОптима, который может реагировать резко в зависимости от трафика вашего приложения. Данный параметр возможно корректировать как для всего окружения, так и для отдельного процесса.
Адаптивное управление трафиком на ЕдиномАгенте АппОптима
Адаптивное управление трафиком гарантирует, что каждый ЕдиныйАгент регистрирует минимальное количество новых распределенных трассировок каждую минуту, тем самым ограничивая объем отправляемых данных. В то же время он гарантирует, что все важные трассировки будут полностью зафиксированы и что для более частых, но менее важных запросов поддерживается статистически достоверный набор трассировок.
Для этого ЕдиныйАгент вычисляет список самых популярных запросов, которые запускаются каждую минуту. Типичные приложения не имеют равномерного распределения запросов. Скорее, есть несколько типов запросов, которые составляют большую часть трафика (например, запросы изображений или проверки статуса), среднее количество важных запросов и большое количество уникальных URL-адресов. Основываясь на списке самых популярных запросов, ЕдиныйАгент захватывает трафик таким образом, что запросы с наибольшим объемом захватываются реже (тем самым избегая захвата «большего количества одинаковых»), в то время как каждый уникальный или редкий запрос захватывается.
В следующей таблице представлен такой пример расчета топ-запросов вместе с соответствующими коэффициентами охвата.
| Запрос | Количество запросов, обработанных приложением | Фактор захвата | Захваченные распределенные трассировки |
|---|---|---|---|
| URI А | 900 | 1/2 | 450 |
| URI Б | 440 | 1/2 | 220 |
| URI С | 250 | 1 | 250 |
| URI Д | 60 | 1 | 60 |
| 50 других URI | 100 | 1 | 100 |
| Общее количество: | 1500 | 1080 |
В этом примере ЕдиныйАгент будет захватывать чуть более 1000 запросов в минуту, так как в данном примере это настроенный целевой номер запроса. URI C, D и 50 других URI захватываются каждый раз, в то время как A и B захватываются только в 50% случаев. Тем не менее, ЕдиныйАгент по-прежнему отслеживает эти запросы от начала до конца более 600 раз в минуту.
Почти во всех случаях вы не заметите такого поведения. АппОптима сохраняет информацию о скорости захвата и соответственно рассчитывает время отклика, пропускную способность и частоту ошибок. Все диаграммы и сервисный анализ показывают экстраполированные данные, основанные на исходной частоте захвата. АппОптима AI по-прежнему имеет более чем достаточно данных (больше, чем любое другое решение APM), чтобы предоставить вам полезную информацию и подробный анализ основных причин обнаруженных проблем. Вы можете увидеть это поведение, если посмотрите на отдельную распределенную трассировку в списке распределенных трассировок, где указано ещё 3 таких. Это указывает на то, что запрос был перехвачен один раз, в то время как было еще три таких же запроса, которые были обработаны отслеживаемым приложением, но не были включены в анализ.
При таком подходе адаптивное управление трафиком значительно экономит полосу пропускания сети, а в случае АппОптима — драгоценные ресурсы ЦП, памяти, сети и хранилища, которые в противном случае потребовались бы для обработки и хранения этих данных.
Мониторинг адаптивного управления трафиком
АппОптима версии 1.232+
Для отслеживания фактического использования и пороговых значений адаптивного управления трафиком АппОптима предоставляет специальные показатели самоконтроля.
Вы можете интегрировать эти показатели самоконтроля в свою собственную настраиваемую панель мониторинга или создать специальную панель мониторинга, подобную той, что показана ниже, для отображения исторической и текущей скорости захвата.
Необходимые метрические выражения, используемые для построения этой информационной панели, перечислены ниже:
| Значение | Выражение метрики |
|---|---|
| Вызовы с полным обслуживанием, полученные кластером | dsfm:server.service_calls.received:splitBy():sum:auto:rate(1m)
|
| Вызовы с полным обслуживанием обрабатываются ЕдинымАгентом | dsfm:oneagent.service_calls.processed:splitBy():sum:auto:rate(1m)
|
| Максимально допустимый полный сервисный вызов / мин | dsfm:server.service_calls.maximum_allowed_per_minute:splitBy():avg:auto:auto
|
| Скорость захвата ЕдиныvАгентом | (dsfm:server.service_calls.received:splitBy():sum:auto)/(dsfm:oneagent.service_calls.processed:splitBy():sum:auto)*(100)
|
Это используемые показатели
| Метрика самоконтроля | Описание |
|---|---|
dsfm:oneagent.service_calls.processed
|
Количество вызовов с полным обслуживанием, обработанных ЕдинымАгентом. |
dsfm:server.service_calls.received
|
Количество вызовов с полным обслуживанием, полученных кластером АппОптима. |
dsfm:server.service_calls.maximum_allowed_per_minute
|
Максимально допустимое количество вызовов с полным обслуживанием в минуту в зависимости от вашей лицензии. |
Адаптивное снижение нагрузки в АппОптима
Благодаря простоте развертывания ЕдиногоАгента инструментирование новых приложений, хостов или даже больших дополнительных сред не составляет труда. Клиенты часто подключают к АппОптима сотни хостов и приложений в день. Это, конечно, значительно увеличивает количество распределенных трассировок, которые обрабатываются кластером АппОптима.
Иногда первоначальные соображения по размеру управляемых узлов и кластеров АппОптима недостаточны для поддержки такого объема; кластеру, управляемому АппОптима, может не хватать необходимого оборудования для обработки всех дополнительных входящих данных. Чтобы защитить работоспособность и целостность вашей среды мониторинга в таких ситуациях, АппОптима использует адаптивное снижение нагрузки на входящие трассировки, чтобы гарантировать, что мониторинг остается стабильным, пока для анализа собирается статистически достоверный набор запросов.
Каждый управляемый хост АппОптима может обрабатывать определенное количество вызовов службы в минуту (распределенная трассировка состоит из множества вызовов службы). Количество вызовов, которые могут быть обработаны, зависит от количества процессоров и объема памяти, доступной хосту. Как только этот предел нарушается, включается адаптивное снижение нагрузки.
Новые распределенные трассировки, поступающие из сред с самым высоким трафиком по отношению к назначенным им хост-устройствам (т. е. трафик/хост-модуль), сначала обрабатываются для снижения нагрузки. В этих средах АппОптима пропускает полную обработку распределенной трассировки. Это происходит случайным образом и уменьшает количество распределенных трассировок, которые обрабатываются поэтапно. В то же время сохраняется статистическая достоверность всех метрик, диаграмм, базовых показателей и событий, поскольку АппОптима знает количество пропущенных распределенных трассировок. Это полностью прозрачно для вас, поскольку АппОптима создает событие и отображает сообщение в пользовательском интерфейсе кластера.
Как и в случае с управлением трафиком ЕдинымАгентом, сокращение объема обрабатываемых данных учитывается прозрачным образом. Это успешно защитит ваш кластер от всплесков трафика. Если такие ситуации единичны, тот факт, что не все данные обрабатываются, не оказывает негативного влияния на ваш мониторинг. АппОптима AI никак не затрагивается и не выдает предупреждения. Все данные диаграмм на основе сервисов прозрачно корректируются (без видимых изменений), и это учитывается во всех аналитических представлениях. Вы не увидите разницы в диаграммах или данных анализа вызовов службы, если вы не смотрите на один PurePath. Единственное место, где это видно, — это список распределенных трассировок, в котором отображается сообщение типа x more like this.
Целевыми являются только те среды, которые имеют большой объем трафика по сравнению с назначенными им хостами. Все остальные среды остаются незатронутыми.
Если адаптивное снижение нагрузки задействуется только время от времени, чтобы покрыть пики, все, что вам нужно знать, это то, что это не должно быть долгосрочным решением. Хотя адаптивное управление трафиком ЕдиныйАгент активно формирует трафик, описанная здесь функция существует только в качестве защиты. Например, спорадический инцидент ALR, который происходит раз в неделю в течение 15 минут, не обязательно означает, что кластер перегружен. Это может быть вызвано необычным скачком нагрузки или временным сбоем в сети.
Если адаптивное снижение нагрузки используется на постоянной основе в течение более длительных периодов (более 15 минут) и особенно в ситуациях, когда ALR активен все время, тот факт, что не все данные обрабатываются, может подорвать ваш мониторинг, метрики и общие данные. качественный. Чтобы предотвратить такой сценарий, вам нужно выбрать один из двух доступных вариантов. Вы можете добавить дополнительное оборудование и новый узел кластера АппОптима.предоставить вашему управляемому кластеру АппОптима необходимые ресурсы для обработки дополнительных данных. Или вы можете уменьшить входящий трафик, настроив параметры управления трафиком для ЕдиныхАгентов среды. Вы также можете рассмотреть эти варианты в адаптивном управлении трафиком, когда вам недостаточно статистической корректности сбора данных и вам нужна более высокая точность данных.
Адаптивное управление захватом
В АппОптима вы можете определить целевое количество недавно отслеживаемых распределенных трассировок точек входа, захватываемых на процесс в минуту.
По умолчанию число вновь отслеживаемых распределенных трассировок точек входа, захваченных на процесс в минуту, составляет 1000, что уже является большим числом. Изменение этого параметра может быть полезно в некоторых ситуациях. У вас может быть среда нагрузочного тестирования, которая потребляет слишком много сетевых, дисковых и ЦП ресурсов в вашем управляемом кластере АппОптима, и вы предпочитаете использовать эту среду для производственного мониторинга. Вы можете уменьшить точность распределенной трассировки среды и, таким образом, уменьшить процент отслеживаемого входящего трафика. Другими словами, тесты могут обеспечить достаточную степень детализации данных даже после сокращения количества трасс до 500 или 100 в минуту.
Уменьшая количество захваченных распределенных трассировок, вы не меняете ни метрики, ни функции анализа службы. За пределами самого списка распределенных трасс это изменение учитывается прозрачным образом и учитывается во всех анализах.
В качестве альтернативы вы можете увеличить количество распределенных трассировок точек входа, захватываемых на процесс в минуту в наиболее важных средах, чтобы получить еще более высокую точность, чем по умолчанию. Верхний предел составляет 100 000 новых сквозных запросов/процессов/мин. Это эффективно указывает ЕдиномуАгенту захватывать все запросы. Это полезно, когда вам нужно обеспечить захват даже редких запросов в средах с большим объемом.
Будьте осторожны, устанавливая это значение слишком высоким, так как это может привести к тому, что ваш управляемый кластер АппОптима окажется в ситуации нехватки ресурсов и вынудит вас добавить дополнительное оборудование. Вы можете использовать этот параметр, чтобы эффективно обеспечить захват каждой отдельной транзакции за счет увеличения затрат на оборудование.
Адаптивное управление захватом для групп процессов
В определенных ситуациях может потребоваться уменьшить количество распределенных трассировок, захваченных для определенных процессов или групп процессов. Чтобы приспособиться к этому, вы можете уменьшить количество захваченных транзакций для конкретной среды для определенных групп процессов.
Перейдите в « Настройки » > « Мониторинг службы на стороне сервера» > « Глубокий мониторинг» .
Как видите, эта функция дополнительно позволяет администратору среды сократить количество распределенных трассировок во всей среде. Это полезно для уменьшения объема сетевого трафика, создаваемого ЕдинымиАгентами во всей среде.
Базовые лимиты и их значения.
Для обеспечения корректной работы кластера в системе имеется ряд показателей, предназначенных для предотвращения перегрузки кластера АппОптима. В таблице ниже вы сможете найти данные показатели в разбивке по типам сущностей.
Приложения
| Название параметра | Значения |
|---|---|
| Количество Ключевых действий | 100(приложение), 500 (окружение) |
| Количества действий в минуту | 1000 |
Сервисы
| Название параметра | Значение |
|---|---|
| Количество трассировок в минуту на процесс | 1000 |
| Расчетные метрики (метрики сервисов) - количество размерностей | 100 |
| Количество ключевых запросов | 100(сервис), 500 (окружение) |
Расширения
| Показатель | Описание | Значение |
|---|---|---|
| Группы | Количество групп устройств, создаваемых в минуту для каждой конечной точки | 500 |
| Ограничение свойств группы | Максимальное количество пользовательских свойств, сообщаемых для каждой группы процессов, пользовательской группы устройств | 20 |
| Устройства | Количество устройств, создаваемых в минуту на конечную точку | 5000 |
| Ограничение свойств | Максимальное количество пользовательских свойств, сообщаемых для каждого узла, экземпляра группы процессов, пользовательского устройства | 20 |
| Длина значения свойства | Длина строки значения пользовательского свойства | 200 |
| Длина ключа свойства | Длина строки пользовательского ключа свойства | 100 |
| Ограничение на измерения | Количество показателей, включая измерения, в минуту на конечную точку | 100 000 |
| Ограничение на события | Количество событий в минуту на конечную точку | 100 |
| Длина заголовка события | Длина строки заголовка события | 1 024 |
| Длина описания события | Длина строки описания события | 10 240 |
| Значения измерений | Количество значений измерения в метрике | 100 |
| Лимит приема метрик гистограммы Prometheus | Максимальное количество поступаемых сегментов метрик гистограммы Prometheus. | 50 |
Делители метрик (dimensions)
| Показатель | Значение | Описание | |
|---|---|---|---|
| Встроенное ограничение размера пула показателей | 10 миллионов
(Это количество будет увеличено до 20 миллионов в версии 1.278+.) |
Все встроенные метрики используют одно и то же пространство кортежей измерений. | |
| Пользовательское ограничение размера пула показателей | 50 миллионов | Все пользовательские метрики используют пространство кортежей измерений (например, Prometheus metrics). | |
| Ограничение размера для каждой метрики | 1 миллион | У каждой метрики есть собственное ограничение на количество кортежей измерений. Это относится ко всем метрикам. |
Метрики OpenTelemetry
| Показатель | Значение | Описание | |
|---|---|---|---|
| Длина ключа метрики, символы | Мин.: 3, Макс.: 255 | Минимальная и максимальная общая длина ключа метрики. Если длина ключа метрики превышает максимальную длину, ключ метрики укорачивается до 255 символов. Если метрический ключ короче 3 символов, метрический ключ дополняется символами подчеркивания, чтобы он соответствовал минимальным требованиям (например, a становится a__).
|
|
| Длина ключа измерения, символы | Минимум: 1, Максимум: 100 | Минимальная и максимальная общая длина ключа измерения. При превышении максимальной длины ключ измерения укорачивается до 100 символов. | |
| Длина значения измерения, символы | 255 | Максимальная общая длина значения измерения. Если максимальная длина превышена, значение измерения сокращается до 255 символов. | |
| Количество измерений в точке данных метрики | 50 | Максимальное общее количество измерений в одной точке данных метрики. Если количество измерений превышено, вся точка данных удаляется. | |
| Общее количество возможных ключей метрик для каждой среды | 20,000 | Максимальное количество ключей метрик, которые могут быть зарегистрированы в АппОптима. | |
| Количество кортежей в месяц для каждой метрики | 1,000,000 | Максимальное количество кортежей (уникальных комбинаций типа ключ-значение измерения метрики) для каждого ключа метрики за последние 30 дней. | |
| Количество кортежей в месяц для всех пользовательских метрик | 50,000,000 | Максимальное количество кортежей (уникальных комбинаций типов ключ-значение метрики-измерения) для всех пользовательских метрик за последние 30 дней. | |
| Единица измерения, символы | 63 | Максимальная общая длина блока прибора. При превышении максимальной длины блок удаляется. | |
| Описание прибора, символы | 1,023 | Максимальная общая длина описания прибора. При превышении максимальной длины описание прибора сокращается до 1023 символов. | |
| Размер запроса | 4 МБ | Максимальный размер запроса OTLP с полезной нагрузкой метрик. При превышении предела весь запрос отбрасывается. |
Часто задаваемые вопросы
Насколько адаптивное управление трафиком влияет на графики, базовые показатели и оповещения?
Короткий ответ: нисколько.
Формирование трафика учитывается прозрачно и выполняется таким образом, чтобы обеспечить статистическую достоверность при захвате редких запросов с высокой вероятностью. На всех диаграммах показано общее реальное количество запросов, обрабатываемых вашим приложением, а также весь специальный анализ, который вы можете выполнить. Это не влияет на АппОптима AI. Единственное место, где видно это формирование трафика, — это список распределенных трассировок, в котором отображается сообщение вроде x more like this.
Почему я не могу найти свой запрос?
Если размер вашего управляемого кластера АппОптима недостаточен или интересующий вас конкретный запрос исходит от уровня с большим объемом (более 1000 запросов в минуту), АппОптима может не зафиксировать запрос. ЕдиныйАгент делает все возможное, чтобы захватить все уникальные запросы, но есть ограничения на то, что можно сделать. Мы продолжим работать над совершенствованием этого механизма. Вы можете уменьшить объем производимого трафика, исключив из захвата неважные запросы; это делается с помощью атрибутов веб-запроса и правил исключения URL-адресов. Такой подход оставляет больше места для важных запросов.
Если это важно для вас, вы также можете увеличить количество захваченных распределенных трассировок в АппОптима.
Что такое полный сервисный вызов?
Полный сервисный вызов — это вызов на стороне сервера, который запускает распределенную трассировку, сервисный вызов на уровне глубокого мониторинга или настраиваемые сервисные вызовы. Внешние вызовы (такие как вызовы базы данных, внешние веб-запросы или вообще любые непрозрачные вызовы службы) не являются вызовами полного обслуживания, поэтому они не учитываются в вашем лимите трафика. АппОптима считает все запросы к службам веб-запросов и веб-служб (кроме внешних), службам RMI, службам обмена сообщениями и пользовательским службам.
Что такое активная хост-единица?
Активные хост-устройства — это хост-устройства, используемые в данный момент и подключенные к среде (а не хост-устройства, назначенные среде).
Каково минимальное количество вызовов полного обслуживания/мин в данной среде?
Минимальное количество вызовов полного обслуживания в минуту в данной среде составляет 5000, что эквивалентно 20 хост-устройствам.
Каково минимальное и максимальное количество следов, которые может создать процесс?
Система автоматически адаптирует ЕдиныйАгент между 50–50 000 трассировок в минуту, чтобы соответствовать общему объему трафика, достигающему системы АппОптима