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

Материал из Документация Ключ-АСТРОМ
Версия от 21:33, 18 июля 2026; IKuznetsov (обсуждение | вклад) (Новая страница: «= Правила обнаружения сервисов = При мониторинге с помощью ЕдиногоАгента развернутые приложения и связанные с ними микросервисы автоматически обнаруживаются Ключ-АСТРОМ на основе определенных свойств развертывания и конфигурации приложения, таких...»)
(разн.) ← Предыдущая версия | Текущая версия (разн.) | Следующая версия → (разн.)

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

При мониторинге с помощью ЕдиногоАгента развернутые приложения и связанные с ними микросервисы автоматически обнаруживаются Ключ-АСТРОМ на основе определенных свойств развертывания и конфигурации приложения, таких как идентификатор приложения, часть URL-адреса или имя сервера.

Атрибуты, используемые для обнаружения, отмечены звездочкой ✱ на странице обзора сервиса в разделе Свойства и теги.

В некоторых случаях качество данных, доступных Ключ-АСТРОМ, может быть недостаточным для высокоточной идентификации сервисов. Чтобы адаптировать стандартные методы обнаружения к вашей среде, вы можете создать новые правила или настроить параметры.

Управление обнаружением сервисов на основе правил

Правила преобразования можно использовать, например, для решения следующих задач:

  • Если идентификаторы веб-приложений содержат версию или дату сборки, вы можете определить правило, которое удаляет дату сборки/идентификатор из идентификатора веб-приложения.
  • Если имена серверов некорректно определены в базовой системе развертывания (например, в Apache HTTP или Nginx в средах AWS), можно задать стабильное имя веб-сервера и, следовательно, стабильную кластерную службу, содержащую все экземпляры.
  • Вы можете исправить некорректное использование корневого контекста в развернутом приложении.
  • В типичном веб-сервере используется концепция, называемая корневым контекстом, для разделения сервисов в зависимости от URL-адреса. Для некоторых технологий, таких как Node.js, корневой контекст недоступен или определен некорректно. Вы можете использовать наложенный корневой контекст и создавать отдельные сервисы для каждого из ваших приложений, вместо одного сервиса, содержащего несколько приложений.
  • При определении типа сервиса порт можно игнорировать. Это полезно, когда порт используется динамически, например, в приложениях Node.js.

Кроме того, правила можно экспортировать и импортировать из одной среды в другую.

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

Настройте правила обнаружения служб через пользовательский интерфейс

Правила обнаружения служб можно настроить через веб-интерфейс Ключ-АСТРОМ.

Предварительные требования

Ознакомьтесь с понятием полного и внешнего (непрозрачного) запроса.

Создать правило

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

Чтобы определить новое правило обнаружения сервисов через веб-интерфейс Ключ-АСТРОМ, необходимо задать его.

  1. Перейдите в Настройки.
  2. Разверните раздел Обнаружение служб и выберите тип запроса (правила для полных веб-запросов или правила для полных веб-сервисов, или правила для внешних веб-запросов или правила для внешних веб-сервисов).
  3. Выберите Добавить элемент и начните настройку параметров нового правила.
  4. Введите название правила.
  5. Чтобы изменить поведение обнаружения сервисов, включите хотя бы один из факторов, влияющих на идентификатор сервиса, чтобы правило сработало.
  6. Чтобы задать целевое применение правила, в разделе Условия настройте ограничения, связанные, например, с зоной управления, конкретными условиями или портом.
  7. Выберите Сохранить изменения.

Изменить правило

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

Чтобы отредактировать существующее правило через веб-интерфейс Ключ-АСТРОМ:

  1. Перейдите в Настройки.
  2. Разверните раздел Обнаружение служб и выберите тип запроса (правила для полных веб-запросов или правила для полных веб-сервисов, или правила для внешних веб-запросов или правила для внешних веб-сервисов).
  3. Разверните строку правила.
  4. Отредактируйте настройки правил.
  5. Выберите Сохранить изменения.

Удалить правило

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

Чтобы удалить правило обнаружения служб через веб-интерфейс Ключ-АСТРОМ:

  1. Перейдите в Настройки.
  2. Разверните раздел Обнаружение служб и выберите тип запроса (правила для полных веб-запросов или правила для полных веб-сервисов, или правила для внешних веб-запросов или правила для внешних веб-сервисов).
  3. В столбце Удалить для соответствующей строки правила выберите Удалить строку (Удалять).

