Independência com OpenTelemetry na Elastic

A busca por serviços mais rápidos e escaláveis está aumentando. No nosso cotidiano, os apps são onipresentes — desde um app de entrega de comida para você pedir sua refeição favorita até o app do banco para administrar suas contas e os apps para agendar  consultas médicas. Esses apps precisam ser capazes de crescer não apenas do ponto de vista dos recursos, mas também em termos de capacidade de usuários. A escala e a necessidade de alcance global aumentam a complexidade dessas aplicações de nuvem de alta demanda.

Para acompanhar a demanda, a maioria desses apps e serviços online (por exemplo, apps para celular, páginas da web, SaaS) está migrando para uma arquitetura distribuída baseada em microsserviços e Kubernetes. Depois de migrar seu app para a nuvem, como você gerencia e monitora a produção, a escala e a disponibilidade do serviço? O OpenTelemetry está rapidamente se tornando o padrão de fato para instrumentação e coleta de dados de telemetria para aplicações do Kubernetes.

OpenTelemetry (OTel) é um projeto open source que fornece um acervo de ferramentas, APIs e SDKs que podem ser usados para gerar, coletar e exportar dados de telemetria (métricas, logs e traces) com o objetivo de entender o desempenho e o comportamento do software. O OpenTelemetry tornou-se recentemente um projeto de incubação do CNCF e tem uma quantidade significativa de suporte crescente da comunidade e de fornecedores.

Embora o OTel forneça uma maneira padrão de instrumentar as aplicações com um formato de telemetria padrão, ele não fornece componentes analíticos ou de backend. Portanto, o uso de bibliotecas do OTel no monitoramento de aplicações, infraestrutura e experiência do usuário oferece flexibilidade na escolha da ferramenta de observabilidade apropriada. Não há mais qualquer dependência de fornecedor para o monitoramento de performance de aplicação (APM).

O Elastic Observability oferece suporte nativo para o OpenTelemetry e seu protocolo OpenTelemetry (OTLP) para ingestão de  traces, métricas e logs. Todas as funcionalidades de APM do Elastic Observability estão disponíveis com dados do OTel. Portanto, as seguintes funcionalidades (e outras) estão disponíveis para dados do OTel:

• Mapas de serviços
• Detalhes dos serviços (latência, taxa de transferência, transações com falha)
• Dependências entre serviços
• Transações (traces)
• Correlações de ML (especificamente para latência)
• Logs de serviços

Além do APM e da visão unificada dos dados de telemetria, agora você poderá usar as poderosas funcionalidades de machine learning da Elastic para reduzir a análise e os alertas e ajudar a reduzir o MTTR.

Devido à sua tradição open source, a Elastic também oferece suporte para outros projetos baseados em CNCF, como Prometheus, Fluentd, Fluent Bit, Istio, Kubernetes (K8S) e muitos outros.  

Neste post do blog:

• Mostraremos como configurar um app popular de demonstração (HipsterShop) instrumentado com OTel para ingestão no Elastic Cloud em algumas etapas fáceis
• Destacaremos algumas das funcionalidades e recursos do Elastic APM relacionados aos dados do OTel e o que você pode fazer com esses dados quando eles estiverem no Elastic

Nos próximos posts do blog, detalharemos como usar o machine learning da Elastic com dados de telemetria do OTel; como instrumentar métricas de aplicações do OTel para idiomas específicos; como podemos oferecer suporte para ingestão do Prometheus por meio do OpenTelemetry Collector; e muito mais. Não deixe de acompanhar!

Pré-requisitos e configuração

Se você planeja seguir este post, aqui estão alguns dos componentes e detalhes que usamos para definir a configuração:

