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'у.

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

Dynatrace: ошибка захвата атрибутов PHP

Всем привет!
Столкнулся с ошибкой захвата атрибутов при мониторинге PHP-FPM. Созданные Request Attributes не захватывают данные из методов, которые точно вызываются. По идее вызов метода инициирует захват атрибутов с помощью Request Attribute, но этого не происходило. Общение с поддержкой ни к чему не привела.

Из выполненных работ:
1. Перезапуск PHP-FPM
2. Отключение - включение OpCache
3. Перезапуск PHP-CLI
4. Обновление агентов OneAgent до последней версии
5. Создание custom service

После очередного перезапуска PHP я заметил, что Dynatrace неверно определяет путь к файлу с классом. Плюс путь очень длинный, что не помещается в строку. Решил изменить путь и пересоздать Request Attributes. Не помогло.
Тогда создал отдельный Custom Service с указанием пути к классу, по которому класс точно располагался на этом хосте. И после этого атрибуты стали захватываться.
Dynatrace неверно определял путь с классом и методом, поэтому атрибуты не захватывались!

Успехов!

Dynatrace: воспроизведение сеанса пользователя

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

Детализация ошибок
С помощью Session Replay можно более подробно детализировать обнаруженные ошибки:

• Обнаружение ошибок JavaScript
• Понять точные действия пользователя, которые привели к ошибке
• Понимание серьезности проблемы и ее влияния дальнейшие действия пользователя
• Наблюдайте за действием пользователя, воспроизводя и просматривая сеанс (в тех случаях, когда проблема не очевидна)

К этим сеансам применяется стандартный срок хранения данных - 35 дней.

Удобство использования
Воспроизведение сеанса также может быть использовано для обнаружения и анализа следующих проблем:

• Дизайн UX недостаточно интуитивно понятен
• Процесс слишком сложен, и пользователи, как правило, оставляют ваше приложение на полпути
• Приложение работает медленно, и пользователь нажимает несколько раз, чтобы перейти к следующему экрану
• Приложение работает не так, как ожидалось, во всех браузерах
• Мобильные веб-приложения предлагают пользователю изменить ориентацию телефона, но пользователь не понимает этого запроса

Для включения User Sessions Replay необходимо:

• DEM Unit Licanse
• Агенты версии 157 или выше
• ASP.NET только
• Дополнительное хранилище под сессии

Все настройки расположены в настройках отдельных приложений Application Settings -> Session Replay.
Включаем.

В некоторых случая можно подключить дополнительные шрифты.
Записываются от 25 до 50% сессий. Это по умолчанию, если вы не изменили лицензию.
Opt-in-Mode и Form filed masking используется для сокрытия приватных данных.

Dynatrace: приватность данных

Dynatrace соблюдает требования GDPR о конфиденциальности пользовательских данных.
Настройки приватности данных Preferences-> Data Privacy and Security
1. The Mask end-user IP addresses & GPS coordinates
Включен по умолчанию. Применяется для мониторинга реальных пользователей(Real User Monitoring) и для мониторинга серверных служб(server-side monitoring). Если этот параметр включен, IP-адреса конечных пользователей маскируются в момент обнаружения из веб-приложений, мобильных приложений, пользовательских приложений и серверных служб.
Вы можете выбрать, следует ли маскировать все или только общедоступные IP-адреса.
С другой стороны вы можете задать параметры конфиденциальности отдельно для приложения. Выбираете приложение, нажимаете редактировать и проваливаетесь в настройки.

User Tracking позволяет вам контролировать использование постоянных файлов cookie для обнаружения и отслеживания пользователей, которые ранее обращались к вашему приложению. Если этот параметр отключен, то Dynatrace не сможет обрабатывать метрики, т.к. не сможет отделить анонимные сессии от пользовательских.

Data collection and cookie Opt-In mode
Когда включено внедряемый код JavaScript для мониторинга реальных пользователей (Real User Monitoring) не будет захватывать данные или устанавливать куки. Однако вы можете управлять сбором данных для отдельных пользователей, с помощью JavaScript API вызываете метод dtrum.enable, который реализует настройку opt-in, позволяя вашим пользователям соблюдать конфиденциальность данных их региона.