Настройте правила обнаружения служб через API настроек

Вы также можете настроить правила обнаружения служб через API настроек.

Предварительные требования

  • Токен доступа: Вам потребуется токен доступа с правами чтения (settings.read) и записи (settings.write). Чтобы узнать, как его получить, см. раздел «Создание токена».
  • Идентификатор схемы: Для вызовов API настроек требуется идентификатор схемы параметров, которые вы хотите изменить.

Идентификатор схемы зависит от типа запроса, как показано в следующей таблице.

Тип запроса Идентификатор схемы
Полный веб-запрос builtin:service-detection.full-web-request
Полный веб-сервис builtin:service-detection.full-web-service
Внешний веб-запрос builtin:service-detection.external-web-request
Внешний веб-сервис builtin:service-detection.external-web-service

Каждая связанная схема содержит информацию о типе и параметрах для конкретного типа правила. Например, схема builtin:service-detection.full-web-request описывает параметры, включенные в полный объект настроек правила веб-запроса.

Перечислите все правила

Чтобы получить список существующих правил через API, используйте вызов GET objects. Укажите схему типа запроса в параметре запроса schemaIds.

GET /api/v2/settings/objects?schemaIds=builtin:service-detection.full-web-service

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

Просмотреть правило

Чтобы получить подробную информацию о конкретном правиле обнаружения сервиса (объекте настроек) через API, используйте вызов GET objects и укажите objectId правила, которое вы хотите получить.

GET /api/v2/settings/objects/{objectId}

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

Создать правило

Для создания нового правила обнаружения сервиса (или списка таких правил) через API используйте POST запрос к конечной точке объекта методом POST и укажите идентификатор схемы настроек и конфигурацию правила в теле запроса.

POST /api/v2/settings/objects

Пример JSON-кода для полного правила веб-запроса:

[
  {
    "schemaId": "builtin:service-detection.full-web-request",
    "scope": "environment",
    "value": {
      "enabled": true,
      "name": "Detect Application,Application-1 as the same",
      "description": "Example: Merge services",
      "managementZones": [ "-8445121454707515572" ],
      "idContributors": {
        "applicationId": {
          "enableIdContributor": true,
          "serviceIdContributor": {
            "contributionType": "TransformValue",
            "transformations": [
              {
                "transformationType": "REMOVE_NUMBERS",
                "minDigitCount": 1,
                "includeHexNumbers": false
              }
            ]
          }
        },
        "contextRoot": {
          "enableIdContributor": false
        },
        "serverName": {
          "enableIdContributor": false
        }
      },
      "conditions": [
        {
          "attribute": "ApplicationId",
          "compareOperationType": "StringStartsWith",
          "textValues": [ "application" ],
          "ignoreCase": false
        }
      ]
    }
  }
]

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

[
  {
    "code": 200,
    "objectId": "vu9U3hXa3q0AAAABACpidWlsdGluOnNlcnZpY2UtZGV0ZWN0aW9uLmZ1bGwtd2ViLXJlcXVlc3QABnRlbmFudAAGdGVuYW50ACQ2MTY5Y2QwNy0xM2Y1LTMyMDAtODc4ZC1hNDljNTRiMmM4Mma-71TeFdrerQ"
  }
]

Изменить правило

Для обновления существующего правила обнаружения сервиса через API используйте PUT запрос к конечной точке PUT, содержащей объект. Укажите objectId в URL-адресе путь к правилу, которое вы хотите обновить, а в теле запроса — обновленную конфигурацию правила.

PUT /api/v2/settings/objects/{objectId}

Чтобы получить текущее значение правила обнаружения сервиса, которое вы хотите изменить, используйте вызов GET objects. Затем вы можете создать JSON-объект для обновления, изменив тело ответа.

Мы рекомендуем использовать updateToken существующий объект, поскольку это обеспечивает корректное версионирование ваших настроек.

Пример JSON-кода для полного правила веб-запроса:

