Адаптивное управление и контроль трафика: различия между версиями
ENetrebin (обсуждение | вклад) |
Lobanov (обсуждение | вклад) |
||
(не показаны 2 промежуточные версии 2 участников) | |||
Строка 1: | Строка 1: | ||
'''''[[Применение Ключ-АСТРОМ|Применение Dynatrace]] / [https://doc.ruscomtech.ru/index.php/%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5_%D0%9A%D0%BB%D1%8E%D1%87-%D0%90%D0%A1%D0%A2%D0%A0%D0%9E%D0%9C#.D0.A1.D0.B5.D1.80.D0.B2.D0.B8.D1.81.D1.8B Сервисы] / Распределенная трассировка по технологии PurePath® /''''' | |||
'''''Адаптивное управление и контроль трафика''''' | |||
Ключевой особенностью Dynatrace является возможность распределенной трассировки PurePath® . Одна распределенная трассировка PurePath представляет собой полную сквозную распределенную трассировку. | |||
В отличие от других технологий трассировки распределенные трассировки в Dynatrace автоматически перехватываются OneAgent. В дополнение к трассировкам на уровне служб и времени отклика распределенные трассировки также обеспечивают глубокую аналитику на уровне кода, что позволяет проводить анализ горячих точек методов, атрибутов запросов, запросов и баз данных, а также подробный анализ ошибок. | |||
Все это предоставляется автоматически, без дополнительной настройки, с распределенной трассировкой Dynatrace. Трассировка на основе технологии PurePath также является одним из основных компонентов, позволяющих Davis®, Dynatrace AI, выполнять автоматическое базовое определение и анализ первопричин. В поддержку этого распределенная трассировка Dynatrace обеспечивает высочайший уровень детализации и точности данных на рынке. | |||
== Высокоточная распределенная трассировка Dynatrace == | |||
Dynatrace OneAgent отслеживает каждую распределенную транзакцию от начала до конца. OneAgent фиксирует большее количество распределенных трассировок, чем любая другая технология трассировки на рынке. При стандартной настройке каждый агент Dynatrace OneAgent ежеминутно фиксирует определенное количество новых сквозных распределенных трассировок в рамках каждого отслеживаемого процесса. Каждая сквозная распределенная трассировка содержит информацию на уровне кода и бизнес-аналитику. Распределенная трассировка может содержать множество вызовов службы на множество уровней. Благодаря полному сквозному захвату для каждой трассировки уровни второго и третьего уровней часто фиксируют больше общих вызовов службы, чем процессы точки входа. | |||
Как только квота распределенных трассировок достигнута, | Благодаря высокой точности отслеживания Dynatrace в большинстве случаев фиксирует каждую распределенную транзакцию. В частности, при больших объемах обращений уровни с одной точкой входа могут обрабатывать больше запросов, чем это. Постоянный захват всех трассировок в таких ситуациях может привести к увеличению требований к пропускной способности сети. Для этого Dynatrace OneAgent предоставляет встроенный ограничитель. Каждому контролируемому OneAgent процессу разрешается запускать заданное количество распределенных трассировок в минуту. Этот лимит можно назвать квотой. | ||
[[Файл:Oneagent-adaptive-traffic-management-pipe-748-5b04a011d8.png|центр|мини|574x574пкс]] | |||
Как только квота распределенных трассировок достигнута, OneAgent применяет интеллектуальный механизм, который максимально эффективно использует отслеживаемый трафик. Такой подход называется «адаптивное управление трафиком». | |||
== SaaS vs Managed — адаптивное управление трафиком версии 1 и версии 2 == | == SaaS vs Managed — адаптивное управление трафиком версии 1 и версии 2 == | ||
=== Версия 1 — | === Версия 1 — Dynatrace Managed === | ||
В версии 1 адаптивного управления трафиком каждому процессу разрешено запускать фиксированное количество 1000 новых распределенных трассировок в минуту. Эта версия в настоящее время используется по умолчанию и активна для большинства управляемых кластеров | В версии 1 адаптивного управления трафиком каждому процессу разрешено запускать фиксированное количество 1000 новых распределенных трассировок в минуту. Эта версия в настоящее время используется по умолчанию и активна для большинства управляемых кластеров Dynatrace . Это хорошо работает, но имеет недостаток. Если в вашей архитектуре есть точка входа с большим объемом (например, балансировщик нагрузки или NGINX), которая превышает это значение, ваш трафик будет ограничен там. Кроме того, такое поведение также приводит к отправке трафика в Dynatrace, который может реагировать резко в зависимости от трафика вашего приложения. | ||
=== Версия 2 — | === Версия 2 — Dynatrace SaaS === | ||
В версии 2 адаптивного управления трафиком ограничение каждого процесса автоматически адаптируется и настраивается таким образом, что общий допустимый объем вызовов службы в минуту отправляется в | В версии 2 адаптивного управления трафиком ограничение каждого процесса автоматически адаптируется и настраивается таким образом, что общий допустимый объем вызовов службы в минуту отправляется в Dynatrace независимо от архитектуры вашего приложения. | ||
* Допустимый объем в минуту основан на активно используемых хост-устройствах в данной среде: 250 вызовов полного обслуживания <code>x</code> активных хост-устройств . | * Допустимый объем в минуту основан на активно используемых хост-устройствах в данной среде: 250 вызовов полного обслуживания <code>x</code> активных хост-устройств . | ||
Строка 29: | Строка 33: | ||
Преимущества этой системы: | Преимущества этой системы: | ||
* Точки входа с большим объемом могут отправлять больше трассировок, поскольку управление трафиком осуществляется на основе общего объема, отправляемого в среду | * Точки входа с большим объемом могут отправлять больше трассировок, поскольку управление трафиком осуществляется на основе общего объема, отправляемого в среду Dynatrace. | ||
* Приложения с малым объемом делят неиспользуемый объем транзакций с приложениями с большим объемом, которым он необходим. | * Приложения с малым объемом делят неиспользуемый объем транзакций с приложениями с большим объемом, которым он необходим. | ||
* Хосты инфраструктуры не отправляют трассировки, но увеличивают общий допустимый объем. | * Хосты инфраструктуры не отправляют трассировки, но увеличивают общий допустимый объем. | ||
* Сетевой трафик, отправляемый в | * Сетевой трафик, отправляемый в Dynatrace, менее скачкообразный, так как трафик управляется на основе общего объема. | ||
Эта версия в настоящее время активна во всех средах | Эта версия в настоящее время активна во всех средах Dynatrace SaaS . | ||
== Адаптивное управление трафиком на | == Адаптивное управление трафиком на Dynatrace OneAgent == | ||
Адаптивное управление трафиком гарантирует, что каждый | Адаптивное управление трафиком гарантирует, что каждый OneAgent регистрирует минимальное количество новых распределенных трассировок каждую минуту, тем самым ограничивая объем отправляемых данных. В то же время он гарантирует, что все важные трассировки будут полностью зафиксированы и что для более частых, но менее важных запросов поддерживается статистически достоверный набор трассировок. | ||
Для этого | Для этого OneAgent вычисляет список самых популярных запросов, которые запускаются каждую минуту. Типичные приложения не имеют равномерного распределения запросов. Скорее, есть несколько типов запросов, которые составляют большую часть трафика (например, запросы изображений или проверки статуса), среднее количество важных запросов и большое количество уникальных URL-адресов. Основываясь на списке самых популярных запросов, OneAgent захватывает трафик таким образом, что запросы с наибольшим объемом захватываются реже (тем самым избегая захвата «большего количества одинаковых»), в то время как каждый уникальный или редкий запрос захватывается. | ||
В следующей таблице представлен такой пример расчета топ-запросов вместе с соответствующими коэффициентами охвата. | В следующей таблице представлен такой пример расчета топ-запросов вместе с соответствующими коэффициентами охвата. | ||
Строка 83: | Строка 87: | ||
|1080 | |1080 | ||
|} | |} | ||
В этом примере | В этом примере OneAgent будет захватывать чуть более 1000 запросов в минуту, так как в данном примере это настроенный целевой номер запроса. URI C, D и 50 других URI захватываются каждый раз, в то время как A и B захватываются только в 50% случаев. Тем не менее, OneAgent по-прежнему отслеживает эти запросы от начала до конца более 600 раз в минуту. | ||
Почти во всех случаях вы не заметите такого поведения. | Почти во всех случаях вы не заметите такого поведения. Dynatrace сохраняет информацию о скорости захвата и соответственно рассчитывает время отклика, пропускную способность и частоту ошибок. Все диаграммы и сервисный анализ показывают экстраполированные данные, основанные на исходной частоте захвата. Dynatrace AI по-прежнему имеет более чем достаточно данных (больше, чем любое другое решение APM), чтобы предоставить вам полезную информацию и подробный анализ основных причин обнаруженных проблем. Вы можете увидеть это поведение, если посмотрите на отдельную распределенную трассировку в списке распределенных трассировок, где указано <code>3 more like this</code>. Это указывает на то, что запрос был перехвачен один раз, в то время как было еще три таких же запроса, которые были обработаны отслеживаемым приложением, но не были включены в анализ. | ||
При таком подходе адаптивное управление трафиком значительно экономит полосу пропускания сети, а в случае | При таком подходе адаптивное управление трафиком значительно экономит полосу пропускания сети, а в случае Dynatrace Managed — драгоценные ресурсы ЦП, памяти, сети и хранилища, которые в противном случае потребовались бы для обработки и хранения этих данных. | ||
== Мониторинг адаптивного управления трафиком == | == Мониторинг адаптивного управления трафиком == | ||
''' | '''Dynatrace версии 1.232+''' | ||
Для отслеживания фактического использования и пороговых значений адаптивного управления трафиком | Для отслеживания фактического использования и пороговых значений адаптивного управления трафиком Dynatrace предоставляет специальные показатели самоконтроля. | ||
Вы можете интегрировать эти показатели самоконтроля в свою собственную настраиваемую панель мониторинга или создать специальную панель мониторинга, подобную той, что показана ниже, для отображения исторической и текущей скорости захвата. | Вы можете интегрировать эти показатели самоконтроля в свою собственную настраиваемую панель мониторинга или создать специальную панель мониторинга, подобную той, что показана ниже, для отображения исторической и текущей скорости захвата. | ||
Строка 106: | Строка 110: | ||
|<code>dsfm:server.service_calls.received:splitBy():sum:auto:rate(1m)</code> | |<code>dsfm:server.service_calls.received:splitBy():sum:auto:rate(1m)</code> | ||
|- | |- | ||
|Вызовы с полным обслуживанием обрабатываются | |Вызовы с полным обслуживанием обрабатываются OneAgent | ||
|<code>dsfm:oneagent.service_calls.processed:splitBy():sum:auto:rate(1m)</code> | |<code>dsfm:oneagent.service_calls.processed:splitBy():sum:auto:rate(1m)</code> | ||
|- | |- | ||
Строка 112: | Строка 116: | ||
|<code>dsfm:server.service_calls.maximum_allowed_per_minute:splitBy():avg:auto:auto</code> | |<code>dsfm:server.service_calls.maximum_allowed_per_minute:splitBy():avg:auto:auto</code> | ||
|- | |- | ||
|Скорость захвата | |Скорость захвата OneAgent | ||
|<code>(dsfm:server.service_calls.received:splitBy():sum:auto)/</code><code>(dsfm:</code><code>oneagent</code><code>.service_calls.processed:splitBy():sum:auto)*(100)</code> | |<code>(dsfm:server.service_calls.received:splitBy():sum:auto)/</code><code>(dsfm:</code><code>oneagent</code><code>.service_calls.processed:splitBy():sum:auto)*(100)</code> | ||
|} | |} | ||
Строка 121: | Строка 125: | ||
|- | |- | ||
|<code>dsfm:oneagent.service_calls.processed</code> | |<code>dsfm:oneagent.service_calls.processed</code> | ||
|Количество вызовов с полным обслуживанием, обработанных | |Количество вызовов с полным обслуживанием, обработанных OneAgent. | ||
|- | |- | ||
|<code>dsfm:server.service_calls.received</code> | |<code>dsfm:server.service_calls.received</code> | ||
|Количество вызовов с полным обслуживанием, полученных кластером | |Количество вызовов с полным обслуживанием, полученных кластером Dynatrace. | ||
|- | |- | ||
|<code>dsfm:server.service_calls.maximum_allowed_per_minute</code> | |<code>dsfm:server.service_calls.maximum_allowed_per_minute</code> | ||
Строка 130: | Строка 134: | ||
|} | |} | ||
== Адаптивное снижение нагрузки в | == Адаптивное снижение нагрузки в Dynatrace Managed == | ||
Благодаря простоте развертывания | Благодаря простоте развертывания OneAgent инструментирование новых приложений, хостов или даже больших дополнительных сред не составляет труда. Клиенты часто подключают к Dynatrace сотни хостов и приложений в день. Это, конечно, значительно увеличивает количество распределенных трассировок, которые обрабатываются кластером Dynatrace Managed. | ||
Иногда первоначальные соображения по размеру управляемых узлов и кластеров | Иногда первоначальные соображения по размеру управляемых узлов и кластеров Dynatrace недостаточны для поддержки такого объема; кластеру, управляемому Dynatrace, может не хватать необходимого оборудования для обработки всех дополнительных входящих данных. Чтобы защитить работоспособность и целостность вашей среды мониторинга в таких ситуациях, Dynatrace Managed использует адаптивное снижение нагрузки на входящие трассировки, чтобы гарантировать, что мониторинг остается стабильным, пока для анализа собирается статистически достоверный набор запросов. | ||
Каждый управляемый хост | Каждый управляемый хост Dynatrace может обрабатывать определенное количество вызовов службы в минуту (распределенная трассировка состоит из множества вызовов службы). Количество вызовов, которые могут быть обработаны, зависит от количества процессоров и объема памяти, доступной хосту. Как только этот предел нарушается, включается адаптивное снижение нагрузки. | ||
Новые распределенные трассировки, поступающие из сред с самым высоким трафиком по отношению к назначенным им хост-устройствам (т. е. трафик/хост-модуль), сначала обрабатываются для снижения нагрузки. В этих средах | Новые распределенные трассировки, поступающие из сред с самым высоким трафиком по отношению к назначенным им хост-устройствам (т. е. трафик/хост-модуль), сначала обрабатываются для снижения нагрузки. В этих средах Dynatrace Managed пропускает полную обработку распределенной трассировки. Это происходит случайным образом и уменьшает количество распределенных трассировок, которые обрабатываются поэтапно. В то же время сохраняется статистическая достоверность всех метрик, диаграмм, базовых показателей и событий, поскольку Dynatrace знает количество пропущенных распределенных трассировок. Это полностью прозрачно для вас, поскольку Dynatrace создает событие и отображает сообщение в пользовательском интерфейсе кластера. | ||
[[Файл:adap3.png]] | [[Файл:adap3.png]] | ||
Как и в случае с управлением трафиком | Как и в случае с управлением трафиком OneAgent, сокращение объема обрабатываемых данных учитывается прозрачным образом. Это успешно защитит ваш кластер от всплесков трафика. Если такие ситуации единичны, тот факт, что не все данные обрабатываются, не оказывает негативного влияния на ваш мониторинг. Dynatrace AI никак не затрагивается и не выдает предупреждения. Все данные диаграмм на основе сервисов прозрачно корректируются (без видимых изменений), и это учитывается во всех аналитических представлениях. Вы не увидите разницы в диаграммах или данных анализа вызовов службы, если вы не смотрите на один PurePath. Единственное место, где это видно, — это список распределенных трассировок, в котором отображается сообщение типа <code>x more like this</code>. | ||
Целевыми являются только те среды, которые имеют большой объем трафика по сравнению с назначенными им хостами. Все остальные среды остаются незатронутыми. | Целевыми являются только те среды, которые имеют большой объем трафика по сравнению с назначенными им хостами. Все остальные среды остаются незатронутыми. | ||
Если адаптивное снижение нагрузки задействуется только время от времени, чтобы покрыть пики, все, что вам нужно знать, это то, что это не должно быть долгосрочным решением. Хотя адаптивное управление трафиком | Если адаптивное снижение нагрузки задействуется только время от времени, чтобы покрыть пики, все, что вам нужно знать, это то, что это не должно быть долгосрочным решением. Хотя адаптивное управление трафиком OneAgent активно формирует трафик, описанная здесь функция существует только в качестве защиты. Например, спорадический инцидент ALR, который происходит раз в неделю в течение 15 минут, не обязательно означает, что кластер перегружен. Это может быть вызвано необычным скачком нагрузки или временным сбоем в сети. | ||
Если адаптивное снижение нагрузки используется на постоянной основе в течение более длительных периодов (более 15 минут) и особенно в ситуациях, когда ALR активен все время, тот факт, что не все данные обрабатываются, может подорвать ваш мониторинг, метрики и общие данные. качественный. Чтобы предотвратить такой сценарий, вам нужно выбрать один из двух доступных вариантов. Вы можете добавить дополнительное оборудование и новый узел кластера | Если адаптивное снижение нагрузки используется на постоянной основе в течение более длительных периодов (более 15 минут) и особенно в ситуациях, когда ALR активен все время, тот факт, что не все данные обрабатываются, может подорвать ваш мониторинг, метрики и общие данные. качественный. Чтобы предотвратить такой сценарий, вам нужно выбрать один из двух доступных вариантов. Вы можете добавить дополнительное оборудование и новый узел кластера Dynatrace Managed.предоставить вашему управляемому кластеру Dynatrace необходимые ресурсы для обработки дополнительных данных. Или вы можете уменьшить входящий трафик, настроив параметры управления трафиком для OneAgent среды. Вы также можете рассмотреть эти варианты в адаптивном управлении трафиком, когда вам недостаточно статистической корректности сбора данных и вам нужна более высокая точность данных. | ||
== Адаптивное управление захватом == | == Адаптивное управление захватом == | ||
В | В Dynatrace Managed вы можете определить целевое количество недавно отслеживаемых распределенных трассировок точек входа, захватываемых на процесс в минуту. | ||
[[Файл:adap4.png]] | [[Файл:adap4.png]] | ||
По умолчанию число вновь отслеживаемых распределенных трассировок точек входа, захваченных на процесс в минуту, составляет 1000, что уже является большим числом. Изменение этого параметра может быть полезно в некоторых ситуациях. У вас может быть среда нагрузочного тестирования, которая потребляет слишком много сетевых, дисковых и ЦП ресурсов в вашем управляемом кластере | По умолчанию число вновь отслеживаемых распределенных трассировок точек входа, захваченных на процесс в минуту, составляет 1000, что уже является большим числом. Изменение этого параметра может быть полезно в некоторых ситуациях. У вас может быть среда нагрузочного тестирования, которая потребляет слишком много сетевых, дисковых и ЦП ресурсов в вашем управляемом кластере Dynatrace, и вы предпочитаете использовать эту среду для производственного мониторинга. Вы можете уменьшить точность распределенной трассировки среды и, таким образом, уменьшить процент отслеживаемого входящего трафика. Другими словами, тесты могут обеспечить достаточную степень детализации данных даже после сокращения количества трасс до 500 или 100 в минуту. | ||
Уменьшая количество захваченных распределенных трассировок, вы не меняете ни метрики, ни функции анализа службы. За пределами самого списка распределенных трасс это изменение учитывается прозрачным образом и учитывается во всех анализах. | Уменьшая количество захваченных распределенных трассировок, вы не меняете ни метрики, ни функции анализа службы. За пределами самого списка распределенных трасс это изменение учитывается прозрачным образом и учитывается во всех анализах. | ||
В качестве альтернативы вы можете увеличить количество распределенных трассировок точек входа, захватываемых на процесс в минуту в наиболее важных средах, чтобы получить еще более высокую точность, чем по умолчанию. Верхний предел составляет 100 000 новых сквозных запросов/процессов/мин. Это эффективно указывает | В качестве альтернативы вы можете увеличить количество распределенных трассировок точек входа, захватываемых на процесс в минуту в наиболее важных средах, чтобы получить еще более высокую точность, чем по умолчанию. Верхний предел составляет 100 000 новых сквозных запросов/процессов/мин. Это эффективно указывает OneAgent захватывать все запросы. Это полезно, когда вам нужно обеспечить захват даже редких запросов в средах с большим объемом. | ||
Будьте осторожны, устанавливая это значение слишком высоким, так как это может привести к тому, что ваш управляемый кластер | Будьте осторожны, устанавливая это значение слишком высоким, так как это может привести к тому, что ваш управляемый кластер Dynatrace окажется в ситуации нехватки ресурсов и вынудит вас добавить дополнительное оборудование. Вы можете использовать этот параметр, чтобы эффективно обеспечить захват каждой отдельной транзакции за счет увеличения затрат на оборудование. | ||
=== Адаптивное управление захватом для групп процессов === | === Адаптивное управление захватом для групп процессов === | ||
Строка 169: | Строка 173: | ||
[[Файл:adap5.png]] | [[Файл:adap5.png]] | ||
Как видите, эта функция дополнительно позволяет администратору среды сократить количество распределенных трассировок во всей среде. Это полезно для уменьшения объема сетевого трафика, создаваемого | Как видите, эта функция дополнительно позволяет администратору среды сократить количество распределенных трассировок во всей среде. Это полезно для уменьшения объема сетевого трафика, создаваемого OneAgent во всей среде. | ||
== Часто задаваемые вопросы == | == Часто задаваемые вопросы == | ||
Строка 176: | Строка 180: | ||
Короткий ответ: нисколько. | Короткий ответ: нисколько. | ||
Формирование трафика учитывается прозрачно и выполняется таким образом, чтобы обеспечить статистическую достоверность при захвате редких запросов с высокой вероятностью. На всех диаграммах показано общее реальное количество запросов, обрабатываемых вашим приложением, а также весь специальный анализ, который вы можете выполнить. Это не влияет на | Формирование трафика учитывается прозрачно и выполняется таким образом, чтобы обеспечить статистическую достоверность при захвате редких запросов с высокой вероятностью. На всех диаграммах показано общее реальное количество запросов, обрабатываемых вашим приложением, а также весь специальный анализ, который вы можете выполнить. Это не влияет на Dynatrace AI. Единственное место, где видно это формирование трафика, — это список распределенных трассировок, в котором отображается сообщение вроде <code>x more like this</code>. | ||
''Почему я не могу найти свой запрос?'' | ''Почему я не могу найти свой запрос?'' | ||
Если размер вашего управляемого кластера | Если размер вашего управляемого кластера Dynatrace недостаточен или интересующий вас конкретный запрос исходит от уровня с большим объемом (более 1000 запросов в минуту), Dynatrace может не зафиксировать запрос. OneAgent делает все возможное, чтобы захватить все уникальные запросы, но есть ограничения на то, что можно сделать. Мы продолжим работать над совершенствованием этого механизма. Вы можете уменьшить объем производимого трафика, исключив из захвата неважные запросы; это делается с помощью атрибутов веб-запроса и правил исключения URL-адресов. Такой подход оставляет больше места для важных запросов. | ||
Если это важно для вас, вы также можете увеличить количество захваченных распределенных трассировок в | Если это важно для вас, вы также можете увеличить количество захваченных распределенных трассировок в Dynatrace Managed. | ||
''Что такое полный сервисный вызов?'' | ''Что такое полный сервисный вызов?'' | ||
Полный сервисный вызов — это вызов на стороне сервера, который запускает распределенную трассировку, сервисный вызов на уровне глубокого мониторинга или настраиваемые сервисные вызовы. Внешние вызовы (такие как вызовы базы данных, внешние веб-запросы или вообще любые непрозрачные вызовы службы) не являются вызовами полного обслуживания, поэтому они не учитываются в вашем лимите трафика. | Полный сервисный вызов — это вызов на стороне сервера, который запускает распределенную трассировку, сервисный вызов на уровне глубокого мониторинга или настраиваемые сервисные вызовы. Внешние вызовы (такие как вызовы базы данных, внешние веб-запросы или вообще любые непрозрачные вызовы службы) не являются вызовами полного обслуживания, поэтому они не учитываются в вашем лимите трафика. Dynatrace считает все запросы к службам веб-запросов и веб-служб (кроме внешних), службам RMI, службам обмена сообщениями и пользовательским службам. | ||
''Что такое активная хост-единица?'' | ''Что такое активная хост-единица?'' | ||
Строка 198: | Строка 202: | ||
''Каково минимальное и максимальное количество следов, которые может создать процесс?'' | ''Каково минимальное и максимальное количество следов, которые может создать процесс?'' | ||
Система автоматически адаптирует | Система автоматически адаптирует OneAgent между 50–50 000 трассировок в минуту, чтобы соответствовать общему объему трафика, достигающему системы Dynatrace |
Текущая версия на 11:51, 22 января 2023
Применение Dynatrace / Сервисы / Распределенная трассировка по технологии PurePath® /
Адаптивное управление и контроль трафика
Ключевой особенностью Dynatrace является возможность распределенной трассировки PurePath® . Одна распределенная трассировка PurePath представляет собой полную сквозную распределенную трассировку.
В отличие от других технологий трассировки распределенные трассировки в Dynatrace автоматически перехватываются OneAgent. В дополнение к трассировкам на уровне служб и времени отклика распределенные трассировки также обеспечивают глубокую аналитику на уровне кода, что позволяет проводить анализ горячих точек методов, атрибутов запросов, запросов и баз данных, а также подробный анализ ошибок.
Все это предоставляется автоматически, без дополнительной настройки, с распределенной трассировкой Dynatrace. Трассировка на основе технологии PurePath также является одним из основных компонентов, позволяющих Davis®, Dynatrace AI, выполнять автоматическое базовое определение и анализ первопричин. В поддержку этого распределенная трассировка Dynatrace обеспечивает высочайший уровень детализации и точности данных на рынке.
Высокоточная распределенная трассировка Dynatrace
Dynatrace OneAgent отслеживает каждую распределенную транзакцию от начала до конца. OneAgent фиксирует большее количество распределенных трассировок, чем любая другая технология трассировки на рынке. При стандартной настройке каждый агент Dynatrace OneAgent ежеминутно фиксирует определенное количество новых сквозных распределенных трассировок в рамках каждого отслеживаемого процесса. Каждая сквозная распределенная трассировка содержит информацию на уровне кода и бизнес-аналитику. Распределенная трассировка может содержать множество вызовов службы на множество уровней. Благодаря полному сквозному захвату для каждой трассировки уровни второго и третьего уровней часто фиксируют больше общих вызовов службы, чем процессы точки входа.
Благодаря высокой точности отслеживания Dynatrace в большинстве случаев фиксирует каждую распределенную транзакцию. В частности, при больших объемах обращений уровни с одной точкой входа могут обрабатывать больше запросов, чем это. Постоянный захват всех трассировок в таких ситуациях может привести к увеличению требований к пропускной способности сети. Для этого Dynatrace OneAgent предоставляет встроенный ограничитель. Каждому контролируемому OneAgent процессу разрешается запускать заданное количество распределенных трассировок в минуту. Этот лимит можно назвать квотой.
Как только квота распределенных трассировок достигнута, OneAgent применяет интеллектуальный механизм, который максимально эффективно использует отслеживаемый трафик. Такой подход называется «адаптивное управление трафиком».
SaaS vs Managed — адаптивное управление трафиком версии 1 и версии 2
Версия 1 — Dynatrace Managed
В версии 1 адаптивного управления трафиком каждому процессу разрешено запускать фиксированное количество 1000 новых распределенных трассировок в минуту. Эта версия в настоящее время используется по умолчанию и активна для большинства управляемых кластеров Dynatrace . Это хорошо работает, но имеет недостаток. Если в вашей архитектуре есть точка входа с большим объемом (например, балансировщик нагрузки или NGINX), которая превышает это значение, ваш трафик будет ограничен там. Кроме того, такое поведение также приводит к отправке трафика в Dynatrace, который может реагировать резко в зависимости от трафика вашего приложения.
Версия 2 — Dynatrace SaaS
В версии 2 адаптивного управления трафиком ограничение каждого процесса автоматически адаптируется и настраивается таким образом, что общий допустимый объем вызовов службы в минуту отправляется в Dynatrace независимо от архитектуры вашего приложения.
- Допустимый объем в минуту основан на активно используемых хост-устройствах в данной среде: 250 вызовов полного обслуживания
x
активных хост-устройств . - Допустимый объем масштабируется с вашей лицензией, гарантируя справедливую стоимость для всех наших клиентов.
Пример. Средняя среда, состоящая из 50 хостов по 32 ГБ каждый (100 хост-модулей), будет обрабатывать до 25 000 вызовов полного обслуживания в минуту.
Преимущества этой системы:
- Точки входа с большим объемом могут отправлять больше трассировок, поскольку управление трафиком осуществляется на основе общего объема, отправляемого в среду Dynatrace.
- Приложения с малым объемом делят неиспользуемый объем транзакций с приложениями с большим объемом, которым он необходим.
- Хосты инфраструктуры не отправляют трассировки, но увеличивают общий допустимый объем.
- Сетевой трафик, отправляемый в Dynatrace, менее скачкообразный, так как трафик управляется на основе общего объема.
Эта версия в настоящее время активна во всех средах Dynatrace SaaS .
Адаптивное управление трафиком на Dynatrace OneAgent
Адаптивное управление трафиком гарантирует, что каждый OneAgent регистрирует минимальное количество новых распределенных трассировок каждую минуту, тем самым ограничивая объем отправляемых данных. В то же время он гарантирует, что все важные трассировки будут полностью зафиксированы и что для более частых, но менее важных запросов поддерживается статистически достоверный набор трассировок.
Для этого OneAgent вычисляет список самых популярных запросов, которые запускаются каждую минуту. Типичные приложения не имеют равномерного распределения запросов. Скорее, есть несколько типов запросов, которые составляют большую часть трафика (например, запросы изображений или проверки статуса), среднее количество важных запросов и большое количество уникальных URL-адресов. Основываясь на списке самых популярных запросов, OneAgent захватывает трафик таким образом, что запросы с наибольшим объемом захватываются реже (тем самым избегая захвата «большего количества одинаковых»), в то время как каждый уникальный или редкий запрос захватывается.
В следующей таблице представлен такой пример расчета топ-запросов вместе с соответствующими коэффициентами охвата.
Запрос | Количество запросов, обработанных приложением | Фактор захвата | Захваченные распределенные трассировки |
---|---|---|---|
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 |
В этом примере OneAgent будет захватывать чуть более 1000 запросов в минуту, так как в данном примере это настроенный целевой номер запроса. URI C, D и 50 других URI захватываются каждый раз, в то время как A и B захватываются только в 50% случаев. Тем не менее, OneAgent по-прежнему отслеживает эти запросы от начала до конца более 600 раз в минуту.
Почти во всех случаях вы не заметите такого поведения. Dynatrace сохраняет информацию о скорости захвата и соответственно рассчитывает время отклика, пропускную способность и частоту ошибок. Все диаграммы и сервисный анализ показывают экстраполированные данные, основанные на исходной частоте захвата. Dynatrace AI по-прежнему имеет более чем достаточно данных (больше, чем любое другое решение APM), чтобы предоставить вам полезную информацию и подробный анализ основных причин обнаруженных проблем. Вы можете увидеть это поведение, если посмотрите на отдельную распределенную трассировку в списке распределенных трассировок, где указано 3 more like this
. Это указывает на то, что запрос был перехвачен один раз, в то время как было еще три таких же запроса, которые были обработаны отслеживаемым приложением, но не были включены в анализ.
При таком подходе адаптивное управление трафиком значительно экономит полосу пропускания сети, а в случае Dynatrace Managed — драгоценные ресурсы ЦП, памяти, сети и хранилища, которые в противном случае потребовались бы для обработки и хранения этих данных.
Мониторинг адаптивного управления трафиком
Dynatrace версии 1.232+
Для отслеживания фактического использования и пороговых значений адаптивного управления трафиком Dynatrace предоставляет специальные показатели самоконтроля.
Вы можете интегрировать эти показатели самоконтроля в свою собственную настраиваемую панель мониторинга или создать специальную панель мониторинга, подобную той, что показана ниже, для отображения исторической и текущей скорости захвата.
Необходимые метрические выражения, используемые для построения этой информационной панели, перечислены ниже:
Значение | Выражение метрики |
---|---|
Вызовы с полным обслуживанием, полученные кластером | dsfm:server.service_calls.received:splitBy():sum:auto:rate(1m)
|
Вызовы с полным обслуживанием обрабатываются OneAgent | dsfm:oneagent.service_calls.processed:splitBy():sum:auto:rate(1m)
|
Максимально допустимый полный сервисный вызов / мин | dsfm:server.service_calls.maximum_allowed_per_minute:splitBy():avg:auto:auto
|
Скорость захвата OneAgent | (dsfm:server.service_calls.received:splitBy():sum:auto)/ (dsfm: oneagent .service_calls.processed:splitBy():sum:auto)*(100)
|
Это используемые показатели
Метрика самоконтроля | Описание |
---|---|
dsfm:oneagent.service_calls.processed
|
Количество вызовов с полным обслуживанием, обработанных OneAgent. |
dsfm:server.service_calls.received
|
Количество вызовов с полным обслуживанием, полученных кластером Dynatrace. |
dsfm:server.service_calls.maximum_allowed_per_minute
|
Максимально допустимое количество вызовов с полным обслуживанием в минуту в зависимости от вашей лицензии. |
Адаптивное снижение нагрузки в Dynatrace Managed
Благодаря простоте развертывания OneAgent инструментирование новых приложений, хостов или даже больших дополнительных сред не составляет труда. Клиенты часто подключают к Dynatrace сотни хостов и приложений в день. Это, конечно, значительно увеличивает количество распределенных трассировок, которые обрабатываются кластером Dynatrace Managed.
Иногда первоначальные соображения по размеру управляемых узлов и кластеров Dynatrace недостаточны для поддержки такого объема; кластеру, управляемому Dynatrace, может не хватать необходимого оборудования для обработки всех дополнительных входящих данных. Чтобы защитить работоспособность и целостность вашей среды мониторинга в таких ситуациях, Dynatrace Managed использует адаптивное снижение нагрузки на входящие трассировки, чтобы гарантировать, что мониторинг остается стабильным, пока для анализа собирается статистически достоверный набор запросов.
Каждый управляемый хост Dynatrace может обрабатывать определенное количество вызовов службы в минуту (распределенная трассировка состоит из множества вызовов службы). Количество вызовов, которые могут быть обработаны, зависит от количества процессоров и объема памяти, доступной хосту. Как только этот предел нарушается, включается адаптивное снижение нагрузки.
Новые распределенные трассировки, поступающие из сред с самым высоким трафиком по отношению к назначенным им хост-устройствам (т. е. трафик/хост-модуль), сначала обрабатываются для снижения нагрузки. В этих средах Dynatrace Managed пропускает полную обработку распределенной трассировки. Это происходит случайным образом и уменьшает количество распределенных трассировок, которые обрабатываются поэтапно. В то же время сохраняется статистическая достоверность всех метрик, диаграмм, базовых показателей и событий, поскольку Dynatrace знает количество пропущенных распределенных трассировок. Это полностью прозрачно для вас, поскольку Dynatrace создает событие и отображает сообщение в пользовательском интерфейсе кластера.
Как и в случае с управлением трафиком OneAgent, сокращение объема обрабатываемых данных учитывается прозрачным образом. Это успешно защитит ваш кластер от всплесков трафика. Если такие ситуации единичны, тот факт, что не все данные обрабатываются, не оказывает негативного влияния на ваш мониторинг. Dynatrace AI никак не затрагивается и не выдает предупреждения. Все данные диаграмм на основе сервисов прозрачно корректируются (без видимых изменений), и это учитывается во всех аналитических представлениях. Вы не увидите разницы в диаграммах или данных анализа вызовов службы, если вы не смотрите на один PurePath. Единственное место, где это видно, — это список распределенных трассировок, в котором отображается сообщение типа x more like this
.
Целевыми являются только те среды, которые имеют большой объем трафика по сравнению с назначенными им хостами. Все остальные среды остаются незатронутыми.
Если адаптивное снижение нагрузки задействуется только время от времени, чтобы покрыть пики, все, что вам нужно знать, это то, что это не должно быть долгосрочным решением. Хотя адаптивное управление трафиком OneAgent активно формирует трафик, описанная здесь функция существует только в качестве защиты. Например, спорадический инцидент ALR, который происходит раз в неделю в течение 15 минут, не обязательно означает, что кластер перегружен. Это может быть вызвано необычным скачком нагрузки или временным сбоем в сети.
Если адаптивное снижение нагрузки используется на постоянной основе в течение более длительных периодов (более 15 минут) и особенно в ситуациях, когда ALR активен все время, тот факт, что не все данные обрабатываются, может подорвать ваш мониторинг, метрики и общие данные. качественный. Чтобы предотвратить такой сценарий, вам нужно выбрать один из двух доступных вариантов. Вы можете добавить дополнительное оборудование и новый узел кластера Dynatrace Managed.предоставить вашему управляемому кластеру Dynatrace необходимые ресурсы для обработки дополнительных данных. Или вы можете уменьшить входящий трафик, настроив параметры управления трафиком для OneAgent среды. Вы также можете рассмотреть эти варианты в адаптивном управлении трафиком, когда вам недостаточно статистической корректности сбора данных и вам нужна более высокая точность данных.
Адаптивное управление захватом
В Dynatrace Managed вы можете определить целевое количество недавно отслеживаемых распределенных трассировок точек входа, захватываемых на процесс в минуту.
По умолчанию число вновь отслеживаемых распределенных трассировок точек входа, захваченных на процесс в минуту, составляет 1000, что уже является большим числом. Изменение этого параметра может быть полезно в некоторых ситуациях. У вас может быть среда нагрузочного тестирования, которая потребляет слишком много сетевых, дисковых и ЦП ресурсов в вашем управляемом кластере Dynatrace, и вы предпочитаете использовать эту среду для производственного мониторинга. Вы можете уменьшить точность распределенной трассировки среды и, таким образом, уменьшить процент отслеживаемого входящего трафика. Другими словами, тесты могут обеспечить достаточную степень детализации данных даже после сокращения количества трасс до 500 или 100 в минуту.
Уменьшая количество захваченных распределенных трассировок, вы не меняете ни метрики, ни функции анализа службы. За пределами самого списка распределенных трасс это изменение учитывается прозрачным образом и учитывается во всех анализах.
В качестве альтернативы вы можете увеличить количество распределенных трассировок точек входа, захватываемых на процесс в минуту в наиболее важных средах, чтобы получить еще более высокую точность, чем по умолчанию. Верхний предел составляет 100 000 новых сквозных запросов/процессов/мин. Это эффективно указывает OneAgent захватывать все запросы. Это полезно, когда вам нужно обеспечить захват даже редких запросов в средах с большим объемом.
Будьте осторожны, устанавливая это значение слишком высоким, так как это может привести к тому, что ваш управляемый кластер Dynatrace окажется в ситуации нехватки ресурсов и вынудит вас добавить дополнительное оборудование. Вы можете использовать этот параметр, чтобы эффективно обеспечить захват каждой отдельной транзакции за счет увеличения затрат на оборудование.
Адаптивное управление захватом для групп процессов
В определенных ситуациях может потребоваться уменьшить количество распределенных трассировок, захваченных для определенных процессов или групп процессов. Чтобы приспособиться к этому, вы можете уменьшить количество захваченных транзакций для конкретной среды для определенных групп процессов.
Перейдите в « Настройки » > « Мониторинг службы на стороне сервера» > « Глубокий мониторинг» .
Как видите, эта функция дополнительно позволяет администратору среды сократить количество распределенных трассировок во всей среде. Это полезно для уменьшения объема сетевого трафика, создаваемого OneAgent во всей среде.
Часто задаваемые вопросы
Как адаптивное управление трафиком влияет на графики, базовые показатели и оповещения?
Короткий ответ: нисколько.
Формирование трафика учитывается прозрачно и выполняется таким образом, чтобы обеспечить статистическую достоверность при захвате редких запросов с высокой вероятностью. На всех диаграммах показано общее реальное количество запросов, обрабатываемых вашим приложением, а также весь специальный анализ, который вы можете выполнить. Это не влияет на Dynatrace AI. Единственное место, где видно это формирование трафика, — это список распределенных трассировок, в котором отображается сообщение вроде x more like this
.
Почему я не могу найти свой запрос?
Если размер вашего управляемого кластера Dynatrace недостаточен или интересующий вас конкретный запрос исходит от уровня с большим объемом (более 1000 запросов в минуту), Dynatrace может не зафиксировать запрос. OneAgent делает все возможное, чтобы захватить все уникальные запросы, но есть ограничения на то, что можно сделать. Мы продолжим работать над совершенствованием этого механизма. Вы можете уменьшить объем производимого трафика, исключив из захвата неважные запросы; это делается с помощью атрибутов веб-запроса и правил исключения URL-адресов. Такой подход оставляет больше места для важных запросов.
Если это важно для вас, вы также можете увеличить количество захваченных распределенных трассировок в Dynatrace Managed.
Что такое полный сервисный вызов?
Полный сервисный вызов — это вызов на стороне сервера, который запускает распределенную трассировку, сервисный вызов на уровне глубокого мониторинга или настраиваемые сервисные вызовы. Внешние вызовы (такие как вызовы базы данных, внешние веб-запросы или вообще любые непрозрачные вызовы службы) не являются вызовами полного обслуживания, поэтому они не учитываются в вашем лимите трафика. Dynatrace считает все запросы к службам веб-запросов и веб-служб (кроме внешних), службам RMI, службам обмена сообщениями и пользовательским службам.
Что такое активная хост-единица?
Активные хост-устройства — это хост-устройства, используемые в данный момент и подключенные к среде (а не хост-устройства, назначенные среде).
Каково минимальное количество вызовов полного обслуживания/мин в данной среде?
Минимальное количество вызовов полного обслуживания в минуту в данной среде составляет 5000, что эквивалентно 20 хост-устройствам.
Каково минимальное и максимальное количество следов, которые может создать процесс?
Система автоматически адаптирует OneAgent между 50–50 000 трассировок в минуту, чтобы соответствовать общему объему трафика, достигающему системы Dynatrace