'Do Not Track' end-user browser settingsБольшинство современных веб-браузеров имеют функцию конфиденциальности под названием "Не отслеживать"(браузеры добавляют дополнительный HTTP-хедер ко всем веб-запросам, отключая отслеживание пользователей.), которую отдельные пользователи могут включить на своих устройствах. Когда включено, Dynatrace будет отслеживать таких пользователей в рамках анонимной сессии. 

2. Mask personal data in URIs
Dynatrace захватывает полные URI запросов. Dynatrace может также захватывать полные URI и на стороне сервера, чтобы обеспечить детальный анализ производительности вашего приложения. Uri могут содержать персональные данные, например имена пользователей. Если этот параметр включен, Dynatrace автоматически определяет UUID, номера кредитных карт, адреса электронной почты, IP- адреса и другие идентификаторы и заменяет эти значения определенным плайсхолдером(placeholder).

3. Mask user actions(web app only)
Dynatrace маскирует действия пользователя, такие как перезагрузка страницы, запуск ява-агента и других скриптов.

Dynatrace: process group

Группа процессов(Process group)-это логический кластер процессов, запущенных на отдельных хостах, принадлежащих к одной группе процессов. Process group являются основными структурными элементами большинства современных приложений.
В больших динамических средах количество процессов, запущенных на ваших хостах, может быть огромным. По этой причине Dynatrace отслеживает только те типы группы процессов, которые считается важными(и которые вы определяете сами). К ним относятся процессы, которые являются хорошо известными приложениями, такими как Java и .NET, базы данных и веб-серверы, или которые работают на определенном порту.
Группы процессов остаются относительно постоянными даже при появлении новых версий или отката к старым. Они обеспечивают необходимую непрерывность, которая позволяет осуществлять постоянный мониторинг вашего окружения.

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

В разделе Processes на странице хоста показаны наиболее важные процессы, запущенные на этом хосте, разделенные на группы процессов.
Что бы посмотреть все процессы -> All process.

Список процессов содержит основные сведения о системных и сетевых ресурсах:

• ЦП (Процент потребляемый процессом)
• Память(Процентная доля системной памяти, потребляемая процессом)
• Трафик(Сетевой трафик)
• Ретрансляция
• Подключения(процент успешно установленных сеансов TCP, за вычетом суммы отказов и тайм- аутов подключения)

Помимо простого вычисления типов процессов в среде, Dynatrace понимает технологии, лежащие в основе этих процессов. Например, Dynatrace понимает, когда процесс Java состоит из Tomcat или Jetty, хотя во многих случаях он даже знает версии этих технологий.

Чтобы просмотреть свойства технологии, лежащие в основе процесса:

В меню навигации выберите хост, на котором выполняется интересующий вас процесс.

В разделе Processes на главной странице выберите интересующий вас процесс.

На странице процесс разверните панель свойств в верхней части страницы.

Свойство Type указывает основную технологию, лежащую в основе процесса. 

Dynatrace автоматически определяет процессы и группы процессов, запущенные на ваших хостах. Основные группы основаны на базовых технологиях, таких как Apache Tomcat, IIS, Java и NodeJS. Процессы, выполняющие одну и ту же функцию на одном или нескольких хостах, представлены в группах(Process group).

Вы также может управлять группами процессов: создать, задавать и изменять параметры.

Settings ->  Processes and Containers -> Process Group Detection 

Dynatrace: service flow

Dynatrace отслеживает транзакции приложений от начала и до конца. Эта транзакционная последовательность визуализируется через поток обслуживания(service flow), который наглядно иллюстрирует последовательность вызовов служб, инициируемых каждым запросом на обслуживание в вашей среде.

