Guida completa al monitoraggio SAP BASIS nel 2026
Tutto quello che devi sapere sul monitoraggio SAP BASIS moderno: dai work process in SM50 alla gestione della memoria HANA.
15 mag12 min di lettura
Keep your SAP systems UP.
Monitoraggio dei sistemi SAP, per chi fa Basis
Le transazioni che usi davvero, lette via RFC. Alert che arrivano con il contesto per capire cosa è successo. E un modulo NIS2/DORA che produce un report da firmare.
- On-premise, nella tua rete
- Nessun agent sui sistemi SAP
- Utenze in sola lettura
- Interfaccia in italiano
ALERT03:41
[SUPtime] PRD · ST22 short dumps above threshold
- ABAP SID
- PRD
- DB SID
- HDB · SAP HANA
- Release
- SAP_BASIS 758 · kernel 793
- Landscape
- Production · Rossi SpA
- Rule
- ST22 dumps > 0 in 15 min
First occurrences
| Time | Error | Program | User |
|---|---|---|---|
| 03:38 | TIME_OUT | ZFI_POST_BATCH | BATCH_FI |
| 03:40 | TSV_TNEW_PAGE_ALLOC_FAILED | ZSD_BILLING_RUN | RFC_SD |
| 03:41 | TIME_OUT | ZFI_POST_BATCH | BATCH_FI |
RECOVERED04:12 · condition cleared on PRD
Cosa monitora
Le transazioni che conosci, lette via RFC
Ogni scheda corrisponde a una transazione che un Basis conosce. I dati arrivano dal sistema, non da un archivio intermedio, e restano nella forma SAP originale: stati dei work process, sigle DIA, lettere E, W, S e I.
Disponibilità
sapcontrolICM
Una sonda ogni 60 secondi, senza credenziali: stato up, degradato o fermo, SLA a 24 ore/7/30 giorni con la copertura dichiarata.
Sicurezza
SM20
Security Audit Log: accessi riusciti e falliti, amministrazione delle utenze, transazioni avviate e chiamate RFC.
Job e update
SM37SM13
Stato e durata dei job, job lunghi, in ritardo e catene periodiche interrotte. Record di update terminati e in attesa.
IDoc
WE02BD87
IDoc in errore e in attesa, dalle sole intestazioni di EDIDC. Errori e attese oltre i sette giorni sono backlog: contati e mostrati, mai un allarme.
Code RFC
SM58qRFC
Stato reale delle code in uscita e in entrata, con gli stati tRFC che SAP usa davvero: SYSFAIL, CPICERR, ANORETRY.
Dump e log
ST22SLG1
Short dump con tipo, programma e utente. Application log filtrati per esito.
Lock e spool
SM12SP01
Blocchi esclusivi e di lunga durata. Richieste di spool e il loro esito.
Trasporti
STMS
Coda di import, errori e destinazioni dei trasporti.
Certificati
STRUST
Tutti i PSE che il sistema elenca, non solo quelli noti: per ciascuno il certificato proprio e quelli fidati, con emittente, scadenza e giorni residui. Un alert avvisa da 1 a 365 giorni prima che scadano, non dopo.
Carico e istanze
SM50SM66SM51AL08ST03NSMLG/SDF/SMON
Work process, istanze, sessioni di dialogo, analisi del carico, gruppi di logon e monitor prestazioni.
Sistema operativo e memoria
ST06ST02
Per ogni application server: filesystem, CPU e load average, memoria, swap e paging. Più extended memory, heap, roll e paging area, e i buffer con hit ratio e swap. Letto via RFC, senza installare niente sull'host.
SAP HANA
SQL
Carico, query lente, tabelle più grandi, backup e dischi. Più a fondo: alert dello statistics server, replica, licenza, delta merge, log e savepoint, tabelle vicine al limite di righe per partizione ed eventi di out of memory.
Oracle
SQL
Carico, query lente, tabelle più grandi, backup RMAN e BR*Tools, tablespace in percentuale del massimo con autoextend. Più a fondo: alert generati dal server, archiver e redo log, sessioni bloccate, stato dell'utenza. Dalla 10.2 in su.
Runtime XS
XS Classic
Applicazioni, errori di attivazione, sessioni e job. Su XS Advanced lo dichiara, invece di mostrare zero.
Database supportati: SAP HANA e Oracle. Export in CSV ed Excel per ogni scheda, più un report completo su tutte le aree. Interfaccia in italiano e inglese, tema chiaro e scuro.
Disponibilità
Uptime misurato, non dedotto
Una sonda su sapcontrol e ICM controlla ogni sistema ogni 60 secondi, senza credenziali. Lo SLA dichiara anche quanto SUPtime ha davvero osservato: un monitoraggio fermo non diventa un uptime del 100%.
Ultimi 30 giorni
- up
- Tutte le istanze GREEN e ICM che risponde.
- degraded
- Qualcosa risponde, ma non tutto è verde.
- down
- Sapcontrol e ICM muti, o istanza ABAP ferma.
- non misurato
- SUPtime non stava osservando: il buco si dichiara, non si conta come fermo di SAP.
SLA dichiarato
- 24 ore
- 100%copertura 100%
- 7 giorni
- 99,86%copertura 99,2%
- 30 giorni
- 99,71%copertura 98,7%
- Il monitoraggio fermo si dichiara
- Alla ripartenza SUPtime rileva il buco fra l'ultimo controllo e adesso, e scrive «Monitoraggio fermo per N minuti» nello storico. Chi riparte dichiara per quanto è mancato.
- Un'utenza bloccata non è un sistema giù
- Se sapcontrol risponde ma le letture RFC o SQL falliscono per tre cicli, lo stato è monitoring_failed e la riga dice il motivo: di solito l'utenza tecnica, non SAP.
- Sessanta secondi, non cinque minuti
- La sonda è separata dal polling: un riavvio pulito di SAP dura meno di cinque minuti e fra due letture passerebbe inosservato.
- Il fermo pianificato si dichiara prima
- Una finestra di manutenzione si apre prima che cominci, dura al massimo sette giorni e da conclusa non si tocca più. I controlli che vi cadono escono dall'uptime, ma vengono dichiarati a parte insieme alla percentuale senza alcuna esclusione.
Come ragiona
Numeri veri, o nessun numero
Un monitor che mostra zero quando non è riuscito a leggere è peggio di nessun monitor: sembra un sistema sano. SUPtime dice sempre cosa sa e cosa no.
Non autorizzato
All'utenza manca un'autorizzazione, e la scheda dice quale: per SM20, per esempio, il gruppo S_RFC RSAU_LOG.
Non disponibile
La sorgente non c'è o è spenta sul sistema, come un Security Audit Log non attivo in SM19.
Zero eventi
Letto correttamente: non è successo niente. È l'unico caso in cui vedi uno zero.
Tre stati che si somigliano e portano a tre azioni diverse.
- UNKNOWN non diventa mai PASS
- Un check di compliance che non si è riusciti a leggere resta fuori dal punteggio, invece di gonfiare un report che qualcuno firmerà.
- L'orologio è quello di SAP
- I filtri seguono il fuso del sistema monitorato, letto via RFC: niente giornate sbagliate fra mezzanotte e le due.
- Dati vecchi dichiarati
- Se il collector di /SDF/SMON è fermo, la scheda mostra l'ultimo snapshot e dice da quanto tempo è vecchio.
- Nessuna stima al posto dei dati
- Dove SAP non espone un valore via RFC, come le licenze o la CPU per istanza, SUPtime non lo inventa: lo dichiara assente.
Alert
Alert che spiegano cosa è successo
Le regole valgono per un sistema, per un landscape o per tutti, e vengono valutate a ogni polling su qualunque monitor.
- Email con SID ABAP e SID del database, release e kernel, landscape e cliente, regola e prime occorrenze.
- Notifica RECOVERED quando la condizione rientra: il silenzio non resta ambiguo.
- Finestra di silenzio configurabile, 60 minuti di default. Il rientro non la azzera: un problema che torna subito notifica comunque.
- Trap SNMP accanto all'email, regola per regola: una allo scatto e una al rientro con la stessa chiave d'evento, così l'NMS chiude da solo l'evento che aveva aperto. SNMPv3 authPriv, v2c per chi non la supporta.
- Finestre di manutenzione per un sistema, un landscape o tutti: durante il fermo pianificato gli alert non partono e restano nello storico come «In manutenzione».
- Le soglie di sistema operativo e carico del database si cambiano dalle Impostazioni, non da un file di configurazione: valgono subito per schede, regole ed email, e la modifica finisce nell'audit trail.
- Storico degli avvisi consultabile dall'interfaccia.
Opzionale
Analisi delle cause con AI
Su richiesta, un modello linguistico propone le cause probabili di un alert. Ogni evidenza viene confrontata con i dati raccolti e quelle non verificabili vengono scartate. Il modulo è spento di default.
Il ciclo di un alert
- 03:38
Condizione verificata
ST22: 3 nuovi dump in 15 minuti su PRD.
- 03:41
Email e trap SNMP
Con SID, release, regola e le prime occorrenze.
- 03:41
Finestra di silenzio
Lo stesso alert non si ripete per 60 minuti.
- 04:12
RECOVERED
La condizione è rientrata: parte la notifica di rientro.
Su cosa si costruiscono le regole
| Monitor | Righe contate | Campo confrontato | Esempio |
|---|---|---|---|
| SM20 | eventi del security audit log (24 h) | codice evento, utenza | AU2 = logon fallito |
| SM37 | job (7 gg) | stato, codice, esito | Cancelled |
| JOBS | problemi dei job già valutati | tipo, gravità, job | cancelled, long_running, late, chain_broken |
| IDOC | IDoc già valutati (WE02/BD87) | tipo, gravità, stato | idoc_error, idoc_stuck |
| RFC | problemi qRFC e tRFC già valutati | tipo, gravità, destinazione | qrfc_error, trfc_error |
| OS | problemi di sistema operativo e memoria già valutati | tipo, gravità, application server | filesystem, cpu_load, swap, extended_memory, os_collector |
| DBLOAD | carico del database oltre le soglie impostate | tipo, gravità | cpu, memory, connections |
| SM12 | blocchi | tipo, modo | E |
| ST22 | dump (7 gg) | tipo, programma | — |
| SP01 | richieste di spool | stato, dispositivo | E |
| SLG1 | log applicativi (24 h) | esito, oggetto | error |
| SM13 | record di update | stato, transazione | Terminated |
| STMS | coda di trasporto | stato, sistema target | Error |
| BACKUP | anomalie di Backup e disco | tipo, gravità | backup_stale, disk_critical |
| DBTABLE | dimensione di una tabella, in MB | nome tabella | BALDAT oltre 1000 |
| AVAILABILITY | condizioni aperte dell'ultimo controllo | stato | down, degraded, monitoring_failed |
| HANA | problemi della scheda HANA | tipo, gravità | hana_alert, replication, partition_rows, out_of_memory |
| ORACLE | problemi di salute di Oracle | tipo, gravità | server_alert, archiver, blocked_session |
| CERTIFICATES | certificati STRUST: la soglia sono i giorni di preavviso | PSE | SSLS/DFAULT, 30 giorni prima |
Una regola conta le righe che corrispondono al valore scelto e scatta oltre la soglia. JOBS, IDOC, RFC, OS, DBLOAD, BACKUP, AVAILABILITY, HANA e ORACLE portano righe già valutate: «almeno un problema aperto» scatta appena c'è e rientra da sola quando non ce n'è più. CERTIFICATES confronta i giorni alla scadenza con il preavviso scelto, da 1 a 365: critico sotto i 7 giorni o già scaduto. La regola «Sistema non raggiungibile» esiste dal primo avvio, senza destinatari.
Compliance NIS2 · DORA
Un report NIS2 e DORA da firmare, con i dati del sistema
Il modulo verifica i controlli di sicurezza di base di SAP e produce un documento Word pronto per la firma. Interroga sistemi di produzione, quindi è spento di default e si attiva da Impostazioni.
| Check | Sorgente | Cosa verifica |
|---|---|---|
| Parametri di profilo | TH_GET_PARAMETER | Valori attivi, confrontati con la SAP Security Baseline |
| Utenti standard | USR02 | SAP*, DDIC, EARLYWATCH, TMSADM e SAPCPIC sbloccati |
| Modificabilità mandanti | T000 | Mandanti di produzione che accettano modifiche (SCC4) |
| Certificati | SSFR_GET_CERTIFICATELIST | Scaduti, o in scadenza entro 30 o 90 giorni |
| Security Audit Log | RSAUPROF, RSAU_READ_LOG | Profilo attivo, confermato dagli eventi registrati nelle ultime 72 ore |
Il report
- Frontespizio con riga per la firma e sintesi del punteggio.
- Dettaglio per check, con rimedio e riferimenti a NIS2 art. 21 e DORA art. 9–10.
- Appendice con l'evidenza grezza e l'hash SHA-256 del run.
- Dichiara quanti check non ha potuto verificare.
Report di compliance
NIS2 · DORA
Sistema PRD · mandante 100 · 2026-09-11
Punteggio3 su 4 conformi
1 non verificabile, escluso dal punteggio
- Parametri di profiloPASS
- Utenti standardPASS
- Modificabilità mandantiPASS
- CertificatiFAIL
- Security Audit LogUNKNOWN
Hash del run · SHA-256 7c1e9a04f3b2…d58e
Firma del responsabile
Sicurezza e installazione
Resta nella tua rete, e legge soltanto
SUPtime si installa on-premise su un server Linux e si collega ai sistemi SAP via RFC e SQL. Sui sistemi SAP non si installa niente.
Un'installazione per cliente
I dati di clienti diversi non convivono: l'isolamento è dato dall'installazione, non da un filtro nelle query.
Utenza RFC di sola lettura
Un ruolo Z derivato da SAP_BC_BASIS_MONITORING, con S_RFC e lettura tabelle. La documentazione elenca ogni oggetto e perché serve.
Utenza database di sola lettura
Su HANA solo le viste e gli schemi che le query usano davvero; su Oracle SELECT sulle viste V$ e DBA_ che servono, e basta. Mai il proprietario dello schema applicativo.
Credenziali cifrate
Le password SAP e SMTP sono cifrate a riposo, con una chiave che resta sul server.
Audit trail a catena di hash
Login, modifiche ai sistemi, accessi alle credenziali e run di compliance, in un registro dove la manomissione diventa rilevabile.
Ruoli e sessioni
admin, operator e viewer, con autenticazione su ogni endpoint. Le sessioni si revocano: disattivare un utente o cambiargli ruolo lo fa uscire subito, non alla scadenza del suo token.
Autenticazione a due fattori
MFA facoltativa, obbligatoria per gli admin o per tutti, più l'obbligo sul singolo utente. Chi è obbligato la attiva al primo accesso utile: nessuno resta chiuso fuori e nessuno entra senza. I dispositivi ricordati si revocano uno a uno.
Privilegi minimi, per scelta
Sapcontrol e ICM non chiedono credenziali, RFC, HANA e Oracle solo lettura. Una funzionalità che richiederebbe di più non viene implementata.
Non blocca le tue utenze
Dopo credenziali rifiutate i connettori HANA e Oracle smettono di ritentare per 15 minuti: il database disattiva un'utenza dopo pochi tentativi, e un monitoraggio non deve chiudersi la porta da solo.
Backup del database
Il database di SUPtime viene salvato ogni giorno, con rotazione delle copie.
Requisiti
- Server
- Linux, 2 vCPU e 4 GB di RAM per una decina di sistemi
- Software
- Python 3.13, MongoDB 7, SAP NW RFC SDK 7.50 o successivo; Oracle Instant Client solo per Oracle precedenti alla 12.1
- Sistemi SAP
- ABAP via RFC; SAP HANA o Oracle via SQL, facoltativo
Prezzi
Un preventivo sul tuo landscape
Raccontaci quanti sistemi hai e come sono organizzati: ti mandiamo una proposta su misura.
Su misura
- Tutte le funzionalità, compliance inclusa
- Installazione on-premise dedicata
- Interfaccia in italiano e inglese
- Documentazione di installazione e delle utenze
Dal blog
Note tecniche
Guide e appunti dal campo su monitoraggio SAP Basis, HANA e progetti S/4HANA.
Migrazione S/4HANA: best practice di monitoraggio
Controlli pre-migrazione, monitoraggio del cutover e strategie di ottimizzazione post go-live per una trasformazione S/4HANA di successo.
10 mag10 min di lettura
Ottimizzare la gestione della memoria in SAP HANA
Consigli pratici per prevenire le situazioni di out-of-memory e ottimizzare le performance del column store HANA.
5 mag8 min di lettura
Domande frequenti
Prima di installarlo
Come raccoglie i dati SUPtime?
Via RFC dagli application server ABAP e, se fornisci le credenziali, via SQL da SAP HANA o Oracle. Il polling è automatico e sui sistemi SAP non si installa nessun agent.
Quali autorizzazioni servono sui sistemi SAP?
Un'utenza RFC con un ruolo di sola lettura, derivato da SAP_BC_BASIS_MONITORING più S_RFC e lettura tabelle, e se vuoi un'utenza HANA o Oracle di sola lettura. La documentazione elenca ogni oggetto e ogni grant. SXPG_COMMAND_EXECUTE non va mai concesso.
Quali database sono supportati?
SAP HANA e Oracle. Su entrambi: carico, query lente, tabelle più grandi, backup e volumi, più i controlli di salute (statistics server, replica, licenza e savepoint su HANA; alert del server, archiver, sessioni bloccate su Oracle). Su HANA anche il runtime XS Classic. Oracle dalla 10.2: per le versioni precedenti alla 12.1 serve l'Instant Client sul server di SUPtime. Le sonde Basis via RFC, come SM20, SM37 e ST22, leggono lo stack ABAP.
Mi avvisa prima che scada un certificato?
Sì. La scheda STRUST elenca i certificati dei PSE SSL server e client con scadenza e giorni residui, e una regola di alert scatta da 1 a 365 giorni prima, a tua scelta: warning fino a 7 giorni, critico sotto o già scaduto, e rientra quando il certificato viene rinnovato. Il modulo di compliance, invece, giudica una volta al giorno per il report.
Posso monitorare più sistemi e più clienti?
Sì. I sistemi si raggruppano in landscape, per esempio per cliente, e le regole di alert valgono per un sistema, un landscape o tutti. Per clienti diversi si usa un'installazione ciascuno, così i loro dati non convivono.
Dove finiscono i dati?
Sul tuo server: SUPtime è on-premise. Le credenziali sono cifrate a riposo e gli accessi sensibili finiscono in un audit trail a catena di hash.
Cosa copre il modulo NIS2/DORA?
Parametri di sicurezza del profilo, utenti standard, modificabilità dei mandanti, scadenza dei certificati e Security Audit Log. Produce un report Word con riga per la firma e hash del run. Un dato non letto non viene mai contato come conforme.
In che lingua è?
L'interfaccia è in italiano e in inglese. Le email di alert sono in inglese.
Misura anche l'uptime?
Sì. Una sonda su sapcontrol e ICM, senza credenziali, controlla ogni sistema ogni 60 secondi: stato up, degradato o fermo, SLA a 24 ore, 7 e 30 giorni. La copertura del monitoraggio è dichiarata, così un fermo di SUPtime stesso non viene confuso con un fermo di SAP.
Contatti
Guarda SUPtime sul tuo landscape
Raccontaci i tuoi sistemi SAP: ti mostriamo cosa legge SUPtime e cosa gli serve per leggerlo.
Scrivici
Domande, un preventivo o un dubbio tecnico: scrivici e ti rispondiamo.
Prenota una demo dal vivo
Scegli data e ora: 30 minuti, con le domande del tuo team Basis.