Comment effectuer une analyse du framework CaptureFramework

1. Contexte

La surveillance des services d'application est une partie importante du système intelligent d'exploitation et de maintenance. Dans le système UAV, la sonde MOF (middleware enhancement framework) fournit des fonctions de collecte de données de portrait d'application et de performances. La fonction de collecte de données collecte principalement quatre types de données : données en temps réel, données de portrait, génération de données de liaison d'appel et données d'analyse de données de thread. . Afin de réaliser une collecte de données en temps réel, UAVStack a conçu le framework CaptureFramework pour fournir un comportement de capture de données unifié et la capacité de générer des résultats de capture.

2. Principe de fonctionnement de CaptureFramework

2.1 Description technique clé

• JavaAssist

• Système de capture de moniteur

• precap/docap

2. 2 Description de l'architecture

• Point de capture : Support Tomcat, MSCP, Springboot, Jetty sont enterrés.

• UAVServer singleton : en tant que point d'entrée de capture unifié, il fournit des méthodes synchrones et asynchrones.

• StandardMonitor : il implémente l'interface Monitor et est une classe d'implémentation de capture de données en temps réel. Il fournit la méthode doCapture, qui est responsable du comportement de capture et de la génération des résultats de capture.

• MonitorElemCapHandler : différentes logiques d'exploration et interfaces communes des points d'exploration implémentent différentes logiques d'enfouissement, fournissant les méthodes preCap et doCap pour le comportement d'exploration et la méthode preStore pour générer des résultats d'exploration.

• StandardMonitorRepository : stocke la structure des données de capture de données en temps réel.

• DataObserver : expose les données de l'interface JMX/HTTP.

2.3 Description de la classe clé

• La surveillance en temps réel de Monitor démarre et initialise principalement l'objet StandardMonitor de la classe DefaultMonitorSupporter et installe l'objet de surveillance dans l'objet DataStore via CaptureFramework.

• DataObserver fournit un service JMX/HTTP pour l'exploration MA ultérieure. Le service Http a enregistré trois gestionnaires, à savoir HttpJEEJVMObserver, HttpJEEMonitorObserver et HttpJEEProfileObserver. Différents gestionnaires exposent différentes interfaces.

• La classe Handler du package MonitorHandler gère spécifiquement le calcul et les statistiques des données des indicateurs de Monitor.

2.4 Analyse des points de capture

CaptureFrameWork fournit un point d'entrée de capture unifié, fournissant respectivement des méthodes synchrones et des méthodes asynchrones dans UAVServer :

• Point d'entrée de capture synchrone : runMonitorCaptureOnServerCapPoint

• Point d'entrée de capture asynchrone runMon : itorAsyncCaptureOnServerCapPoint

2.4.1 Analyse des différences entre les appels synchrones et asynchrones

Asynchronous ajoute un paramètre de plus que la synchronisation, CaptureContextMapFromAnotherThread. Si ce paramètre n'est pas vide, les informations de contexte doivent être fusionnées. Dans des circonstances normales, lors de l'utilisation d'une méthode asynchrone pour enterrer le point, le CaptureContextMapFromAnotherThread transmis en appelant la méthode de capture asynchrone avant l'exécution de la méthode est vide et les informations de contexte encapsulées sont renvoyées une fois l'exécution de la méthode terminée, la capture asynchrone. La méthode est appelée pour transmettre les informations de contexte, et les informations de contexte sont fusionnées, puis des opérations de capture spécifiques sont effectuées. Pour plus de détails, veuillez vous référer aux extraits de code suivants :

• Appel asynchrone avant l'exécution de la méthode

.

• L'appel asynchrone après l'exécution de la méthode est le suivant, où ccMap est un appel asynchrone Les informations de contexte encapsulées renvoyées

2.5 Analyse du comportement de saisie

• Interface du moniteur : fournit plusieurs interfaces, la plus importante dont les méthodes doCapture et doPreStore, doCapture est utilisé pour implémenter une capture spécifique. Cliquez pour exécuter le comportement de saisie de données. La méthode doPreStore est utilisée pour implémenter certaines actions de capture avant de les stocker dans la structure de données et effectuer un traitement de données spécial.

• Classe StandardMonitor : La classe d'implémentation spécifique de l'interface Monitor.

• Classe StandardMonitorRepository : stocke la structure des données de capture de données en temps réel.

• Interface MonitorElementInstance : une interface d'instance qui stocke les structures de données de capture de données en temps réel.

• Classe StandardMonitorElementInstance : La classe d'implémentation spécifique de l'interface MonitorElementInstance.

Qu'il s'agisse d'un point d'entrée de capture synchrone ou d'un point d'entrée de capture asynchrone, la méthode doCapture sera exécutée L'extrait de code est le suivant :

