Solucionar problemas de la integración de Elasticsearch y OpenTelemetry

$
sudo systemctl status otelcol-contrib

• Si el servicio está inactivo, inícielo: sudo systemctl start otelcol-contrib
• Si el servicio falló, corrija los errores de configuración y reinicie: sudo systemctl restart otelcol-contrib

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

Revise la salida del log y resuelva la causa raíz (por ejemplo, problemas de conexión, fallas de autenticación o problemas de permisos).

Muestra de error: dial tcp [::1]:9200: connect: connection refused

• Asegúrese de que el endpoint en config.yaml coincida con el host y el puerto de Elasticsearch.
• Confirme que Elasticsearch se esté ejecutando y sea accesible desde el host del colector.

Muestra de error: permanent error: 403 Forbidden

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

2. Recargue systemd y reinicie el recopilador:

   bash

   Copia

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

Muestra de error: permission denied o cannot open file

1. Agregue el usuario del colector al grupo de Elasticsearch:
   bash

   Copia

   $
   sudo usermod -a -G elasticsearch otelcol-contrib

2. Reinicie el colector: sudo systemctl restart otelcol-contrib

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

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

Verifique que el clúster esté en buen estado, que las credenciales sean válidas y que la configuración del firewall o de seguridad permita el acceso.

• Asegúrese de que el procesador resourcedetection esté incluido en cada pipeline de métricas.
• Verifique que elasticsearch.cluster.name esté configurado mediante el procesador resource/cluster_name_override .

• Confirme que las rutas del receptor filelog sean correctas y absolutas.
• Verifique que el pipeline de logs incluya tanto el receptor filelog como el exportador otlphttp .

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

Si no se devuelven pods, a sus pods de Elasticsearch les falta la etiqueta app=elasticsearch requerida. El receiver_creator no puede descubrir pods sin etiquetas coincidentes.

• Para StatefulSet/despliegue, agregue la etiqueta en la plantilla del pod:

  spec:
    template:
      metadata:
        labels:
          app: elasticsearch

  Copia
• Para los pods existentes, agregue la etiqueta y reinicie:
  bash

  Copia

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

• Si utiliza etiquetas personalizadas, actualice la regla del receptor en values.yaml para que coincida con sus etiquetas:

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

  Copia

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

• Verifique los eventos del pod para detectar errores: kubectl describe pod

• Revisar los logs del recolector:

  bash

  Copia

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

• Verifique que exista el secreto:

  bash

  Copia

  $
  kubectl get secret newrelic-licenses -n newrelic

• Verificar que los límites de recursos no sean demasiado bajos

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

• Verifique que los permisos RBAC estén configurados correctamente:

  bash

  Copia

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

• Asegúrese de que el recolector tenga permisos para observar pods, nodos y extremos

• Verifique que la extensión k8s_observer esté habilitada en la configuración

$
# 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 que las políticas de red permitan el tráfico desde el namespace newrelic hacia su namespace de Elasticsearch
• Verifique si los pods de Elasticsearch están exponiendo el puerto correcto (predeterminado: 9200)
• Asegúrese de que ninguna regla de firewall bloquee la comunicación entre pods.

Muestra de error: permanent error: 403 Forbidden

• Verifique que el secreto contenga la clave de licencia correcta:

  bash

  Copia

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

• Asegúrese de que el extremo OTLP sea correcto para su región

• Compruebe que el secreto esté montado en el pod recolector:

  bash

  Copia

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

• Verifique que está usando mode: daemonset (el modo de despliegue no puede acceder a los logs del nodo)

• Verifique que los montajes de volumen estén configurados correctamente:

  bash

  Copia

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

• Verifique que la ruta del receptor filelog coincida con los logs de su pod de Elasticsearch:

  bash

  Copia

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

• Asegúrese de que el recolector tenga permisos de lectura en los directorios de logs del host

• Verifique que la variable de entorno K8S_CLUSTER_NAME esté configurada en values.yaml