{
  "updateToken": "vu9U3hXY3q0ATAAkOWFiNGI2ZDAtYWFhNC00M2IwLWEzZDYtNDQ2OTZkNzIyYzE5ACRmMTA1NTJlMC01M2Q5LTExZWQtODAwMS0wMTAwMDAwMDAwMDO-71TeFdjerQ",
  "value": {
    "enabled": true,
    "name": "Detect Application, Application-1 as the same",
    "description": "Example: Merge services",
    "managementZones": [ "-8445121454707515572" ],
    "idContributors": {
      "applicationId": {
        "enableIdContributor": true,
        "serviceIdContributor": {
          "contributionType": "TransformValue",
          "transformations": [
            {
              "transformationType": "REMOVE_NUMBERS",
              "minDigitCount": 1,
              "includeHexNumbers": false
            }
          ]
        }
      },
      "contextRoot": {
        "enableIdContributor": false
      },
      "serverName": {
        "enableIdContributor": false
      }
    },
    "conditions": [
      {
        "attribute": "ApplicationId",
        "compareOperationType": "StringStartsWith",
        "textValues": [ "application" ],
        "ignoreCase": true
      }
    ]
  }
}

Удалить правило

Для удаления правила обнаружения сервиса через API используйте DELETE запрос к конечной точке DELETE объекта. Укажите путь objectId к удаляемому правилу в URL-адресе.

DELETE /api/v2/settings/objects/{objectId}

Чтобы получить идентификатор objectId правила, которое вы хотите удалить, используйте вызов метода GET objects.

Правила переупорядочивания

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

[
  {
    "schemaId": "builtin:service-detection.full-web-request",
    "scope": "environment",
    "value": {
      "name": "New top rule",
      "...": "..."
    },
    "insertAfter": ""
  }
]

Примеры конфигурации обнаружения сервисов

Раздельные, полностью отслеживаемые службы обработки веб-запросов на основе URL-адреса или наложенного корневого контекста

Для некоторых технологий, отслеживаемых Ключ-АСТРОМ, корневой контекст не поддерживается. По умолчанию определяется только одна служба на группу процессов. Вы можете изменить обнаружение службы, наложив корневой контекст на полностью отслеживаемый веб-запрос.

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

Настройка правил через веб-интерфейс:

  1. Перейдите в Настройки.
  2. Разверните раздел Обнаружение служб и выберите Правила полных веб-запросов.
  3. В правилах полного веб-запроса выберите Добавить элемент.
  4. Настройте параметры следующим образом.
    • Введите название правила.
    • Необязательно: Введите описание.
    • Перейдите в корневой каталог контекста URL и включите параметр Преобразовывать это значение перед тем, как разрешить ему учитываться в идентификаторе службы.
    • В списке Тип вклада выберите Использовать преобразованный URL-путь.
    • В поле Сегменты для копирования из URL-адреса введите количество сегментов URL-адреса, которые необходимо сохранить (1).
    • Перейдите в раздел Условия и выберите Добавить элемент.
    • В списке Получить значение этого атрибута выберите Путь URL.
    • В списке Применить эту операцию выберите Начинается с.
    • Перейдите в раздел Значения, выберите Добавить элемент, затем введите blog/.
  5. Выберите Сохранить изменения.

Объединение данных приложения в единый сервис на основе значения идентификатора приложения

Когда входящие данные нестабильны или недостаточно конкретны, можно использовать правила обнаружения сервисов для объединения сервисов, например, кластеров Apache HTTP в AWS без надлежащего виртуального хоста или идентификаторов веб-приложений, содержащих дату сборки.

В этом примере мы хотим объединить в одном сервисе все входящие данные от приложений, идентификаторы которых начинаются с application.

Настройка правил через веб-интерфейс:

  1. Перейдите в Настройки.
  2. Разверните раздел Обнаружение служб и выберите Правила полных веб-запросов.
  3. В правилах полного веб-запроса выберите Добавить элемент.
  4. Настройте параметры следующим образом.
    • Введите название правила.
    • Необязательно: Введите описание.
    • Выберите Задать зону управления и выберите зону управления для списка.
    • Перейдите к разделу Идентификатор приложения и включите параметр Преобразовывать это значение перед тем, как разрешить его использование для присвоения идентификатора службы.
    • В списке Тип взноса выберите Использовать преобразованное значение.
    • Перейдите в раздел Преобразования и выберите Добавить элемент.
    • В списке Тип преобразования выберите Удалить числа.
    • Введите минимальное количество цифр (1).
    • Перейдите в раздел Условия и выберите Добавить элемент.
    • В списке Получить значение этого атрибута выберите Идентификатор приложения.
    • В списке Применить эту операцию выберите Начинается с.
    • Перейдите в раздел Значения, выберите Добавить элемент, затем введите application.
  5. Выберите Сохранить изменения.

