OpenTelemetry (Beta) opentelemetry-apm

A Adobe está substituindo a integração do Application Performance Monitoring (APM) incorporada ao AEM as a Cloud Service pela OpenTelemetry, uma abordagem aberta padrão do setor para observabilidade suportada por todas as principais plataformas de monitoramento.

Atualmente, o AEM as a Cloud Service inclui uma integração de APM integrada, gerenciada totalmente pela Adobe. À medida que essa integração for substituída, você precisará trazer seu próprio ponto de extremidade APM — uma plataforma de fornecedor que aceite dados OpenTelemetry ou um back-end autohospedado (local) compatível com OpenTelemetry.

Benefícios dessa alteração benefits

Visão geral overview

O AEM as a Cloud Service pode emitir a telemetria de seu aplicativo usando OpenTelemetry, uma abordagem aberta padrão do setor para observabilidade, e encaminhá-la para o provedor de APM de sua escolha. Isso permite monitorar o aplicativo AEM junto com o restante dos sistemas nas ferramentas que suas equipes já usam.

Motivos comuns para usar essa integração incluem investigar solicitações lentas ou com falha, rastrear a integridade da JVM e o uso de recursos ao longo do tempo, criar painéis e alertas para seus níveis do AEM e correlacionar o comportamento do AEM com o restante dos serviços durante um incidente, tudo sem sair das ferramentas de monitoramento que suas equipes já usam.

A telemetria a seguir está no escopo:

​* Rastreamentos — rastreamentos distribuídos de solicitações manipuladas pelo seu aplicativo AEM.
​* Métricas — métricas do aplicativo, como métricas de tempo de execução JVM (memória, coleta de lixo, threads) e taxas de solicitação HTTP de entrada, latências e taxas de erro.
​* Logs — os logs do seu aplicativo AEM, enviados usando o sinal de logs do OpenTelemetry. Os logs são opcionais e podem ser alternados independentemente de rastreamentos e métricas.

O Encaminhamento de Log continua sendo suportado por meio de seu mecanismo separado existente, e não é afetado por essa integração.

Versões suportadas do OpenTelemetry supported-versions

O agente OpenTelemetry é executado como parte do tempo de execução do Cloud Service. A Adobe fornece e mantém a atualização, de modo que você mesmo não precisa instalá-la, gerenciá-la ou atualizá-la. A versão de patch específica pode mudar à medida que o Adobe atualiza o agente.

Variantes de OpenTelemetry compatíveis supported-variants

Seu aplicativo AEM pode ser instrumentado com qualquer uma das seguintes variantes do agente OpenTelemetry (distribuições), todas com base na versão acima. Escolha a variante que se adapta à sua ferramenta; consulte a documentação de cada projeto para obter detalhes:

A variante upstream padrão funciona com qualquer fornecedor de APM. As variantes do Grafana e do Splunk adicionam instrumentação específica do fornecedor e padrões para essas plataformas.

Fornecedores de APM apm-vendors

Você pode enviar sua telemetria para qualquer fornecedor do Application Performance Monitoring que aceite dados OpenTelemetry por OTLP/HTTPS. Isso é independente da variante OpenTelemetry escolhida. Os fornecedores com suporte a OTLP/HTTPS incluem:

​* New Relic
​* Grafana Cloud
​* Nuvem de observação do Splunk
​* Dynatrace
​* Datadog
​* Traço0
​* Colmeia
​* Observabilidade Elástica
​* Lógica Sumo
​* Observabilidade do ServiceNow Cloud

Esta lista não é exaustiva — qualquer back-end que exponha um endpoint OTLP/HTTPS pode ser usado.

Ambientes compatíveis supported-environments

Você pode habilitar essa integração nos ambientes de produção, estágio e desenvolvimento do Cloud Manager. Cada ambiente é habilitado individualmente — consulte Etapa 1. Os ambientes de desenvolvimento rápido (RDE) não são compatíveis.

Conectividade de rede network-connectivity

O terminal do seu provedor de APM deve estar acessível no seu ambiente AEM as a Cloud Service por HTTPS.

Se o seu ponto de extremidade APM for privado ou se você precisar que o tráfego externo saia de um endereço IP estável e conhecido, essa integração oferecerá suporte ao Sistema de Rede Avançado com saída dedicada. Consulte Rede Avançada para saber como habilitá-la.

Quais dados são enviados what-data-is-sent

Somente os rastreamentos, as métricas e os logs (se habilitados) gerados pelo seu aplicativo AEM são enviados para o seu provedor de APM. Os exemplos a seguir ilustram o tipo de dados que você pode esperar.

Rastreamentos — abrange as solicitações manipuladas pelo seu aplicativo, incluindo:

