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. Это удаляет порт из обнаружения и заменяет его на *.