• /
  • EnglishEspañolFrançais日本語한국어Português
  • Se connecterDémarrer

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.

Créer un problème

Premiers pas avec Workloads intelligents

|View as Markdown (English)

Aperçu

Nous travaillons toujours sur cette fonctionnalité, mais nous aimerions que vous l'essayiez !

Cette fonctionnalité est actuellement fournie dans le cadre d'un programme d'aperçu conformément à nos politiques de pré-sortie.

Le monitoring traditionnel oblige souvent les équipes d'ingénierie à suivre des métriques isolées au niveau du service, ce qui crée une expérience de débogage fragmentée, « swivel-chair », lorsque les parcours critiques des utilisateurs se dégradent. Workloads intelligents fait évoluer le dépannage réactif de Transaction 360 vers un hub de monitoring proactif et auto-actualisable. En exploitant le tracing distribué pour mapper automatiquement l'ensemble de votre parc architectural à une seule transaction métier, il suit en continu les dépendances full-stack et aligne les performances techniques sur les résultats de l’entreprise (KPI) en temps réel à mesure que votre système évolue.

Prérequis

Avant de créer des Intelligent Workloads, assurez-vous d’ activer le tracing distribué sur l’ensemble de vos services APM.

Comment créer des workloads intelligents

Vous pouvez créer des Workloads intelligents de trois manières, chacune ne prenant que quelques minutes à configurer :

Définissez la portée de vos workloads intelligents

Par défaut, un workload intelligent inclut dynamiquement chaque service en amont et en aval qui participe aux traces distribuées avec votre transaction centrale. Si votre transaction appelle des microservices non détenus, des API tierces ou des branches de pipeline fan-out complexes que vous ne souhaitez pas voir impacter la santé globale de votre workload, utilisez le filtrage d’exclusion pour élaguer ces chemins de dépendance.

Cas d’utilisation courants de définition du périmètre :

  • Élaguer les dépendances non détenues: excluez les gateways d’API en amont ou les services secondaires en aval (tels que les gateways de paiement externes ou les microservices de coupons) que votre équipe ne gère pas directement.
  • Isoler les branches de pipeline: dans les architectures complexes de type fan-in et fan-out (telles que les pipeline de messages Kafka), réduisez les files d’attente de consommateur parallèles ou les sujets non pertinents pour isoler la branche d’exécution exacte que votre équipe possède.

Fonctionnement des filtres d’exclusion :

Lors de l'ajout d'un filtre d'exclusion à votre graphique de workload, configurez trois paramètres :

  • Entité cible: le nœud de service spécifique sur la carte de dépendance où vous souhaitez appliquer le filtre.
  • Direction: s’il faut élaguer les dépendances entrant dans l’entité sélectionnée (Upstream) ou en sortant (Downstream).
  • Visibilité de l’entité cible: s’il faut exclure l’entité cible elle-même ainsi que toutes ses connexions (en la supprimant entièrement du graphique de workload), ou conserver l’entité cible visible tout en élaguant uniquement ses autres dépendances en amont ou en aval.

Parce que les filtres d’exclusion sont dynamiques, tous les nouveaux microservices ou connexions qui apparaissent le long d’une branche exclue dans les futures traces sont automatiquement filtrés sans nécessiter de mises à jour manuelles de votre workload.

Screenshot of the Intelligent Workload creation wizard showing the Dynamic Flow Map with exclude filter rules applied to downstream entities

Et ensuite ?

Une fois vos workloads intelligents créées, explorez les vues et outils principaux pour vous familiariser avec le monitoring de vos parcours clients critiques :

Droits d'auteur © 2026 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.