Solucionar problemas da integração do Elasticsearch com OpenTelemetry

$
sudo systemctl status otelcol-contrib

• Se o serviço estiver inativo, inicie-o: sudo systemctl start otelcol-contrib
• Se o serviço falhou, corrija os erros de configuração e reinicie: sudo systemctl restart otelcol-contrib

$
sudo journalctl -u otelcol-contrib.service -f

Analise a saída do log e resolva a causa raiz (por exemplo, problemas de conexão, falhas de autenticação ou problemas de permissão).

Amostra de erro: dial tcp [::1]:9200: connect: connection refused

• Certifique-se de que o endpoint em config.yaml corresponda ao host e à porta do Elasticsearch.
• Confirme se o Elasticsearch está em execução e acessível a partir do host do coletor.

Amostra de erro: permanent error: 403 Forbidden

1. Verifique NEWRELIC_LICENSE_KEY em /etc/systemd/system/otelcol-contrib.service.d/environment.conf .

2. Recarregue o systemd e reinicie o coletor:

   bash

   Copiar

   $
   sudo systemctl daemon-reload
   $
   sudo systemctl restart otelcol-contrib

Amostra de erro: permission denied ou cannot open file

1. Adicione o usuário do coletor ao grupo Elasticsearch:
   bash

   Copiar

   $
   sudo usermod -a -G elasticsearch otelcol-contrib

2. Reinicie o coletor: sudo systemctl restart otelcol-contrib

$
# Unsecured cluster
$
curl -I http://localhost:9200
$

$
# With authentication
$
curl -u username:password -k https://localhost:9200

Verifique se o cluster está íntegro, se as credenciais são válidas e se as configurações de firewall ou segurança permitem o acesso.

• Garanta que o processador resourcedetection esteja incluído em todos os pipelines de métricas.
• Verifique se elasticsearch.cluster.name está definido via processador resource/cluster_name_override .

• Confirme se os caminhos do receptor filelog estão corretos e absolutos.
• Verifique se o pipeline de logs inclui tanto o receptor filelog quanto o exportador otlphttp .

$
# Verify your Elasticsearch pods have the required label
$
kubectl get pods -n <namespace> -l app=elasticsearch --show-labels

Se nenhum pod for retornado, seus pods do Elasticsearch não possuem o rótulo app=elasticsearch obrigatório. O receiver_creator não consegue descobrir pods sem rótulos correspondentes.

• Para StatefulSet/Implantação, adicione o rótulo no modelo do pod:

  spec:
    template:
      metadata:
        labels:
          app: elasticsearch

  Copiar
• Para pods existentes, adicione o rótulo e reinicie:
  bash

  Copiar

  $
  kubectl label pods -l <your-selector> app=elasticsearch -n <namespace>
  $
  kubectl rollout restart statefulset/elasticsearch -n <namespace>

• Se estiver usando rótulos personalizados, atualize a regra do receiver no values.yaml para corresponder aos seus rótulos:

  rule: type == "pod" && labels["app"] == "your-custom-label"

  Copiar

$
kubectl get pods -n newrelic
$
kubectl describe pod <collector-pod-name> -n newrelic

• Verifique os eventos do pod para erros: kubectl describe pod

• Revise os logs do coletor:

  bash

  Copiar

  $
  kubectl logs -n newrelic -l app.kubernetes.io/name=opentelemetry-collector

• Verifique se o segredo existe:

  bash

  Copiar

  $
  kubectl get secret newrelic-licenses -n newrelic

• Verifique se os limites de recursos não estão muito baixos

$
# Check collector logs for discovery errors
$
kubectl logs -n newrelic -l app.kubernetes.io/name=opentelemetry-collector | grep "receiver_creator"

• Verifique se as permissões RBAC estão definidas corretamente:

  bash

  Copiar

  $
  kubectl get clusterrole | grep opentelemetry
  $
  kubectl describe clusterrole <role-name>

• Certifique-se de que o coletor tenha permissões para monitorar pods, nós e endpoints

• Verifique se a extensão k8s_observer está ativada na configuração

$
# Check network policies
$
kubectl get networkpolicies -n <namespace>
$

$
# Test connectivity from collector to Elasticsearch
$
kubectl exec -n newrelic <collector-pod> -- curl http://<es-pod-ip>:9200

• Verifique se as políticas de rede permitem o tráfego do namespace newrelic para o seu namespace Elasticsearch
• Verifique se os pods do Elasticsearch estão expondo a porta correta (padrão: 9200)
• Certifique-se de que nenhuma regra de firewall bloqueie a comunicação entre pods

Amostra de erro: permanent error: 403 Forbidden

• Verifique se o segredo contém a chave de licença correta:

  bash

  Copiar

  $
  kubectl get secret newrelic-licenses -n newrelic -o jsonpath='{.data.NEWRELIC_LICENSE_KEY}' | base64 -d

• Certifique-se de que o endpoint OTLP esteja correto para sua região

• Verifique se o segredo está montado no pod do coletor:

  bash

  Copiar

  $
  kubectl describe pod <collector-pod> -n newrelic | grep -A5 "Environment"

• Verifique se você está usando mode: daemonset (o modo de implantação não pode acessar os logs do nó)

