skip to Main Content

Riporto,  su richiesta,  alcune note sul progetto Register2, il cui sviluppo è ripreso il 12/02/2009.
L’architettura è client/server con il client sulla macchina da monitorare e il server sul server di Nethesis (attualmente c2).
Per ora lo sviluppo si concentra su NethSecurity, lasciando NethService ad una fase successiva (la struttura rimane comunque analoga).
Attualmente il monitoraggio dei parametri è affidato ad un demone (sendstatus) richiamato periodicamente dal cron o su richiesta (dalla gui o da linea di comando).
Il progetto prevede di rimpiazzare il sendstatus con un demone (Ardad, scritto in C++ (confronto prestazioni rispetto altri linguaggi) ) in esecuzione continua sulla macchina da monitorare. Il demone si comporta nel modo seguente:

  • quando avviato per la prima volta si inizializza e invia i parametri monitorati al server,
  • dopo il primo avvio è residente sulla macchina e monitora periodicamente i parametri che possono generare allarmi,
  • se rileva uno o più parametri in condizione di allarme li comunica immediatamente al server,
  • continua a monitorare i parametri senza inviare nuovamente i parametri in allarme già comunicati,
  • quando i parametri in allarme comunicati risolvono la loro condizione di allarme informa il server,
  • allo spegnimento invia tutti i parametri al server,
  • alla ricezione di un segnale predefinito invia tutti i parametri al server.

La comunicazione dei parametri al server avviene attraverso un protocollo concordato e comprensibile dal server.
Il server riceve le informazioni relative ai parametri monitorati dai client e scrive sul database lo stato dei parametri, gli allarmi e lo storico degli allarmi relativi alle macchine monitorate.
Una applicazione web consente di leggere ed interpretare i dati disponibili sul database delle macchine monitorate.
Le differenze rispetto a Register(1) sono notevoli:

  • spostamento della logica di monitoraggio dei parametri dal server al client:
    • distribuzione del carico di lavoro sui client,
    • possibilità di stabilire soglie personalizzate di allarme;
  • comunicazioni intelligenti (comunica i parametri soltanto in caso di allarmi o risoluzioni di allarmi precedentemente notificati, cioè quando serve):
    • ottimizzazione del flusso di informazioni verso il server;
  • migliore acquisizione dei parametri:
    • i parametri vengono acquisiti nativamente,  senza l’invocazione di comandi esterni, velocizzando l’acquisizione;
    • i parametri sono classificati in classi predefinite (system, interface, storage, service),
    • possibilità di campionare diversi parametri in intervalli di acquisizione differenti (es. il carico della cpu ogni due cicli di acquisizione, la partizione root ogni quattro cicli, etc..).

I parametri sono classificati nelle seguenti categorie:

  • system: comprende tutti quei parametri generici (dns, hostname, password di default, …) non riconducibili alle altre categorie e non in grado di generare allarmi,
  • interface: comprende le interfacce di sistema; ogni interfaccia è caratterizzata da:
    • device: (es. etho, eth1, …)
    • address: indirizzo dell’interfaccia
    • netmask: maschera di rete dell’interfaccia
    • type: tipo di interfaccia
    • mode: modo dell’interfaccia
  • storage: comprende i dispositivi di memorizzazione (dischi, ram, partizioni); ogni storage è caratterizzato dai parametri seguenti:
    • size: dimensione totale dello storage,
    • used: spazio utilizzato
  • service: comprende i servizi presenti nella macchina; ogni servizio può essere abilitato/disabilitato dal rivenditore e può girare/non girare. Alcuni servizi presentano però più stati in funzione delle interfacce su cui sono abilitati ed è quindi necessaria una discussione per stabilire le caratteristiche di questa classe di parametri.

Gli argomenti da definire riguardano principalmente la parte di acquisizione:

  • quali parametri monitorare,
  • quali parametri generano allarmi,
  • come definire i servizi.
Back To Top
English French German Italian Spanish