Linkerd exécute un proxy invisible aux côtés de chaque service maillé, de sorte que sans observabilité au niveau du maillage, vous pouvez voir ce que font vos services, mais pas comment ils communiquent entre eux.
Cette intégration utilise le Récepteur Prometheus de l’OpenTelemetry Collector pour récupérer automatiquement les métriques du proxy et du control plane de Linkerd, sans modification de code, ni instrumentation par service. Vous obtenez le taux de requêtes, la latence, et le statut mTLS pour chaque workload maillé prêts à l’emploi, et vous pouvez facultativement ajouter des traces distribuées qui relient les spans au niveau du maillage dans la même cascade que les traces APM de votre application.
Principaux avantages
- Signaux dorés au niveau du maillage: consultez le taux de requêtes, la latence (p50/p95/p99), le taux de réussite, et les connexions TCP pour chaque workload maillé, collectés automatiquement sans modifier le code de l’application.
- Visibilité de mTLS et de la sécurité: suivez l’expiration des certificats, le taux de rotation, et le nombre d’autorisations accordées/refusées en un seul endroit.
- Santé du control plane: monitorez la profondeur de la file d’attente, le nombre de points de terminaison actifs, le taux d’émission de certificats, et l’activité du proxy-injector pour le control plane Linkerd lui-même.
- Visibilité des relations APM: lorsque vous activez le tracing distribué (Linkerd 2.19+), Linkerd synthétise les spans de proxy dans la même entité que vos services APM, vous n’avez donc pas besoin d’un backend de tracing distinct.
- Zéro modification de code: le proxy sidecar de chaque pod maillé expose des métriques sur
:4191, et le Collecteur Otel les récupère automatiquement.
Cas d'utilisation
Si vous êtes une équipe de plateforme ou SRE qui exécute des microservices natifs Kubernetes, la visibilité au niveau du maillage vous aide à identifier le service en amont provoquant un pic de latence, à détecter les certificats mTLS avant leur expiration, à comprendre les tempêtes de nouvelles tentatives, et à corréler la charge du control plane avec les performances des applications. Vous obtenez tout cela à partir d’une seule entité New Relic.
Capacités
- Métriques: taux de requêtes, latence (p50/p95/p99), taux de réussite, et statistiques de connexion TCP pour chaque workload maillé, ainsi que l'expiration du certificat mTLS, et l'état de santé du control plane, collectés automatiquement sans aucune modification de code
- Traces (facultatif, Linkerd 2.19+) : les spans du proxy Linkerd sont synthétisés dans la même cascade que vos traces APM, de sorte que la latence au niveau du maillage et les spans au niveau de l’application s’affichent ensemble
- Logs: les logs du conteneur sidecar
linkerd-proxyrattachés à la même entité que les métriques et les traces - Entités: une entité Linkerd par workload maillé, corrélée au déploiement Kubernetes sous-jacent
Choisissez votre chemin d'installation
- NRDOT avec Helm (recommandé): distribution OpenTelemetry Collector prise en charge par New Relic, installée de la même manière que la plupart des utilisateurs de Kubernetes gèrent déjà les sorties Helm
- NRDOT avec manifeste: le même collecteur NRDOT, pour les clusters qui gèrent la configuration via des manifestes Kubernetes bruts au lieu de Helm
- Collecteur Otel Contrib avec Helm: le Collector OpenTelemetry de la communauté, si vous l’avez déjà adopté comme standard au lieu de NRDOT
- Collecteur Otel Contrib avec manifeste: le même collecteur communautaire, installation basée sur un manifeste
Installation en un coup d'œil
- Vérifier la compatibilité et rassembler les prérequis
- Installez le collecteur et configurez-le pour scraper Linkerd
- Appliquer la configuration minimale
- Trouvez et utilisez les données dans New Relic
Suivant : installation et configuration
- Utilisation de NRDOT avec Helm
- Utilisation de NRDOT avec un manifeste
- Utilisation de l’ OTel Collector Contrib avec Helm
- Utilisation de l’ OTel Collector Contrib avec manifeste