Dépanner l'intégration Elasticsearch OpenTelemetry

$
sudo systemctl status otelcol-contrib

• Si le service est inactif, démarrez-le : sudo systemctl start otelcol-contrib
• Si le service a échoué, corrigez les erreurs de configuration et redémarrez : sudo systemctl restart otelcol-contrib

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

Examinez la sortie des logs et résolvez la cause première (par exemple, problèmes de connexion, échecs d'authentification ou problèmes d'autorisation).

Exemple d'erreur: dial tcp [::1]:9200: connect: connection refused

• Assurez-vous que le endpoint dans config.yaml correspond à l'hôte et au port Elasticsearch.
• Confirmez qu'Elasticsearch est en cours d'exécution et accessible depuis l'hôte du collecteur.

Exemple d'erreur: permanent error: 403 Forbidden

1. Vérifier NEWRELIC_LICENSE_KEY dans /etc/systemd/system/otelcol-contrib.service.d/environment.conf .

2. Rechargez systemd et redémarrez le collecteur :

   bash

   Copier

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

Exemple d'erreur: permission denied ou cannot open file

1. Ajoutez l'utilisateur du collecteur au groupe Elasticsearch :
   bash

   Copier

   $
   sudo usermod -a -G elasticsearch otelcol-contrib

2. Redémarrez le collecteur : sudo systemctl restart otelcol-contrib

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

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

Vérifiez que le cluster est sain, que les identifiants sont valides et que les paramètres du pare-feu ou de sécurité autorisent l'accès.

• Assurez-vous que le processeur resourcedetection est inclus dans chaque pipeline de métriques.
• Vérifier que elasticsearch.cluster.name est défini via le processeur resource/cluster_name_override .

• Confirmez que les chemins du récepteur filelog sont corrects et absolus.
• Vérifiez que le pipeline de logs inclut le récepteur filelog et l'exportateur otlphttp .

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

Si aucun pod n’est renvoyé, vos pods Elasticsearch ne possèdent pas l’étiquette app=elasticsearch requise. Le receiver_creator ne peut pas découvrir de pods sans étiquettes correspondantes.

• Pour un StatefulSet/déploiement, ajoutez l’étiquette dans le modèle de pod :

  spec:
    template:
      metadata:
        labels:
          app: elasticsearch

  Copier
• Pour les pods existants, ajoutez l’étiquette et redémarrez :
  bash

  Copier

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

• Si vous utilisez des étiquettes personnalisées, mettez à jour la règle du récepteur dans values.yaml pour qu’elle corresponde à vos étiquettes :

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

  Copier

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

• Vérifiez les événements du pod pour détecter des erreurs : kubectl describe pod

• Consultez les logs du collecteur :

  bash

  Copier

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

• Vérifiez que le secret existe :

  bash

  Copier

  $
  kubectl get secret newrelic-licenses -n newrelic

• Vérifiez que les limites de ressources ne sont pas trop basses

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

• Vérifiez que les autorisations RBAC sont correctement définies :

  bash

  Copier

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

• Assurez-vous que le collecteur dispose des permissions pour surveiller les pods, les nœuds, et les points de terminaison

• Vérifiez que l’extension k8s_observer est activée dans la configuration

$
# 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

• Vérifiez que les stratégies réseau autorisent le trafic depuis l’espace de nommage newrelic vers votre espace de nommage Elasticsearch
• Vérifiez si les pods Elasticsearch exposent le port correct (par défaut : 9200)
• Assurez-vous qu’aucune règle de pare-feu ne bloque la communication inter-pod

Exemple d'erreur: permanent error: 403 Forbidden

• Vérifiez que le secret contient la bonne clé de licence :

  bash

  Copier

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

• Assurez-vous que le point de terminaison OTLP est correct pour votre région

• Vérifiez que le secret est monté dans le pod du collecteur :

  bash

  Copier

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

• Vérifiez que vous utilisez mode: daemonset (le mode de déploiement ne peut pas accéder aux log des nœuds)

• Vérifiez que les montages de volumes sont correctement configurés :

  bash

  Copier

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

• Vérifiez que le chemin du Récepteur filelog correspond à vos logs de pod Elasticsearch :

  bash

  Copier

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