monitor.doCapture appelle doCapture dans l'interface Monitor, et son. la classe d'implémentation est StandardMonitor.

La méthode doCapture dans StandardMonitor effectue principalement les opérations suivantes :

• Obtenir le tableau MonitorElement actuel en fonction des paramètres Le tableau MonitorElement est implémenté via getElementByCapId de StandardMonitorRepository ;

• Parcourez le tableau MonitorElement, obtenez la classe d'implémentation des données de capture, obtenez le gestionnaire actuellement exécuté en fonction de la classe d'implémentation et enfin déterminez l'étape de capture (precap/docap) en fonction du gestionnaire actuellement obtenu, puis procédez à Handle en conséquence. Différents gestionnaires génèrent MonitorElementInstance en fonction de différentes caractéristiques et stockent enfin les résultats dans la structure de données StandardMonitorRepository.

Prenons ServerEndRespTimeCapHandler (comportement d'exploration côté serveur) comme exemple :

• preCap méthode : uniquement enregistrée L’heure de demande de démarrage du service.

• doCap méthode : effectuez différents traitements logiques en fonction de différents monitorElemId, enfin encapsulez l'instance MonitorElementInstance, puis traitez les résultats du comportement de capture, y compris l'annulation de la valeur maximale correspondante traitement des données tel que pic, valeur maximale, valeur minimale, code d'état de retour, mise à jour de l'horodatage, comptage, etc.

3. Collecte de données en temps réel

3.1 Qu'est-ce que les données en temps réel

signifie les données d'exécution, qui fait référence aux informations générées lors de l'exécution du programme, au processeur, à la mémoire tas, aux informations JVM occupées par le programme et aux informations statistiques liées à l'accès au service et aux appels clients (temps de réponse moyen, nombre d'accès, etc.). #🎜🎜 ## 3#3.2 Acquisition de données côté service ## 🎜🎜##Implémentation de DEFAULTMOTORSUPPORTER#🎜🎜 ## 🎜🎜 ## 🎜🎜 ## 🎜🎜#🎜🎜 defaultMonitorsupPorter .start est le point d'entrée pour créer l'instance de moniteur :

Par défaut, une instance StandardMonitor du type de service est construite, qui contient une instance StandardMonitorRepository enregistre le moniteur que l'instance contient. plusieurs instances de MonitorElement et enregistre toutes les instances de MonitorElement dans l'attribut elemsMap.

elemsMap l'attribut enregistre différents gestionnaires de classes de collection en fonction de différents objets de collection :

ServerEndRespTimeCapHandler : collecte le temps de réponse et la somme du serveur, de l'APP et Nombre de chargements d'URL, etc.

JVMStateCapHandler : collecte l'état de la JVM, y compris l'utilisation du tas, le nombre de GC, le nombre de threads, le processeur, le nombre de classes, etc.

• L'extrait de code est le suivant :

• #🎜🎜 ##🎜 🎜#3.3 Collecte de données client

Implémentation de DefaultClientMonitorSupporter

La collecte de données client utilise DefaultClientMonitorSupporter.start comme point d'entrée pour créer une instance de moniteur : # 🎜🎜#

Par défaut, une instance StandardMonitor du type client est construite, qui contient une instance StandardMonitorRepository enregistre un moniteur. Cette instance contient plusieurs MonitorElement. instances et enregistre toutes les instances de MonitorElement dans l'attribut elemsMap.

elemsMap : La propriété enregistre uniquement une classe de collection ClientRespTimeCapHandler.

ClientRespTimeCapHandler : collectez le temps de réponse et le nombre de chargements du client, etc.

• Qu'il s'agisse d'une collecte de données côté client ou d'une collecte de données côté serveur, le moniteur sera installé dans le DataObserver ; et enfin Le moniteur construit avec succès sera lié à la méthode de capture spécifiée (c'est-à-dire precap et docap).
  3.4 Implémentation de DataObServer
• DataObServer propose deux modes pour exposer les données d'interface, à savoir JMX et HTTP :

# 🎜🎜# Méthode HTTP : HttpDataObserverWorker.start est utilisé comme point d'entrée et trois gestionnaires sont enregistrés respectivement, qui sont des gestionnaires pour obtenir les données JVM, les données Monitor et les données de profil. Chaque gestionnaire expose une interface unique, mais ils renvoient tous des données au format JSON.

Méthode JMX : L'agent JMX obtient l'interface exposée via la méthode getMBeanInfo pour obtenir des données.

DataObServer fournit également des méthodes pour installer et désinstaller des moniteurs, ajouter et supprimer des écouteurs et obtenir des profils et des moniteurs :

# 🎜🎜#

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!