# Solução de problemas relacionados à instalação do Application Signals Esta seção contém dicas de solução de problemas para o CloudWatch Application Signals. **Topics** + [Resolva os conflitos de configuração do OpenTelemetry no Amazon EKS com o Application Signals](#Application-Signals-troubleshoot-eks-applications) + [Performance de inicialização a frio da camada Java do Application Signals](#Application-Signals-troubleshoot-cold-start-performance) + [A aplicação não inicia após a habilitação do Application Signals](#Application-Signals-troubleshoot-starting) + [A aplicação em Python não é iniciada após a habilitação do Application Signals](#Application-Signals-troubleshoot-starting-Python) + [Não há dados do Application Signals para aplicações em Python que usam um servidor WSGI](#Application-Signals-troubleshoot-Python-WSGI) + [Minha aplicação em Node.js não está instrumentada ou não está gerando telemetria do Application Signals](#Application-Signals-troubleshoot-telemetry-nodejs) + [A aplicação My .NET não está instrumentada ou é interrompida em chamadas do AWS SDK](#Application-Signals-troubleshoot-sdk-calls) + [Nenhum dado da aplicação no painel do Application Signals](#Application-Signals-troubleshoot-missingdata) + [Métricas de dependência ou de serviço têm valores desconhecidos](#Application-Signals-troubleshoot-unknown-values) + [Tratamento de um ConfigurationConflict durante o gerenciamento do complemento Amazon CloudWatch Observability do EKS](#Application-Signals-troubleshoot-conflict) + [Quero filtrar métricas e rastreamentos desnecessários](#Application-Signals-troubleshoot-cardinality) + [O que significa `InternalOperation`?](#Application-Signals-troubleshoot-InternalOperation) + [Como habilito o registro em log para aplicações .NET?](#Application-Signals-troubleshoot-dotnet-logging) + [Como resolvo conflitos de versão de montagem em aplicações .NET?](#Application-Signals-troubleshoot-dotnet-conflicts) + [Posso desabilitar o FluentBit?](#Application-Signals-troubleshoot-FluentBit) + [Posso filtrar logs de contêineres antes de exportar para o CloudWatch Logs?](#Application-Signals-troubleshoot-filter-logs) + [Resolver TypeError ao usar a camada do Lambda JavaScript do AWS Distro para OpenTelemetry (ADOT)](#lambda-execution) + [TypeError ao usar manipuladores do Lambda de streaming de respostas com a camada de AWS Distro para OpenTelemetry (ADOT) JavaScript do Lambda](#lambda-execution-streaming) + [Atualizar para as versões necessárias dos agentes ou do complemento do Amazon EKS](#CloudWatch-Application-Signals-Agent-Versions) + [Formato de métrica incorporado (EMF) desabilitado para o Application Signals](#emf-appsignals) ## Resolva os conflitos de configuração do OpenTelemetry no Amazon EKS com o Application Signals Se você usar OpenTelemetry (OTel) para monitoramento de performance de aplicações (APM) com o Amazon EKS e configurar endpoints de exportação OTLP personalizados, exceto endpoints do CloudWatch, poderá experimentar os seguintes comportamentos após instalar ou atualizar para a versão 5.0.0 ou posterior do complemento CloudWatch Observability: + Interrupção na telemetria OTel existente: o complemento CloudWatch Observability pode substituir os endpoints do exportador OTLP codificado na aplicação. Essa substituição não afeta os endpoints configurados por variáveis de ambiente do contêiner ou do ConfigMap `envFrom`. Quando eles são substituídos, as métricas e rastros podem não chegar ao destino pretendido. Para manter a configuração de APM existente após atualizar para a V5.0.0 ou posterior, consulte [Optar por não usar o Application Signals](install-CloudWatch-Observability-EKS-addon.md#Opting-out-App-Signals) + O Application Signals pode não funcionar se ele tiver sido habilitado usando o complemento CloudWatch Observability e tiver um endpoint OTLP personalizado configurado. Para resolver isso, remova os endpoints OTLP personalizados ou defina a variável de ambiente `OTEL_AWS_APPLICATION_SIGNALS_ENABLED=true` ao instalar ou atualizar para a versão 5.0.0 ou posterior ## Performance de inicialização a frio da camada Java do Application Signals Adicionar a camada do Application Signals às funções Java do Lambda aumenta a latência de inicialização (tempo de inicialização a frio). As dicas a seguir podem ajudar a reduzir a latência para funções sensíveis ao tempo. **Inicialização rápida do agente Java**: a camada Java para o Lambda do Application Signals inclui um recurso de inicialização rápida que é desativado por padrão, mas pode ser habilitado definindo a variável OTEL\$1JAVA\$1AGENT\$1FAST\$1STARTUP\$1ENABLED como true. Quando habilitado, esse recurso configura a JVM para usar o compilador C1 de compilação em camadas de nível 1 para gerar código nativo otimizado rapidamente para inicializações a frio mais rápidas. O compilador C1 prioriza a velocidade em detrimento da otimização de longo prazo, enquanto o compilador C2 fornece performance geral superior ao caracterizar dados ao longo do tempo. Para obter mais informações, consulte [Fast startup for Java agent](https://github.com/open-telemetry/opentelemetry-lambda/blob/main/java/README.md#fast-startup-for-java-agent). **Reduzir tempos de inicialização a frio com simultaneidade provisionada**: a simultaneidade provisionada pelo AWS Lambda pré-aloca um número específico de instâncias de função, mantendo-as inicializadas e prontas para lidar com solicitações imediatamente. Isso reduz os tempos de inicialização a frio, eliminando a necessidade de inicializar o ambiente da função durante a execução, garantindo uma performance mais rápida e consistente, especialmente para workloads sensíveis à latência. Para obter mais informações, consulte [Configurar a simultaneidade provisionada para uma função](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html). **Otimizar a performance da inicialização usando o Lambda SnapStart**: o AWS Lambda SnapStart é um recurso que otimiza a performance de inicialização das funções do Lambda criando um snapshot pré-inicializado do ambiente de execução após a fase de inicialização da função. Esse snapshot é então reutilizado para iniciar novas instâncias, reduzindo significativamente os tempos de inicialização a frio ao ignorar o processo de inicialização durante a invocação da função. Para obter informações, consulte [Aprimoramento da performance de inicialização com o Lambda SnapStart](https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html). ## A aplicação não inicia após a habilitação do Application Signals Se a aplicação em um cluster do Amazon EKS não iniciar após a habilitação do Application Signals no cluster, verifique o seguinte: + Verifique se a aplicação foi instrumentada por outra solução de monitoramento. O Application Signals não é compatível com a coexistência com outras soluções de instrumentação. + Confirme se a aplicação atende aos requisitos de compatibilidade para o uso do Application Signals. Para obter mais informações, consulte [Sistemas compatíveis](CloudWatch-Application-Signals-supportmatrix.md). + Se não foi possível usar a aplicação para realizar a extração dos artefatos do Application Signals, como o agente em Java ou em Python do AWS Distro para OpenTelemetery e as imagens do agente do CloudWatch, pode ser um problema de rede. Para mitigar o problema, remova a anotação `instrumentation.opentelemetry.io/inject-java: "true"` ou `instrumentation.opentelemetry.io/inject-python: "true"` do manifesto de implantação da aplicação e implante-a novamente. Em seguida, verifique se a aplicação está funcionando. **Problemas conhecidos** Sabemos que a coleção de métricas de runtime na versão v1.32.5 do Java SDK não funciona com aplicações que usam o JBoss Wildfly. Esse problema se estende ao complemento Amazon CloudWatch Observability EKS, afetando as versões `2.3.0-eksbuild.1` até `2.5.0-eksbuild.1`. Se você for afetado, faça o downgrade da versão ou desabilite a coleção de métricas de runtime adicionando a variável de ambiente `OTEL_AWS_APPLICATION_SIGNALS_RUNTIME_ENABLED=false` à sua aplicação. ## A aplicação em Python não é iniciada após a habilitação do Application Signals É um problema conhecido na instrumentação automática do OpenTelemetry que uma variável de ambiente `PYTHONPATH` ausente pode, às vezes, causar falha na inicialização da aplicação. Para resolver isso, certifique-se de definir a variável de ambiente `PYTHONPATH` para o local do diretório de trabalho da sua aplicação. Para obter mais informações sobre esse problema, consulte [Python autoinstrumentation setting of PYTHONPATH is not compliant with Python's module resolution behavior, breaking Django applications](https://github.com/open-telemetry/opentelemetry-operator/issues/2302). Para aplicações em Django, existem configurações adicionais necessárias, descritas na [documentação do OpenTelemetry em Python](https://opentelemetry-python.readthedocs.io/en/latest/examples/django/README.html). + Use o sinalizador `--noreload` para evitar o recarregamento automático. + Defina a variável de ambiente `DJANGO_SETTINGS_MODULE` para o local do arquivo `settings.py` da sua aplicação em Django. Isso garante que o OpenTelemetry possa acessar e se integrar adequadamente às suas configurações do Django. ## Não há dados do Application Signals para aplicações em Python que usam um servidor WSGI Se você estiver usando um servidor WSGI, como Gunicorn ou uWSGI, é necessário realizar alterações adicionais para que a instrumentação automática em Python do ADOT funcione. **nota** Certifique-se de que está usando a versão mais recente do ADOT para Python e do complemento de observabilidade do EKS do Amazon CloudWatch antes de prosseguir. **Etapas adicionais para habilitar o Application Signals com um servidor WSGI** 1. Faça a importação da instrumentação automática nos processos de trabalho separados. Para Gunicorn, use o hook `post_fork`: ``` # gunicorn.conf.py def post_fork(server, worker): from opentelemetry.instrumentation.auto_instrumentation import sitecustomize ``` Para uWSGI, use a diretiva `import`: ``` # uwsgi.ini [uwsgi] ; required for the instrumentation of worker processes enable-threads = true lazy-apps = true import = opentelemetry.instrumentation.auto_instrumentation.sitecustomize ``` 1. Habilite a configuração para a instrumentação automática em Python do ADOT com a finalidade de ignorar o processo principal e delegar para o processamento ao definir a variável de ambiente `OTEL_AWS_PYTHON_DEFER_TO_WORKERS_ENABLED` como `true`. ## Minha aplicação em Node.js não está instrumentada ou não está gerando telemetria do Application Signals Para habilitar o Application Signals para o Node.js, você deve garantir que a aplicação Node.js use o formato de módulo do CommonJS (CJS). O AWS Distro para OpenTelemetry para Node.js não oferece suporte ao formato de módulo ESM, visto que o suporte de OpenTelemetry JavaScript para ESM é experimental e está em desenvolvimento. Para determinar se a aplicação está usando CJS, e não ESM, certifique-se de que ela não atenda às [condições necessárias para habilitar o ESM](https://nodejs.org/api/esm.html#enabling). ## A aplicação My .NET não está instrumentada ou é interrompida em chamadas do AWS SDK O SDK do AWS Distro for Open Telemetry (ADOT) para .NET não é compatível com o SDK da AWS para o .NET V4. Use o SDK da AWS do .NET V3 para total compatibilidade com o Application Signals. ## Nenhum dado da aplicação no painel do Application Signals Se as métricas ou os rastreamentos estiverem ausentes nos painéis do Application Signals, as informações apresentadas a seguir podem ser as causas. Investigue essas causas somente se você tiver aguardado 15 minutos para que o Application Signals coletasse e exibisse dados desde a última atualização. + Certifique-se de que a biblioteca e a estrutura que você está usando sejam compatíveis com o agente em Java do ADOT. Para obter mais informações, consulte [Libraries / Frameworks](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/supported-libraries.md#libraries--frameworks). + Certifique-se de que o agente do CloudWatch esteja em execução. Primeiro, verifique o status dos pods do agente do CloudWatch e certifique-se de que todos estejam com o status `Running`. ``` kubectl -n amazon-cloudwatch get pods. ``` Adicione o conteúdo apresentado a seguir ao arquivo de configuração do agente do CloudWatch para habilitar os logs de depuração e, em seguida, reinicie o agente. ``` "agent": { "region": "${REGION}", "debug": true }, ``` Em seguida, verifique se ocorreram erros nos pods do agente do CloudWatch. + Verifique se há problemas de configuração com o agente do CloudWatch. Confirme se o conteúdo apresentado a seguir ainda está no arquivo de configuração do agente do CloudWatch e se o agente foi reiniciado desde que houve essa adição. ``` "agent": { "region": "${REGION}", "debug": true }, ``` Em seguida, verifique os logs de depuração do OpenTelemetry em busca de mensagens de erro, como `ERROR io.opentelemetry.exporter.internal.grpc.OkHttpGrpcExporter - Failed to export ...`. É possível que essas mensagens indiquem o problema. Se isso não resolver o problema, realize o despejo e verifique as variáveis de ambiente com nomes que começam com `OTEL_` ao descrever o pod com o comando `kubectl describe pod`. + Para habilitar que o OpenTelemetry em Python depure o registro em log, defina a variável de ambiente `OTEL_PYTHON_LOG_LEVEL` para `debug` e implante a aplicação novamente. + Verifique se há permissões incorretas ou insuficientes para a exportação de dados do agente do CloudWatch. Se você visualizar mensagens de `Access Denied` nos logs do agente do CloudWatch, esse pode ser o problema. É possível que as permissões aplicadas quando você instalou o agente do CloudWatch tenham sido alteradas ou revogadas posteriormente. + Verifique se há um problema relacionado ao AWS Distro para OpenTelemetry (ADOT) ao gerar dados de telemetria. Certifique-se de que as anotações de instrumentação `instrumentation.opentelemetry.io/inject-java` e ` sidecar.opentelemetry.io/inject-java` estejam aplicadas à implantação da aplicação e que o valor seja `true`. Sem essas anotações, os pods da aplicação não serão instrumentados, mesmo que o complemento do ADOT esteja instalado corretamente. Em seguida, verifique se o contêiner `init` está aplicado na aplicação e se o estado `Ready` é `True`. Se o contêiner `init` não estiver pronto, consulte o status para saber o motivo. Se o problema persistir, habilite o registro em log de depuração no SDK do OpenTelemetry para Java definindo a variável de ambiente `OTEL_JAVAAGENT_DEBUG` como true e reimplantando a aplicação. Em seguida, procure por mensagens que comecem com `ERROR io.telemetry`. + O exportador de métricas ou de extensões pode estar descartando dados. Para descobrir se isso está ocorrendo, verifique o log da aplicação em busca de mensagens que incluam `Failed to export...`. + O agente do CloudWatch pode estar com controle de utilização ao enviar métricas ou extensões para o Application Signals. Verifique se há mensagens que indicam um controle de utilização nos logs do agente do CloudWatch. + Verifique se você habilitou a configuração de descoberta de serviços. Você precisa fazer isso somente uma vez na sua região. Para confirmar essa configuração, no console do CloudWatch, escolha **Application Signals**, **Serviços**. Se a Etapa 1 não estiver marcada como **Concluída**, escolha **Começar a descobrir os serviços**. Os dados devem começar a fluir em até cinco minutos. ## Métricas de dependência ou de serviço têm valores desconhecidos Se **UnknownService**, **UnknownOperation**, **UnknownRemoteService** ou **UnknownRemoteOperation** aparecer em um nome de dependência ou operação nos painéis do Application Signals, verifique se a ocorrência de pontos de dados para o serviço remoto desconhecido e para a operação remota desconhecida coincidem com as implantações. + **UnknownService** significa que o nome de uma aplicação instrumentada é desconhecido. Se a variável de ambiente `OTEL_SERVICE_NAME` for indefinida e o `service.name` não estiver especificado em `OTEL_RESOURCE_ATTRIBUTES`, o nome do serviço será definido como `UnknownService`. Para corrigir isso, especifique o nome do serviço em `OTEL_SERVICE_NAME` ou `OTEL_RESOURCE_ATTRIBUTES`. + **UnknownOperation** significa que o nome de uma operação invocada é desconhecido. Essa situação ocorre quando o Application Signals não consegue descobrir um nome de operação que invoque a chamada remota, ou quando o nome da operação extraída contém valores altos de cardinalidade. + **UnknownRemoteService** significa que o nome do serviço de destino é desconhecido. Essa situação ocorre quando o sistema não consegue extrair o nome do serviço de destino que a chamada remota acessa. Uma solução é criar um intervalo personalizado para a função que envia a solicitação e adicionar o atributo `aws.remote.service` com o valor designado. Outra opção é configurar o agente do CloudWatch para personalizar o valor da métrica do `RemoteService`. Para obter mais informações sobre personalizações no agente do CloudWatch, consulte [Habilitar o CloudWatch Application Signals](CloudWatch-Agent-Application_Signals.md). + **UnknownRemoteOperation** significa que o nome da operação de destino é desconhecido. Essa situação ocorre quando o sistema não consegue extrair o nome da operação de destino que a chamada remota acessa. Uma solução é criar um intervalo personalizado para a função que envia a solicitação e adicionar o atributo `aws.remote.operation` com o valor designado. Outra opção é configurar o agente do CloudWatch para personalizar o valor da métrica do `RemoteOperation`. Para obter mais informações sobre personalizações no agente do CloudWatch, consulte [Habilitar o CloudWatch Application Signals](CloudWatch-Agent-Application_Signals.md). ## Tratamento de um ConfigurationConflict durante o gerenciamento do complemento Amazon CloudWatch Observability do EKS Ao instalar ou atualizar o complemento Amazon CloudWatch Observability do EKS, se você perceber uma falha causada por um `Health Issue` do tipo `ConfigurationConflict` com uma descrição que começa com `Conflicts found when trying to apply. Will not continue due to resolve conflicts mode`, é provável que você já tenha o agente do CloudWatch e os componentes associados, como o ServiceAccount, o ClusterRole e o ClusterRoleBinding instalados no cluster. Quando o complemento tentar instalar o agente do CloudWatch e os componentes associados, se ele detectar quaisquer alterações no conteúdo, por padrão, apresentará falhas na instalação ou na atualização para evitar a substituição do estado dos recursos no cluster. Se você estiver tentando realizar a integração do complemento Amazon CloudWatch Observability do EKS e obter essa falha, recomendamos excluir uma configuração existente do agente do CloudWatch instalada anteriormente no cluster e, em seguida, instalar o complemento do EKS. Certifique-se de fazer backup de quaisquer personalizações que você possa ter executado na configuração original do agente do CloudWatch, como uma configuração do agente personalizada, e fornecê-las ao complemento Amazon CloudWatch Observability do EKS na próxima instalação ou atualização. Se você realizou a instalação do agente do CloudWatch para a integração com o Container Insights, consulte [Exclusão do agente do CloudWatch e do Fluent Bit para o Container Insights](ContainerInsights-delete-agent.md) para obter mais informações. Como alternativa, o complemento oferece suporte a uma opção de configuração de resolução de conflitos que tem a funcionalidade de especificar `OVERWRITE`. É possível usar essa opção para prosseguir com a instalação ou a atualização do complemento ao substituir os conflitos no cluster. Se você estiver usando o console do Amazon EKS, encontrará o **Método de resolução de conflitos** ao escolher as **Definições de configuração opcionais** na criação ou na atualização do complemento. Caso esteja usando a AWS CLI, você poderá fornecer o comando `--resolve-conflicts OVERWRITE` para criar ou atualizar o complemento. ## Quero filtrar métricas e rastreamentos desnecessários Se o Application Signals estiver coletando rastreamentos e métricas que você não deseja, consulte [Gerenciamento de operações de alta cardinalidade](Application-Signals-Cardinality.md) para obter informações sobre como configurar o agente do CloudWatch com regras personalizadas para reduzir a cardinalidade. Para obter informações sobre como personalizar regras de amostragem de rastreamentos, consulte [Configure sampling rules](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray-interface-console.html#xray-console) na documentação do X-Ray. ## O que significa `InternalOperation`? Uma `InternalOperation` é uma operação que é acionada internamente pela aplicação e não por uma invocação externa. Ver `InternalOperation` é esperado, comportamento íntegro. Alguns exemplos típicos em que você veria `InternalOperation` incluem o seguinte: + **Pré-carregamento na inicialização**: sua aplicação executa uma operação chamada `loadDatafromDB` que lê metadados de um banco de dados durante a fase de aquecimento. Em vez de observar `loadDatafromDB` como uma operação de serviço, você a verá categorizada como uma `InternalOperation`. + **Execução assíncrona em segundo plano**: sua aplicação assina uma fila de eventos e processa os dados de streaming adequadamente sempre que há uma atualização. Cada operação acionada será classificada em `InternalOperation` como uma operação de serviço. + **Recuperação de informações do host de um registro de serviços**: sua aplicação se comunica com um registro de serviços para a descoberta de serviços. Todas as interações com o sistema de descoberta são classificadas como uma `InternalOperation`. ## Como habilito o registro em log para aplicações .NET? Para habilitar o registro em log para aplicações .NET, configure as seguintes variáveis de ambiente. Para obter mais informações sobre como configurar essas variáveis de ambiente, consulte [Troubleshooting .NET automatic instrumentation issues](https://opentelemetry.io/docs/zero-code/net/troubleshooting/#general-steps) na documentação do OpenTelemetry. + `OTEL_LOG_LEVEL` + `OTEL_DOTNET_AUTO_LOG_DIRECTORY` + `COREHOST_TRACE` + `COREHOST_TRACEFILE` ## Como resolvo conflitos de versão de montagem em aplicações .NET? Se você receber o erro a seguir, consulte [Assembly version conflicts](https://opentelemetry.io/docs/zero-code/net/troubleshooting/#assembly-version-conflicts) na documentação do OpenTelemetry para ver as etapas de resolução. ``` Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified. File name: 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' at Microsoft.AspNetCore.Builder.WebApplicationBuilder..ctor(WebApplicationOptions options, Action`1 configureDefaults) at Microsoft.AspNetCore.Builder.WebApplication.CreateBuilder(String[] args) at Program.
$(String[] args) in /Blog.Core/Blog.Core.Api/Program.cs:line 26 ``` ## Posso desabilitar o FluentBit? Você pode desabilitar o FluentBit configurando o complemento de observabilidade do EKS do Amazon CloudWatch. Para obter mais informações, consulte [(Opcional) Configuração adicional](install-CloudWatch-Observability-EKS-addon.md#install-CloudWatch-Observability-EKS-addon-configuration). ## Posso filtrar logs de contêineres antes de exportar para o CloudWatch Logs? Não, ainda não há compatibilidade para filtrar logs de contêineres. ## Resolver TypeError ao usar a camada do Lambda JavaScript do AWS Distro para OpenTelemetry (ADOT) Sua função do Lambda pode falhar com o erro `TypeError - "Cannot redefine property: handler"` quando você: + Usa a camada do Lambda JavaScript do ADOT + Usa `esbuild` para compilar o TypeScript + Exporta seu manipulador com a palavra-chave `export` A camada do Lambda JavaScript do ADOT precisa modificar seu manipulador em tempo de execução. Quando você usa a palavra-chave `export` com `esbuild` (diretamente ou por meio do AWS CDK), `esbuild` torna seu manipulador imutável, evitando essas modificações. Exporte sua função de manipulador usando `module.exports` em vez da palavra-chave `export`: ``` // Before export const handler = (event) => { // Handler Code } ``` ``` // After const handler = async (event) => { // Handler Code } module.exports = { handler } ``` ## TypeError ao usar manipuladores do Lambda de streaming de respostas com a camada de AWS Distro para OpenTelemetry (ADOT) JavaScript do Lambda Sua função do Lambda pode falhar com o erro `TypeError - "responseStream.write is not a function"` quando você: + Use a camada de ADOT JavaScript do Lambda com a instrumentação do AWS Lambda habilitada (habilitada por padrão) + Usar o atributo de streaming de respostas em runtimes gerenciados pelo Node.js. Por exemplo, quando o manipulador de funções é assim: ``` * export const handler = awslambda.streamifyResponse(...) ``` Atualmente, a instrumentação do AWS Lambda na camada de ADOT JavaScript do Lambda não é compatível com streaming de respostas em runtimes gerenciados pelo Node.js, portanto, ela deve ser desabilitada para evitar esse TypeError. ## Atualizar para as versões necessárias dos agentes ou do complemento do Amazon EKS Após 9 de agosto de 2024, o CloudWatch Application Signals não oferecerá mais suporte a versões anteriores do complemento de observabilidade do EKS do Amazon CloudWatch, do agente do CloudWatch e do agente de instrumentação automática do AWS Distro para OpenTelemetry. + Para o complemento de observabilidade do EKS do Amazon CloudWatch, as versões anteriores à `v1.7.0-eksbuild.1` não serão mais compátíveis. + Para o agente do CloudWatch, as versões anteriores à `1.300040.0` não serão mais compatíveis. + Para o agente de instrumentação automática do AWS Distro para OpenTelemetry: + Para Java, versões mais antigas que a versão `1.32.2` não são compatíveis. + Para Python, versões mais antigas que a versão `0.2.0` não são compatíveis. + Para .NET, versões mais antigas que a versão `1.3.2` não são compatíveis. + Para o Node.js, as versões anteriores à `0.3.0` não são compatíveis. **Importante** As versões mais recentes dos agentes incluem atualizações no esquema métrico do Application Signals. Essas atualizações não são compatíveis com versões anteriores, o que poderá resultar em problemas de dados se versões incompatíveis forem usadas. Para ajudar a garantir uma transição ininterrupta para a nova funcionalidade, faça o seguinte: Se a aplicação estiver em execução no Amazon EKS, certifique-se de reiniciar todas as aplicações instrumentadas após atualizar o complemento de observabilidade do Amazon CloudWatch. Para aplicações executadas em outras plataformas, certifique-se de atualizar **ambos** os agentes do CloudWatch e da instrumentação automática do AWS OpenTelemetry para as versões mais recentes. As instruções nas seções a seguir podem ajudar você a atualizar para uma versão compatível. **Contents** + [Atualizar o complemento de observabilidade do EKS do Amazon CloudWatch](#Application-Signals-Upgrade-Addon) + [Usar o console](#Upgrade-Addon-Console) + [Usar a AWS CLI](#Upgrade-Addon-CLI) + [Atualizar o agente do CloudWatch e o do ADOT](#Application-Signals-Upgrade-Agents) + [Atualizar no Amazon ECS](#Upgrade-Agents-ECS) + [Atualizar no Amazon EC2 ou em outras arquiteturas](#Upgrade-Addon-EC2) ### Atualizar o complemento de observabilidade do EKS do Amazon CloudWatch Para o complemento de observabilidade do EKS do Amazon CloudWatch, você pode usar o Console de gerenciamento da AWS ou a AWS CLI. #### Usar o console **Para atualizar o complemento usando o console** 1. Abra o console do Amazon EKS em [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters). 1. Escolha o nome do cluster do Amazon EKS a ser atualizado. 1. Escolha a guia **Complementos** e, em seguida, escolha **Observabilidade do Amazon CloudWatch**. 1. Escolha **Editar**, selecione a versão para a qual você deseja atualizar, e escolha **Salvar alterações**. Certifique-se de escolher `v1.7.0-eksbuild.1` ou superior. 1. Insira um dos comandos da AWS CLI a seguir para reiniciar os serviços. ``` # Restart a deployment kubectl rollout restart deployment/name # Restart a daemonset kubectl rollout restart daemonset/name # Restart a statefulset kubectl rollout restart statefulset/name ``` #### Usar a AWS CLI **Para atualizar o complemento usando a AWS CLI** 1. Insira o comando a seguir para encontrar a versão mais recente. ``` aws eks describe-addon-versions \ --addon-name amazon-cloudwatch-observability ``` 1. Insira comando a seguir para atualizar o complemento. Substitua *\$1VERSION* por uma versão que seja a `v1.7.0-eksbuild.1` ou posterior. Substitua *\$1AWS\$1REGION* e *\$1CLUSTER* pelos nomes da região e do cluster. ``` aws eks update-addon \ --region $AWS_REGION \ --cluster-name $CLUSTER \ --addon-name amazon-cloudwatch-observability \ --addon-version $VERSION \ # required only if the advanced configuration is used. --configuration-values $JSON_CONFIG ``` **nota** Caso esteja usando uma configuração personalizada para o complemento, você poderá encontrar um exemplo da configuração a ser usada para *\$1JSON\$1CONFIG* em [Habilitar o CloudWatch Application Signals](CloudWatch-Agent-Application_Signals.md). 1. Insira um dos comandos da AWS CLI a seguir para reiniciar os serviços. ``` # Restart a deployment kubectl rollout restart deployment/name # Restart a daemonset kubectl rollout restart daemonset/name # Restart a statefulset kubectl rollout restart statefulset/name ``` ### Atualizar o agente do CloudWatch e o do ADOT Se seus serviços estiverem sendo executados em arquiteturas diferentes do Amazon EKS, você precisará atualizar o agente do CloudWatch e o da instrumentação automática do ADOT para usar os recursos mais recentes do Application Signals. #### Atualizar no Amazon ECS **Para atualizar os agentes para serviços executados no Amazon ECS** 1. Crie uma nova revisão de definição de tarefa. Para obter mais informações, consulte [Atualizar uma definição de tarefa usando o console](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-task-definition-console-v2). 1. Substitua a `$IMAGE` do contêiner `ecs-cwagent` pela tag de imagem mais recente de [cloudwatch-agent](https://gallery.ecr.aws/cloudwatch-agent/cloudwatch-agent) no Amazon ECR. Se você atualizar para uma versão fixa, certifique-se de usar uma versão igual ou posterior à `1.300040.0`. 1. Substitua a `$IMAGE` do contêiner `init` pela tag de imagem mais recente dos seguintes locais: + Para Java, use [aws-observability/adot-autoinstrumentation-java](https://gallery.ecr.aws/aws-observability/adot-autoinstrumentation-java). Se você atualizar para uma versão fixa, certifique-se de usar uma versão igual ou posterior à `1.32.2`. + Para Python, use [aws-observability/adot-autoinstrumentation-python](https://gallery.ecr.aws/aws-observability/adot-autoinstrumentation-python). Se você atualizar para uma versão fixa, certifique-se de usar uma versão igual ou posterior à `0.2.0`. + Para .NET, use [aws-observability/adot-autoinstrumentation-dotnet](https://gallery.ecr.aws/aws-observability/adot-autoinstrumentation-dotnet). Se você atualizar para uma versão fixa, certifique-se de usar uma versão igual ou posterior à `1.3.2`. + Para o Node.js, use [aws-observability/adot-autoinstrumentation-node](https://gallery.ecr.aws/aws-observability/adot-autoinstrumentation-node). Se você atualizar para uma versão fixa, certifique-se de usar uma versão igual ou posterior à `0.3.0`. 1. Atualize as variáveis de ambiente do Application Signals no contêiner da sua aplicação seguindo as instruções em [Etapa 4: instrumentalizar a aplicação com o agente do CloudWatch](CloudWatch-Application-Signals-ECS-Sidecar.md#CloudWatch-Application-Signals-Enable-ECS-Instrument). 1. Implemente seu serviço com a nova definição de tarefa. #### Atualizar no Amazon EC2 ou em outras arquiteturas **Para atualizar os agentes para serviços executados no Amazon EC2 ou em outras arquiteturas** 1. Certifique-se de selecionar a versão `1.300040.0` ou uma versão posterior do agente do CloudWatch. 1. Faça download da versão mais recente do agente de instrumentação automática do AWS Distro para OpenTelemetry para um dos seguintes locais: + Para Java, use [aws-otel-java-instrumentation ](https://gallery.ecr.aws/aws-observability/adot-autoinstrumentation-java). Se você atualizar para uma versão fixa, certifique-se de escolher `1.32.2` ou posterior. + Para Python, use [aws-otel-python-instrumentation](https://github.com/aws-observability/aws-otel-python-instrumentation/releases). Se você atualizar para uma versão fixa, certifique-se de escolher `0.2.0` ou posterior. + Para .NET, use [aws-otel-dotnet-instrumentation](https://github.com/aws-observability/aws-otel-dotnet-instrumentation/releases). Se você atualizar para uma versão fixa, certifique-se de escolher `1.3.2` ou posterior. + Para o Node.js, use [aws-otel-js-instrumentation](https://github.com/aws-observability/aws-otel-js-instrumentation/releases). Se você atualizar para uma versão fixa, certifique-se de escolher `0.3.0` ou posterior. 1. Aplique as variáveis de ambiente atualizadas do Application Signals em sua aplicação e a inicie. Para obter mais informações, consulte [Etapa 3: instrumentalizar a aplicação e iniciá-la](CloudWatch-Application-Signals-Enable-EC2Main.md#CloudWatch-Application-Signals-Enable-Other-instrument). ## Formato de métrica incorporado (EMF) desabilitado para o Application Signals A desabilitação do EMF para o grupo de logs `/aws/application-signals/data` pode ter o impacto a seguir na funcionalidade do Application Signals. + Métricas e gráficos do Application Signals não serão exibidos + A funcionalidade do Application Signals será degradada **Como faço para restaurar o Application Signals?** Quando o Application Signals exibe gráficos ou métricas vazios, você deve habilitar o EMF para que o grupo de logs `/aws/application-signals/data` restaure a funcionalidade total. Para obter mais informações, consulte [PutAccountPolicy](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutAccountPolicy.html#API_PutAccountPolicy_RequestSyntax).