С помощью потока обслуживания вы видите поток вызовов служб с точки зрения одной службы, запроса или их отфильтрованного подмножества. Наряду с конкретными службами, которые запускаются, вы также можете увидеть, как каждый компонент запроса вносит свой вклад в общее время ответа. Как видно из примера, поток обслуживания может быть очень велик и каждый отдельный виток нужно анализировать отдельно.
Если выделяете какой-то элемент из потока, он отображает 2 метрики.

Первая метрика показывает процент запросов, инициированных исходной службой и связанных с вызовом целевой службы, в примере - Booking service. Вторая метрика показывает среднее количество вызовов целевой службы, которые были включены в каждый запрос.

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

В приведенном выше примере потока обслуживания они помечены следующим образом:

1-среднее время отклика службы(Average response time service)
2-общий вызов (Call share)
3-вызов по запросу (Call per request)
4-среднее время отклика в целом(Average response time overall)

Небольшой пример для службы:
Среднее время отклика =288 МС
Процент вызовов= 36%
Количество вызовов на запрос = 3,5

Вклад времени отклика = (среднее время отклика) x (процент вызовов) x (вызовы на запрос)
Вклад времени отклика = 288 x .36 х 3,5
В этом случае вклад времени отклика =363 МС

С правой стороны экрана находится -> Side pane.
На вкладке проходящие транзакции(Passing transactions) отображается пропускная способность сервиса и его производительность—время отклика, количество запросов и др.
Вкладка инфраструктура(Infrastructure) показывает на каких хостах расположен и как распределяется пропускная способность между ними. Нажмите кнопку отфильтровать —будут показаны только вызовы, исходящие от выбранного хоста.

Dynatrace: атрибуты службы

Каждая служба содержит список наиболее важных показателей, которые расположены на  отдельных инфографиках. Каждая инфографика показывает вам, какие приложения или службы используют эту службу(или объединенную службу) и выполняет ли она какие-либо вызовы к другим службам или базам данных.
Откройте Transactions and services -> выберите любую службу.

Каждая область инфографики сервиса служит ссылкой, по которой вы можете щелкнуть, чтобы просмотреть подробную информацию, например, дополнительные диаграммы или особенности взаимодействия. Например, чтобы получить доступ к подробным диаграммам времени отклика(Response time) и частоты отказов во времени для выбранной службы, щелкните области Время отклика, самые медленные 10%(slowest 10%) или частота отказов в инфографике службы. Такие же вызовы касаются и ЦП(CPU), ошибок(Failure rate) и пропускной способности(Throughput).

На диаграммах на каждой странице сервиса есть ползунок" временные рамки анализа"(Analysis timeframe), который помогает анализировать всплески времени отклика. Временной интервал анализа, выбранный с помощью ползунка, отражается на кнопке просмотра времени отклика на определенной диаграмме.

Что посмотреть детально по выбранному временному интервалу(обращения к БД, выполненные запросы) выбираем View Response time hotspots

Нажмите Interaction with services and queues, чтобы посмотреть как происходят взаимодействия с другими службами.

Слева вы видите, как часто анализируемая служба вызывает другие службы и в какой степени эти вызовы влияют на время отклика. На правой стороне эта информация разбита на более подробные части. Можно выбрать и посмотреть детальную информацию по ним, стрелочка влево возвращает на предыдущий экран.
Database usage -> обращения к БД.
Service exetion -> время выполнения запросов.
Длина столбиков представляет собой количество времени, затраченного в каждой конкретной области. Щелкните по любому элементу, отображаемому в виде ссылки, чтобы просмотреть соответствующие горячие точки на уровне модуля или метода.

Посмотреть на горячие точки выполнение метода -> View method hotspots
Проверьте все классы и методы, которые были выполнены во время запуска службы в разделе дерево вызовов. Столбец образы трассировки(Stacktrace samples) стека показывает, сколько раз класс / метод был выполнен для службы в течение выбранного периода времени . Столбец вклад (Contribution)показывает долю потребления, которую класс/метод вносит в общее выполнение. Это позволяет определить, какой класс и / или метод занимает большую часть времени выполнения, и впоследствии оптимизировать код.

