Minute meeting 2 Dicembre 2014

Emidio Giorgio (EG), Vincenzo Spinoso (VS), Sara Bertocco (SB), Marica Antonacci(MA), Stefano Stalio (SS)

VS ha installato zabbiz server su una macchia virtuale (proxmox) a Bari alla quale per ora si puo` accedere come utente 'admin' con la stessa password che usavamo per l'istanza nagios di LNGS. Esiste anche un utente guest, ma e` vuoto, cioe` non vede nulla. Ha gia` configurato gruppi e template ed ora e` pronto per configurare i test. Le regioni che vogliono avere i nodi monitorati devono installare lo zabbix agent. Le istruzioni si trovano in Monitoring multiregione con Zabbix insieme ad altre informazioni utili. SB chiede se c'e` gia` qualche idea su come rendere ridondante lo zabbix server. VS dice che a Bari fanno il backup della macchina virtuale della quale si puo` fare il restore qualora necessario. Un'altra via potrebbe essere usare 2 zabbix server e sfruttare il fatto che possono sia importare che esportare i dati. SB si offre di guardare come si potrebbe realizzare una ridondanza dal punto di vista multiregione. SS si offre per fornire una macchina virtuale a LNGS per fare dei test con 2 nagios server.

SB chiede se c'e` un'analisi di zabbix vs. nagios per motivare la nostra scelta di andare verso zabbix.

VS risponde che a Bari e` gia` stata fatta. Anche a Bari come a Padova c'era esperienza pregressa su nagios, in particolare si usavano nagios per l'allarmistica e ganglia per avere i display grafici. Si e` scelto zabbix perche`

• ha entrambi: allarmistica+grafici
• ha un enorme numero di metriche embedded
• e` disponibile in rete una buona quantita` di tool preconfigurati (es. ceilometer+zabbix citato alla riunione precedente)
• zabbix e` pilotabile via API, anche da remoto, con autenticazione
• zabbix supporta diversi tipi di autenticazione (utente-password; ldap; via apache con certificato utente)
• si possono configurare gruppi di utenti (cosa che facilita l'invio di allarmi in maniera selettiva)
• consente di fare da interfaccia degli update massivi dei nodi che monitora
• ha un'interfaccia estremamente evoluta
• usa come backend un database (puo` essere visto come un vincolo, ma in fondo si puo` scegliere fra mysql e postgres)
• puo` essere aggiunto un nuovo host da monitorare con un meccaismo di autoregistrazione: nell'host si installa l'agent e lo si configura come "taggato con una certa etichetta" e in base a questa etichetta il server gli applichera` una certa configurazione
• similarmente un host puo` essere rimosso in maniera automatica configurando una sorta di timer.

SS chiede se e` possibile fare dei check mediante script, come ad esempio utilizzare comandi cinder-client (installati sul server zabbix) per eseguire delle operazioni. VS risponde affermativamente e aggiunge che si possono fare anche altre cose tipo ping, snmp, ecc.

Si decide di chiedere di poter presentare il nostro lavoro sul monitorig dicendo

• quello che e` stato fatto su nagios, sottolineando in particolare il lavoro sulle sonde fatte ex-novo tipo quelle su cinder
• che e` in corso un lavoro di migrazione verso zabbix (lavoro fatto e da fare)
• che si stanno studiando le soluzioni per una configurazione ridondante a livello regionale
• che si sta lavorando alla gestione centralizzata dei log sia per analisi del funzionamento che per la gestione della sicurezza.

La schedula del workshop prevede che il monitoring sia presentato da Sara Vallero, come proposto da Stefano Bagnasco. SB si impegna a contattarli per chiedere di fare una presentazione condivisa in modo che uno di noi possa presentare il nostro lavoro. EG ha contattato i componenti di OCP di Torino, come deciso alla riunione precedente, per capire che tipo di lavoro hanno fatto. Si tratta di Gaido e Guarise. A Torino hanno sviluppato un'applicazione analoga a ZabbixCeilometerProxy di Catania e con EG hanno preso accordi per fare degli sviluppi comuni futuri.

EG fa notare che l'analisi dei log dovrebbe poter essere usata anche per valutare l'opportunita` di migrare una macchina virtuale da un server ad un altro in base ad esempio alle risorse usate.

C'e` il problema che non si riescono ad avere istanze regionali funzionanti, probabilmente per carenza di man power. Tenuto conto che si stanno aggiugendo nuove regioni, si potrebbe chiedere a ciascuno di dedicarsi e far funzionare un numero limitato di componenti tra nova, neutron, cinder, ceilometer,…. in modo da avere una cloud funzionante. Questo argomento e` da trattare con tutti.

Riassumendo:

• SB: deve cotattare Torino e orgenizzatori workshop per chiarira presentazione monitoring
• SB: valutazione soluzioni per ridondare zabbix
• SB e VS: test con 2 server zabbix
• VS: finire di configurare i test sul server zabbix riutilizzando il lavoro fatto su nagios
• Tutti: installare zabbix agent sui nodi che vogliamo monitorare

Non e` stato discusso oggi, ma la volta scorsa si era deciso di scrivere un documento architetturale che abbiamo cominciato ad abbozzare qui.