Perché il monitoraggio generico non basta

Azure Monitor da solo vede la macchina: CPU, memoria, latenza dei dischi, stato della rete. Un impianto SAP però si guasta anche quando l’infrastruttura sembra sana — work process saturi, code di enqueue, un secondario di HANA System Replication che non sincronizza più, una risorsa Pacemaker in stato failed. Azure Monitor for SAP solutions esiste per chiudere questo divario: si distribuisce come risorsa Azure e attiva dei provider dedicati (SAP NetWeaver, SAP HANA, il database — SQL Server o Db2 —, il cluster ad alta disponibilità e il sistema operativo) che scrivono telemetria SAP e telemetria di piattaforma nello stesso Log Analytics workspace. In esame, ogni scenario del tipo “serve visibilità sui componenti SAP oltre che sulle VM” punta lì.

Segnali da osservare e costruzione degli avvisi

I dati arrivano dai provider e vengono letti tramite workbook e query nel workspace; da quelle stesse query si costruiscono le alert rule di Azure Monitor, instradate a un action group. I segnali che contano sono di tre famiglie: disponibilità (istanze e work process attivi, stato dei nodi e delle risorse di cluster, eventi di fencing), prestazioni (utilizzo dei work process, tempi di risposta, latenza e throughput dei volumi di /hana/data e /hana/log, coda dei dischi), continuità dei dati (stato e ritardo della replica, esito dei backup). Criterio di progetto: allertare sugli indicatori che descrivono il servizio end-to-end e usare la telemetria infrastrutturale come diagnosi, non come sorgente primaria di alert — altrimenti si ottiene rumore. Il workspace va dimensionato come componente architetturale: retention e costo di ingestion sono decisioni, non dettagli.

Patching e finestre di manutenzione

Il patching si muove su due piani. Il sistema operativo si aggiorna con Azure Update Manager e le sue maintenance configuration, che permettono di dichiarare finestre ricorrenti e includere o escludere gruppi di VM; le patch dell’impianto SAP (kernel, support package, database) restano nel dominio degli strumenti SAP, tipicamente SUM. Su un impianto in cluster l’ordine è la vera domanda d’esame: si mette il cluster (o il singolo nodo) in maintenance mode per evitare failover e fencing indesiderati durante il riavvio, si aggiorna prima il nodo passivo o il secondario della replica, si verifica, si esegue un takeover controllato e solo dopo si tocca l’ex primario. Gli application server si aggiornano a rotazione, drenando gli utenti tramite i logon group, così che ASCS/SCS e database restino disponibili. Da distinguere anche la manutenzione pianificata di Azure sull’host: availability set e availability zone servono proprio a non far cadere contemporaneamente i nodi ridondati.

Sicurezza operativa e vista d’insieme

L’accesso amministrativo va ricondotto a Microsoft Entra ID con RBAC a privilegio minimo e ruoli elevati assegnati a tempo tramite PIM; l’accesso interattivo alle VM passa da Azure Bastion o da un jump box, mai da indirizzi pubblici esposti a SSH/RDP. I segreti — credenziali dei provider di monitoraggio, utenze tecniche, identità usata dal fencing agent — vivono in Key Vault, e dove possibile si preferisce una managed identity a una credenziale memorizzata. Sul piano della postura, Microsoft Defender for Cloud fornisce raccomandazioni e secure score, Azure Policy impone le baseline, e la cifratura a riposo si governa con server-side encryption e customer-managed key. Azure Center for SAP solutions chiude il quadro: registra l’impianto come Virtual Instance for SAP solutions e offre inventario, quality check rispetto alle best practice, stato di salute, start/stop dell’intero sistema e integrazione con il monitoraggio — la vista “per SID”, non “per risorsa”.

Trappole tipiche d’esame

  • Serve monitorare work process, enqueue e replica HANA → Azure Monitor for SAP solutions con i provider pertinenti: VM insights e le metriche di piattaforma sono il distrattore classico, vedono la VM ma non il layer SAP.
  • Patch del cluster senza perdere il servizio → maintenance mode, poi nodo passivo/secondario per primo: aggiornare il primario o lasciare il fencing attivo provoca failover non pianificati durante il riavvio.
  • Ridurre i privilegi permanenti degli amministratori → RBAC minimo + accesso a tempo con PIM + Bastion: aggiungere un IP pubblico “protetto da NSG” è la risposta sbagliata che sembra sufficiente.
  • Credenziali usate dai provider o dal fencing agent → Key Vault o managed identity: salvarle nella configurazione locale o dentro uno script è la trappola.
  • Governo unificato di più sistemi SAP con controlli di best practice → Azure Center for SAP solutions: tag, resource group dedicati o workbook custom non danno la nozione di sistema SAP.
  • Alert troppo numerosi dopo l’attivazione del monitoraggio → soglie sui segnali di servizio, non su ogni contatore: la risposta non è disattivare i provider, ma ridisegnare le alert rule e l’action group.