Documentation sur Oracle Cloud Infrastructure

Options configurables de l'agent Java APM

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

Traces abrégées

Cette fonction est conçue pour éliminer les cas de nombre d'intervalles excessif par trace. Lorsque trop d'intervalles sont créés en un seul appel, l'agent peut provoquer une surcharge supérieure à celle souhaitée, il peut également augmenter le nombre d'intervalles horaires, entraînant une charge plus élevée que prévue. 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 et d'autres.

  • La fonction d'abridge permet aux utilisateurs de limiter le nombre maximal d'intervalles par appel. Elle permet également d'exclure des intervalles qui peuvent être considérés comme "dignes" (par exemple, un volume élevé de SQL très rapides).
  • Les limites de nombre spécifiques à la sonde, l'inclusion/exclusion basée sur le nom d'intervalle et le seuillage JDBC sont configurables par unité d'exécution, par appel. Pour plus de détails sur les options de configuration, voir le fichier ProbeConfig.acml sous le répertoire oracle-apm-agent\config.
  • Le paramètre par défaut consiste à limiter chaque appel à 100 intervalles.
  • Les statistiques sommaires de base sur les intervalles abandonnés peuvent être collectées par thread, par appel.

Voici un exemple de paramètre qui limitera le nombre maximal d'intervalles JDBC par appel de fil à 50, exclura un énoncé SQL banal connu et exclura les énoncés SQL qui s'exécutent en moins de 2 ms. Notez qu'en activant l'option summarize, l'agent ajoutera les mesures suivantes à l'intervalle parent : nombre d'intervalles abandonnés, durée moyenne d'intervalles abandonnés, durée minimale d'intervalles abandonnés, durée maximale d'intervalles abandonnés, nombre d'erreurs d'intervalles abandonnés, ainsi que les enregistrements de journaux affichant les 5 intervalles abandonnés les plus longs et les 5 premières erreurs abandonné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 JVM par l'agent lors de la détection d'une forte pression sur les ressources. Il reprend automatiquement la fonction normale de l'agent lorsque la pression sur les ressources a suffisamment diminué.
  • Par défaut, le disjoncteur arrête et reprend automatiquement de manière incrémentielle le travail de l'agent en fonction de l'utilisation de la mémoire du tas et du temps de récupération de mémoire.
    Facteur de performance Arrêt Reprise Intervalle Composants ciblés
    Utilisation de la mémoire du tas 95 % 85 % 2 minutes Sondes
          5 minutes Agent complet
    Durée de récupération de mémoire 10 % 5 % 2 minutes Sondes
          5 minutes Agent complet
  • Les facteurs de performance, les seuils d'arrêt, les seuils de reprise, les intervalles et les composants ciblés sont configurables. Pour plus de détails, voir le 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, tous les intervalles sont collectés. Pour modifier la configuration de l'échantillonnage, vous devez configurer l'échantillonnage personnalisé.
  • Vous pouvez réduire la quantité de données de trace en définissant la configuration d'échantillonnage. Pour plus de détails, voir Configurer l'échantillonnage APM.
  • L'opération d'échantillonnage est soumise à la limite de collecte des données des traces abrégées et du disjoncteur.

Injection de bibliothèque de journaux

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

Pour configurer cette fonction, procédez de la façon suivante :

  • Activez la sonde LOG_LIB dans le fichier ProbeConfig.acml.

  • Activez l'injection de journal souhaitée dans la section LOG_LIB détaillée dans 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 de traceId sans modification de la configuration de journalisation d'application existante.

    Les options Log4j 1.2, log4j 2, logback et java.util.logging sont prises en charge.

  • L'injection de journal d'accès au serveur WebLogic peut injecter les valeurs spanId et traceId actives pour une demande HTTP donnée. Notez que le contenu statique tel que favicon.ico n'est généralement pas associé à spanId ou traceId.

  • L'injection de contexte de diagnostic mappé (MDC) tire parti des fonctions intégrées de log4j, log4j2 et de journalisation pour rendre les services spanId et traceId actifs disponibles pour les cadres de journalisation.

    Vous pouvez spécifier les clés suivantes dans la configuration de journalisation MDC appropriée pour le cadre de journalisation de l'application :
    • oracle.apm.spanId<! [CDATA[ ]]>
    • oracle.apm.traceId<! [CDATA[ ]]>