Посмотрим теперь по ошибкам(Failure rate), детально за 15 минут по ошибкам

Кнопка Hotspots (горячие точки) на каждой странице сервиса показывает наиболее важные точки(возникновение события) в вашем сервисе. Собирается на основе ИИ. 

Для оценки производительности ваших приложений крайне важно иметь возможность отслеживать время отклика каждого запроса в рамках каждой сквозной транзакции, выполняемой вашими приложениями. Dynatrace предоставляет такую функциональность для отслеживания времени отклика(response time) и анализа резко отличающихся параметров(outlier analysis). Понимая распределение времени отклика по всем запросам, вы можете сосредоточиться на тех запросах, которые имеют самое медленное время отклика. Анализ отличающихся значений времени отклика (те запросы, которые имеют либо необычно высокое, либо необычно низкое время отклика) значительно влияет на общее время отклика транзакций.
Для анализа этих значений кликаем по кнопке Analyze outliners

По данному графику видно. что время отклика высокое и 12% запросов выполнены с ошибками.
Zoom in -> для более детального просмотра. 

Выбираем Analyze backtrace, чтобы посмотреть запросы составляющие общую транзакционную картину данного периода. 

Нашли запросы с ошибками и определили причину их возникновения. 

Посмотрим поток обслуживания(View service flow), точки входа, основные запросы, время выполнения. 

Dynatrace: opaque services

Opaque services - непрозрачные службы, обнаруженные на вызывающей стороне Dynatrace, для которых видимость на уровне кода недоступна. Dynatrace может обнаруживать запросы к непрозрачным службам и определять, какими процессами они обрабатываются, но Dynatrace не может напрямую отслеживать эти службы.

Видимость на уровне кода невозможна, если

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

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

Тем не менее Dynatrace может обнаруживать все запросы к службам CouchDB, отправляемые службами, которые отслеживает Dynatrace. Dynatrace рассчитывает время отклика и частоту отказов и генерирует соответствующие предупреждения. Благодаря искусственному интеллекту Dynatrace понимает, какое влияние могут оказать проблемы службы на  производительность хоста и процесса. Вот почему Dynatrace соотносит проблемы хоста и процесса с соответствующими замедлениями в запросах на обслуживание. Например, если служба CouchDB аварийно завершает работу, Dynatrace интерпретирует этот сбой как основную причину увеличения частоты отказов в вызовах службы CouchDB. Хотя глубокий мониторинг не поддерживается для этой службы, Dynatrace все еще может обнаруживать все запросы к этой службе, отправляемые отслеживаемыми службами, и, например, вычислять соответствующее время отклика и частоту отказов.

Обратите внимание, что непрозрачные сервисы непризнанных или не поддерживаемых технологий все еще включены в Smartscape. Это обеспечивает полное представление топологии вашей инфраструктуры, даже если ваша среда включает непрозрачные сервисы.

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

• Процесс находится в оффлайне(автономном режиме работы), хотя служба продолжает делать к нему вызовы. Эти типы непрозрачных служб используются для визуализации зависимостей в контексте проблем доступности.
• Процесс никогда не начинал обработку запроса (вызывающая служба получает ошибку или тайм-аут), и поэтому Dynatrace не может отслеживать запрос в процессе.
• Процесс не был перезапущен после установки OneAgent. После перезапуска процесса он должен изменить свой статус и не должен казаться непрозрачным.
• Фреймворк, обрабатывающий запрос на определенном порту, в настоящее время не поддерживается одним агентом. 
• Фреймворк поддерживается, но OneAgent столкнулся с технической проблемой. Далее обращение в техподдержку или на форум:)

Dynatrace: merged services

Merged service - это служба, которая объединяет несколько служб веб-запросов одной и той же группы процессов, выполняющих идентичные функции на разных узлах кластера. Слияние служб доступно только для служб веб-запросов, выполняющих одну и ту же функцию в рамках одной и той же группы процессов и поэтому фактически идентичных с точки зрения мониторинга производительности. Объединенная служба отображается в Dynatrace как единая служба, содержащая данные всех агрегированных служб.