• Verifique se as montagens de volume estão configuradas corretamente:

  bash

  Copiar

  $
  kubectl describe pod <collector-pod> -n newrelic | grep -A10 "Mounts"

• Verifique se o caminho do receptor filelog corresponde aos logs do seu pod do Elasticsearch:

  bash

  Copiar

  $
  kubectl exec -n newrelic <collector-pod> -- ls /var/log/pods/*/elasticsearch*/*.log

• Certifique-se de que o coletor tenha permissões de leitura nos diretórios de log do host

• Verifique se a variável de ambiente K8S_CLUSTER_NAME está definida no values.yaml

• Verifique se o processador resource/cluster está no pipeline de métricas

• Consulta para verificar:

  FROM Metric SELECT * WHERE metricName LIKE 'elasticsearch.%' LIMIT 1

  Copiar

  Verifique se o atributo k8s.cluster.name está presente

FROM Span SELECT count(*) WHERE es.cluster.name = '<elasticsearch-cluster-name>' SINCE 30 minutes ago

• A exportação nativa de trace OTLP requer o Elasticsearch 9.4 ou posterior. Confirme sua versão com curl http://localhost:9200 .
• Verifique se todas as três configurações estão presentes em elasticsearch.yml : telemetry.tracing.enabled: true , telemetry.export.endpoint e telemetry.tracing.sample_rate .
• Confirme se a propriedade de sistema da JVM -Dtelemetry.otel.traces.enabled=true está definida (em jvm.options ou ES_JAVA_OPTS ) e, em seguida, reinicie o Elasticsearch.
• O telemetry.tracing.sample_rate padrão é 0.001 (0,1%). Aumente-o durante a validação para que os spans apareçam rapidamente.

• Confirme se o coletor tem um receptor otlp com o protocolo gRPC habilitado em 0.0.0.0:4317 e se o endpoint está acessível a partir dos nós do Elasticsearch.
• Confirme se existe um pipeline traces e se ele inclui o receptor otlp e o exportador otlphttp .
• Verifique os logs do coletor em busca de erros do receptor OTLP ou de exportação.

Um self-loop aparece quando os spans do Elasticsearch que chegam ao New Relic não podem ser atribuídos a um aplicativo chamador. Existem duas origens comuns:

• Spans do Elasticsearch sem pai (raiz) — spans sem um span de aplicativo pai, como sondas de integridade do Kubernetes ou as próprias chamadas de coleta do receptor de métricas do Elasticsearch ( _nodes/stats , _cluster/health e similares). Como eles não fazem parte do trace de um aplicativo, o New Relic não tem um serviço de chamada e desenha o relacionamento no próprio cluster.

• O próprio endereço do nó — os spans do servidor Elasticsearch carregam http.request.headers.host (e server.address ), que o New Relic resolve de volta para o cluster.

  Resolução

  Adicione ambos os processadores ao pipeline traces e, em seguida, reinicie o coletor. filter/drop_rootless_es descarta os spans do Elasticsearch sem pai (os spans orientados por aplicativo sempre têm um pai, portanto, são mantidos) e transform/strip_es_host remove os atributos de endereço:

  processors:
    filter/drop_rootless_es:
      error_mode: ignore
      traces:
        span:
          - 'instrumentation_scope.name == "elasticsearch" and IsRootSpan()'
    transform/strip_es_host:
      error_mode: ignore
      trace_statements:
        - context: span
          statements:
            - delete_key(attributes, "http.request.headers.host") where instrumentation_scope.name == "elasticsearch"
            - delete_key(attributes, "server.address") where instrumentation_scope.name == "elasticsearch"
  # traces pipeline: processors: [filter/drop_rootless_es, transform/strip_es_host, batch]

  Copiar

  Os auto-loops existentes são limpos automaticamente assim que os spans corrigidos chegam e o relacionamento anterior expira (isso pode levar até cerca de 75 minutos).

• Certifique-se de que seus aplicativos estejam instrumentados e propaguem o cabeçalho W3C traceparent em suas chamadas do Elasticsearch. A maioria dos clientes modernos do Elasticsearch faz isso automaticamente quando o aplicativo é instrumentado com o OpenTelemetry.
• Abra um distributed trace que inclua uma chamada do Elasticsearch e confirme se os spans do aplicativo e os spans do Elasticsearch compartilham o mesmo trace.
• Aguarde alguns minutos para que o relacionamento seja estabelecido. O New Relic reavalia os relacionamentos de entidade periodicamente.

• O caminho dos traces usa es.cluster.name como chave (marcado pelo Elasticsearch em seus spans) e o caminho das métricas usa elasticsearch.cluster.name . O elasticsearchreceiver relata elasticsearch.cluster.name automaticamente a partir do valor que o Elasticsearch retorna, portanto, ambos derivam do mesmo cluster.name e são resolvidos em uma entidade — nenhuma configuração extra do coletor é necessária.
• Não force o nome do cluster de métricas para um valor fixo. Se a configuração do seu coletor o definir com um processador resource (por exemplo, um resource/cluster_name_override que define o nome de forma fixa), remova essa substituição — caso contrário, as métricas e os traces serão resolvidos em duas entidades diferentes e a entidade correlacionada não mostrará dados de métricas.
• Certifique-se de que o cluster.name do Elasticsearch seja exclusivo em sua conta do New Relic para que seja mapeado para uma única entidade não ambígua.