Differences

This shows you the differences between two versions of the page.

--- cn:ccr:cloud:cloud_multiregione:minute_meeting_monitoring:meeting20141120 [2014/12/02 16:00] – created bertocco@infn.it
+++ cn:ccr:cloud:cloud_multiregione:minute_meeting_monitoring:meeting20141120 [2014/12/02 16:10] (current) – [Riferimenti] bertocco@infn.it
@@ Line 1: / Line 1: @@
+====== Minute meeting 2 Dicembre 2014 ======
+===== Presenti =====
+Emidio Giorgio (EG), Vincenzo Spinoso (VS), Sara Bertocco (SB), Marica Antonacci(MA)
+===== Report sul lavoro svolto autonomamente =====
+  * EG parla di ProZaC [1], il proxy tra Zabbix e Ceilometer sviluppato a partire da un progetto opensource trovato su github. Il proxy prende le informazioni su tenant e istanze da Ceilometer e le esporta a Zabbix. Rispetto al progetto originale, ProZaC aggiunge il supporto a QPID, e permette di configurare due message broker distinti tra Keystone e Nova, piu' altre migliorie minori (init script, refinement dei template Zabbix, token renewal). VS commenta che ha sentito di sviluppi analoghi su OCP, e suggerisce di contattarli.
+  * VS parla dell'architettura di monitoring sviluppata a Bari secondo i requirement del progetto PRISMA :
+  - Livello IAAS : e' quello visto dall'orchestrator di PRISMA, ed espone le informazioni sullo stato dell'infrastruttura ed i serviziche la compongono. E' implementato.
+  - Zabbix Metrics : fornisce la base per l'accounting e billing, sia a livello SaaS che IaaS. Per i servizi offerti tramite SaaS, l'implementazione e' fornita tramite agente Zabbix installato sulla macchina che espone il servizio. Per il livello IaaS, non potendo contare sulla possibilita' di installare l'agent sull'istanza, si utilizza Ceilometer. VS osserva che Ceilometer ha diverse limitazioni : alarming rudimentale, poca configurabilita' (in particolare il refresh). Tuttavia, in mancanza di altre soluzioni ufficiali integrate in Openstack, Ceilometer sembra essere l'unica opzione praticabile.
+  - Watcher (Monitoring as a Service) :  un servizio utente volto a fornirgli una vista delle metriche relativo a tutte (e sole) le  sue istanze. SB chiede se la vista fornita da Watcher e' coerente con quella di Zabbix Metrics. VS conferma, precisando che usano la stessa base di dati. EG chiede se hanno pensato di integrare Keystone a Watcher. VS spiega che ci hanno pensato, ma ritengono piu' conveniente fornire all'utente le metriche attraverso il portale, selezionando quindi a monte le metriche cui puo' accedere.
+  * SB parla del lavoro fatto a Padova, un'installazione di Nagios che fa monitoring di 'basso livello' sullo stato delle macchine e i relativi servizi OpenStack. VS chiede se e' un monitoring locale o centralizzato, SB risponde che sono monitorate PD e LNGS, e che le probe andrebbero pacchettizzate in modo da facilitarne il deployment. SB chiede se le probe sviluppate con Nagios possono essere importate su Zabbix. VS ed EG rispondono positivamente.
+===== Logging centralizzato =====
+  * SB espone la loro l'idea di centralizzare i log per facilitare il lavoro degli amministratori. VS e MA confermano che anche a Bari c'e` un'idea analoga. SB chiede se pensano di contestualizzare le istanze, e come risolvono il problema di customizzazioni da parte dell'utente. VS conferma che contestualizzano le istanze ma non si puo' fare molto nel caso in cui l'utente amministratore della macchina stoppi il logging centralizzato. VS sottolinea che la responsabilita' della macchina e' dell'utente, e sua quindi la responsabilita' di stoppare eventualemente un servizio che e' anche a suo vantaggio. MA ribadisce l'importanza del logging centralizzato, e riporta di un tool, StackTach [2], raccomandato per questo scopo da OpenStack.
+===== Roadmap e sviluppi futuri =====
+  * Deployment Zabbix : EG chiede a VS se hanno pensato ad un'architettura di deployment in uno scenario multiregione. VS risponde dicendo che inizialmente avevano pensato ad un proxy Zabbix, ma dopo diverse esperienze sfavorevoli, sono propensi a un  agent in modalita' attiva (cioe' che manda i dati al server, anziche' aspettare che sia il server a contattarli). VS spiega i vantaggi di questa soluzione, ovvero l'aggiramento di restrizioni dovuti a firewall (e' necessaria solo la connettivita' esterna degli agent) e la scalabilita' rispetto al numero di item in questione. MA propone di cominciare subito la migrazione delle sonde di Nagios su Zabbix. EG osserva che bisognerebbe concordare le metriche da mostrare. Viene deciso di condividere un google doc nel quale mostrare le metriche, che saranno poi abilitate in una nuova istanza di Zabbix che sara' usata per il monitoring della cloud mr.
+===== Prossima riunione =====
+La settimana prossima non ci sara' riunione per via della scuola di
+cloud computing, ci sara' un giro di mail tra giovedi' e venerdi' per
+fissare la prossima phone call, orientativamente a inizio settimana.
+===== Azioni =====
+  * Unordered List Itemcreazione/riempimento google doc per la collezione delle metriche (VS,Tutti)
+  * installazione nuova istanza di Zabbix (VS)
+===== Riferimenti =====
+[1] : [[https://github.com/egiorgio/ProZaC|https://github.com/egiorgio/ProZaC]]
+[2] : [[http://www.youtube.com/watch?v=pZgwDHZ3wm0|http://www.youtube.com/watch?v=pZgwDHZ3wm0]]