Dynatrace Service timing

Всем привет. 

Для понимания таймингов выполнения сервисов нашел статейку на сайте Dynatrace. Немного добавил своих комментов, чтобы улучшить перевод. 

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

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

PP: PurePath. Полный путь
RT: Response time. Время отклика.
SF: Service flow. Маршрут прохождения сервиса.
MH: Method hotspots. Метод горячих точек.

 

Response time	PP, SF	Общее время выполнения первого узла в PurePath.   Server side Время между моментами запуска PurePath на стороне сервера и отправкой ответа обратно клиенту.   Client side Время между моментами, когда клиент запускает запрос и получает ответ.
Response time	RT	Общее время выполнения метода.   Server side Время обработки метода. Client side Время между моментами, когда клиент запускает запрос и получает ответ.
Processing time	PP, SF, RT	Продолжительность PurePath от начала до конца.   Это последовательно высчитываемое время (разница между временем начала и окончания).
Execution time	RT	Общее время, затраченное на выполнение кода.   Это сумма всех асинхронных исполнений, поэтому она может быть больше времени обработки.
Suspension	PP, SF, RT	Время, в течение которого выполнение любого кода останавливается. Обычно это происходит из-за сборщика мусора.
Wait time	PP, SF	Время, в течение которого код активно чего-то ждет (например, Object.wait() или аналогичная функциональность)
Lock wait	RT	Время, в течение которого код блокируется. Это обычно вызвано временем ожидания входа в синхроно-выполняемый блок кода или временем ожидания для получения спин-блокировки.
Active wait	RT	Время, в течение которого код в этом узле чего-то ждет. Ожидание, вызванное дочерними вызовами, не считается.
Sync time	PP, SF	Время, в течение которого код блокируется ожиданием синхронного блока кода.
Network I/O	PP, SF, RT	Время, в течение которого код активно ожидает собственные сетевые функции (например, java.net.SocketInputStream.socketRead0). Этот анализ не учитывает дочерние вызовы.
Disk I/O	PP, SF, RT	Время, в течение которого код активно считывается с диска или записывается на него или ожидает ввода/вывода диска.
CPU time	PP, SF, RT	Время, в течение которого процессор выполняет код, связанный с PurePath. Измерение производит OneAgent.
Self time	PP, SF, RT	Время обработки конкретного узла в PurePath.
Other	PP, SF	Любое неопределенное действие из Self time.
Code execution	MH	Процент измеренных образцов, в которых код метода активно выполняется.
Disk I/O	MH	Процент измеренных образцов, в которых метод активно считывает данные с диска или записывает их на диск или ожидает ввода/вывода диска.
Network I/O	MH	Процент измеренных образцов, в которых метод активно ожидает собственных сетевых функций.

Dynatrace: новое в версии 1. 208

Привет всем. 

Последние изменения и усовершенствования АРМ Dynatrace(1.208 <=).

1. Новый инструмент управления метриками и построения кастом чартов(Data explorer). В меню появилась новая вкладка Metrics. Метрики наглядно демонстрируются: как встроенные, так и созданные. Теперь для чарта стало удобнее добавлять различные фильтры. 

Теперь выбираем метрику и переходим к чарту. 

2. Cross Environment Dashboard. 

Настраивается через (для подключаемой среды нужно сгенерировать токен)

Settings -> Integration -> Remote Environment

Есть небольшой прикол! Если строить кастом чарт и выбрать удаленной энвиромент, то данные так лего не подтянутся как казалось бы с первого взгляда. На примере выглядит так: есть хост хотим мониторить загрузку по ЦПУ. Строим кастом чарт по метрике Host->CPU->CPU Usage, данные по загрузке ЦПУ из удаленного энвайромента не подтягивается, то есть данные по метрике не видны. Как исправить? Копируем id-хоста из URL-адреса, открываем JSON-файл борда, находим метрику с RemoteEnvironmentUri и заменяем айдишник хоста из другого энвиромента. 

3. Добавлены новые метрики для мониторинга реальных пользователей (RUM).

Для более точного анализа быстродействия приложения и определения действий пользователей. 

4. SLO

Настраивается через Settings -> Monitoring -> SLOs

В настройках выбираем метрику(как она определена в апи).

Далее определяем как будем агрегировать метрику(в сингл валью или несколько метрик).

Указываем целевое значение(target) и значение оповещения. 

Если статус опускается ниже целевого значения, меняется цвет отображения. 

5. Новые сенсоры 

6. Поддержка распределенной трассировки агента(OneAgent OpenTracing support)

Распределенная трассировка (распределенной трассировкой запросов) - это метод, используемый для профилирования и мониторинга приложений, особенно тех, которые построены с использованием архитектуры микросервисов.

Вы можете интегрировать OpenTracing в Dynatrace. Open Tracing API предоставляет стандартную, не зависящую от поставщика платформу для инструментирования ваших приложений для распределенной трассировки.

Dynatrace интегрирует открытые трассировки и обогащает данные аналитикой, включая:

• Анализ точек доступа к готовым услугам (service hotspot analysis)
• Детали выполнения глубокого кода (deep-code execution details)
• Постоянное профилирование в контексте транзакции (always-on profiling in transaction context)

Dynatrace выступает в качестве инструмента или объекта  GlobalTracer 

7. Отслеживание запросов DNS

Dynatrace: важные лимиты

Привет всем. 

Когда нагрузка на кластер растет и появляются мысли, а что же это так тормозит? 

Даже в моменты, когда бы нагрузки не планировалось. 

Вот и возвращаемся к мат части - лимиты.

Ограничения по умолчанию устанавливаются для защиты работоспособности кластера. Существуют мягкие и жесткие ограничения(hard & soft limits): жесткие ограничения обойти нельзя, мягкие ограничения могут быть увеличены, если они одобрены внутренней командой Dynatrace. Для этого потребуется внешняя эскалация и изменения могут быть не одобрены в зависимости от вашего запроса и состояния работоспособности кластера. 

В настоящее время вот самые важные ограничения. 

Лимиты: 

 • 5000 Зон управления на энвиронмент (Management Zones per environment) 

 • 2000 бордов на энвиронмент (dashboards per environment) 

• 1000 приложений на энвиронмент (applications per environment) 

• 5000 синтетических тестов на энвиронмент (synthetic tests per environment) 

• 10000 кастомных событий для алертинга на энвиронмент (custom events for alerting per environment) 

Лимиты для реквест-атрибутов (Request attributes): 

• Без ограничений на создание РА (no limit) 

• Максимум 10 РА на один реквест (10 request attributes per request (hard limit)). 

Свойства сеанса пользователя/действия(user sessions & actions): 

• Максимум 20 свойств пользовательского сеанса в каждом сеансе(20 User session properties per session) 

•  Максимум 200 свойств на одно приложение, а для каждого действия -не более 20 свойств действия. 

И другие ограничения по RUM'у.

Комментарии приветствуются.