Унифицированные службы

АппОптима версия 1.274

Тип службы «Единая служба» представляет службы, обнаруженные на основе интервалов, и создан с учетом Cloud Native и OpenTelemetry. Унифицированные службы обеспечивают безагентную поддержку данных из API приема, например API приема трассировки .

Унифицированные службы, полученные через API-интерфейсы приема, перечислены вместе с другими службами и в топологии . После обогащения трассировок информацией о топологии взаимосвязи сопоставляются в вашей среде, обеспечивая полное вертикальное и горизонтальное представление топологии и упрощая анализ первопричин проблем.
АппОптима рассчитывает время отклика, пропускную способность и показатели частоты сбоев для этих сервисов, которые доступны через анализ служб.
ИИ анализирует проблемы, связанные с базовыми ресурсами, с помощью готовых базовых показателей. Кроме того, вы можете создавать собственные оповещения на основе информации лога.
Вы можете искать отслеживаемые объекты в АппОптима по имени диапазона.
Вы можете отслеживать сетки сервисов Istio .
Распределенные трассировки, логи и события помещаются в контекст.
Вы можете отслеживать и настраивать оповещения для автоматически обнаруженных конечных точек.

Прежде чем вы начнете

Если вы уже используете тип службы Span ( span:service) в своей среде, мы рекомендуем перенести ваши экземпляры на тип службы Unified . Чтобы автоматически перенести экземпляры, включите обнаружение унифицированной службы.

Перейдите в настройки .
Выберите «Обнаружение службы» .
Выберите унифицированные службы для OpenTelemetry и включите параметр «Включить унифицированные службы» .

Критические изменения:

Миграция на другой тип службы повлияет на существующие запросы метрик API, панели мониторинга, а также имена служб и запросов.

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

Правила обнаружения унифицированных служб

Затем создается унифицированная служба, когда АппОптима обнаруживает промежутки, обработанные API . При обнаружении унифицированной службы следующие атрибуты ресурса оцениваются в следующем порядке. Значение первого соответствующего атрибута определяет имя объединенной службы. Обратите внимание, что замаскированные/заблокированные атрибуты игнорируются при обнаружении службы.

Оцениваемый атрибут	Наименование службы
`k8s.workload.name`	Значение атрибута¹
`dt.kubernetes.workload.name`	Значение атрибута¹
`istio.canonical_service`	Значение атрибута
`service.name`	Значение атрибута

¹Если атрибут k8s.namespace.nameприсутствует, для каждого пространства имен создается уникальная служба с сохранением того же имени службы. Пространство имен можно найти в обзоре службы «Свойства и теги» .

Правила обнаружения конечных точек

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

Следующие атрибуты диапазона оцениваются в следующем порядке.

Технологии	Оцениваемый атрибут	Имя конечной точки
gRPC	`rpc.service`(или `rpc.method`)	Значение атрибута
HTTP	`http.route`	Значение атрибута
Веб-серверы (NGINX, Apache) и входные шлюзы Istio.		`"/"`как одно статическое имя конечной точки
Бессерверные функции (FaaS)		`"invoke"`как единая статическая конечная точка
Неспецифические технологии	`code.namespace`или`code.function` `span.name` `span.kind == server`или`span.kind == consumer`	Значение атрибута
HTTP	`http.method`	Значение атрибута
Неспецифические технологии	`span.kind == server`или`span.kind == consumer`	Значение атрибута

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

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

Управление мониторингом конечных точек

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

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

Ключ метрики	Имя и описание	Единица	Агрегации	Мониторинг потребления
builtin:service.request.count	Общее количество запросов на обслуживание Количество запросов, полученных данной службой.	Количество	автозначение	DDU
builtin:service.request.failure_count	Счетчик отказов единого сервиса Количество неудачных запросов, полученных данной службой.	Количество	автозначение	Хост-юниты
builtin:service.request.response_time	Единое время ответа на запрос на обслуживание Время отклика службы измеряется в мс на стороне сервера (измерения на стороне сервера не включают, например, время прокси-сервера и время работы в сети). Время ответа — это время, пока ответ не будет отправлен вызывающему приложению, процессу или другой службе. Он не включает дальнейшую асинхронную обработку. Чтобы узнать, как	Миллисекунды	autocountmaxmedianminpercentile	DDU

Уровень среды:

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

Перейдите в настройки .
Выберите «Обнаружение службы» .
Выберите «Метрики конечных точек унифицированных служб» и включите или выключите «Включить метрики конечных точек» .

Уровень службы:

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

Перейдите в Службы .
необязательно На странице Службы в столбце Тип службы установите флажок Единая служба .
Найдите и выберите единую службу, для которого вы хотите настроить мониторинг конечных точек.
На странице обзора единой службы выберите Дополнительно ( … ) > Настройки .
На странице настроек службы выберите Метрики конечной точки .
На странице «Метрики конечных точек унифицированных служб» включите или выключите параметр «Включить метрики конечных точек» .

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

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

Чтобы АппОптима правильно коррелировала сигналы наблюдения, унифицированный сервис должен быть обнаружен на основе промежутков. Убедитесь, что логи содержат атрибут trace_idили trace.id.

Что сохраняется?

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

Нужно ли мне мигрировать непрозрачные сервисы?

Нет. Непрозрачные сервисы (такие как исходящие сторонние сервисы Python, Rust или Ruby) автоматически переводятся в тип сервиса Unified .

Нужно ли мне проверять определения зон управления?

Да, вам необходимо просмотреть существующие правила зоны управления, нацеленные на метрики с измерением service.name, например зоны управления на основе процессов или групп процессов. Результаты правила зоны управления зависят от соответствия между основным объектом метрики и отслеживаемым объектом в зоне управления. Если основной объект метрики не соответствует отслеживаемому объекту, правило зоны управления не дает результатов. Поскольку унифицированные службы используют метрики, в которых основной объект является адаптивным, мы рекомендуем изменить такие правила зоны управления, включив в них унифицированные службы. Обратите внимание, что логи не затрагиваются напрямую.

В следующем примере текстовое правило выбора объекта для существующей зоны управления обеспечивает доступ ко всем группам процессов с этим aws-az-1тегом.

type("PROCESS_GROUP"),tag("aws-az-1")

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

type(service),fromRelationship.runsOn(type("PROCESS_GROUP"),tag("aws-az-1"))