Обнаружение и наименование сервиса

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

• Чтобы улучшить стандартное обнаружение, узнайте, как установить правила обнаружения службы.
• Чтобы улучшить обнаружение служб в вашей среде, вы можете настроить улучшения
• Если схема именования по умолчанию не соответствует вашим потребностям, вы можете изменить наименование своих служб.

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

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

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

Службы веб-запросов

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

Имя веб-сервера

Есть три разных термина — виртуальный хост , серверный блок и сайт — которые представляют схожие концепции в разных технологиях.

• Хостинг виртуального доменного имени объединяет веб-запросы от нескольких хостов, доменов и IP-адресов в единую конфигурацию на веб-сервере. Например, HTTP-сервер Apache позволяет настраивать www.astromkey.com, www.astromkey.atи www.astromkey.plвсе на одном виртуальном хосте .
• NGINX использует концепцию серверных блоков . В случае блока сервера необходимо настроить файл server_name.
• Сайт — это концепция, установленная в Microsoft IIS.

В средах на основе Kubernetes веб-серверы Apache и NGINX часто настраиваются только как IP-адрес localhostили просто как IP-адрес. В этих случаях Dynatrace автоматически использует автоматически определенное имя базового модуля в качестве имени веб-сервера, чтобы обеспечить более осмысленное представление из коробки.

Корень контекста

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

Идентификатор веб-приложения

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

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

Вы можете найти эти атрибуты в свойствах и тегах на странице обзора службы.

Dynatrace выбирает некоторые или все эти свойства, а затем создает на их основе уникальный сервис. Когда Dynatrace находит идентификатор веб-приложения, он использует этот идентификатор в качестве имени службы по умолчанию. В других случаях службы веб-запросов именуются на основе имени веб-сервера и корня контекста. Это означает, что если вы дадите сайту IIS правильное имя или определите имя для своего веб-приложения в web.xmlили package.json, Dynatrace подберет указанное вами имя.

Веб-сервисы

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

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

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

Услуги базы данных

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

Полный список служб баз данных, поддерживаемых Dynatrace, см. в разделе поддерживаемые службы баз данных .

Amazon RDS

Dynatrace создает уникальную отслеживаемую службу базы данных для каждого обнаруженного экземпляра Amazon RDS . Подробнее о настройке см. в разделе Настройка Dynatrace на Amazon Web Services.

Имя хоста, которое вы используете для подключения к Amazon RDS, должно совпадать с фактическим именем конечной точки.

Обмен сообщениями и очередь

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

Службы прослушивания очереди

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

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

Службы обмена сообщениями

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

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

Службы удаленного доступа

Услуги удаленного доступа делятся на две категории:

• Вызов удаленного метода (RMI)
• Удаленный вызов процедур (RPC)

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

Cлужба RMI

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

Служба RPC

Dynatrace отслеживает удаленные вызовы процедур SDK, Akka и AWSLambda. В отличие от RMI, Dynatrace создает отдельную службу RPC для каждой конечной точки службы.

Службы фоновой активности

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

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

Индивидуальные услуги

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

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

O* служба по умолчанию

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