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

• Native OTLP trace export requires Elasticsearch 9.4 or later. Confirm your version with curl http://localhost:9200 .
• Verify all three settings are present in elasticsearch.yml : telemetry.tracing.enabled: true , telemetry.export.endpoint , and telemetry.tracing.sample_rate .
• Confirm the JVM system property -Dtelemetry.otel.traces.enabled=true is set (in jvm.options or ES_JAVA_OPTS ), then restart Elasticsearch.
• The default telemetry.tracing.sample_rate is 0.001 (0.1%). Raise it while validating so spans appear quickly.

• Confirm the collector has an otlp receiver with the gRPC protocol enabled on 0.0.0.0:4317 , and that the endpoint is reachable from the Elasticsearch nodes.
• Confirm a traces pipeline exists and includes the otlp receiver and the otlphttp exporter.
• Check the collector logs for OTLP receiver or export errors.

A self-loop appears when Elasticsearch spans reach New Relic that can't be attributed to a calling application. There are two common sources:

• Parentless (root) Elasticsearch spans — spans with no parent application span, such as Kubernetes health probes or the Elasticsearch metrics receiver's own scrape calls ( _nodes/stats , _cluster/health , and similar). Because they aren't part of an application's trace, New Relic has no calling service and draws the relationship on the cluster itself.

• The node's own address — Elasticsearch server spans carry http.request.headers.host (and server.address ), which New Relic resolves back to the cluster.

  Resolução

  Add both processors to the traces pipeline, then restart the collector. filter/drop_rootless_es drops the parentless Elasticsearch spans (application-driven spans always have a parent, so they're kept), and transform/strip_es_host removes the address attributes:

  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

  Existing self-loops clear on their own once the corrected spans arrive and the previous relationship expires (this can take up to about 75 minutes).

• Make sure your applications are instrumented and propagate the W3C traceparent header on their Elasticsearch calls. Most modern Elasticsearch clients do this automatically when the application is instrumented with OpenTelemetry.
• Open a distributed trace that includes an Elasticsearch call and confirm the application spans and Elasticsearch spans share the same trace.
• Give the relationship a few minutes to build. New Relic re-evaluates entity relationships periodically.

• The traces path keys on es.cluster.name (stamped by Elasticsearch on its spans) and the metrics path on elasticsearch.cluster.name . The elasticsearchreceiver reports elasticsearch.cluster.name automatically from the value Elasticsearch returns, so both derive from the same cluster.name and resolve to one entity — no extra collector configuration needed.
• Don't force the metrics cluster name to a fixed value. If your collector config sets it with a resource processor (for example a resource/cluster_name_override that hardcodes the name), remove that override — otherwise metrics and traces resolve to two different entities and the correlated entity shows no metrics data.
• Make sure your Elasticsearch cluster.name is unique within your New Relic account so it maps to a single, unambiguous entity.