Options configurables de l'agent Java APM

L'agent Java APM dispose des options configurables suivantes pour la collecte de données :

Traces abrégées

Cette fonctionnalité est conçue pour éliminer les cas de comptage excessif par trace. Lorsque trop d'étendue sont créées en un seul appel, l'agent peut entraîner une surcharge supérieure à la surcharge souhaitée, il peut également augmenter le nombre d'étendue horaire, ce qui entraîne une charge plus élevée que prévu. Dans certains cas, il peut s'agir d'appels récursifs (intentionnels ou non), de code généré entraînant un nombre élevé d'instructions SQL exécutées par transaction, entre autres.

  • La fonctionnalité d'abridge permet aux utilisateurs de limiter le nombre maximal d'étendues par appel. Elle permet également d'exclure des étendues qui peuvent être considérées comme "non dignes" (par exemple, un grand nombre d'instructions SQL très rapides).
  • Les limites de nombre spécifiques aux sondes, l'inclusion/exclusion basée sur un nom d'étendue et les seuils JDBC sont configurables par thread, par appel. Pour plus d'informations sur les options de configuration, reportez-vous au fichier ProbeConfig.acml sous le répertoire oracle-apm-agent\config.
  • Le paramètre par défaut est de limiter chaque appel à 100 étendues.
  • Les statistiques récapitulatives de base sur les étendues supprimées peuvent être collectées par thread, par appel.

Voici un exemple de paramètre qui limite le nombre maximal d'étendues JDBC par appel de thread à 50, exclut une instruction SQL ordinaire connue et exclut les instructions SQL exécutées en moins de 2 ms. En activant l'option summarize, l'agent ajoute les mesures suivantes à l'étendue parent : nombre d'étendues supprimées, durée moyenne d'étendu supprimée, temps minimal d'étendue supprimée, temps maximal d'étendue supprimée, nombre d'erreurs de l'étendue supprimée, ainsi que les enregistrements de journal présentant les 5 étendues supprimées les plus longues et les 5 premières erreurs supprimées.

abridged_probes: 
 summarize: true 
 settings_by_probe: 
 - probe: "JDBC" 
   span_limit: 50 
   excluded_patterns: 
    - contains: "select sysdate from dual" 
      excluded: true 
    threshold: 
      duration: 2 
      start_thresholding_after: 10

Disjoncteur

  • Le disjoncteur réduit automatiquement la consommation des ressources de la JVM par l'agent lorsqu'une charge importante est détectée sur ces dernières. Le disjoncteur relance automatiquement le fonctionnement normal de l'agent lorsque la charge sur les ressources a été suffisamment réduite.
  • Par défaut, le disjoncteur arrête/reprend le travail de l'agent de façon automatique et incrémentielle en fonction de l'utilisation de la portion de mémoire et de la durée de nettoyage de la mémoire.
    Facteur de performance Arrêt Reprise Intervalle Composants ciblés
    Utilisation de la portion de mémoire 95 % 85 % 2 minutes Sondes
          5 minutes Agent complet
    Durée du nettoyage de la mémoire 10 % 5 % 2 minutes Sondes
          5 minutes Agent complet
  • Vous pouvez configurer les facteurs de performance, les seuils d'arrêt, les seuils de reprise, les intervalles et les composants ciblés. Pour plus de détails, reportez-vous au fichier CircuitBreakerConfig.acml sous le répertoire oracle-apm-agent\config\<version>.
  • Le disjoncteur est activé par défaut. Il peut être désactivé et réactivé à l'aide de la propriété com.oracle.apm.agent.circuit.breaker.enable du fichier AgentConfig.properties situé sous le répertoire oracle-apm-agent\config.

    La désactivation et la réactivation du disjoncteur ne nécessitent pas le redémarrage de l'agent Java APM.

échantillonnage

  • Par défaut, toutes les étendues sont collectées. Pour modifier la configuration d'échantillonnage, vous devez configurer un échantillonnage personnalisé.
  • Vous pouvez réduire la quantité de données de trace en définissant une configuration d'échantillonnage. Pour plus d'informations, reportez-vous à Configuration de l'échantillonnage APM.
  • L'échantillonnage est soumis aux limites de collecte des données des traces abrégées et du disjoncteur.

Injection de bibliothèque de journaux

Les éléments spanId et traceId actifs peuvent être injectés dans les messages de journal. Elle fournit une corrélation entre les messages de journal et les traces APM pour faciliter l'analyse et le dépannage des journaux.

Pour configurer cette fonction, procédez comme suit :
  • Activez la sonde LOG_LIB dans le fichier ProbeConfig.acml.

  • Activez l'injection de journal souhaitée dans la section détaillée LOG_LIB de ProbeConfig.acml.

L'activation de l'injection de bibliothèque de journaux effectue les opérations suivantes :

  • L'injection automatique permet l'injection de spanId et traceId sans modification de la configuration de journalisation de l'application existante.

    Log4j 1.2, log4j 2, logback et java.util.logging sont pris en charge.

  • WebLogic L'injection de journal d'accès au serveur peut injecter les éléments spanId et traceId actifs pour une demande HTTP donnée. En général, aucun élément spanId ou traceId n'est associé au contenu statique tel que favicon.ico.
  • L'injection de MDC (Mapped Diagnostic Context) tire parti des fonctionnalités intégrées de log4j, log4j2 et logback pour mettre les éléments spanId et traceId actifs à la disposition des structures de journalisation.

    Vous pouvez spécifier les clés suivantes dans la configuration de journalisation MDC appropriée pour la structure de journalisation de l'application :
    • oracle.apm.spanId
    • oracle.apm.traceId