L'agent eBPF de New Relic utilise la technologie eBPF pour fournir des fonctionnalités APM dans un agent unique sans instrumentation de code. Cette approche renforce les équipes d'ingénierie de plateforme en éliminant le besoin de coordination avec les équipes d'application pour monitoring du déploiement.
Quand utiliser l'APM eBPF
- Déploiement à grande échelle : lorsque vous avez de nombreuses applications nécessitant monitoring à grande échelle et exigeant des indicateurs « suffisamment bons » sans la surcharge liée aux agents linguistiques individuels.
- Charge de travail inconnue ou non modifiable : lorsque la workload que vous souhaitez monitorer est écrite dans un langage de programmation inconnu et/ou ne peut pas être modifiée.
- Efficacité de l'ingénierie de plateforme : lorsque vous souhaitez déployer monitoring à grande échelle sans coordination avec les équipes d'application individuelles.
- Environnements axés sur Linux : lorsque vous n’avez pas besoin de monitorer la plateforme Windows, car eBPF fonctionne parfaitement sous Linux, aussi bien dans les environnements Kubernetes que dans les environnements hôtes.
- Aucune exigence de tracing distribué : lorsque vos besoins monitoring ne nécessitent pas de capacités de tracing distribué.
Comparaison entre eBPF et APM traditionnel
Comprendre les différences entre les agents APM basés sur eBPF et les agents APM traditionnels vous aide à choisir la bonne approche :
Fonctionnalité | APM eBPF | Agent APM |
|---|---|---|
Résumé | ✅ | ✅ |
Transaction | ✅ (liaison de segments pour Java, Go, Node.js) | ✅ |
opérations de base de données | ✅ | ✅ |
Cartographie des services | ✅ | ✅ |
Tracing distribué | ❌ | ✅ |
Indépendant du langage de programmation | ✅ | ❌ |
instrumentation personnalisée | ❌ | ✅ |
Découvrir automatiquement des applications et des services en continu | ✅ | ❌ |
Prise en charge de Linux | ✅ | ✅ |
Prise en charge de Windows | ❌ | ✅ |
Télémétrie TCP et DNS | ✅ | ❌ |
perspective de la source de données
L'APM basé sur eBPF déplace la perspective monitoring de la couche application à la couche noyau :
Fonctionnalité | Agent de langue APM | APM alimenté par eBPF |
|---|---|---|
Source des données | Points d'ancrage mémoire/d'exécution de l'application | Noyau Linux (via eBPF) |
dépendance linguistique | Élevé (nécessite un agent spécifique pour chaque langue) | Aucun (opère au niveau du noyau pour la vue du processus) |
Modification du code | Requis | Non requis (observe le processus de l'extérieur) |
Résultat | Informations approfondies et détaillées pour les langues connues | Excellentes informations détaillées pour toute workload sous Linux (C++, Rust, etc.) |
bonnes pratiques pour déployer
1. Compléter le modèle APM traditionnel
Utilisez l'agent eBPF pour compléter les agents de langage APM pour une couverture complète. Cela vous offre une couverture APM complète avec une coexistence entre l'APM eBPF et les agents APM, sans double ingestion de données.
Approche recommandée :
- Agents de langage APM : à utiliser pour vos applications les plus critiques qui nécessitent des informations détaillées, un tracing distribué ou une instrumentation personnalisée de niveau approfondi.
- APM basé sur eBPF : à utiliser pour couvrir tout le reste, y compris les services non instrumentés, les applications tierces et pour la découverte/le signalement continu de nouveaux services.
2. Ajoutez des métriques de réseau pour un contexte plus approfondi
Aperçu
Nous travaillons encore sur la fonctionnalité de métriques réseau eBPF, mais nous serions ravis que vous l'essayiez !
Cette fonctionnalité est actuellement fournie dans le cadre d'un aperçu conformément à nos politiques de pré-sortie. Il n'est pas disponible pour les clients soumis aux réglementations HIPAA ou FedRAMP.
L'agent eBPF peut également fournir des métriques réseau granulaires (TCP, DNS, etc.) pour vous donner de la visibilité en dehors du périmètre de votre application. Cette fonctionnalité est complémentaire et peut être utilisée avec ou sans eBPF APM. Pour plus d'informations, consultez network-metrics.
Les options de déploiement suivantes sont disponibles :
Application métrique source | Réseau métrique source | Configuration |
|---|---|---|
Agent de langue APM | Agent eBPF (mode métriques réseau uniquement) | Deux agents |
APM eBPF | Agent eBPF (même agent) | Agent unique |
3. Créer une approche monitoring unifiée
En suivant les pratiques ci-dessus, vous pouvez utiliser l'agent eBPF unique pour gérer à la fois les besoins de monitoring de l'infrastructure et des applications. Cela unifie votre observabilité, permettant à l'agent de collecter automatiquement des données critiques sur les performances des applications (APM eBPF) et des métriques réseau (métriques réseau eBPF) pour alimenter les dashboards existants, offrant un contexte approfondi sans modification de code ni redémarrage.
Avantages:
- Informations APM détaillées qui remplissent automatiquement l'interface utilisateur New Relic APM.
- Informations réseau détaillées du même agent.
Recommandations de mise en œuvre
Commencez par l'APM eBPF pour passer à l'échelle : si vous devez déployer le monitoring à grande échelle sur de nombreuses applications et que vous souhaitez des métriques "suffisantes" sans coordination complexe, commencez par l'APM basé sur eBPF.
Ajoutez des métriques réseau pour une visibilité complète : Une fois eBPF APM déployé, envisagez d'ajouter des métriques réseau eBPF pour gagner en visibilité au-delà du périmètre de l'application et bénéficier de capacités de dépannage complètes.