• Verifique que el procesador resource/cluster esté en el pipeline de métricas

• Consulta para verificar:

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

  Copia

  Verifique si el atributo k8s.cluster.name está presente

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

• La exportación nativa de trazas OTLP requiere Elasticsearch 9.4 o posterior. Confirme la versión con curl http://localhost:9200 .
• Verifique que las tres configuraciones estén presentes en elasticsearch.yml : telemetry.tracing.enabled: true , telemetry.export.endpoint y telemetry.tracing.sample_rate .
• Confirme que la propiedad del sistema de la JVM -Dtelemetry.otel.traces.enabled=true esté configurada (en jvm.options o ES_JAVA_OPTS ) y, luego, reinicie Elasticsearch.
• El valor predeterminado de telemetry.tracing.sample_rate es 0.001 (0.1 %). Auméntelo durante la validación para que los spans aparezcan rápidamente.

• Confirme que el recolector tenga un receptor otlp con el protocolo gRPC habilitado en 0.0.0.0:4317 y que el extremo sea accesible desde los nodos de Elasticsearch.
• Confirme que exista un pipeline de traces e incluya el receptor otlp y el exportador otlphttp .
• Verifique los logs del recolector en busca de errores de exportación o del receptor OTLP.

Aparece un bucle automático cuando llegan a New Relic spans de Elasticsearch que no se pueden atribuir a una aplicación de llamada. Hay dos fuentes comunes:

• Spans de Elasticsearch sin elementos principales (raíz) —spans sin span de aplicación principal, como los sondeos de estado de Kubernetes o las propias llamadas de extracción del receptor de métricas de Elasticsearch ( _nodes/stats , _cluster/health y similares). Debido a que no son parte de la traza de una aplicación, New Relic no tiene un servicio de llamada y dibuja la relación en el propio clúster.

• La dirección propia del nodo —los spans del servidor de Elasticsearch contienen http.request.headers.host (y server.address ), que New Relic resuelve en el clúster.

  Resolución

  Agregue ambos procesadores a la canalización de traces y, a continuación, reinicie el recolector. filter/drop_rootless_es descarta los spans de Elasticsearch sin elementos principales (los spans controlados por la aplicación siempre tienen un elemento principal, por lo que se mantienen) y transform/strip_es_host elimina los atributos de dirección:

  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]

  Copia

  Los autobucles existentes se eliminan por sí solos una vez que llegan los spans corregidos y la relación anterior expira (esto puede tardar hasta unos 75 minutos).

• Asegúrese de que las aplicaciones estén instrumentadas y propaguen el encabezado traceparent del W3C en las llamadas a Elasticsearch. La mayoría de los clientes modernos de Elasticsearch hacen esto automáticamente cuando la aplicación está instrumentada con OpenTelemetry.
• Abra un rastreo distribuido que incluya una llamada a Elasticsearch y confirme que los spans de la aplicación y los spans de Elasticsearch comparten la misma traza.
• Espere unos minutos para que se establezca la relación. New Relic vuelve a evaluar las relaciones de entidad periódicamente.

• La ruta de trazas se basa en es.cluster.name (marcado por Elasticsearch en sus spans) y la ruta de métricas en elasticsearch.cluster.name . El elasticsearchreceiver informa elasticsearch.cluster.name automáticamente a partir del valor que devuelve Elasticsearch, por lo que ambos derivan del mismo cluster.name y se resuelven en una entidad —no se necesita configuración adicional del recolector.
• No fuerce el nombre del clúster de métricas a un valor fijo. Si la configuración del recolector lo establece con un procesador resource (por ejemplo, un resource/cluster_name_override que define el nombre de forma rígida), elimine esa sobrescritura —de lo contrario, las métricas y las trazas se resuelven en dos entidades diferentes y la entidad correlacionada no muestra datos de métricas.
• Asegúrese de que el cluster.name de Elasticsearch sea único en la cuenta de New Relic para que se asigne a una única entidad inequívoca.