Отдельные сервисы для «общедоступных сетевых сервисов» на основе URL-адреса

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

Настройка правил через веб-интерфейс:

  1. Перейдите в Настройки.
  2. Разверните раздел Обнаружение служб и выберите Правила внешних веб-запросов.
  3. В правилах внешних веб-запросов выберите Добавить элемент.
  4. Настройте параметры следующим образом.
    • Введите название правила.
    • Необязательно: Введите описание.
    • Перейдите в корневой каталог контекста URL и включите параметр Преобразовывать это значение перед тем, как разрешить ему учитываться в идентификаторе службы.
    • В списке Тип вклада выберите Использовать преобразованный URL-путь.
    • В поле Сегменты для копирования из URL-адреса введите количество сегментов URL-адреса, которые необходимо сохранить (1).
    • Перейдите в раздел Имя публичного домена и отключите порт.
    • Перейдите в раздел Условия и выберите Добавить элемент.
    • В списке Получить значение этого атрибута выберите Домен верхнего уровня.
    • В выпадающем списке Применить эту операцию выберите Заканчивается на.
    • Перейдите в раздел Значения, выберите Добавить элемент, затем введите dynatrace.com.
    • Чтобы игнорировать регистр символов, включите параметр Игнорировать регистр.
  5. Выберите Сохранить изменения.

Раздельные сервисы для «общедоступных сетевых сервисов» на основе поддоменов

Если в рамках одной службы не следует объединять разные конечные точки (например, support.dynatrace.com и blog.dynatrace.com), вы можете указать Ключ-АСТРОМ обнаруживать несколько служб из одного домена на основе обнаруженного имени хоста, а не имени домена запроса.

Настройка правил через веб-интерфейс:

  1. Перейдите в Настройки.
  2. Разверните раздел Обнаружение служб и выберите Правила внешних веб-запросов.
  3. В правилах внешних веб-запросов выберите Добавить элемент.
  4. Настройте параметры следующим образом.
    • Введите название правила.
    • Необязательно: Введите описание.
    • Перейдите в раздел Имя общедоступного домена и включите параметр Преобразовывать это значение перед тем, как разрешить его использование для идентификатора службы.
    • В списке Тип взноса выберите Использовать исходное значение.
    • Включите опцию Копировать с имени хоста.
    • Отключите порт.
    • Перейдите в раздел Условия и выберите Добавить элемент.
    • В списке Получить значение этого атрибута выберите Домен верхнего уровня.
    • В выпадающем списке Применить эту операцию выберите Заканчивается на.
    • Перейдите в раздел Значения, выберите Добавить элемент, затем введите dynatrace.com.
    • Чтобы игнорировать регистр символов, включите параметр Игнорировать регистр.
  5. Выберите Сохранить изменения.

Улучшено обнаружение сервисов

Проблемы с именованием веб-серверов

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

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

Для решения подобных проблем с localhost используйте переменную среды для определения имен виртуальных хостов: установите DT_LOCALTOVIRTUALHOSTNAME для каждого процесса веб-сервера любое значение. Ключ-АСТРОМ подхватит эти имена и будет использовать их вместо существующих имен виртуальных хостов localhost. Такой подход гарантирует, что несколько физических хостов будут сообщать об одном и том же виртуальном хосте, и, таким образом, вы получите одну службу с несколькими экземплярами, по одному экземпляру на каждый физический хост.

Определите идентификаторы веб-приложений

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

Вращающиеся и анонимные порты

Ключ-АСТРОМ учитывает порт прослушивания каждого веб-сервиса при именовании и обнаружении запросов. В некоторых случаях эти порты бессмысленны или случайны, меняясь при каждом перезапуске. Это особенно актуально, если вы используете балансировщик нагрузки, который динамически назначает порты процессам приложений, как это часто бывает в сценариях Node.js.

Чтобы исправить это, установите переменную окружения DT_IGNOREDYNAMICPORT=true. Это удалит порт из системы обнаружения и заменит его на *.

Часто задаваемые вопросы

Что произойдет, если после создания/редактирования/удаления правила служба не получит новых данных? При создании, редактировании или удалении правила данные, отслеживаемые после изменения правил обнаружения служб, агрегируются и назначаются службам в зависимости от конфигурации правила. Если служба перестает получать данные, ее исторические данные остаются доступными (например, для построения графиков). Вы по-прежнему можете видеть службу и ее трассировки в своей среде.