• Você deverá ter uma conta no Elastic Cloud e uma stack implantada (consulte as instruções aqui).
• Usamos uma variante da popular aplicação de demonstração HipsterShop. Ela foi originalmente desenvolvida pelo Google para demonstrar o Kubernetes em diversas variantes disponíveis, como o app de demonstração do OpenTelemetry. Para usar o app, clique aqui e siga as instruções para implantar.
• Além disso, estamos usando uma versão da aplicação instrumentada manualmente com OTel. Nenhuma instrumentação automática do OTel foi usada nesta configuração do post.
• Localização dos nossos clusters. Embora tenhamos usado o Google Kubernetes Engine (GKE), você pode usar qualquer plataforma do Kubernetes de sua escolha. 
• Embora o Elastic possa fazer a ingestão da telemetria diretamente dos serviços instrumentados do OTel, vamos nos concentrar na implantação mais tradicional, que usa o OpenTelemetry Collector.
• Prometheus e FluentD/Fluent Bit — tradicionalmente usados para extrair todos os dados do Kubernetes — não estão sendo usados aqui em contraste com agentes do Kubernetes. Os posts de acompanhamento mostrarão isso.

Aqui está a configuração que faremos neste post:

Para preparar tudo

Nas próximas etapas, mostrarei:

• Como obter uma conta no Elastic Cloud
• Como iniciar um cluster do GKE
• Como iniciar a aplicação
• Como definir o configmap do OTel Collector do Kubernetes para apontar para o Elastic Cloud
• Como usar o APM do Elastic Observability com dados do OTel para melhorar a visibilidade

Etapa 0: criar uma conta no Elastic Cloud

Siga as instruções para começar a usar o Elastic Cloud.

Etapa 1: iniciar um cluster do K8S

Nós usamos o Google Kubernetes Engine (GKE), mas você pode usar qualquer plataforma do Kubernetes de sua escolha.

Não há requisitos especiais para o Elastic coletar dados do OpenTelemetry de um cluster do Kubernetes. Qualquer cluster do Kubernetes normal no GKE, EKS, AKS ou um cluster compatível com o Kubernetes (autoimplantado e gerenciado) funciona.

Etapa 2: carregar a aplicação HipsterShop no cluster

Coloque sua aplicação em um cluster do Kubernetes no serviço de nuvem de sua preferência ou na plataforma do Kubernetes local. A aplicação que eu estou usando está disponível aqui.

Depois que sua aplicação estiver em execução no Kubernetes, você terá os pods a seguir (ou alguma variante) em execução no espaço de nome default.

A saída deve ser semelhante à seguinte:

Nesta versão, iniciamos apenas os services e o loadgenerator. Você notará que o OpenTelemetry Collector ainda não foi iniciado. (Consulte a próxima etapa.)
Se você observar os yamls de serviço individuais, verá que estão apontando para o OpenTelemetry Collector na port 4317.

Port 4317 é a porta padrão na qual o OpenTelemetry escuta para extrair dados de telemetria dos serviços.  Portanto, todos os serviços devem apontar para o OpenTelemetry Collector.

Etapa 3: inicie o OpenTelemetry Collector apontando para o Elastic

Como você verá no arquivo otelcollector.yaml, no /deploy-with-collector-k8s, existem duas variáveis específicas que precisam ser definidas na seção configmap.

OTEL_EXPORTER_OTLP_ENDPOINT é o APM Server da Elastic.

OTEL_EXPORTER_OTLP_ENDPOINT fornece sua autorização.

Para obter mais detalhes sobre as variáveis, consulte a documentação da Elastic sobre a configuração do OpenTelemetry Collector.

Onde você obtém esses valores? 

Na UI do Elastic Observability em APM, +add data, a tela a seguir aparecerá. 

Vá para OpenTelemetry:

Você verá valores para as variáveis OTEL_EXPORTER_OTLP_ENDPOINT (seu endpoint do APM Server da Elastic) e a autorização de OTEL_EXPORTER_OTLP_HEADERS .

Ao configurar o OpenTelemetry Collector com o endpoint do APM Server da Elastic, há duas opções: gRPC e http.

No otelcollector.yaml aqui, os exporters são configurados com http. 

Se você quer enviar com a porta gRPC para o servidor do APM, precisa modificar os exportadores como tal:

Observe a alteração de otlphttp para otlp. Depois de fazer as alterações necessárias conforme indicado acima, crie o otelcollector:

Verifique se está funcionando corretamente.

Etapa 4: abra o Kibana e use o Service Map do APM para visualizar seus serviços instrumentados do OTel

Na UI do Elastic Observability em APM, selecione servicemap para ver seus serviços.

Se você está vendo isso, o OpenTelemetry Collector está enviando dados para o Elastic:

Parabéns, você instrumentou os serviços da aplicação de demonstração HipsterShop para tracing usando o OpenTelemetry e fez a ingestão dos dados de telemetria no Elastic!

Como configurar ambientes específicos

O Elastic APM permite que você tenha várias aplicações ingeridas com a capacidade de filtrar com base no Environment. Portanto, se dev team 1 e dev team 2 estiverem usando a UI, você precisará definir a variável environment corretamente. 

A definição da variável de ambiente para esta aplicação é feita por meio da variável deployment.environment nos yamls do serviço.

Se quiser mudar isso, você terá de mudar os OTEL_RESOURCE_ATTRIBUTES em cada um dos yamls do serviço no git da aplicação para este post.

Mude:

Para:

Para fazer isso em todos os serviços, execute o seguinte:

Etapa 5: o que o Elastic pode me mostrar?

Agora que os dados do OpenTelemetry foram inseridos no Elastic, o que você pode fazer?

Primeiro, você pode visualizar o mapa de serviços do APM (como mostrado na etapa anterior). Isso lhe dará uma visão completa de todos os serviços e dos fluxos de transação entre os serviços.

Em seguida, você pode verificar os serviços individuais e as transações que estão sendo coletadas.

Como você pode ver, os detalhes do frontend estão listados. Tudo de: 

• Latência média do serviço
• Taxa de transferência
• Principais transações
• Taxa de transações com falha
• Erros
• Dependências

Vamos ao trace. Na guia Transactions (Transações), você pode examinar todos os tipos de transações relacionadas ao serviço de frontend:

Selecionando as transações /pt/cart/checkout, podemos ver o trace completo com todos os spans:

Além de poder examinar o trace, você também pode analisar o que está relacionado à latência acima do normal para /pt/cart/checkout.

O Elastic usa machine learning para ajudar a identificar possíveis problemas de latência nos serviços a partir do trace. É tão simples quanto selecionar a guia Latency Correlations (Correlações de latência) e executar a correlação.

Isso mostra que as transações do cliente 10.8.0.16 possivelmente estão com latência anormal para esta transação.

Em seguida, você pode detalhar os logs diretamente da visualização do trace e examinar os logs associados ao trace para ajudar a identificar e apontar possíveis problemas.

Analise seus dados com o machine learning (ML) do Elastic

Depois que as métricas do OpenTelemetry estiverem no Elastic, comece a analisar seus dados com as funcionalidades de ML do Elastic.

Uma ótima análise desses recursos pode ser encontrada aqui: Correlating APM telemetry to determine root causes in transactions (Correlação da telemetria do APM para determinar as causas principais nas transações).

E há muitos outros vídeos e posts no Blog da Elastic.

Faremos o acompanhamento com posts adicionais sobre como utilizar as funcionalidades de machine learning do Elastic para dados do OpenTelemetry.

Conclusão

Espero que você tenha gostado de saber como o Elastic Observability pode ajudar a ingerir e analisar dados do OpenTelemetry com as funcionalidades de APM da Elastic.

Fazendo uma rápida recapitulação das lições, aprendemos o seguinte:

• Como configurar um app popular de demonstração (HipsterShop) instrumentado com OTel para ingestão no Elastic Cloud em algumas etapas fáceis
• Destacar algumas das funcionalidades e recursos do Elastic APM relacionados aos dados do OTel e o que você pode fazer com esses dados quando eles estiverem no Elastic

Tudo pronto para começar? Cadastre-se para usar o Elastic Cloud e experimente os recursos e funcionalidades que descrevi acima para extrair o máximo de valor e visibilidade dos seus dados do OpenTelemetry.