• Assurez-vous que le collecteur dispose des droits de lecture sur les répertoires de log de l’hôte

• Vérifiez que la variable d’environnement K8S_CLUSTER_NAME est définie dans values.yaml

• Vérifiez que le Processeur resource/cluster se trouve dans le pipeline de métriques

• Requête à vérifier :

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

  Copier

  Vérifiez si l’attribut k8s.cluster.name est présent

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

• L’exportation native de trace OTLP nécessite Elasticsearch 9.4 ou version ultérieure. Confirmez votre version avec curl http://localhost:9200 .
• Vérifiez que les trois paramètres sont présents dans elasticsearch.yml : telemetry.tracing.enabled: true , telemetry.export.endpoint , et telemetry.tracing.sample_rate .
• Confirmez que la propriété système JVM -Dtelemetry.otel.traces.enabled=true est définie (dans jvm.options ou ES_JAVA_OPTS ), puis redémarrez Elasticsearch.
• Le telemetry.tracing.sample_rate par défaut est 0.001 (0,1 %). Augmentez-le lors de la validation afin que les spans apparaissent rapidement.

• Confirmez que le collecteur dispose d'un récepteur otlp avec le protocole gRPC activé sur 0.0.0.0:4317 , et que le point de terminaison est accessible depuis les nœuds Elasticsearch.
• Confirmez qu’un pipeline traces existe et inclut le récepteur otlp et l’exportateur otlphttp .
• Vérifiez les logs du collecteur pour les erreurs de récepteur OTLP ou d'exportation.

Une boucle sur elle-même apparaît lorsque des spans Elasticsearch atteignent New Relic sans pouvoir être attribués à une application appelante. Il existe deux sources courantes :

• Spans Elasticsearch sans parent (racine) : spans sans span d’application parent, tels que les sondes d’intégrité Kubernetes ou les propres appels de scraping du récepteur de métriques Elasticsearch ( _nodes/stats , _cluster/health et similaires). Parce qu’ils ne font pas partie de la trace d’une application, New Relic n’a pas de service appelant et établit la relation sur le cluster lui-même.

• L'adresse propre du nœud : les spans du serveur Elasticsearch contiennent http.request.headers.host (et server.address ), que New Relic résout vers le cluster.

  Résolution

  Ajoutez les deux processeurs au pipeline traces , puis redémarrez le collecteur. filter/drop_rootless_es rejette les spans Elasticsearch sans parent (les spans pilotés par l’application ont toujours un parent, ils sont donc conservés), et transform/strip_es_host supprime les attributs d’adresse :

  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]

  Copier

  Les auto-boucles existantes s’effacent d’elles-mêmes une fois que les spans corrigés arrivent et que la relation précédente expire (cela peut prendre jusqu’à environ 75 minutes).

• Assurez-vous que vos applications sont instrumentées et propagent l’en-tête W3C traceparent lors de leurs appels Elasticsearch. La plupart des clients Elasticsearch modernes le font automatiquement lorsque l’application est instrumentée avec OpenTelemetry.
• Ouvrez une trace distribuée qui inclut un appel Elasticsearch, et confirmez que les spans d’application et les spans Elasticsearch partagent la même trace.
• Laissez quelques minutes à la relation pour s'établir. New Relic réévalue périodiquement les relations entre les entités.

• Le chemin des traces se base sur es.cluster.name (estampillé par Elasticsearch sur ses spans) et le chemin des métriques sur elasticsearch.cluster.name . Le elasticsearchreceiver rapporte elasticsearch.cluster.name automatiquement à partir de la valeur renvoyée par Elasticsearch, de sorte que les deux dérivent du même cluster.name et se résolvent en une seule entité : aucune configuration de collecteur supplémentaire n’est nécessaire.
• Ne forcez pas le nom du cluster de métriques à une valeur fixe. Si la configuration de votre collecteur le définit avec un Processeur resource (par exemple un resource/cluster_name_override qui code le nom en dur), supprimez cette surcharge — sinon les métriques et les traces se résolvent en deux entités différentes et l’entité corrélée n’affiche aucune donnée de métriques.
• Assurez-vous que votre cluster.name Elasticsearch est unique au sein de votre compte New Relic afin qu’il corresponde à une seule entité sans ambiguïté.