Application Real-Time Monitoring Service:Analyse des journaux

Pourquoi la corrélation des journaux échoue-t-elle après des modifications XML ?

Si ce problème survient lors de l'interrogation des journaux dans SLS, vérifiez d'abord que les journaux sont bien transmis à SLS et que vous avez associé le projet et le Logstore corrects dans la console ARMS.

Une fois que vous avez confirmé la présence des données dans SLS, résolvez le problème en fonction des deux scénarios suivants :

• Aucun journal n'est corrélé à un ID de trace. Ce problème peut avoir plusieurs causes :

  • L'agent n'est pas correctement attaché.

    Vérifiez si toutes les métriques s'affichent correctement dans la console ARMS.

  • Le commutateur principal de l'agent est désactivé, ou certains plug-ins, tels que le plug-in Tomcat, sont désactivés.

    Vérifiez cela dans la section Agent switch settings de la page Custom configurations.

  • Le framework côté serveur n'est pas pris en charge. Par exemple, vous utilisez peut-être un conteneur web, un framework RPC, un framework de tâches planifiées ou un framework de messagerie non pris en charge. Pour obtenir la liste des frameworks pris en charge, consultez la rubrique Composants et frameworks Java pris en charge par la surveillance des applications.

  • Vous utilisez des frameworks de journalisation autres que Log4j, Log4j2 ou Logback, ou vous avez fortement modifié ces frameworks.

  • La configuration XML du journal est incorrecte.

    Suivez les étapes ci-dessous pour investiguer :

    • Si vous utilisez la version 4.1.6 ou ultérieure de l'agent, activez la fonction d'injection automatique de l'ID de trace. Si les ID de trace peuvent être corrélés, cela confirme une erreur dans la configuration XML du journal.

    • Importez le SDK ARMS pour Java et récupérez manuellement l'ID de trace lors de l'impression des journaux. Voici un exemple de code :

      Span span = Tracer.builder().getSpan();   // This does not create a new span.
      String traceId = span.getTraceId();
      logger.warn("traceId={} this is your log message", traceId)

      Si vous pouvez récupérer l'ID de trace, cela confirme une erreur dans la configuration XML du journal.

    • Si les deux méthodes échouent, soumettez un ticket.

• Certains journaux ne sont pas corrélés à un ID de trace. Cela peut être dû à l'absence de contexte de trace dans les journaux.

  En général, les journaux ne disposent pas de contexte de trace lors de leur écriture. Un contexte de trace n'est généralement présent que dans les journaux imprimés aux points d'entrée des requêtes, tels que dans le code de traitement des interfaces HTTP, des interfaces RPC, des tâches planifiées ou de la consommation de messages.

  Scénarios d'exemple :

  • Après qu'une application reçoit une requête HTTP, elle exécute une requête de base de données, puis imprime un journal. Dans ce cas, un contexte de trace existe et le journal peut être correctement corrélé à un ID de trace.

  • Une application reçoit une requête HTTP, soumet une tâche asynchrone à un pool de threads pour exécuter une requête de base de données, puis imprime un journal.

    • Pour l'agent v3.x, les journaux ne peuvent pas être corrélés à un ID de trace car l'agent ne prend pas en charge la propagation asynchrone automatique du contexte de trace. Le thread asynchrone ne dispose pas de contexte de trace.

    • Pour l'agent v4.x, les journaux peuvent être corrélés à un ID de trace car l'agent prend en charge la propagation asynchrone automatique du contexte de trace. Le thread asynchrone dispose d'un contexte de trace.

  • Après le démarrage, une application utilise un pool de threads JDK pour exécuter cycliquement des requêtes de base de données et imprimer un journal après chaque requête. Dans ce cas, aucun contexte de trace n'existe et les journaux ne peuvent pas être corrélés à un ID de trace.

  Identifiez le scénario spécifique en vérifiant le nom du thread qui a écrit le journal.

  Par exemple :

  • Lorsque vous utilisez Tomcat comme conteneur web, les noms de threads commençant par http-nio- représentent généralement les threads qui gèrent les requêtes HTTP. Les journaux imprimés par ces threads peuvent être corrélés à un ID de trace.

  • Lorsque vous utilisez Dubbo comme framework RPC, les noms de threads commençant par DubboServerHandler- représentent généralement les threads qui gèrent les requêtes Dubbo. Les journaux imprimés par ces threads peuvent être corrélés à un ID de trace.

  Les autres frameworks se comportent de manière similaire. Si vous déterminez que le problème n'est causé par aucun de ces scénarios, soumettez un ticket.