Чтобы понимать какие из ваших служб подходят для слияния служб, Dynatrace автоматически идентифицирует для вас объединяемые службы и отображает их на странице мониторинга Для этого перейдите Settings > Server-side service monitoring > Merged service monitoring
Только эти службы могут быть объединены.

Примером может служить приложение easyTravel.
Создадим объединенную службу.

После объединения данные отдельных служб больше не могут быть различены—данные мониторинга доступны только в совокупности для всех объединенных служб.

После объединения новые агрегированные данные будут назначены новой объединенной службе и связаны с ней(определяйте имена правильно, чтобы не запутаться). А отдельные компоненты объединенной службы больше не обновляются как источники данных. Хотя исторические данные остаются доступными (например, для построения графиков).

Если вы разделяете службу от Объединенного сервиса (т. е. "размонтируете" сервис или удаляете смердженную службу), исторические данные будут доступны только для объединенного сервиса. Все вновь полученные данные будут связаны с автономной службой.

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

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

Dynatrace: services

Службы - это наборы кода, которые принимают запросы и возвращают результаты. После того как OneAgent установлен и система(ОС) перезапущена начинается мониторинг всех служб на этой машине. OneAgent определяет все известные ему сервисы, если он не знает такого сервиса, то его можно сделать отдельно, указав путь к исполняющимся файлам.

Веб и мобильные приложения основаны на службах, которые обрабатывают запросы, такие как веб-запросы, вызовы веб-служб и службы обмена сообщениями. Такие "серверные службы" могут принимать форму веб-служб, веб-контейнеров, запросов баз данных, пользовательских служб и т. д. Службы, в свою очередь, могут вызывать другие службы, такие как веб-службы, удаленные службы и службы баз данных. Поскольку ландшафты служб могут стать довольно сложными, Dynatrace автоматически классифицирует службы на основе их зависимостей от других общностей:

• Точки входа(Entry points): эти службы представляют собой первый контакт транзакции с отслеживаемой серверной службой и являются начальными точками Purepath на стороне сервера. Службы точек входа обычно представляют собой службы поверх отслеживаемого веб-сервера или общедоступного API. Службы могут иметь транзакции точек входа, а также транзакции, исходящие из других отслеживаемых компонентов. 
• Используемые приложениями(Used by applications): эти службы вызываются веб-приложениями, мобильными приложениями или пользовательскими приложениями (т. е. всеми приложениями, которые отслеживаются с помощью реального мониторинга пользователей, RUM). Эти сервисы также являются службами точек входа. 
• Фоновая активность(Background activity): эти службы представляют собой запросы, выполняемые в фоновых потоках.
• Только внутренние(Internal only): эти службы вызываются только другими отслеживаемыми службами. Таким образом, эти службы не ведут себя как точки входа и не имеют никакого прямого отношения к приложениям.
• Внешние зависимости(External dependencies): эти службы представляют собой исходящие вызовы к системам, которые не отслеживаются в текущей среде Dynatrace. Существует два типа внешних зависимостей:

1. Вызовы в общедоступные сети(Calls to public networks): Эти службы представляют собой исходящие вызовы, которые разрешаются на общедоступный IP-адрес и поэтому обычно находятся вне сети вашей компании. Звонок к платежному провайдеру типа paypal.com это пример внешней зависимости.
2. Вызовы к неконтролируемым хостам(Calls to unmonitored hosts): они представляют собой вызовы, которые разрешаются на частный (внутренний) IP-адрес и обычно находятся под ответственностью вашей организации. Поэтому для получения видимости в этих частях вашей среды рекомендуется специальный мониторинг этих зависимостей с помощью OneAgent или с помощью пользовательского мониторинга устройств.

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

Process groups 

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

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

Службы веб запросов (Web request services) обслуживают веб-приложения, которые развертываются либо через веб-сервер (например, Apache или NGINX), либо в веб-контейнерах (например, Java, Node.js, или PHP). Dynatrace рассматривает три дискретных понятия при идентификации и именовании служб: имя веб-сервера, корневой контекст и идентификатор веб-приложения.

