Se você é um desenvolvedor que executa aplicativos no Kubernetes, pode usar New Relic para entender como a infraestrutura Kubernetes afeta seu aplicativo OpenTelemetryinstrumentado.
Depois de concluir as etapas abaixo, você pode usar a interface New Relic para correlacionar a métrica em nível de aplicativo do OpenTelemetry com a métrica de infraestrutura Kubernetes . Isso ajudará você a visualizar todo o cenário de seus dados de telemetria e trabalhar entre equipes para obter um tempo médio de resolução (MTTR) mais rápido para problemas em seu ambiente Kubernetes.
Visão geral: como correlacionamos os dados
As etapas deste guia permitem que seu aplicativo injete metadados específicos da infraestrutura nos dados de telemetria. O resultado é que a interface New Relic é preenchida com informações acionáveis. Aqui estão as etapas que você seguirá para fazer isso:
- Em cada contêiner de aplicativo, defina uma variável de ambiente para enviar dados de telemetria ao coletor
- implantar o coletor OpenTelemetry como um
DaemonSet
no modo agente com processadoresresourcedetection
,resource
,batch
ek8sattributes
para injetar metadados relevantes (nomes cluster, implantação e namespace )
Pré-requisitos
Para ter sucesso com as etapas abaixo, você já deve estar familiarizado com OpenTelemetry e Kubernetes e ter feito o seguinte:
Criou as seguintes variáveis de ambiente:
OTEL_EXPORTER_OTLP_ENDPOINT
( NovoNew Relic endpoint para sua região ou finalidade)NEW_RELIC_API_KEY
()
Instalou a integração do New Relic Kubernetes em seu cluster
instrumentei seu aplicativo com OpenTelemetry e enviei dados com sucesso para New Relic via OpenTelemetry Protocol (OTLP)
Se você tiver dúvidas gerais sobre o uso do coletor com New Relic, consulte nossa Introdução ao coletor OpenTelemetry com New Relic.
Configure seu aplicativo para enviar dados de telemetria para o coletor OpenTelemetry
Para configurar isso, você precisa adicionar um trecho personalizado à seção env
do seu arquivo YAML do Kubernetes . O exemplo abaixo mostra o trecho para um exemplo de microsserviços de frontend (Frontend.yaml
). O trecho inclui duas seções que fazem o seguinte:
Section 1:
Certifique-se de que os dados de telemetria sejam enviados ao coletor. Isso define a variável de ambiente
OTEL_EXPORTER_OTLP_ENDPOINT
com o IP do host. Isso é feito chamando a API descendente para extrair o IP do host.Section 2:
Anexe metadados específicos da infraestrutura. Para fazer isso, capturamos
metadata.uid
usando a API descendente e o adicionamos à variável de ambienteOTEL_RESOURCE_ATTRIBUTES
. Esta variável de ambiente é usada pelos processadoresresourcedetection
ek8sattributes
do coletor OpenTelemetry para adicionar contexto específico de infraestrutura adicional aos dados de telemetria.
Para cada microsserviços instrumentado com OpenTelemetry, adicione as linhas destacadas abaixo na seção env
do seu manifesto:
# Frontend.yamlapiVersion: apps/v1kind: Deployment...spec: containers: - name: yourfrontendservice image: yourfrontendservice-beta env: # Section 1: Ensure that telemetry data is sent to the collector - name: HOST_IP valueFrom: fieldRef: fieldPath: status.hostIP # This is picked up by the opentelemetry sdks - name: OTEL_EXPORTER_OTLP_ENDPOINT value: "http://$(HOST_IP):55680" # Section 2: Attach infrastructure-specific metadata # Get pod ip so that k8sattributes can tag resources- name: POD_NAMEvalueFrom:fieldRef:fieldPath: metadata.name- name: POD_UIDvalueFrom:fieldRef:fieldPath: metadata.uid # This is picked up by the resource detector - name: OTEL_RESOURCE_ATTRIBUTES value: service.instance.id=$(POD_NAME),k8s.pod.uid=$(POD_UID)”
Configurar e implantar o coletor OpenTelemetry como agente
Recomendamos que você implante o coletor como agente em cada nó de um cluster do Kubernetes. O agente pode receber dados de telemetria e enriquecer os dados de telemetria com metadados. Por exemplo, o coletor pode adicionar atributo personalizado ou infraestrutura de informações por meio de processadores, bem como lidar com lotes, novas tentativas, compactação e recursos avançados adicionais que são tratados de forma menos eficiente no nível de instrumentação do cliente.
Para obter ajuda na configuração do coletor, consulte o arquivo de configuração do coletor de amostra abaixo, juntamente com as seções sobre como configurar essas opções:
- Exportador OTLP
- processador em lote
- processador de resourcedetection
- Processador de atributos k8s: geral
- Processador de atributos k8s: RBAC
- Processador de atributos k8s: filtros
receivers: otlp: protocols: grpc:
processors: batch: resource: attributes: - key: host.id from_attribute: host.name action: upsert resourcedetection: detectors: [ gke, gce ] k8sattributes: auth_type: "serviceAccount" passthrough: false filter: node_from_env_var: KUBE_NODE_NAME extract: metadata: - k8s.pod.name - k8s.pod.uid - k8s.deployment.name - k8s.cluster.name - k8s.namespace.name - k8s.node.name - k8s.pod.start_time pod_association: - from: resource_attribute name: k8s.pod.uid
exporters: otlp: endpoint: $OTEL_EXPORTER_OTLP_ENDPOINT headers: api-key: $NEW_RELIC_API_KEY logging: logLevel: DEBUG
service: pipelines: metrics: receivers: [ otlp ] processors: [ resourcedetection, k8sattributes, resource, cumulativetodelta, batch ] exporters: [ otlp ] traces: receivers: [ otlp ] processors: [ resourcedetection, k8sattributes, resource, batch ] exporters: [ otlp ] logs: receivers: [ otlp ] processors: [ resourcedetection, k8sattributes, resource, batch ] exporters: [ otlp ]
Etapa 1: configurar o exportador OTLP
Primeiro, adicione um exportador OTLP ao arquivo YAML de configuração OpenTelemetry coletor junto com o New Relic como cabeçalho.
exporters: otlp: endpoint: $OTEL_EXPORTER_OTLP_ENDPOINT headers: api-key: $NEW_RELIC_API_KEY
Etapa 2: configurar o processador em lote
O processador em lote aceita spans, métrica ou log e os coloca em lotes para facilitar a compactação dos dados e reduzir o número de solicitações de saída do coletor.
processors: batch:
Etapa 3: configurar o processador de detecção de recursos
O processador resourcedetection
obtém informações específicas do host para adicionar contexto adicional aos dados de telemetria que estão sendo processados por meio do coletor. Neste exemplo, usamos Google Kubernetes Engine (GKE) e Google computar Engine (GCE) para obter metadados específicos Google Cloud , incluindo:
- cloud.provider ("gcp")
- cloud.platform ("gcp_compute_engine")
- cloud.account.id
- cloud.region
- cloud.availability_zone
- host.id
- host.image.id
- host.type
processors: resourcedetection:Detectors: [ gke, gce ]
Etapa 4: Configurar o processador de atributo Kubernetes (geral)
Quando executamos o processador k8sattributes
como parte do coletor OpenTelemetry rodando como agente, ele detecta os endereços IP do pod enviando dados de telemetria para o agente coletor OpenTelemetry , utilizando-os para extrair metadados pod . Abaixo está um exemplo básico de manifesto do Kubernetes com apenas uma seção de processadores. Para implantar o coletor OpenTelemetry como um DaemonSet
, leia este exemplo de manifesto abrangente.
processors: k8sattributes: auth_type: "serviceAccount" passthrough: false filter: node_from_env_var: KUBE_NODE_NAME extract: metadata: - k8s.pod.name - k8s.pod.uid - k8s.deployment.name - k8s.cluster.name - k8s.namespace.name - k8s.node.name - k8s.pod.start_time pod_association: - from: resource_attribute name: k8s.pod.uid
Etapa 5: configurar o processador de atributo Kubernetes (RBAC)
Você precisa adicionar configuração para controle de acesso baseado em função (RBAC). O processador k8sattributes
precisa de permissões get
, watch
e list
para recursos de pod e namespace incluídos nos filtros configurados. Veja este exemplo de como configurar o controle de acesso baseado em função (RBAC) para ClusterRole
para conceder a um ServiceAccount
as permissões necessárias para todos os pods e namespaces no cluster.
Etapa 6: Configurar o processador de atributo Kubernetes (filtro de descoberta)
Ao executar o coletor como agente, você deve aplicar um filtro de descoberta para que o processador descubra apenas o pod do mesmo host em que ele está sendo executado. Se você não usar um filtro, o uso de recursos poderá ser desnecessariamente alto, especialmente em clusters muito grandes. Depois que o filtro for aplicado, cada processador consultará apenas a Kubernetes API para pod em execução em seu próprio nó.
Para definir o filtro, use a API descendente para injetar o nome do nó como uma variável de ambiente na seção pod env
do arquivo YAML do OpenTelemetry coletor agente configuração (consulte GitHub para obter um exemplo). Isso injetará uma nova variável de ambiente no contêiner do agente coletor OpenTelemetry . O valor será o nome do nó em que o pod foi programado para ser executado.
spec: containers: - env: - name: KUBE_NODE_NAME valueFrom: fieldRef: apiVersion: v1 fieldPath: spec.nodeName
Então, você pode filtrar pelo nó com k8sattributes
:
k8sattributes: filter: node_from_env_var: KUBE_NODE_NAME
Valide se sua configuração está funcionando
Se você vinculou com sucesso seus dados OpenTelemetry aos dados Kubernetes , você poderá ver atributos Kubernetes como k8s.cluster.name
e k8s.deployment.name
em seus períodos na interface distributed tracing .
Clique para ampliar a imagem:
Qual é o próximo?
Agora que você conectou seus aplicativos instrumentados OpenTelemetryao Kubernetes, confira nosso guia de práticas recomendadas para obter dicas para melhorar o uso do OpenTelemetry e New Relic.
Você também pode verificar esta postagem do blog, Correlacionar rastreamento, métrica e log OpenTelemetry com dados de desempenho Kubernetes para obter mais informações sobre as etapas fornecidas acima.