Pourquoi les journaux sont-ils vides dans Trace Explorer ?

Suivez ces étapes de dépannage :

1. Vérifiez si aucun des journaux de l'application n'est corrélé à un ID de trace. Si c'est le cas, reportez-vous aux étapes de dépannage de la rubrique Pourquoi les journaux ne sont-ils pas corrélés aux ID de trace après modification de la configuration XML des journaux ?. Sinon, passez à l'étape suivante.

2. Si vous ne trouvez pas de journaux pour un ID de trace concernant une ou plusieurs interfaces spécifiques, cela signifie généralement que ces interfaces n'ont généré aucun journal.

3. Si aucun des scénarios ci-dessus ne s'applique, soumettez un ticket.

Pourquoi le Logstore est-il vide après l'association ?

Vous devez configurer la collecte de journaux pour le Logstore conformément à la documentation SLS. ARMS ne collecte pas automatiquement les journaux dans le Logstore.

Pourquoi la corrélation des ID de trace échoue-t-elle pour les journaux de passerelle ?

L'agent v3.x présente un défaut connu dans son instrumentation de Spring Cloud Gateway. La mise à niveau vers l'agent v4.x résout ce problème.

Pourquoi la corrélation des ID de trace échoue-t-elle avec TraceCallable.wrap() ?

Cela indique que la méthode est utilisée incorrectement. Nous recommandons de mettre à niveau vers l'agent v4.x, qui gère les scénarios asynchrones sans modification du code.

Pourquoi la corrélation des ID de trace échoue-t-elle avec l'injection automatique ?

Ce problème survient généralement dans deux situations :

• Aucun journal n'est corrélé à un ID de trace : cela indique généralement que la configuration n'a pas été appliquée avec succès à l'agent. Vérifiez la connectivité au serveur Application Configuration Management (ACM) en consultant la documentation Configuration réseau pour la surveillance des applications Java.

• Certains journaux ne sont pas corrélés à un ID de trace : reportez-vous aux étapes de dépannage de la rubrique Pourquoi les journaux ne sont-ils pas corrélés aux ID de trace après modification de la configuration XML des journaux ?.

ARMS peut-il remplacer Simple Log Service (SLS) ?

Non. Application Real-Time Monitoring Service (ARMS) et Simple Log Service (SLS) ont des objectifs différents et se complètent plutôt que de se remplacer mutuellement.

• ARMS est un produit de surveillance des performances des applications (APM) qui se concentre sur l'analyse des traces, la surveillance des API et l'analyse des performances des applications. La fonctionnalité d'analyse des journaux d'ARMS interroge les journaux du projet SLS et du Logstore que vous avez associés ; elle utilise donc SLS comme backend de stockage des journaux. ARMS ne collecte pas les journaux dans le Logstore à votre place.

• SLS est un service polyvalent de collecte, de stockage et d'analyse de journaux, qui prend en charge l'ingestion de données provenant de multiples sources.

Pour utiliser la fonctionnalité d'analyse des journaux d'ARMS, associez un projet SLS et un Logstore comme décrit dans l'Étape 1 : Corréler les journaux métier de cette rubrique. Ensuite, dans la barre de navigation supérieure, sélectionnez Scenario-based Analysis > Log Analysis pour interroger et analyser les journaux.