Web server name

Существует три различных термина: виртуальный хост, серверный блок и сайт, которые представляют собой сходные понятия в различных технологиях. Виртуальный хостинг доменных имен объединяет веб-запросы от нескольких хостов, доменов и IP-адресов в единую конфигурацию на веб-сервере. Например, Apache HTTP Server позволяет настроить www.dynatrace.com, www.dynatrace.at, и www.dynatrace.us все в пределах одного виртуального хоста. NGINX использует концепцию серверного блока. В случае серверного блока необходимо настроить имя сервера. Сайт-это концепция, созданная в Microsoft IIS. В средах на базе kubernetes веб-серверы Apache и NGINX часто настраиваются только как "localhost" или просто IP-адрес. В этих случаях Dynatrace автоматически использует автоматически определяемое базовое имя модуля в качестве имени веб-сервера, чтобы обеспечить более осмысленное представление из коробки.

Context root

В любом веб контейнере вы можете иметь несколько приложений в нескольких каталогах. Например, /admin приводит к заявке администратора, а /salon - ведет в интернет- магазин. В мире Java это называется контекстным корнем. В IIS - это виртуальный каталог. Большинство веб серверов данного понятия.

Web application ID

Некоторые технологии позволяют давать веб-приложениям явные имена.

• Для сервлетов Java это делается путем определения отображаемого имени в web.xml.
• Для приложений Spring boot вы должны определить следующие параметры: spring.application.name, которые могут быть в заявке.файл свойств или приложение.файл yml.
• Для технологий Java, которые не допускают именования приложений (и обеспечивают именование приложений по умолчанию), можно определить свойство командной строки Java-Ddynatrace.application.id= < name>. это не будет переопределять параметры именования, упомянутые выше.
• Для Node.js вы можете определить имя в пакете.файл json.
• Для других технологий или для предоставления имени по умолчанию можно использовать переменную окружения DT_APPLICATION ID=<name>. 

Посмотреть данные атрибуты можно выбрав Transactions & services из навигационного меню. Далее указываете нужный сервис, и выбираете Properties and tags

Веб- службы обнаруживаются на основе веб фреймворков. Веб- службы определяются языком описания веб-служб (WSDL), который является частью вашего развертывания. WSDL определяет службы, способ их вызова и имена служб. Dynatrace собирает имена служб вместе со значениями targetNamespace и объединяет эти значения для уникальной идентификации каждой службы.

Database services

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

Queue listener services

Службы прослушивания очередей  показывают какие очереди вы слушаете. Это облегченные службы, которые не имеют времени отклика. Эти службы сообщают вам, сколько сообщений было снято с очереди. Они ничего не говорят вам об обработке сообщений-это делают службы обмена сообщениями. Если Dynatrace автоматически обнаруживает прослушиватель сообщений на основе событий, за службой прослушивания очередей всегда следует служба обмена сообщениями, которая дает вам представление о деталях сообщений. Однако если вы просто отслеживаете очередь, а не изучаете детали сообщения, служба прослушивания очереди может существовать сама по себе.

Messaging services

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

RMI service (Remote service)

В мире Java удаленный вызов метода (Remote Method Invocation) является распространенным средством связи, используемым ява-машинами (JVM) . Поскольку в одном JVM может быть много динамически создаваемых серверов RMI, Dynatrace создает только одну службу RMI для каждой группы процессов. Это не означает, что вы теряете видимость ваших служб RMI, т.к. Dynatrace отслеживает каждый класс RMI как отдельный тип запроса.

RPC service (Remote service)

Dynatrace отслеживает удаленные вызовы процедур с помощью SDK, Akka и AWS Lambda. В отличие от RMI, Dynatrace создает отдельную службу RPC для каждого эндпоинта(endpoint) службы.

Background activity service 

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

