Independência com OpenTelemetry na Elastic

Por

Bahubali Shetti

illustration-scalability-gear-1680x980_(1).jpg

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:

Configuração para ingestão de dados do OpenTelemetry usada 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.

kubectl get pods -n default

A saída deve ser semelhante à seguinte:

NAME                                     READY   STATUS    RESTARTS   AGE
adservice-f9bf94d56-5kt89                1/1     Running   0          41h
cartservice-54d5955c59-7lrk9             1/1     Running   0          41h
checkoutservice-57b95c78bb-qqcqv         1/1     Running   0          41h
currencyservice-6869479db8-7tsnj         1/1     Running   0          43h
emailservice-7c95b8766b-mp5vn            1/1     Running   0          41h
frontend-5f54bcb7cf-kxwmf                1/1     Running   0          41h
loadgenerator-bfb5944b6-2qhnw            1/1     Running   0          43h
paymentservice-5bc8f549c8-hkxks          1/1     Running   0          40h
productcatalogservice-665f6879d6-kv29f   1/1     Running   0          43h
recommendationservice-89bf4bfc5-ztcrr    1/1     Running   0          41h
redis-cart-5b569cd47-6wt59               1/1     Running   0          43h
shippingservice-768b94fb8d-8hf9c         1/1     Running   0          41h

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.

        - name: OTEL_EXPORTER_OTLP_ENDPOINT
          value: "http://otelcollector: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.

    exporters:
      otlphttp/elastic:
        endpoint: OTEL_EXPORTER_OTLP_ENDPOINT
        headers:
          Authorization: OTEL_EXPORTER_OTLP_HEADERS

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:

    exporters:
      otlp/elastic:
        endpoint: OTEL_EXPORTER_OTLP_ENDPOINT
        headers:
          Authorization: OTEL_EXPORTER_OTLP_HEADERS

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

kubectl create -f otelcollector.yaml

Verifique se está funcionando corretamente.

mycomputer% kubectl get pods | grep otelcollector
otelcollector-5b87f4f484-4wbwn          1/1     Running   0            18d

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:

       - name: OTEL_RESOURCE_ATTRIBUTES
          Value: "service.name=recommendationservice,service.version=1.0.0,deployment.environment=MY-DEMO"

Para:

       - name: OTEL_RESOURCE_ATTRIBUTES
          Value: "service.name=recommendationservice,service.version=1.0.0,deployment.environment=XXX"

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

sed -i `s/MY-DEMO/XXX/g` *.yaml

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:

Latência média para esta transação, taxa de transferência, falhas e, é claro, o trace!

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.

Inscreva-se para fazer uma avaliação gratuita do Elastic Cloud

Inicie uma implantação totalmente carregada no provedor de serviços em nuvem de sua escolha. Somos a empresa por trás do Elasticsearch e oferecemos nossos recursos e suporte aos seus clusters da Elastic na nuvem.

Iniciar avaliação gratuita