CMS T2: monitoring Cosa c’e’ / cosa vorremmo / cosa manca T.BOCCALI PER I T2 DI CMS

Monitoring - cosa serve? Un po’ di statement generali Sono necessari due livelli: uno dettagliato (per site admin e … referees) e uno condensato (per gli utenti afferenti al T2) In prima approssimazione il compito dei T2 dovrebbe essere quello di _aggregare_ informazioni esistenti in altri sistemi di monitoring. Ricordate infatti che Il monitoring delle risorse sotto grid e’ una responsabilita’ (ben finanziata) di LCG/EGEE ecc ecc I T2 non hanno personale sviluppatore pagato detto questo, e’ chiaro che se qualcosa manca si fa _il possibile_ per realizzarlo (questo chiaramente NON e’ valido per informazioni di monoting tipo temperatura, monitoring di allarmi hardware ecc, ma non era nelle richieste)

Monitoring centralizzato – cosa esiste CPU: numero di ore CPU(tempo, VO): cesga Mensile, non + fine Non CPU totali, ma si possono ricavare da Gstat Gridice: numeri presenti ma spesso moltiplicati per xN (N == numero di CE attivi) HLRMon: ok ma con limiti (per esempio non da’ il totale delle CPU, il denominatore dell’efficienza) v

Storage Molto poco, a parte qualcosa in Gstat Gridice: numeri poco affidabili, ancora qualche problema per esempio nell’interfacciare dCache e Gridice Monitoring interno di dCache: funziona ma tecnicamente e’ un prodotto esterno Se sono definiti gruppi distinti per VO, puo’ dare occupato/libero per gruppo

Network Di centralizzato solo la Pagin del GARR In pratica piu’ o meno tutte le sezioni hanno ganglia o equivalente in funzione

Un’altra cosa … Non era esplicitamente nei requirements, ma poi c’e’ tutta la questione del monitoring del funzionamento. A parte I SAM di OPS, gli esperimenti grandi (e fra questi CMS) hanno sovrastrutture di controllo CMS ha SAM specifici Sottomissione continua di Job Una SiteView che condensa

Per la rete … C’e’ tutta la complessa machinery del monitoring di phedex Sia di dataset veri Sia di roba iniettata ad arte per controllare I trasferimenti

Cosa manca … CPU/Jobs: un monitoring piu’ granulare (per esempio, cesga giornaliero o per ora) che dia anche un’efficienza dell’utilizzo del Sito Un monitoring delle priorita’ delle code che permetta ad un utente di avere un’idea di quando girera’ il suo job (Gstat ci prova ma con una metrica troppo semplicistica) Storage: un monitoring che tenga conto di di gruppi, quote, ecc ecc

Questo ha fatto si’ … … che I vari T2, per il momento in modo sostanzialmente autonomo e guidato dai bisogni locali, abbiano sviluppato Non solo le pagine di aggregazione di cui sopra Ma anche tool aggiuntivi Non sempre condivisibili facimlente: PBS vs LSF, siti mono VO e siti aperti a tutti, ecc ecc Adesso (== nell’ultimo mese) sono partite delle discussioni su come avere qualcosa di uniforme almeno sotto il profilo dei contenuti Una carrellata dei tentativi esistenti:

Bari Mon2: Raccoglie informazioni mandati dai vari host (CE,SE, WN…) Li pubblica sul WEB e crea feed RSS Manda allarmi Email/SMS Crea un DB locale con l’archivio storico Per il momento focus sul monitoring Hardware del Sito (raid, temperatura, stato delle code) A breve, presentera’ la pagina di aggregazione di cui sopra; per il momento un prototipo di questa e’ stato realizzato tramite link

Legnaro Site Admin: Ganglia Monitoring LSF (vedi Pisa) Storage: pagina nativa di dCache

Dal lato utente Prototipizzata una pagina pensata per l’utente del T2

Pisa SiteAdminView: un sacco di tools sviluppati LSFMON: monitor di LSF (ora usato anche a LNL) WNMon: effettua tests basilari dei WN ogni 6 ore

Tools di debug JobMON: permette di andare a “sbirciare” cosa fanno I singoli Job (utilizzo RAM/CPU, controllare log files etc) Phedex Status Mon: permette di tracciare I sample presenti la loro storia

Tool di aggregazione Cominciato da poco, utilizzando tecnologia widget (netvibes) e lavoro preesistente di Isidro Gonzales

Roma Pagina di aggregazione complessa scritta in perl/javascript Aggrega informazioni hardware/locali (LSF)/cms specific (trasferimenti, release software …) Comprende una collezione completa di link utili per debuggare il sito hardware (T° racks) e software (test CMS) e a documentazione varia per problem solving

Conclusioni Siamo ben contenti di pensare a pagine di aggregazione Possibilmente comuni fra I T2 italiani, ci stiamo muovendo in questa direzione gia’ adesso Un po’ meno contenti di dover disegnare nuovi tool di monitoring; speriamo a regime di poter utilizzare solo quelli ufficiali (a parte chiaramente monitoring di hardware ecc ecc) Tutto il lavoro qui presentato e’ chiaramente a disposizione di tutti, ma il supporto potrebbe essere un problema (di risorse umane)