Например, если у вас есть фоновый поток в Tomcat, который делает веб-запросы к Apache, Dynatrace представляет его как фоновую службу активности Tomcat. Вы сможете увидеть, какие запросы Tomcat делает к вашему Apache, проанализировав время отклика службы фоновой активности Tomcat.

Custom services

Кастомизированные службы позволяют вам управлять приложением, которые не построены на стандартных технологиях. Вы также можете настроить свою систему и использовать определенный метод, класс или интерфейс, который вас интересует. Вы можете создавать пользовательские службы, используя Java, .NET и PHP.

Проблемы обнаружения службы

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

Если на HTTP-сервере Apache нет виртуального хоста, то имя веб-сервера по умолчанию соответствует имени физического хоста. В облачных средах это приводит к одному виртуальному хосту для каждого физического экземпляра хоста и, следовательно, к одному экземпляру службы. Если облачная среда запускает и останавливает хосты, то эти службы будут временными.

Чтобы исправить такие сценарии localhost, используйте переменную среды для определения имен виртуальных узлов. Просто установите 'DT_LOCALTOVIRTUALHOSTNAME' для каждого процесса веб-сервера в любое значение (например, www.dynatrace.com). Dynatrace будет подбирать имена и использовать их вместо существующих имен виртуальных хостов localhost. При таком подходе вы можете гарантировать, что несколько физических узлов (т. е. "кластер") сообщают об одном и том же виртуальном узле и таким образом получают одну службу с несколькими экземплярами, по одному экземпляру на физический узел.

Некоторые технологии не предоставляют уникальных имен приложений. В этих случаях можно определить переменную окружения с именем DT_APPLICATION ID для предоставления уникального имени. Это влияет только на службы соответствующего процесса, которые еще не имеют идентификаторов приложений. Для приложений Java можно также использовать системное свойство dynatrace.application.id

В случае, если ваша служба динамически менять порт после перезапуска, можно воспользоваться переменной окружения DT_IGNORE DYNAMIC PORT=true. Это удаляет порт из обнаружения и заменяет его на *.

Dynatrace: обнаружение проблем

Проблемы в Dynatrace представляют собой аномалии, то есть отклонения от нормального поведения или состояния. Такими аномалиями могут быть, например, медленный сервис или медленный вход пользователя в приложение. Всякий раз, когда обнаруживается проблема, Dynatrace вызывает конкретное событие проблемы(Event type), указывающее на такую аномалию.

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

Dynatrace непрерывно измеряет уровни входящего трафика в соответствии с определенными пороговыми значениями, чтобы определить, когда обнаруженное замедление или увеличение частоты ошибок оправдывает генерацию нового события проблемы. Быстро увеличивающиеся деградации времени отклика(response-time degradations) для приложений и служб оцениваются на основе 5-минутных интервалов времени. Медленно изменяющаяся деградация оценивается на основе 15-минутных интервалов времени.

Dynatrace использует два типа определения пороговых значений:

• Автоматизированные базовые линии(Automated baselines) : Многомерная базовая линия автоматически определяет индивидуальные значения, которые адаптируются с течением времени. Автоматизированные базовые значения используются для управления динамическими изменениями в пределах времени отклика приложения или службы, частоты ошибок и нагрузки.
• Встроенные статические пороги(Built-in static thresholds): Dynatrace использует встроенные статические пороги для всех событий инфраструктуры (например, обнаружение высокой загрузки процессора, уменьшение дискового пространства или малого количества доступной памяти).

Методология, используемая для создания событий с помощью автоматизированной базовой линии, полностью отличается от методологии  используемой для статических пороговых значений. Статические пороговые значения предлагают простой и понятный подход к определению базовых показателей, который работает сразу же, не требуя периода обучения, не учитывая работу Davis'a. Наоборот, методология автоматизированной базовой линии автоматически адаптируется к изменениям в структуре трафика. Dynatrace позволяет регулировать чувствительность обнаружения проблем либо путем адаптации статических пороговых значений, либо путем отклонения от автоматизированных базовых показателей.