​* Extensões de solicitação HTTP de entrada, nomeadas por método e rota (por exemplo, GET /content/...).
​* O servlet e o banco de dados de saída (JDBC) abrangem gerados enquanto uma solicitação é processada.

O agendador interno de alto volume e a atividade de investigação de integridade (por exemplo, tarefas Quartz) são filtrados para que os rastreamentos permaneçam focados nas solicitações de aplicativos. Estrutura otimizada do AEM - as extensões internas — como a resolução de recursos do Sling, os serviços OSGi ou o acesso ao JCR — não são emitidas nesta versão.

Métricas — as métricas de tempo de execução JVM e do servidor HTTP, que usam nomes de métricas OpenTelemetry padrão, incluindo:

​* Tempo de execução JVM: jvm.memory.used, jvm.gc.duration, jvm.thread.count e jvm.cpu.recent_utilization.
​* Servidor HTTP: http.server.request.duration (taxa de solicitação, percentis de latência e taxa de erro são derivados deste histograma).

Logs — as entradas de log do seu aplicativo AEM, enviadas usando o sinal de logs do OpenTelemetry, quando habilitadas. As entradas de log possuem os mesmos atributos de recurso que os rastreamentos e as métricas (service.name, deployment.environment), para que possam ser correlacionadas a elas.

Os logs enviados dessa maneira são independentes do Encaminhamento de Logs — consulte Visão geral para saber por que habilitar ambos para o mesmo destino causa duplicatas.

Como a telemetria é identificada — cada rastreamento e métrica carrega atributos de recurso que identificam sua origem, incluindo:

​* service.name — identifica seu programa, ambiente, serviço e camada (por exemplo, cm-p<program>-e<environment>-aem-publish-prod).
​* deployment.environment — o tipo de ambiente (por exemplo, prod ou stage).

As informações sobre o tempo de execução do Cloud Service e a plataforma que hospeda seu aplicativo — como nomes de host internos, endereços, identificadores de container e detalhes do sistema operacional ou do processo — são removidas antes que os dados saiam do ambiente.

Configurar a integração set-up

Etapa 1: Habilitar a integração request-access

Adicione um arquivo config/otel.yaml ao repositório do Pipeline de configuração do Cloud Manager. No mínimo, especifique:

​* Os tipos de ambiente aos quais essa configuração se aplica (por exemplo, stage e prod).
​* O tipo do seu provedor de APM e o URL do terminal OTLP/HTTPS (incluindo a região, se aplicável).
​* O método de autenticação que seu provedor usa (consulte Etapa 2).

Consulte Exemplo de configuração abaixo para obter o formato de arquivo exato, incluindo exemplos para New Relic, Dynatrace, Datadog, Dash0 e pontos de extremidade genéricos ou auto-hospedados.

Etapa 2: configurar sua credencial de autenticação configure-credential

Forneça a credencial que seu provedor de APM requer declarando uma variável de ambiente secreta chamada OTEL_CUSTOMER_AUTH no Cloud Manager. Defina o Serviço Aplicado como Todos para que a credencial esteja disponível para os níveis de criação, publicação e visualização.

Para adicionar ou atualizar variáveis de ambiente, você deve ser membro da função de Gerente de Implantação. Para obter o procedimento completo, consulte Variáveis de ambiente no Cloud Manager.

Defina o valor de acordo com o método de autenticação do provedor:

Configurações específicas do provedor provider-specific

A tabela a seguir resume o endpoint e a autenticação de alguns provedores comuns. Sempre confirme os valores atuais na documentação do seu provedor. Para provedores que usam um cabeçalho personalizado (por exemplo, New Relic e Datadog), defina OTEL_CUSTOMER_AUTH somente como o valor bruto da chave e defina authHeaderName no arquivo de configuração com o nome de cabeçalho correto (consulte Exemplo de configuração).

Exemplo de configuração example-configuration

Adicione um arquivo como um dos seguintes exemplos a config/otel.yaml no repositório do Pipeline de configuração, com base no seu provedor de Configurações específicas do provedor.

New Relic:

kind: "Otel"
version: "v1"
metadata:
  envTypes:
    - "stage"
    - "prod"
data:
  enabled: true
  type: "newrelic"
  endpoint: "https://otlp.nr-data.net"   # https://otlp.eu01.nr-data.net for the EU region
  authHeaderValue: "${{secrets.OTEL_CUSTOMER_AUTH}}"
  metrics: true   # optional
  logs: true      # optional — see Overview for the Log Forwarding duplicate-message warning

Dynatrace:

kind: "Otel"
version: "v1"
metadata:
  envTypes:
    - "stage"
    - "prod"
data:
  enabled: true
  type: "dynatrace"
  endpoint: "https://{your-environment-id}.live.dynatrace.com/api/v2/otlp"
  authHeaderValue: "${{secrets.OTEL_CUSTOMER_AUTH}}"   # the secret's value must be "Api-Token <token>"
  metrics: true
  logs: true

