Guide des bonnes pratiques pour les agents eBPF

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 l'APM eBPF et les agents APM traditionnels vous aide à choisir la bonne approche :

perspective de la source de données

L'APM eBPF déplace la perspective de monitoring de la couche applicative vers la couche noyau :

bonnes pratiques pour déployer

Compléter l'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.
• eBPF APM : À utiliser pour couvrir tout le reste, y compris les services non instrumentés, les applications tierces, et pour découvrir/signaler en continu de nouveaux services.

Ajouter des métriques du réseau pour un contexte plus approfondi

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 :

Ajout de la collecte de log pour MELT complet

L'agent eBPF peut également collecter les logs d'application et les enrichir avec les métadonnées New Relic par défaut, sans déployer de redirecteur de logs distinct. Cette capacité s'exécute sur le même agent, vous pouvez donc l'activer aux côtés de l'APM eBPF et des métriques réseau sans rien déployer de plus. Pour plus d'informations, consultez les logs eBPF.

Utilisez reportLogs: "auto" pour éviter automatiquement la collecte de logs en double : l'agent eBPF se retire d'un agent APM uniquement si cet agent collecte activement des logs lui-même, et se retire entièrement chaque fois qu'un agent OpenTelemetry est attaché. N'utilisez "true" que lorsque vous avez confirmé qu'aucun autre agent ne signale de log pour cette entité.

Recommandations de mise en œuvre

• Commencez par l'APM eBPF pour la mise à l'échelle : Si vous avez besoin de déployer le monitoring à grande échelle sur de nombreuses applications et que vous souhaitez des métriques "suffisamment bonnes" sans coordination complexe, commencez par l'APM 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.

• Ajoutez la collecte de logs pour un dépannage unifié : Une fois que vous êtes prêt, activez les logs eBPF pour collecter les logs d'application sans déployer un redirecteur de logs distinct.

Échantillonnage et ajustement des données

Les agents de langage APM limitent les événements de transaction avec un réservoir fixe, par défaut 10 000 événements par minute (configuré avec transaction_events.max_samples_stored). L'agent eBPF n'utilise pas de limite fixe unique par minute. Au lieu de cela, il échantillonne chaque type de télémétrie différemment, donc comprendre comment chaque type se comporte vous aide à contrôler le volume de données et les coûts sans perdre les signaux qui vous intéressent.

Comment fonctionne l'échantillonnage de portée

L'agent eBPF ne limite pas les spans à un nombre fixe par minute. Pour chaque protocole, il exporte uniquement les spans qui franchissent un seuil que vous avez défini :

• Seuil de latence (samplingLatency) : exporte les spans plus lents que le percentile choisi pour une route donnée. La valeur par défaut est p50 (la médiane). Augmentez-le vers p90 ou p99 pour ne conserver que la queue la plus lente et réduire le volume de données ; diminuez-le vers p1 ou p0 pour conserver presque tous les spans et augmenter la visibilité. Tout percentile de p0 à p99 est accepté.
• Seuil de taux d’erreur (samplingErrorRate, HTTP) : une valeur de 1 à 100. Lorsque le taux d’erreur d'une route dépasse ce seuil, les spans pour cette route sont exportées afin que les échecs ne soient jamais exclus de l'échantillonnage. Laissez-le vide pour désactiver l'exportation basée sur les erreurs.

Contrôle des spans non liées

Les spans que l’agent capture mais ne peut pas associer à un parent sont appelés spans non liés. Ils sont plafonnés par protocole par max_unlinked_spans (par défaut 100; définissez sur 0 pour désactiver le plafond). Le paramètre unlinked_spans_error_quota_percentage (par défaut 30) réserve une partie de ce budget pour les spans d’erreur, de sorte que les échecs restent visibles même lorsque les spans normaux arrivent en premier.

Exemples de réglage

L'échantillonnage est configuré dans le fichier Helm values.yaml (Kubernetes) ou dans /etc/newrelic-ebpf-agent/newrelic-ebpf-agent.yaml (hôte Linux). Les clés sont identiques pour les deux.

protocols:
  global:
    max_unlinked_spans: 100          # 0 disables the cap
    unlinked_spans_error_quota_percentage: 30
  http:
    enabled: true
    spans:
      enabled: true
      samplingLatency: "p90"         # keep only slower requests, less data
      samplingErrorRate: "5"         # always keep routes with >5% errors
logDataFilters:
  applicationLogReporting:
    maxSamplesPerMinute: 10000         # APM-equivalent reservoir for logs

Recommandations

• Pour maximiser la visibilité des traces : abaissez samplingLatency vers p0 et définissez un samplingErrorRate bas, mais attendez-vous à une ingestion plus élevée.
• Pour réduire les données : augmentez samplingLatency (par exemple, p90 ou p99), désactivez complètement les protocoles indésirables (ou juste spans.enabled: false pour ne conserver que les métriques de protocole), et diminuez maxSamplesPerMinute pour les logs.
• Gardez les métriques à l'esprit : les métriques ne sont pas affectées par l'échantillonnage des spans. Désactivez un protocole entier uniquement lorsque vous n'avez pas du tout besoin de ses données.

Articles connexes