Событие в Dynatrace может быть определенного типа. Каждый тип события имеет определенный уровень серьезности, который указывает на значимость инцидента. Результирующие проблемы объединяют все включенные серьезности событий и оцениваются с самым высоким уровнем серьезности составляющих событий. В течение срока действия проблемы уровень ее серьезности может повышаться (например, проблема может начинаться с уровня замедления, а затем автоматически повышаться до уровня доступности при обнаружении сбоя).

Уровни серьезности событий:

1. События доступности(Availability events): указывают на серьезные инциденты в вашей среде, такие как полное отключение или недоступность серверов или процессов. Эти типы событий имеют самый высокий уровень серьезности.
2. События ошибок(Error events): информирование вас об увеличении частоты ошибок или других инцидентах, связанных с ошибками, которые мешают регулярной работе вашей среды.
3. События замедления(Slowdown events): указывают на снижение производительности в одной из ваших операционных служб или приложений. События замедления менее серьезны,чем события первых 2-х уровней. Тем не менее, они информируют вас о потенциальных проблемах с выполнением ваших услуг.
4. События ресурсов(Resource events): указывают на конфликт ресурсов. Типичными примерами являются события повышения уровня утилизации процессора, памяти и др.
5. Настраиваемые оповещения(Custom alerts): используются для включения оповещения о любых заданных пользователем пороговых значениях. Настраиваемые оповещения для определенных пользователем пороговых значений могут быть установлены для любой метрики Dynatrace. Пользовательские оповещения не коррелируются и не изменяются искусственным интеллектом, хотя они автоматически включаются.
6. Информационные события(Info events): события, запускаемые вручную, которые не приводят к созданию новой проблемы. Эти события используются для обозначения важных развертываний или изменений конфигурации, а также административных событий, таких как автоматическая миграция виртуальной машины. Информационные события не рассылаются в виде предупреждений, так как этот тип событий не указывает на ненормальную ситуацию.

Немного о том, как Davis определяет проблему.
Уровень воздействия проблемы определяет, влияет ли ненормальная ситуация на инфраструктуру (INFRASTRUCTURE), программные службы (SERVICE) или приложения(APPLICATION). Четвертый, специальный уровень воздействия (ENVIRONMENT) используется для классификации общей проблемы в среде мониторинга. Эти проблемы используются для сообщения о прерывании вашего мониторинга Dynatrace или ActiveGates.

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

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

Службы, которые отображаются в пределах их собственного уровня в Smartscape, автоматически приводят к событиям уровня обслуживания(service level events). В случае, если служба сообщает о замедлении или ошибке, возникает проблема уровня воздействия службы(service impact level). Веб- , мобильные или пользовательские приложения отображаются на уровне приложения(application level) в Smartscape. Любые проблемы, с которыми сталкивается реальный пользователь, приводят к проблеме уровня воздействия приложения(application impact level).

Предположим, что Dynatrace обнаружила и сообщила о скачке процессора на одном из ваших отслеживаемых хостов. Ни одна служба или любое приложение не затрагивается. В этом случае проблема сообщается на уровне воздействия инфраструктуры. Если скачок ЦП отрицательно влияет на запущенную службу с точки зрения снижения производительности или увеличения числа ошибок, то к открытой проблеме добавляется событие уровня обслуживания. Затем проблема автоматически увеличивает свой уровень воздействия до уровня обслуживания. Обратите внимание, что каждый уровень воздействия не является исключительным. Проблема может затрагивать инфраструктуру, а также объекты уровня обслуживания. Таким образом, одна и та же проблема будет классифицирована как проблема инфраструктуры, так и проблема уровня обслуживания в ленте проблем. Еще один аспект, который следует отметить, заключается в том, что проблема может повлиять на службу, не затрагивая при этом никакой базовой инфраструктуры. В таких случаях проблема классифицируется как проблема только уровня обслуживания. Эта ситуация может возникнуть в бессерверных сценариях, а также в тех случаях, когда на любой базовой инфраструктуре не может быть найдена четкая первопричина.