JMX-SflowAgent cesse de collecte de statistiques JVM de aspectj instrumenté WebSphere Application Server

Question

projet:

J'utilise SFlow + Ganglions pour surveiller des paramètres de la JVM de Websphere Application Server (WAS). WAS est instrumenté en utilisant les aspects AspectJ. J'ai ajouté un aspect pour mesurer toutes les exécutions de méthode d'application. J'utilise Hsflowd en tant que collecteur de métriques JVM. Hsflowd utilise en interne le javaagent JMX-SflowAgent pour se connecter à la JVM afin de collecter des métriques à l'aide de MXBeans (RuntimeMXBean, GarbageCollectorMXBean, CompilationMXBean et ThreadMXBean).

Problème:

Quand je lance ÉTAIT sans crochet je peux tissage dans la programmation orientée aspect voir tous les paramètres (CPU, bureau, mémoire, processus, etc.) dans le Web de façon continue Ganglions. Mais quand aspectjweaver est ajouté aux arguments JVM et après le redémarrage du serveur, je peux voir les métriques pendant 10 minutes, mais après cela, il ne rapporte pas les métriques JVM dans Ganglia web.

Dans les journaux de tissage Aspectj, je peux voir qu'AspectJ tisse le code JMXsflowAgent. Même si elle est exclue via !call(* com.sflow.JMX.SFlowAgent(..)).

Aspect:

package com.foo.main; 

import java.io.*; 
import java.lang.reflect.Method; 
import java.security.Signature; 
import java.util.*; 

import org.aspectj.lang.ProceedingJoinPoint; 
import org.aspectj.lang.annotation.*; 
import org.osgi.service.application.ApplicationAdminPermission; 

@Aspect 
public class ResponseTimeAspect { 
    @Pointcut(
     "execution(* com.foo.*(..)) && " + 
     "!within(com.foo.main.ResponseTimeAspect) && " + 
     "!within(ThreadLocal+) && " + 
     "!within(&& !within(*..*Aspect)) && " + 
     "!within(com.foo.main.AppInformationReader) && " + 
     "!within(@org.aspectj.lang.annotation.Aspect *) && " + 
     "!within(com.sflow.jmx.SFlowAgent) && " + 
     "!(call(* com.sflow.jmx.SFlowAgent(..)))" 
    ) 
    public void loggingResponseTime() {} 

    private static ThreadLocal<String> uuidContainer = new ThreadLocal<String>() { 
     @Override 
     protected String initialValue(){ 
      return UUID.randomUUID().toString(); 
     } 
    }; 

    AppInformationReader logWriter = AppInformationReader.getInstance(); 

    @Around("loggingResponseTime()") 
    public Object tracing(ProceedingJoinPoint thisJoinPoint) throws Throwable { 

     Long startTime= System.currentTimeMillis(); 
     Long startTotalMemory = Runtime.getRuntime().totalMemory(); 
     Long startFreeMemory = Runtime.getRuntime().freeMemory(); 

     Object ret = thisJoinPoint.proceed(); 

     Long elapsedTime=System.currentTimeMillis() - startTime; 
     Long endTotalMemory = Runtime.getRuntime().totalMemory(); 
     Long endFreeMemory = Runtime.getRuntime().freeMemory(); 
     String methodSignature=thisJoinPoint.getSignature().toString(); 
     String classname=methodSignature.split("\\.")[thisJoinPoint.getSignature().toString().split("\\.").length-1]; 
     String methodName =thisJoinPoint.getSignature().getDeclaringType().getCanonicalName(); 
     logWriter.writeLog(uuidContainer.get().toString(), startTime, System.currentTimeMillis(), elapsedTime, classname, methodName); 
     return ret; 
    } 
} 

Les paquets JMX sont sous com.sflow.jmx.SFlowAgent.

Answer 1

Désistement: Ceci est une réponse, mais pas encore une solution. Cela n'a pas de sens d'écrire encore plus de remarques, donc je vais plutôt affiner ma réponse ici en recueillant plus d'informations de Vimlesh.

