Application Real-Time Monitoring Service:[Mise à niveau] Agent ARMS Application Monitoring 4.x

Modifications et impacts

• Par défaut, l'instrumentation des méthodes pour les beans gérés par Spring est désactivée. L'agent n'instrumente désormais que les méthodes des contrôleurs.

  Risques potentiels :

  • Après la mise à niveau, les méthodes des classes annotées avec @Service ou @Component n'apparaîtront plus dans les traces.

  • Les exceptions levées par les méthodes des classes annotées avec @Service ou @Component ne seront pas capturées.

• Les noms des métriques pour la surveillance des pools de threads et des pools de connexions ont changé. Pour plus de détails, consultez Surveillance des pools de threads et des pools de connexions.

  Risques potentiels :

  • Si vous avez configuré des règles d'alerte pour la surveillance des pools de threads dans Application Monitoring, reconfigurez-les.

    Sur la page Create Application Monitoring Alert Rule, définissez Metric Type sur Thread_Pool_Version_2.

  • Si vous disposez d'un tableau de bord personnalisé utilisant les métriques des pools de threads, celui-ci n'affichera aucune donnée.

  • L'augmentation du volume de métriques peut entraîner une hausse des coûts en paiement à l'utilisation.

• La métrique de surveillance du délai des messages a été renommée arms_mq_delay_seconds.

  Risque potentiel : si vous disposez d'un tableau de bord personnalisé utilisant cette métrique, celui-ci n'affichera aucune donnée.

• L'agent propage désormais automatiquement le contexte de trace pour les appels asynchrones, ce qui élimine le besoin de configurer les noms de packages.

• Il n'est plus nécessaire de définir des consommateurs personnalisés pour RabbitMQ ou des méthodes de consommation personnalisées pour Kafka. Les définitions existantes ne sont pas affectées.

• La récupération de l'ID de trace via MDC.get("EagleEye-TraceID") n'est plus prise en charge. Toutefois, la corrélation entre les journaux et l'ID de trace n'est pas affectée.

  Risque potentiel : l'ID de trace récupéré via MDC.get("EagleEye-TraceID") sera null.

• Les appels internes sans point d'entrée génèrent désormais un span.

  Risque potentiel : l'augmentation du nombre de spans peut entraîner une hausse des coûts en paiement à l'utilisation.

• L'agent calcule désormais les statistiques de quantile en utilisant une méthode de distribution par buckets basée sur l'interpolation linéaire, remplaçant l'algorithme précédent basé sur Prometheus Summary.

  Risque potentiel : les métriques de quantile peuvent devenir imprécises si la distribution réelle des durées diffère significativement du bucketing actuel.

• Le SpanStatus est désormais aligné sur le standard OpenTelemetry. Selon ce standard, les requêtes HTTP avec un code de réponse 4xx ou 5xx sont marquées comme error. Tous les autres cas sont marqués comme unset. Les versions précédentes de l'agent marquaient ces autres cas comme ok.

• Après la mise à niveau vers l'agent 4.x, l'ID de trace doit comporter 32 caractères. Ce format n'est pas compatible avec l'ancienne fonctionnalité Browser Monitoring. Nous vous recommandons d'intégrer le nouveau service Real User Monitoring.

• Les versions 4.1.12 et antérieures de l'agent ne sont pas compatibles avec la fonctionnalité de threads virtuels du JDK 21. Une compatibilité complète est prévue pour la version 4.3.x. Si votre application dépend fortement des threads virtuels, nous vous recommandons de rester sur une version 3.x de l'agent.

• Pour les applications qui utilisent arms-sdk pour ajouter des bagages via un filtre spring-cloud-gateway, la propagation des bagages échoue lors de la mise à niveau vers l'agent 4.2.x et de l'activation du plugin spring-bean dans la configuration personnalisée.

Augmentation du reporting de données dans la version 4.x

Après la mise à niveau d'un agent 3.x vers un agent 4.x, vous pouvez constater une augmentation du volume de métriques rapportées dans certains scénarios. Cette augmentation est due aux modifications suivantes :

• L'agent crée désormais des spans pour les appels internes sans point d'entrée, ce qui augmente le nombre de spans et de métriques rapportés.

• L'agent prend désormais en charge davantage de pools de threads personnalisés dans la surveillance des pools de threads, ce qui augmente le nombre de métriques rapportées.

• L'agent prend désormais en charge davantage de types de pools de connexions dans la surveillance des pools de connexions, ce qui augmente le nombre de métriques rapportées.

• Pour les appels asynchrones, le nombre de métriques en amont et en aval augmente car l'agent 4.x propage automatiquement le contexte de trace.

• L'agent offre désormais une prise en charge plus large des plugins, tels que l'instrumentation étendue pour Lettuce, ce qui se traduit par un plus grand nombre de métriques rapportées.

• Pour améliorer les performances du profilage des threads dans les applications comportant un nombre élevé de threads, l'agent 4.x ajuste la manière dont les données sont collectées et stockées. Par rapport à l'agent 3.x, l'activation du profilage des threads rapporte désormais un petit nombre de métriques supplémentaires préfixées par arms_grouped_thread. Pour désactiver cette fonctionnalité, consultez Profilage des threads.

• Pour la consommation de messages par lots dans une file d'attente de messages (MQ), l'agent crée désormais un span distinct pour chaque message d'un lot, au lieu d'un seul span pour l'ensemble du lot. Cela peut augmenter considérablement le nombre de spans rapportés si les lots contiennent de nombreux messages. Il s'agit d'une modification intentionnelle qui fournit des données plus granulaires. Si le volume de données est préoccupant, envisagez d'ajuster le taux d'échantillonnage ou de désactiver le plugin MQ pertinent.