Cette traduction automatique est fournie pour votre commodité.
En cas d'incohérence entre la version anglaise et la version traduite, la version anglaise prévaudra. Veuillez visiter cette page pour plus d'informations.
Considérez HAProxy comme un saut connecté dans vos traces distribuées, et non plus comme une simple boîte noire entre les services. HAProxy 3,4 et les versions ultérieures incluent un filtre OpenTelemetry qui permet à votre équilibreur de charge de participer directement aux traces distribuées, afin que New Relic puisse cartographier automatiquement les relations de service entre vos applications, et l’entité HAProxy dans les cartes de service : aucune configuration manuelle n’est requise.
Cette page vous montre comment configurer le filtre OTel HAProxy, son exportateur, et le Collecteur Otel afin que les données de trace parviennent à New Relic. Pour découvrir comment le tracing fonctionne sous le capot (l’extraction, et la propagation du W3C Trace Context via HAProxy), consultez la section Comment ça marche ci-dessous.
Comment ça marche
Dans une configuration typique, le trafic circule comme suit :
L'application frontend envoie une requête avec un en-tête W3C traceparent.
Le filtre OTel d’HAProxy extrait le contexte de trace, crée des spans couvrant le cycle de vie de la requête, et injecte le contexte de trace mis à jour dans la requête transférée au backend.
L’application backend reçoit la requête avec le contexte de trace propagé et continue la trace.
Le frontend, HAProxy, et le backend exportent leurs spans vers un OpenTelemetry Collector, qui les transmet à New Relic.
New Relic utilise ces spans connectés pour créer des relations CALLS :
Agents New Relic APM (Go, Java, .NET, Node.js, Python, Ruby, PHP) avec le tracing distribué activé
Vous pouvez combiner les approches d’instrumentation. Par exemple, un frontend du SDK OTel peut appeler via HAProxy un backend de l’agent New Relic APM, et la chaîne de relation s’affiche correctement dans New Relic.
HAProxy 3.4 ou version ultérieure avec le filtre OTel activé. Consultez le guide d’installation OTel HAProxy pour obtenir des instructions sur l’obtention d’une distribution prenant en charge le filtre OTel.
Collector OpenTelemetry (OTel Collector Contrib, ou NRDOT) s’exécutant sur le même hôte, ou accessible depuis l’hôte HAProxy
Applications instrumentées envoyant des requests via HAProxy, en utilisant l’une des approches d’instrumentation compatibles répertoriées ci-dessus
Ce guide configure à la fois la collecte de métriques et le tracing distribué dans un seul Collecteur Otel. Pour une configuration avancée des métriques ou un déploiement Kubernetes, consultez Monitorer HAProxy auto-hébergé et Monitorer HAProxy sur Kubernetes.
Configurer le tracing distribué
Conseil
Le pipeline de traces ci-dessous correspond à la même configuration standard que vous utiliseriez pour tout service participant au tracing distribué, et non à une configuration de relation manuelle. Une fois le tracing actif, New Relic détecte automatiquement les spans connectés, et crée des relations de service. Aucune configuration supplémentaire n’est nécessaire pour que les relations s’affichent.
Ajoutez la directive filter opentelemetry à la section frontend de votre haproxy.cfg. Cela indique à HAProxy d'appliquer le filtre OTel aux requests entrantes :
frontend main
bind *:8080
default_backend app_servers
filter opentelemetry id otel config /etc/haproxy/otel.cfg
frontend stats
bind *:8404
stats enable
stats uri /stats
Le paramètre config pointe vers un fichier de configuration de filtre OTel distinct qui définit les spans, la propagation du contexte et les paramètres de l’exportateur.
Le frontend stats active le point de terminaison de statistiques HAProxy, que le haproxyreceiver du Collecteur Otel utilise pour collecter les métriques de performances. Ajustez l’adresse de liaison, et le port si nécessaire.
Créez le fichier de configuration du filtre OTel (par exemple, /etc/haproxy/otel.cfg) :
[otel]
otel-instrumentation otel-inst
config /etc/haproxy/otel.yml default
no option disabled
rate-limit 100.0
scopes client_session_start
scopes frontend_http_request
scopes backend_http_request
scopes client_session_end
scopes server_session_start
scopes http_response
scopes server_session_end
otel-scope client_session_start
extract "-ctx" use-headers
span "HAProxy session" parent "-ctx" root
otel-event on-client-session-start
otel-scope frontend_http_request
span "Frontend HTTP request" parent "HAProxy session" kind server
Cette configuration effectue les opérations suivantes :
Extrait l’en-tête W3C traceparent entrant (extract "-ctx" use-headers), reliant les spans HAProxy à la trace du service appelant.
Crée des spans pour l’ensemble du cycle de vie de la requête : début de session, traitement de la requête frontend, transfert de la requête backend, traitement de la réponse, et fin de session.
Injecte le contexte de trace mis à jour dans les requests envoyées aux backend (inject "-ctx" use-headers), permettant aux services en aval de continuer la trace.
Trace 100 % des requests (rate-limit 100.0). Ajustez cette valeur pour réduire le volume de trace dans les environnements à haut débit.
Important
La valeur id dans la directive filter opentelemetry dans haproxy.cfg doit correspondre au nom de la section dans otel.cfg (par exemple, [otel]).
Créez le fichier de configuration de l’exportateur du filtre (par exemple, /etc/haproxy/otel.yml). Cela indique au filtre OTel HAProxy où envoyer ses données de trace :
exporters:
exporter_traces:
type: otlp_grpc
endpoint:"http://localhost:4317/v1/traces"
processors:
processor_batch:
type: batch
providers:
provider_traces:
resources:
-service.name:"YOUR_HAPROXY_SERVICE_NAME"
signals:
traces:
default:
scope_name:"HAProxy OTel filter"
exporters: exporter_traces
processors: processor_batch
providers: provider_traces
Remplacez YOUR_HAPROXY_SERVICE_NAME par un nom qui identifie cette instance HAProxy (par exemple, haproxy-prod-lb).
service.name est l’ attribut de ressource OpenTelemetry standard qui identifie tout service participant au tracing distribué, et pas seulement HAProxy. Chaque application instrumentée par OTel le définit (via OTEL_SERVICE_NAME), et chaque agent New Relic APM possède l’équivalent (app_name). Sans cela, les traces circulent et se connectent toujours correctement, mais les spans apparaissent sous la forme unknown_service dans l’UI, ce qui les rend difficiles à identifier. Pour plus de détails, consultez les bonnes pratiques des ressources OpenTelemetry.
Il s’agit d’une configuration unique par instance HAProxy. Lorsque vous ajoutez de nouvelles applications backend, ou frontend, vous n’avez pas besoin de modifier ce fichier : les relations se forment automatiquement grâce à la propagation du contexte de trace.
L’exportateur envoie les traces via gRPC à localhost:4317, où le Collecteur Otel est à l’écoute. Ajustez le endpoint si le collecteur s’exécute sur un hôte différent.
Configurez le Collecteur Otel pour recevoir les traces du filtre OTel HAProxy, et les métriques du point de terminaison de statistiques HAProxy, et pour les transférer à New Relic.
Cette configuration de collecteur inclut deux pipelines :
Pipeline de trace: reçoit les données de trace OTLP du filtre OTel HAProxy et de vos applications instrumentées via gRPC (port 4317) ou HTTP (port 4318). Il s’agit du même pipeline de trace standard que vous utiliseriez pour tout service envoyant des données OTLP à New Relic.
Pipeline de métriques: utilise le haproxyreceiver pour collecter des métriques de performances (sessions par seconde, taux de requêtes, santé du backend) à partir du point de terminaison de statistiques HAProxy. Ces métriques créent l’entité HAProxy dans New Relic avec des métriques dorées.
Les deux pipelines partagent ces Processeurs :
resourcedetection: ajoute host.name et host.id, qui sont des attributs de ressource standards utilisés pour identifier les hôtes dans l’écosystème OpenTelemetry.
resource/haproxy: ajoute l’attribut haproxy.addr, qui identifie cette instance HAProxy et relie les métriques et les données de trace sous la même entité HAProxy dans New Relic.
La valeur http://127.0.0.1:8404/stats est l’adresse de statistiques HAProxy conventionnelle utilisée dans la documentation officielle de HAProxy, et correspond à la valeur haproxy.cfg de l’étape 1. Il s’agit d’une valeur statique unique par instance HAProxy. Lorsque vous ajoutez, ou supprimez des applications backend, et frontend, vous n’avez pas besoin de modifier la configuration du collecteur : les relations se forment automatiquement grâce à la propagation du contexte de trace. Ajustez uniquement la valeur endpoint, et resource/haproxy du Récepteur haproxy si votre point de terminaison de statistiques utilise une adresse, un port, ou une URI différente : les deux doivent toujours correspondre.
Définissez les variables d’environnement requises et démarrez (ou redémarrez) le collecteur :
Redémarrez HAProxy pour charger la configuration du filtre OTel :
bash
$
sudo systemctl restart haproxy
Important
Le binaire HAProxy doit inclure le filtre OTel. Si vous voyez des erreurs telles que unknown keyword 'filter' ou unknown keyword 'opentelemetry', votre build HAProxy n’inclut pas le filtre. Consultez le guide d’installation OTel HAProxy pour obtenir une distribution compatible.
Afficher les relations de vos services
Une fois que HAProxy et le collecteur sont en cours d’exécution, générez du trafic via vos applications instrumentées. Après quelques minutes, vérifiez que les données arrivent dans New Relic :
-- Verify HAProxy trace spans
FROM Span SELECTcount(*)
WHERE service.name ='YOUR_HAPROXY_SERVICE_NAME'
SINCE 10 minutes ago
-- Verify HAProxy metrics
FROM Metric SELECTcount(*)
WHERE metricName LIKE'haproxy.%'
SINCE 10 minutes ago
Une fois que les données de trace circulent, New Relic crée automatiquement des relations CALLS entre vos services et l’entité HAProxy. Les relations peuvent mettre jusqu’à 10 minutes à apparaître.
Vous pouvez également interroger les relations avec NRQL :
FROM Relationship SELECT*
WHERE source.entityName ='YOUR_HAPROXY_SERVICE_NAME'
OR target.entityName ='YOUR_HAPROXY_SERVICE_NAME'
SINCE 1day ago
Dépannage
Recherchez ces erreurs de démarrage :
Prise en charge du filtre manquante: si vous voyez unknown keyword 'filter' ou unknown keyword 'opentelemetry', votre binaire HAProxy n’inclut pas le filtre OTel. Consultez le guide d’installation OTel HAProxy.
Fichier de configuration introuvable: si vous voyez unable to load OTel configuration, vérifiez que le chemin config dans la directive filter opentelemetry est correct et que le fichier existe. Les chemins sont relatifs au répertoire de travail de HAProxy.
Erreurs de bibliothèque partagée: le filtre OTel nécessite les bibliothèques partagées du SDK C++ OpenTelemetry. Assurez-vous qu’elles sont installées et détectables (par exemple, via LD_LIBRARY_PATH ou ldconfig).
Effectuez ces vérifications dans l'ordre :
Vérifiez que HAProxy a démarré sans erreurs : sudo journalctl -u haproxy -n 50 --no-pager
Vérifiez que le filtre OTel est chargé. Recherchez les erreurs mentionnant filter, opentelemetry, ou otel dans les logs HAProxy.
Vérifiez que le Collecteur Otel est en cours d’exécution et à l’écoute sur le port spécifié dans otel.yml: sudo ss -tlnp | grep 4317
Vérifiez les logs du collecteur pour les erreurs : sudo journalctl -u otelcol-contrib -n 50 --no-pager
Confirmez que le point de terminaison de l'exportateur otel.yml correspond à l'adresse d'écoute gRPC du collecteur.
Vérifiez ces causes possibles :
Prévoyez jusqu’à 10 minutes pour que les relations apparaissent après l’arrivée des premiers spans.
Vérifiez que vos applications instrumentées envoient des traces via le collecteur. Les spans HAProxy et les spans de l’application doivent atteindre New Relic pour que les relations se forment.
Vérifiez que vos applications frontend propagent les en-têtes W3C traceparent. Sans propagation du contexte de trace, les spans HAProxy ne sont pas connectés au service appelant.
Confirmez que les processeurs resourcedetection et resource/haproxy sont tous deux inclus dans le pipeline de trace du collecteur. Les attributs host.id et haproxy.addr sont requis pour l'identification de l'entité HAProxy.
Vérifiez que le pipeline de métriques est en cours d’exécution avec le Récepteur haproxy. Le pipeline de métriques crée l’entité HAProxy ; sans lui, HAProxy apparaît comme un service générique plutôt que comme une entité HAProxy dédiée.
Requête pour vérifier que les spans HAProxy et de l’application partagent les ID de trace :
FROM Span SELECT uniques(service.name)
WHERE trace.id IN(
SELECT uniques(trace.id)FROM Span
WHERE service.name ='YOUR_HAPROXY_SERVICE_NAME'
SINCE 10 minutes ago LIMIT5
)
SINCE 10 minutes ago
Vous devriez voir le nom de votre service HAProxy à côté des noms de vos services d'application.
Envisagez ces causes possibles :
Envoyez les traces de chaque application instrumentée via le même Collecteur Otel (ou directement à New Relic) afin que les données de span pour tous les services atteignent le même compte.
Pour les applications utilisant des agents New Relic APM, vérifiez que le tracing distribué est activé, et que l’agent est connecté.
Pour les applications SDK OTel, vérifiez que l’exportateur OTLP est configuré pour envoyer au collecteur.
Prévoyez un délai supplémentaire, car les relations pour les services avec un volume de trafic plus faible peuvent mettre plus de temps à apparaître.