Bon, il est impossible de reproduire votre problème avec juste l'aspect et non un vrai SSCCE affichant le comportement problématique. Il y a beaucoup de questions ouvertes:

• Je ne sais pas combien de classes l'aspect est appliqué à,
• combien de threads il y a dans le serveur d'applications et
• ce qui se passe avec la consommation de mémoire les 10 minutes avant et après les résultats JMX ne sont plus affichés.
• Vous avez indiqué que l'agent SFlow s'exécutait une seule fois au lieu de toutes les 10 secondes. Comment le sais-tu? Pouvez-vous s'il vous plaît fournir des informations expliquant comment vous avez découvert et comment reproduire le comportement, de manière optimale sans un serveur d'applications, mais avec une simple machine virtuelle Java SE?
• Je me demande aussi pourquoi l'aspect rassemble des informations sur la mémoire libre. N'est-ce pas ce que l'autre agent Java devrait faire? Pourquoi le faire deux fois? Il me semble étrange qu'une variable nommée logWriter soit une instance de AppInformationReader. Alors, qu'est-ce que c'est, un lecteur ou un écrivain? Et que fait la classe? L'aspect l'utilise, mais il n'est pas montré.
• Pourquoi diable créez-vous UUID s par fil dans l'aspect et à quoi servent-ils? Ils semblent ne rien ajouter, comme je l'ai déjà dit dans l'autre question que vous avez postée plus tôt. Vous n'avez pas répondu à la question, pouvez-vous le faire maintenant? Cela ressemble à des frais généraux inutiles.
• Le pointcut est excessif.Par exemple,
  • execution(* com.foo.*(..)) capture uniquement les exécutions de méthode dans les classes directement sous le package com.foo, mais pas dans les sous-packages. Il est donc inutile d'exclure des classes de sous-packages. Probablement ce que vous voulez vraiment est execution(* com.foo..*(..)) - notez les deux points dans foo..* signifiant des sous-paquets.
  • Vous avez mal compris ma réponse à l'autre question parce que vous n'avez pas choisi un de mes solutions pour exclure l'aspect et sa sous-classe ThreadLocal anonyme utilisé en interne, mais concaténé tous d'entre eux avec &&. Cela ne le rend pas meilleur ou plus lisible.
  • Vous essayez d'exclure call(* com.sflow.jmx.SFlowAgent(..)), mais pour deux raisons, il n'est pas nécessaire: Tout d'abord, SFlowAgent n'est pas dans le package ciblé com.foo. Deuxièmement, un jointure execution() ne peut jamais être un jointure call() en même temps, donc l'ensemble d'intersection doit être vide - pas besoin d'exclure les appels des exécutions.
  • Cette syntaxe est invalide: !within(&& !within(*..*Aspect)) - peut-être une copie & collez l'erreur concernant les clauses within() imbriquées.

Cela dit, vous voulez probablement ce pointcut:

execution(* com.foo..*(..)) && 
!within(@org.aspectj.lang.annotation.Aspect *) && 
!within(com.foo.main.AppInformationReader) 

Cela devrait être suffisant. Après avoir corrigé votre pointcut, vous pouvez essayer d'arrêter la collecte et la journalisation des informations dans l'aspect pour le rendre plus efficace. Comme pour l'autre agent Java, il n'est pas nécessaire de l'exclure du tissage d'aspect, mais vous devez peut-être exclure l'aspect d'être ciblé par SFlowAgent. Peut-être qu'il y a un problème dans le code d'aspect instrumenté par l'agent SFlow, mais c'est juste une supposition. Peut-être que votre configuration est fausse, peut-être quelque chose d'autre. Il me semble que vous essayez de manier deux armes (outils) que vous n'avez jamais appris à utiliser correctement. Sans un SSCCE, il est vraiment difficile de diagnostiquer la cause première du problème.

Mise à jour: Vous pouvez également essayer de lister AspectJ Weaver en tant que premier agent Java sur la ligne de commande JVM, c'est-à-dire avant l'agent SFlow. Testez si cela fait une différence.