Cockpit grafico per monitorare dei landscape SAP
Un sistema di monitoraggio custom, realizzato come Yahoo! Widget, che legge i dati direttamente dai sistemi SAP e traduce centinaia di allarmi eterogenei in un'unica risposta: il servizio è disponibile, oppure no.
Sapere se il servizio regge, non se il server è acceso
L'architettura metteva in fila otto ambienti SAP di produzione — PXI, PC3, PW3, PTS, SRV, PRD, PEP e CUA — due load balancer, code MQ, web service e scenari ALE. Ogni pezzo aveva il proprio allarme: il database segnalava le tablespace, il J2EE la memoria, MQ la profondità delle code, il CCMS gli errori di sistema.
Allarmi senza gerarchia
Decine di segnali atomici, ognuno vero preso da solo e inutile preso da solo: nessuno diceva se il flusso di business stesse passando.
Due mondi separati
Metà dei componenti era SAP, metà no: MQ, web service WBI, alta affidabilità HACMP. Due console diverse, nessuna vista comune.
Diagnosi lenta
Capire dove si fosse fermato un messaggio voleva dire aprire in sequenza strumenti diversi, mentre il disservizio era già in corso.
Tre livelli di controllo e un criterio di monitoring
Invece di aggiungere un'altra console, abbiamo definito per ogni sistema un criterio di monitoraggio: la regola che, combinando gli allarmi atomici, dice se quel componente sta reggendo il flusso. Gli allarmi restano dove sono; cambia come vengono letti.
Hardware layer
Disponibilità del server, stato dell' affidabilità HACMP e del sistema operativo, disponibilità dei CSS.
Application layer
SAP, database e ABAP, più l'Adapter Framework J2EE seguito nelle sue quattro fasi: Call, Receive, Request, Send.
Services layer
I componenti non come entità a sé, ma come grandezze integrate nel flusso: qui vive il criterio di monitoraggio.
Un widget, non un portale
La control room è stata realizzata come Yahoo! Widget: sempre visibile sulla scrivania di chi presidia, senza una console da aprire e senza necessità di manutenzione dell'infrastruttura.
JMS e Near On Line, tracciati end-to-end
Ogni flusso è stato scomposto nei sistemi che attraversa, e per ognuno sono stati definiti gli elementi da osservare.
Profondità delle code, handle aperti, percentuale di riempimento, con soglia a 10.000 messaggi. Stato del queue manager e del channel initiator.
Heartbeat di Repository, Directory, Runtime Workbench, Adapter Engine e System Landscape Directory. Memoria e processi del J2EE.
Code RFC in uscita e in entrata: errori di comunicazione, di esecuzione, mancanza di risorse server, code bloccate e scheduler in errore.
Code in entrata e code applicative, messaggi in errore per categoria: mapping, determinazione interfaccia, determinazione ricevente, outbinding.
Un semaforo al posto di una caccia al tesoro
Una vista sola
Un widget desktop da 1024x768 con la mappa dell'architettura e lo stato di ogni nodo a colpo d'occhio, su quattro livelli di colore. L'icona nel dock riporta lo stato peggiore anche a finestra chiusa.
SAP e non SAP insieme
Allarmi CCMS e agenti di monitoraggio infrastrutturale letti con lo stesso criterio: la distinzione fra i due mondi sparisce dalla vista dell'operatore.
Base per l'automazione
Una volta codificato il criterio di monitoraggio, diventa possibile agganciarci gli auto-reaction method e rimediare da soli a una parte dei guasti.
Avete un'architettura che nessuno riesce a leggere per intero?
È il problema che risolviamo da vent'anni: mettere in relazione componenti diversi e farli raccontare una cosa sola.