Caso d'uso · Disponibilità
Uptime dei sistemi SAP, misurato ogni minuto
Due chiamate senza credenziali per sistema, ogni 60 secondi: sapcontrol e ICM. Lo stato è misurato, non dedotto dal fatto che qualche lettura sia andata a buon fine.
Cosa interroga
Due porte, nessuna credenziale
I metodi usati sono quelli di sola lettura che ogni istanza espone già, gli stessi della SAP MMC.
| Sorgente | Porta | Cosa dice |
|---|---|---|
| GetSystemInstanceList · GetProcessList | 5NN13 | Stato di ogni istanza e dei suoi processi |
| /sap/public/ping | 80NN | Se l'ICM risponde alle richieste HTTP |
| Storico dei controlli | interno | SLA a 24 ore, 7 e 30 giorni, con copertura e buchi |
Stati
Quattro stati, non due
«Su o giù» non basta: un sistema che risponde a metà richiede un'azione diversa da uno spento.
up
Tutte le istanze GREEN e ICM che risponde.
degraded
Qualcosa risponde ma non tutto è verde: un'istanza gialla, ICM muto, sapcontrol muto con ICM vivo.
down
Sapcontrol e ICM non rispondono, oppure l'istanza ABAP o il message server sono fermi.
unknown
Nessun controllo registrato: non viene confuso con «tutto bene».
SLA
Lo SLA dichiara anche sé stesso
Una percentuale calcolata solo sui controlli riusciti farebbe sembrare perfetto un monitoraggio spento.
Copertura
Quanti controlli sono stati fatti rispetto a quelli attesi nella finestra, con i minuti non misurati.
Buchi in timeline
I periodi non osservati compaiono in grigio, proporzionali alla durata, con inizio e fine.
Monitoraggio fermo
Alla ripartenza SUPtime registra «Monitoraggio fermo per N minuti» nello storico, con email se la regola ha destinatari.
In dashboard
La percentuale a 30 giorni compare accanto agli altri indicatori del sistema.
Fermo pianificato
Una manutenzione si dichiara prima, non dopo
Un fermo dichiarato a cose fatte sarebbe solo un modo di ripulire lo SLA. Le regole esistono per impedirlo.
Prima che cominci
La finestra si apre in anticipo, con cinque minuti di tolleranza, per un sistema, un landscape o tutti. Dura al massimo sette giorni.
Non si riscrive
Una finestra futura si annulla, una in corso si chiude solo in anticipo, una conclusa non si modifica. Creazione, annullamento e chiusura finiscono nell'audit trail con il nome di chi le ha fatte.
Gli alert tacciono, lo storico no
Durante la finestra le notifiche non partono e restano nello storico come «In manutenzione». A finestra chiusa, un problema ancora aperto notifica subito, senza aspettare il silenzio della regola.
Nello SLA, a parte
I controlli dentro la finestra escono da availability_percent, e accanto compaiono i minuti pianificati, i minuti giù in manutenzione e la percentuale senza alcuna esclusione.
Quando non è SAP
Un'utenza bloccata non è un sistema giù
monitoring_failed
Il sistema risponde a sapcontrol, ma le letture RFC o SQL falliscono da tre cicli: la riga lo dice, e dice perché.
Le cause tipiche
Utenza bloccata, password scaduta, credenziali rifiutate: problemi dello strumento, non del sistema monitorato.
Nessun blocco causato da noi
Dopo credenziali rifiutate il connettore HANA attende 15 minuti prima di riprovare: HANA disattiva un'utenza al sesto tentativo.
Alert
La regola c'è già
Sistema non raggiungibile
La regola AVAILABILITY esiste dal primo avvio, senza destinatari: basta aggiungere gli indirizzi.
Rientro automatico
Le righe sono condizioni già valutate: l'alert rientra da solo quando la condizione sparisce.
Email con contesto
SID ABAP e del database, release e kernel, landscape e cliente, regola e prime occorrenze.
Domande frequenti
Uptime e SLA
Servono credenziali per misurare l'uptime?
No. Sapcontrol espone metodi di sola lettura non protetti sulla porta 5NN13, gli stessi che usa la SAP MMC, e l'ICM risponde a /sap/public/ping. Le credenziali servono solo alle letture RFC e SQL.
Ogni quanto controlla?
Ogni 60 secondi di default, con un minimo di 15, separatamente dal polling RFC e SQL che gira ogni cinque minuti. Un riavvio pulito di SAP dura meno di cinque minuti e fra due letture passerebbe inosservato.
Cosa succede se SUPtime viene fermato?
Alla ripartenza registra il buco come «Monitoraggio fermo per N minuti» e lo SLA dichiara la copertura, cioè quanti controlli sono stati fatti rispetto a quelli attesi.
Distingue un sistema fermo da un'utenza bloccata?
Sì. Se sapcontrol risponde ma le letture falliscono per tre cicli, lo stato è monitoring_failed e la riga riporta il motivo.
Una manutenzione programmata rovina lo SLA?
No, se la dichiari prima che cominci. I controlli dentro la finestra diventano fermo pianificato: escono dalla percentuale di disponibilità e vengono riportati a parte, insieme alla percentuale calcolata senza alcuna esclusione. Una finestra non si può aprire a posteriori né modificare una volta chiusa.
Limiti dichiarati
Cosa non misura
- Tempi di risposta applicativi ed esperienza utente.
- Il sistema operativo: nessuna credenziale, nessun agent installato.
- Se sapcontrol e ICM non sono raggiungibili dalla rete di SUPtime, lo stato resta non misurabile e viene dichiarato.
- Previsioni: lo SLA guarda indietro, non avanti.
Quanto è stato su davvero il tuo SAP?
Ti mostriamo SLA, copertura e buchi su un sistema reale, senza toccare le utenze.