Aucune trace d'appels

Pour des raisons de performances, nous limitons les rapports d'erreurs comme suit :

• 100 événements par minute par agent instance
• 20 détails de trace par minute par instance d'agent

Notre agent APM signale automatiquement les erreurs pour les exceptions non gérées. Dans les situations où la logique application gère l'erreur, notre agent APM peut manquer l'erreur et ne signalera pas de trace d'appels.

Vous pouvez utiliser l'API spécifique à l'agent notice_error() pour enregistrer les exceptions traitées.

Si vous avez configuré les erreurs à ignorer, la trace des appels ne sera pas disponible

Le renvoi d'une erreur 500 signifie que le serveur d'application lui-même a détecté une erreur et défini le code d'état HTTPS 500 .

• Si la condition d'erreur a été détectée et gérée par la logique application , il n'y avait aucun objet d'exception et donc aucune stack.

• S'il y avait un objet d'exception à un moment donné, mais qu'il était géré en interne par le code d'application qui définissait le statut 500 sur la réponse, alors l'exception n'est jamais devenue visible pour l'agent. Il n'y a aucune stack disponible pour que l'agent puisse la signaler.

  Lorsque des traces d'appels sont signalées, l'erreur résulte d'une exception qui n'a pas été détectée et gérée dans la logique du serveur application . L'agent voit l'exception non gérée lors d'une transaction de monitoring, il signale donc la trace des appels.

Lorsqu'une erreur est générée dans une séquence répétée rapidement, le compilateur Java peut optimiser la trace des appels pour améliorer les performances. Pour désactiver cette optimisation : Dans vos indicateurs JVM, incluez :

-XX:-OmitStackTraceInFastThrow