Recent Changes - Search:

Architecture du processus de collecte

Le programme MainThread commence par vérifier les paramètres, il initialise les diverses structures de données puis lit le fichier de configuration. En cas d'erreur lors de ces premières étapes il se termine en affichant un message d'erreur sur l'erreur standard et en retournant un code de retour non nul. En l'absence d'erreur il se clone et se termine avec un code de retour nul. Le processus fils démarre alors plusieurs processus «légers» («threads»).

Un premier «thread» (instance de la classe ReaderThread) lit les datagrammes et les mémorise dans un «pool» de blocs de mémoire (instance de DataDock).

Chaque datagramme est ensuite traité par l'un des «threads» d'analyse des datagrammes (instances de NetflowDatagramParser) qui en extrait les différents flux. Ce «thread» d'analyse construit pour chaque flux à conserver, conformément aux règles du fichier de configuration, un enregistrement (instance de NetMatRecord) ne contenant que l'information indispensable à la comptabilité (numéros d'interfaces, numéro de protocole, adresses IP, ports, nombre d'octets) et le mémorise dans un tampon circulaire.

Chacun de ces enregistrements est ensuite traité par l'un des «threads» comptables (instances de AccountingThread) qui calcule le service/protocole concerné et met à jour la table de comptage.

Lors d'une demande de «vidage» faite par une commande MonitorMain ... --dump ... ou MonitorMain ... --temporaryDump ..., le «thread» de vidage (instance de DumperThread) écrit le contenu de la table dans un fichier (cf. Les fichiers résultats de la collecte) et dans le deuxième cas réinitialise la table. Depuis la version 4.0 du collecteur le «thread» de vidage crée un nouveau processus (primitive fork()) pour effectuer cette tâche. L'opération d'écriture pouvant durer plusieurs secondes, dans les versions antérieures la table de comptage est dupliquée dans l'espace d'adressage du collecteur pour que les «threads» puissent effectuer parallèlement collecte et écriture sur des objets différents. L'importance croissante du trafic sur notre réseau rendait impossible la duplication à certains moments ce qui provoquait l'avortement du collecteur. La création d'un processus de vidage repousse la limite.

C'est le «thread» principal (du processus fils) qui crée le tube de commande et y lit les différentes commandes.

<< Les fichiers résultats de la collecte | Documentation | La commande netMETexp >>

Print - Recent Changes - Search
Page last modified on 2009/11/20 12:50:42