Datadog:

kind: "Otel"
version: "v1"
metadata:
  envTypes:
    - "stage"
    - "prod"
data:
  enabled: true
  type: "generic"
  endpoint: "https://otlp.<your-datadog-site>"   # for example, https://otlp.datadoghq.com
  authHeaderName: "dd-api-key"
  authHeaderValue: "${{secrets.OTEL_CUSTOMER_AUTH}}"   # the secret's value is the raw API key, no prefix
  metrics: true
  logs: true

Traço0:

kind: "Otel"
version: "v1"
metadata:
  envTypes:
    - "stage"
    - "prod"
data:
  enabled: true
  type: "generic"
  endpoint: "https://ingress.<region>.aws.dash0.com:4318"
  authHeaderValue: "${{secrets.OTEL_CUSTOMER_AUTH}}"   # the secret's value must be "Bearer <token>"
  metrics: true
  logs: true

Ponto de extremidade genérico ou auto-hospedado (por exemplo, um coletor OpenTelemetry local):

kind: "Otel"
version: "v1"
metadata:
  envTypes:
    - "stage"
    - "prod"
data:
  enabled: true
  type: "generic"
  endpoint: "https://<your-otlp-endpoint>"
  authHeaderValue: "${{secrets.OTEL_CUSTOMER_AUTH}}"   # for example, "Basic <base64(user:pass)>"
  metrics: true
  logs: true

Rede Avançada (saída dedicada) — para um ponto de extremidade privado ou um que exija o tráfego de saída de um endereço IP estável e conhecido (consulte Conectividade de rede):

kind: "Otel"
version: "v1"
metadata:
  envTypes:
    - "stage"
    - "prod"
data:
  enabled: true
  type: "generic"
  endpoint: "https://<your-private-otlp-endpoint>"
  authHeaderValue: "${{secrets.OTEL_CUSTOMER_AUTH}}"
  metrics: true
  logs: true
  advancedNetworking: true   # routes this endpoint's egress through Advanced Networking instead of direct internet egress

Etapa 3: implantar deploy

A integração entra em vigor na próxima implantação do seu ambiente, ou seja, na próxima vez que um pipeline de implantação for executado para o ambiente no Cloud Manager (por exemplo, uma implantação de pilha completa). Se o ambiente não foi implantado desde que você adicionou o arquivo config/otel.yaml e definiu a credencial, execute uma implantação para ativá-lo.

Após a implantação, os rastreamentos, as métricas e os logs (se ativados) do aplicativo AEM começam a aparecer no provedor de APM. Use a Etapa 4 para confirmar.

Etapa 4: verificar a integração verify

Como a telemetria é enviada para seu próprio provedor de APM, você confirma a integração com as ferramentas de seu provedor; a Adobe não exibe esses dados de volta para você.

Depois que uma implantação for concluída, aguarde alguns minutos para a chegada dos dados e verifique o provedor de APM quanto ao seguinte:

​* Rastreamentos — novos intervalos para seus serviços da AEM. Por exemplo, pesquise por service.name do seu nível de criação ou publicação ou por extensões de solicitação HTTP de entrada.
​* Métricas — jvm.* e http.server.* métricas de entrada para seus serviços.
​* Logs (se habilitado) — entradas de log de entrada para seus serviços da AEM.

Se esses dados forem exibidos, a integração está funcionando.

Resolução de problemas troubleshooting

Se a telemetria não aparecer no seu provedor de APM, verifique o seguinte:

Se a telemetria ainda não aparecer após essas verificações, contate aemcs-apm-beta@adobe.com com os detalhes do programa e do ambiente.

Perguntas frequentes faq

Por que esta alteração está acontecendo?

Os clientes do AEM as a Cloud Service solicitaram métricas e dados operacionais adicionais, bem como rastreamentos, extensões e logs no contexto. OpenTelemetry é um padrão do setor que aceita todos esses recursos e os coloca em um formato amplamente compatível (OTLP).

O que acontece com o New Relic se eu habilitar OpenTelemetry?

Quando você executa o pipeline de configuração, os dados para o New Relic não serão mais transmitidos do AEM as a Cloud Service.

Se eu migrar do New Relic para o OpenTelemetry, posso voltar?

Sim. Desative o OpenTelemetry por meio do Pipeline de configuração e execute um pipeline de empilhamento completo até a conclusão. Isso é possível até o final de novembro de 2026.

O que acontece após novembro de 2026?

A Adobe mudará de sua solução integrada de APM para OpenTelemetry como sua solução de observabilidade permanente.

Artigos relacionados related-articles

​* Encaminhamento de logs
​* Configurar rede avançada
​* Variáveis de ambiente no Cloud Manager