Применение АппОптима / Сервисы / Обнаружение и наименование сервиса
АппОптима автоматически определяет серверные службы ваших приложений и присваивает им имена на основе конкретных свойств развертывания и конфигурации вашего приложения.
- Чтобы улучшить стандартное обнаружение, узнайте, как установить правила обнаружения службы.
- Чтобы улучшить обнаружение служб в вашей среде, вы можете настроить улучшения
- Если схема именования по умолчанию не соответствует вашим потребностям, вы можете изменить наименование своих служб.
Поскольку сервисные ландшафты могут стать довольно сложными, АппОптима автоматически классифицирует сервисы на основе их зависимостей от других объектов, таких как сервисы или приложения.
АппОптима автоматически группирует связанные процессы в группы процессов . Когда АппОптима обнаруживает несколько групп процессов, предполагается, что группы процессов представляют отдельные приложения или, по крайней мере, отдельные логические части одного приложения. Таким образом, группы процессов представляют собой границы содержащихся в них служб.
Когда АппОптима обнаруживает одну и ту же службу в нескольких процессах в одной группе процессов, она представляет службу как единую службу, работающую в нескольких процессах или хостах. И наоборот, если АппОптима обнаруживает кажущуюся идентичной службу в нескольких группах процессов, она представляет отдельные экземпляры службы как отдельные службы, даже если службы кажутся одинаковыми. По этой причине иногда имеет смысл настроить, как АппОптима обнаруживает группы процессов .
Службы веб-запросов
Службы веб-запросов обслуживают веб-приложения, которые вы развертываете либо через веб-сервер (например, Apache, IIS или NGINX), либо в веб-контейнерах (например, Java, .NET, Node.js или PHP). АппОптима учитывает три отдельных понятия при идентификации и именовании веб-сервисов: имя веб-сервера , корневой контекст и идентификатор веб-приложения .
Имя веб-сервера
Есть три разных термина — виртуальный хост , серверный блок и сайт — которые представляют схожие концепции в разных технологиях.
- Хостинг виртуального доменного имени объединяет веб-запросы от нескольких хостов, доменов и IP-адресов в единую конфигурацию на веб-сервере. Например, HTTP-сервер Apache позволяет настраивать
www.astromkey.com,www.astromkey.atиwww.astromkey.plвсе на одном виртуальном хосте . - NGINX использует концепцию серверных блоков . В случае блока сервера необходимо настроить файл
server_name. - Сайт — это концепция, установленная в Microsoft IIS.
В средах на основе Kubernetes веб-серверы Apache и NGINX часто настраиваются только как IP-адрес localhostили просто как IP-адрес. В этих случаях АппОптима автоматически использует автоматически определенное имя базового модуля в качестве имени веб-сервера, чтобы обеспечить более осмысленное представление из коробки.
Корень контекста
В любом заданном веб-контейнере у вас может быть несколько приложений в нескольких каталогах. Например /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>. Это не отменит упомянутые выше параметры именования — оно используется по умолчанию для случаев, когда идентификатор приложения недоступен.
Вы можете найти эти атрибуты в свойствах и тегах на странице обзора службы.
АппОптима выбирает некоторые или все эти свойства, а затем создает на их основе уникальный сервис. Когда АппОптима находит идентификатор веб-приложения, он использует этот идентификатор в качестве имени службы по умолчанию. В других случаях службы веб-запросов именуются на основе имени веб-сервера и корня контекста. Это означает, что если вы дадите сайту IIS правильное имя или определите имя для своего веб-приложения в web.xmlили package.json, АппОптима подберет указанное вами имя.
Веб-сервисы
Веб-службы определяются языком описания веб-служб (WSDL), который является частью вашего развертывания. WSDL определяет службы, способ их вызова и имена служб. АппОптима выбирает имена сервисов вместе со targetNamespaceзначениями и объединяет эти значения для уникальной идентификации каждого сервиса.
АппОптима обнаруживает веб-службы на основе конкретных технологий. Дополнительные сведения о готовых платформах веб-служб, отслеживаемых АппОптима, см. в разделе поддерживаемые платформы веб-служб для Java и .NET .
Иногда технически невозможно легко определить имя веб-службы. В таких случаях АппОптима использует конечную точку веб-службы, а не имя.
Услуги базы данных
Когда АппОптима обнаруживает, что ваше приложение отправляет запросы к базе данных, оно определяет имя базы данных или схемы, поставщика базы данных и IP-адрес/порт базы данных. Эта информация используется для определения уникальной отслеживаемой службы базы данных и, по возможности, определения того, в каком процессе запускается служба базы данных.
Полный список служб баз данных, поддерживаемых АппОптима, см. в разделе поддерживаемые службы баз данных .
Amazon RDS
АппОптима создает уникальную отслеживаемую службу базы данных для каждого обнаруженного экземпляра Amazon RDS . Подробнее о настройке см. в разделе Настройка АппОптима на Amazon Web Services.
Имя хоста, которое вы используете для подключения к Amazon RDS, должно совпадать с фактическим именем конечной точки.
Обмен сообщениями и очередь
АппОптима обнаруживает прослушиватели очередей и тем в ваших приложениях и идентифицирует их на основе имени класса прослушивателя. См. поддерживаемые службы обмена сообщениями .
Службы прослушивания очереди
Службы прослушивания очередей сообщают вам, какие очереди или темы вы слушаете. Это легкие сервисы, у которых нет времени отклика. Они сообщают вам, сколько сообщений было исключено из очереди или темы; они ничего не говорят вам об обработке сообщений — этим занимаются службы обмена сообщениями.
Если АппОптима автоматически обнаруживает прослушиватель сообщений на основе событий, за службой прослушивания очереди всегда следует служба обмена сообщениями, которая дает вам представление о деталях сообщения. Однако, если вы просто отслеживаете очередь и не просматриваете сведения о сообщениях, служба прослушивателя очереди может существовать сама по себе.
Службы обмена сообщениями
Службы обмена сообщениями (потребительские службы) обрабатывают сообщения из очереди или темы. Службе обмена сообщениями всегда предшествует служба прослушивателя очереди, которая прослушивает очередь или тему, из которой пришло сообщение.
Если ваше приложение использует обработчики очередей сообщений, не основанные на событиях, или удаляет сообщения из очереди в пакетном режиме , АппОптима не сможет автоматически определить, как обрабатываются сообщения. Чтобы получить представление об этом, вы должны создать собственный сервис для обработки сообщений.
Службы удаленного доступа
Услуги удаленного доступа делятся на две категории:
- Вызов удаленного метода (RMI)
- Удаленный вызов процедур (RPC)
Список служб удаленного взаимодействия, поддерживаемых АппОптима, см. в разделе поддерживаемые службы удаленного взаимодействия .
Cлужба RMI
В мире Java удаленный вызов метода (RMI) является распространенным средством связи, используемым JVM. Поскольку в одной JVM может быть много динамически создаваемых серверов RMI, АппОптима создает только одну службу RMI для каждой группы процессов. Однако это не означает, что вы теряете видимость своих служб RMI; АппОптима отслеживает и контролирует каждый класс RMI как отдельный тип запроса.
Служба RPC
АппОптима отслеживает удаленные вызовы процедур SDK, Akka и AWSLambda. В отличие от RMI, АппОптима создает отдельную службу RPC для каждой конечной точки службы.
Службы фоновой активности
Во многих случаях службы вызываются потоками, работающими в фоновом режиме вашего приложения или другого приложения. Эти запросы, выполняемые в фоновых потоках, представляют собой фоновую активность отслеживаемых групп процессов, которые вызывают другие службы. Они также отслеживают исходящие сообщения в очередях.
Например, если у вас есть фоновый поток в Tomcat, который отправляет веб-запросы к Apache, АппОптима представляет его как службу фоновой активности Tomcat. Вы сможете увидеть, какие запросы Tomcat отправляет вашему Apache, проанализировав время отклика службы фоновой активности Tomcat.
Индивидуальные услуги
Специальные сервисы позволяют вам инструментировать приложение, которое не построено на стандартных технологиях. Вы также можете точно настроить свою систему и настроить конкретный метод, класс или интерфейс, которые вас интересуют. Вы можете создавать собственные службы для Java, .NET и PHP.
Чтобы узнать, как создавать настраиваемые службы, см. раздел Определение настраиваемых служб .
O* служба по умолчанию
Служба по умолчанию * создается, когда АппОптима обнаруживает вызов службы для вложения span. Это всего лишь служба-заполнитель, необходимая для построения допустимой древовидной структуры. Обратите внимание, что АппОптима в настоящее время не поддерживает обнаружение служб для интервалов.