I server aziendali ospitano i dati e le applicazioni da cui dipende il funzionamento dell'intera organizzazione: il gestionale ERP, il database clienti, la posta elettronica, i file condivisi, il dominio Active Directory. Quando un server si ferma, l'azienda si ferma. E gli attacchi informatici non rispettano gli orari d'ufficio: secondo un report Mandiant 2025, il 76% dei deployment di ransomware avviene nei weekend o nelle ore notturne, quando nessuno monitora i sistemi. Il monitoraggio server 24/7 è la risposta a questa realtà: una sorveglianza continua che rileva anomalie, previene guasti e protegge il business anche quando l'ufficio è vuoto. In questa guida approfondiamo cosa monitorare, come configurare gli alert, le differenze tra ambienti Windows e Linux, il monitoraggio di server fisici, virtuali e cloud, e come BullTech implementa il monitoraggio server con NinjaOne.
Indice dei Contenuti
- 1. Perché il Monitoraggio 24/7 È Imprescindibile
- 2. Cosa Monitorare su un Server Aziendale
- 3. Monitoraggio Windows Server vs Linux
- 4. Server Fisici vs Virtuali: Cosa Cambia
- 5. Monitoraggio Server Cloud: Azure, AWS e RMM Unificato
- 6. Alert Automatici e Catene di Escalation
- 7. I Problemi Che il Monitoraggio Previene
- 8. Script e Automazione per la Remediation
- 9. Il Monitoraggio Server BullTech con NinjaOne
- 10. Domande Frequenti
1. Perché il Monitoraggio 24/7 È Imprescindibile
La risposta sta in una semplice statistica: i problemi server non rispettano gli orari d'ufficio. Un'analisi di oltre 10.000 incidenti server gestiti da MSP nel 2025 mostra che il 42% dei guasti hardware (dischi RAID, alimentatori, ventole) si manifesta fuori dall'orario lavorativo standard. Per gli attacchi informatici, la percentuale sale al 76%: i cybercriminali scelgono deliberatamente weekend e notti per lanciare i payload ransomware, sapendo che i tempi di rilevamento e risposta sono più lunghi quando nessuno guarda gli schermi.
Il costo di un'ora di downtime di un server critico varia enormemente in base al settore e alle dimensioni dell'azienda, ma le stime convergono su una forbice significativa. Per una PMI manifatturiera con 50 dipendenti, il fermo del server ERP può bloccare ordini, produzione e spedizioni con un costo stimato di 2.000-5.000 euro/ora. Per uno studio professionale con 20 persone, il fermo del server file e del gestionale contabile durante le scadenze fiscali può significare penali, ritardi e danno reputazionale. Per un e-commerce, ogni ora di downtime è fatturato perso misurabile al centesimo.
Il monitoraggio 24/7 non è un lusso: è un'assicurazione il cui costo è una frazione del danno che previene. Un agente di monitoraggio che rileva un disco RAID in stato "predictive failure" alle 2 di notte consente di pianificare la sostituzione la mattina dopo, senza downtime. Senza monitoraggio, quel disco si guasta nelle ore successive, il RAID degrada, e se un secondo disco fallisce prima della sostituzione (evento non raro su server con dischi della stessa età), i dati sono persi. La differenza tra "sostituzione programmata di un disco a caldo" e "ripristino da backup dopo perdita RAID" è la differenza tra zero downtime e 8-24 ore di fermo.
Il rischio della "zona cieca" notturna
Un server senza monitoraggio 24/7 ha una "zona cieca" di 14-16 ore al giorno (dalle 18:00 alle 8:00) e di 48 ore nei weekend. In queste finestre, un ransomware può cifrare l'intero filesystem, un disco guasto può causare la perdita del RAID, un backup fallito può passare inosservato per giorni. Il monitoraggio 24/7 elimina questa zona cieca, garantendo che ogni evento critico venga rilevato e gestito in tempo reale, indipendentemente dall'ora o dal giorno della settimana.
2. Cosa Monitorare su un Server Aziendale
Il monitoraggio di un server aziendale deve coprire ogni strato — hardware, sistema operativo, servizi e applicazioni — per fornire una visione completa dello stato di salute del sistema. Non basta sapere che il server è "acceso": un server può essere raggiungibile via ping ma avere il gestionale bloccato, il backup fallito e un disco in stato di pre-failure. Ecco le metriche critiche organizzate per categoria.
CPU: utilizzo, temperature, throttling
L'utilizzo della CPU va monitorato sia come media che come picco, sia aggregato che per singolo core. Una CPU costantemente sopra l'85% indica sottodimensionamento o un processo fuori controllo. La temperatura della CPU è un indicatore critico nei server fisici: temperature sopra i 75°C indicano problemi di raffreddamento (ventole guaste, prese d'aria ostruite, temperatura ambiente troppo alta in sala server). Il thermal throttling — la riduzione automatica della frequenza per evitare il surriscaldamento — causa degrado delle performance spesso difficile da diagnosticare senza monitoraggio.
RAM: utilizzo, commit charge, errori ECC
La RAM va monitorata su tre dimensioni: utilizzo effettivo (percentuale di RAM fisica in uso), commit charge (memoria totale richiesta dai processi, che può superare la RAM fisica se c'è swap) e, per server con memoria ECC, il conteggio degli errori corretti e non corretti. Un aumento degli errori ECC corretti è un segnale predittivo di guasto imminente del modulo DIMM. Lo swap (pagefile su Windows, swap partition su Linux) deve essere monitorato: un utilizzo costante dello swap indica RAM insufficiente e causa degrado severo delle performance I/O.
Disco: spazio, IOPS, latenza, RAID, S.M.A.R.T.
Lo spazio disco è la metrica più ovvia ma non l'unica. Le IOPS (operazioni di I/O per secondo) e la latenza del disco determinano le prestazioni reali del server per le applicazioni database-intensive (SQL Server, ERP). La disk queue length (numero di operazioni I/O in attesa) sopra 2 per disco fisico indica un collo di bottiglia I/O. Lo stato RAID va monitorato costantemente: un RAID degradato (con un disco guasto) funziona ma non protegge più dai guasti — se un secondo disco fallisce, i dati sono persi. I parametri S.M.A.R.T. dei dischi (Reallocated Sector Count, Current Pending Sector Count, Spin Retry Count) forniscono indicatori predittivi di guasto con giorni o settimane di anticipo.
Servizi e processi critici
Ogni server esegue servizi specifici che definiscono la sua funzione: Active Directory (NTDS, DNS, Kerberos), SQL Server (MSSQLSERVER, SQL Agent), Exchange (Information Store, Transport), file server (Server service, DFS), print server (Print Spooler), servizi ERP/gestionale. Il monitoraggio deve verificare che ogni servizio critico sia in esecuzione e, in caso di arresto, tentare il riavvio automatico prima di generare un alert. Oltre allo stato, va monitorato il consumo di risorse per servizio: un SQL Server che consuma progressivamente più RAM può avere una query inefficiente o un memory leak.
Sicurezza: patch, antivirus, certificati, event log
Il monitoraggio di sicurezza del server include: aggiornamenti di sicurezza pendenti (le patch critiche non applicate entro 72 ore rappresentano una vulnerabilità attiva), stato dell'agente antivirus (installato, aggiornato, ultima scansione), certificati SSL/TLS in scadenza (un certificato scaduto su un server web o un server LDAPS causa disservizi improvvisi), e analisi degli event log di sicurezza (login falliti ripetuti, modifiche ai gruppi di sicurezza, creazione di nuovi account, accessi fuori orario). Questo livello di monitoraggio si sovrappone alle funzioni SOC e contribuisce alla protezione complessiva del server.
Backup: stato job, dimensione, integrità
Il monitoraggio del backup è forse la funzione più critica e più sottovalutata. Va verificato: esito dell'ultimo job di backup (successo, warning, fallito), dimensione del backup (variazioni anomale indicano problemi), tempo di completamento (un backup che si allunga progressivamente indica crescita dati o degrado performance), spazio disponibile sul target di backup, e — fondamentale — test periodici di restore per verificare che i backup siano effettivamente ripristinabili. Un backup che fallisce silenziosamente per settimane è una bomba a orologeria. BullTech monitora quotidianamente lo stato dei backup di ogni server e interviene immediatamente in caso di fallimento.
3. Monitoraggio Windows Server vs Linux
Sebbene i principi del monitoraggio siano universali, l'implementazione pratica differisce significativamente tra Windows Server e le distribuzioni Linux. Le PMI italiane operano prevalentemente su Windows Server (Active Directory, SQL Server, file server, print server), ma la presenza di Linux è in crescita per web server, containerizzazione e appliance specializzate. Un sistema di monitoraggio completo deve supportare entrambi.
Windows Server
Su Windows Server, il monitoraggio si basa principalmente su WMI (Windows Management Instrumentation) e sui Performance Counter. WMI fornisce accesso a centinaia di classi di oggetti che espongono metriche su ogni aspetto del sistema: processi, servizi, disco, rete, registro eventi, software installato. I Performance Counter offrono metriche granulari e ad alta frequenza su CPU, memoria, disco e rete. L'Event Log di Windows è una fonte fondamentale di informazioni: gli eventi di sicurezza (Security log), di sistema (System log) e delle applicazioni (Application log) contengono segnali critici come errori NTFS, crash di servizi, login falliti e modifiche alla configurazione del sistema.
Le metriche specifiche di Windows Server da monitorare includono: stato della replica Active Directory (replication lag, replication failures), stato del DFSR (Distributed File System Replication), quote disk, stato del Windows Server Backup o dell'agent Veeam, policy di gruppo non applicate (GPO failures), stato delle licenze (licenze in scadenza, CAL sufficienti). L'agente NinjaOne per Windows raccoglie tutte queste metriche con un impatto minimo sulle risorse del server (tipicamente meno del 2% di CPU e 100 MB di RAM).
Linux Server
Su Linux, il monitoraggio utilizza una combinazione di fonti: il filesystem /proc e /sys per le metriche hardware e di sistema in tempo reale, i log di sistema (/var/log/syslog, /var/log/messages, journalctl per systemd), comandi standard (top, free, df, iostat, netstat) e, per un monitoraggio più strutturato, agenti come Zabbix agent, Telegraf o l'agente NinjaOne per Linux. Il monitoraggio Linux richiede attenzione a metriche specifiche: load average (che su Linux include anche i processi in attesa di I/O, a differenza della CPU utilization), file descriptor aperti (un limite raggiunto causa crash di applicazioni), inode usage (un filesystem può esaurire gli inode anche con spazio disco disponibile), stato dei servizi systemd e della connettività di rete.
Per gli ambienti containerizzati (Docker, Kubernetes), il monitoraggio si estende ai container: stato del container (running, stopped, restarting), risorse consumate (CPU, RAM, network I/O per container), health check applicativi, log del container, e orchestrazione (stato dei pod Kubernetes, deployment rollout status, persistent volume claims). Questo livello di monitoraggio richiede strumenti specifici (Prometheus + Grafana, Datadog, o le integrazioni container dei principali RMM) che vanno oltre il monitoraggio server tradizionale.
4. Server Fisici vs Virtuali: Cosa Cambia
La maggior parte delle PMI italiane opera con un mix di server fisici e virtuali. L'host fisico (il server "ferro") esegue un hypervisor (VMware vSphere/ESXi o Microsoft Hyper-V) che ospita più macchine virtuali. Il monitoraggio deve coprire entrambi i livelli: l'host fisico e le VM guest.
Monitoraggio host fisico
L'host fisico va monitorato per le metriche hardware che l'hypervisor non espone direttamente alle VM: temperatura CPU e chassis, stato alimentatori ridondanti (PSU 1 OK, PSU 2 failed), stato ventole, stato controller RAID e dischi fisici (S.M.A.R.T.), errori memoria ECC, stato schede di rete fisiche. L'accesso a queste metriche avviene tramite IPMI, interfacce di management proprietarie (Dell iDRAC, HPE iLO, Lenovo XCC) e agent VMware/Hyper-V. Un alimentatore guasto su un server con PSU ridondante non causa downtime, ma se non viene rilevato e sostituito, il server è vulnerabile al guasto del secondo alimentatore.
Monitoraggio hypervisor e VM
A livello hypervisor, le metriche critiche sono: CPU overcommit (rapporto tra vCPU allocate e CPU fisiche — sopra 4:1 può causare contention), RAM overcommit e ballooning (quando l'hypervisor recupera RAM dalle VM, causando swap nel guest), performance dei datastore (latenza I/O, IOPS), stato della rete virtuale (vSwitch, port group). Per ogni VM: CPU ready time (tempo di attesa per l'accesso alla CPU fisica — sopra il 5% indica contention), stato dei VMware Tools o Integration Services, snapshot aperti (consumano spazio e degradano le performance), stato della replica VM se configurata.
Un errore comune nelle PMI è monitorare solo le VM e ignorare l'host fisico. Questo crea un punto cieco pericoloso: un problema hardware sull'host (disco RAID degradato, ventola guasta, alimentatore fallito) non viene rilevato finché non causa il crash dell'intero host — portando down tutte le VM contemporaneamente. BullTech monitora sistematicamente sia gli host fisici (tramite IPMI e agent) sia le VM (tramite agent nel guest e integrazione con l'hypervisor) per ogni cliente con infrastruttura virtualizzata.
5. Monitoraggio Server Cloud: Azure, AWS e RMM Unificato
La migrazione al cloud non elimina la necessità di monitoraggio — la trasforma. Un server su Azure o AWS è comunque un server: ha un sistema operativo, dei servizi, delle applicazioni e dei dati che richiedono monitoraggio. Quello che cambia è l'infrastruttura sottostante: l'hardware fisico è gestito dal cloud provider (niente RAID da monitorare, niente ventole da controllare), ma emergono nuove metriche specifiche del cloud.
Azure Monitor e AWS CloudWatch sono le piattaforme native di monitoraggio dei rispettivi cloud provider. Forniscono metriche specifiche della piattaforma: crediti CPU sulle istanze burstable (quando finiscono, la VM viene throttled), performance dei dischi managed (IOPS e throughput sono limitati dal tipo di disco), stato dei servizi PaaS (Azure SQL, Azure App Service, AWS RDS), costi in tempo reale (un alert sui costi che superano il budget può prevenire sorprese in fattura). Tuttavia, queste piattaforme native monitorano l'infrastrutturacome la vede il cloud provider, non come la vive l'applicazione.
Per un monitoraggio completo dei server cloud, BullTech adotta un approccio a due livelli: l'agente NinjaOne installato all'interno della VM cloud fornisce le stesse metriche di un server on-premise (CPU, RAM, disco, servizi, event log, backup, sicurezza), mentre l'integrazione con le API native del cloud provider fornisce le metriche specifiche della piattaforma. Il risultato è una vista unificata in un'unica dashboard: i server on-premise, i server virtuali e i server cloud vengono monitorati con lo stesso livello di dettaglio e con le stesse procedure di alert e escalation. Per il cliente, l'esperienza è trasparente: non importa dove risiede il server, il monitoraggio funziona allo stesso modo.
6. Alert Automatici e Catene di Escalation
La configurazione degli alert e delle catene di escalation è il ponte tra il rilevamento di un problema e la sua risoluzione. Un sistema di monitoraggio che rileva un'anomalia ma non la notifica alla persona giusta, nel modo giusto, al momento giusto, è inutile quanto l'assenza di monitoraggio. La progettazione della catena di escalation deve considerare: chi notificare (ruolo, competenza), come notificare (canale), quando notificare (orario) e cosa fare se la prima notifica non riceve risposta.
Alert generato dal sistema di monitoraggio — classificazione automatica della severità (P1/P2/P3/P4) basata su regole predefinite e contesto
P1 Critico: notifica immediata (SMS + chiamata) al tecnico di turno — SLA di risposta: 15 minuti in orario, 30 minuti fuori orario
Se nessuna risposta entro lo SLA: escalation automatica al secondo tecnico nella catena, poi al team leader, poi al responsabile tecnico
P2 Alto: notifica via email e ticket — SLA di risposta: 1 ora in orario, 4 ore fuori orario. Escalation dopo 2 ore senza risposta
P3/P4 Medio/Basso: ticket creato automaticamente, gestito nel normale flusso di lavoro — SLA di risposta: 4-8 ore lavorative
Chiusura dell'alert: verifica che il problema sia effettivamente risolto (non solo mitigato), documentazione nel ticket, analisi root cause per problemi ricorrenti
La catena di escalation deve essere testata regolarmente: un numero di telefono errato nella lista di turno, un'email che finisce nello spam, un sistema di notifica SMS con credito esaurito possono vanificare l'intero sistema di monitoraggio. BullTech esegue test di escalation mensili per verificare che ogni anello della catena funzioni correttamente, e aggiorna la lista dei contatti di turno settimanalmente.
7. I Problemi Che il Monitoraggio Previene
Il valore del monitoraggio server non si misura solo nei problemi che rileva, ma soprattutto nei problemi che previene. Un buon sistema di monitoraggio trasforma eventi catastrofici in interventi pianificati. Ecco i sette problemi più comuni che il monitoraggio 24/7 previene nelle PMI italiane.
Disco pieno (filesystem full)
Il killer silenzioso dei server. Un filesystem al 100% causa crash delle applicazioni, corruzione dei database, impossibilità di login, fallimento dei backup. Con il monitoraggio, l'alert scatta al 80-85%, dando giorni o settimane per liberare spazio o espandere il volume. Senza monitoraggio, si scopre il problema quando il gestionale si blocca il lunedì mattina.
Memory leak applicativo
Un'applicazione che non rilascia memoria correttamente consuma progressivamente tutta la RAM disponibile, fino al crash del server. Il monitoraggio identifica il trend crescente di consumo RAM di uno specifico processo e genera un alert preventivo, permettendo il riavvio pianificato dell'applicazione o la segnalazione al vendor per il fix.
Disco RAID in pre-failure
I parametri S.M.A.R.T. dei dischi (Reallocated Sectors, Current Pending Sectors) segnalano il degrado settimane prima del guasto effettivo. Il monitoraggio rileva questi segnali e permette di ordinare il disco sostitutivo e pianificare la sostituzione a caldo, senza alcun downtime. Senza monitoraggio, il disco si guasta e il RAID degrada — se succede di notte e un secondo disco fallisce, i dati sono persi.
Certificato SSL scaduto
Un certificato SSL/TLS scaduto su un server web causa errori di connessione per tutti gli utenti. Su un server LDAPS, causa l'impossibilità di login al dominio. Il monitoraggio genera un alert 30, 14 e 7 giorni prima della scadenza, dando tempo sufficiente per il rinnovo. Senza monitoraggio, il certificato scade nel weekend e il lunedì nessuno riesce ad accedere.
Servizio di backup arrestato
L'agent di backup (Veeam, Windows Backup, altro) che si arresta silenziosamente è una delle situazioni più pericolose: i backup non vengono eseguiti, ma nessuno se ne accorge finché non servono. Il monitoraggio verifica quotidianamente lo stato dell'agent e l'esito dell'ultimo job di backup, generando alert immediato in caso di fallimento.
Surriscaldamento in sala server
La temperatura in sala server può salire per vari motivi: guasto del condizionatore, ostruzione delle prese d'aria, ondata di calore estiva. Temperature sopra i 30-35°C causano throttling delle CPU e, se prolungate, guasti hardware. Il monitoraggio della temperatura ambientale (tramite sensori) e della temperatura delle CPU genera alert che permettono di intervenire prima del danno, anche di notte.
8. Script e Automazione per la Remediation
Il monitoraggio moderno non si limita a generare alert: quando il problema è noto e la soluzione è standard, l'azione correttiva viene eseguita automaticamente. Gli script di remediation trasformano il monitoraggio da passivo (segnalo il problema) ad attivo (risolvo il problema). NinjaOne, la piattaforma utilizzata da BullTech, supporta script in PowerShell (Windows), Bash (Linux/macOS) e Python, eseguiti automaticamente in risposta a condizioni specifiche.
Esempi di remediation automatizzata implementata da BullTech per i server dei clienti: quando il disco C: supera l'85%, lo script cancella automaticamente i file temporanei, svuota la cartella Windows Update cache, comprime i log più vecchi di 30 giorni e invia un report con lo spazio recuperato. Quando un servizio critico (SQL Server, Print Spooler, servizi ERP) risulta arrestato, lo script tenta il riavvio automatico, verifica che il servizio sia effettivamente ripartito e, se il tentativo fallisce dopo 3 prove, genera un alert critico per intervento manuale. Quando un aggiornamento di sicurezza critico viene pubblicato e il server non lo ha installato entro 48 ore, lo script pianifica l'installazione nella finestra di manutenzione successiva.
L'automazione è particolarmente preziosa per gli interventi fuori orario: un servizio che si arresta alle 23:00 viene riavviato automaticamente in 30 secondi, senza svegliare nessuno. Se la remediation automatica fallisce, l'alert viene scalato al tecnico reperibile con tutte le informazioni raccolte durante il tentativo di risoluzione automatica, accelerando la diagnosi manuale. Secondo i nostri dati interni, l'automazione risolve il 35% degli alert senza intervento umano, con un risparmio significativo in termini di tempo e costi.
9. Il Monitoraggio Server BullTech con NinjaOne
BullTech Informatica offre un servizio di gestione server completo che include il monitoraggio 24/7 come componente fondamentale. La piattaforma NinjaOne fornisce visibilità unificata su tutti i server del cliente — fisici, virtuali e cloud — con un singolo agente leggero installato su ogni macchina.
Il nostro approccio al monitoraggio server si distingue per tre elementi. Primo, la personalizzazione delle soglie: non applichiamo template generici ma calibriamo le soglie di ogni server in base al suo carico di lavoro reale. Un server SQL ha soglie diverse da un file server, un Domain Controller ha requisiti diversi da un web server. Secondo, l'integrazione con la gestione IT: il monitoraggio non è un servizio isolato ma è integrato con il nostro servizio di monitoraggio proattivo complessivo e con il supporto help desk. Quando un alert server richiede un intervento che impatta gli utenti, il team di supporto è già informato e pronto a gestire le comunicazioni. Terzo, la reportistica actionable: ogni mese il cliente riceve un report che non si limita a elencare le metriche, ma include raccomandazioni concrete — ad esempio, "il server SQL ha raggiunto il 90% di utilizzo RAM nei picchi, consigliamo di aggiungere 16 GB di RAM entro il prossimo trimestre".
Monitoraggio server + business continuity
Il monitoraggio server è il primo tassello della strategia di business continuity. Un server monitorato 24/7 con backup verificati quotidianamente e procedure di disaster recovery testate periodicamente offre una resilienza che nessun approccio reattivo può eguagliare. BullTech integra monitoraggio server, gestione backup con Veeam e piani di disaster recovery in un unico servizio gestito, garantendo che la tua azienda possa riprendersi da qualsiasi scenario — dal disco guasto all'attacco ransomware.
Domande Frequenti
Quali metriche vengono monitorate su un server aziendale?
Un monitoraggio server completo copre metriche hardware, software e applicative. Hardware: CPU utilization (percentuale e per core), temperatura CPU e chassis, stato ventole, stato alimentatori ridondanti, stato RAID (disco guasto, rebuilding, degradato), S.M.A.R.T. status dei dischi (indicatori predittivi di guasto), memoria ECC errors. Software: RAM utilizzata/disponibile/committed, spazio disco per volume (utilizzato, disponibile, trend di crescita), disk I/O (IOPS, latency, queue length), stato dei servizi critici (Active Directory, SQL Server, Exchange, ERP, backup agent), event log di sistema (errori e warning), aggiornamenti di sicurezza pendenti, stato dell'antivirus (aggiornamento firme, scan completati), certificati SSL/TLS in scadenza. Rete: utilizzo delle interfacce di rete, connessioni TCP attive, porte in ascolto. Applicativo: tempo di risposta delle applicazioni web, connessioni al database, code di messaggi, log applicativi con pattern di errore. NinjaOne, la piattaforma utilizzata da BullTech, raccoglie tutte queste metriche con un singolo agente installato sul server, senza necessità di configurazioni complesse.
Attraverso quali canali ricevo gli alert del monitoraggio?
Il sistema di notifica degli alert è multi-canale e configurabile in base alla severità dell'evento e all'orario. Per gli alert informativi (bassa priorità): notifica via email riepilogativa giornaliera o settimanale, consultabile anche via dashboard web. Per gli alert di warning (media priorità): email immediata al referente IT del cliente durante l'orario lavorativo. Per gli alert critici (alta priorità): notifica immediata via SMS e/o chiamata telefonica, 24 ore su 24, 7 giorni su 7. In parallelo, il sistema crea automaticamente un ticket nel sistema di gestione BullTech con tutte le informazioni dell'alert, che il tecnico utilizza per la diagnosi e la risoluzione. Per i clienti che lo richiedono, è possibile integrare anche notifiche via Microsoft Teams, Slack o webhook personalizzati verso sistemi ITSM aziendali. La configurazione dei canali è personalizzabile per ogni cliente e può essere diversificata per tipo di dispositivo: ad esempio, il responsabile IT riceve gli alert su tutti i server, mentre il responsabile amministrativo riceve solo gli alert sul server ERP.
Come si gestiscono i falsi allarmi nel monitoraggio server?
I falsi allarmi (falsi positivi) sono la sfida principale di ogni sistema di monitoraggio. Un falso allarme è un alert che segnala un problema inesistente — ad esempio, un picco di CPU che dura 30 secondi durante un backup schedulato non è un'anomalia, è il comportamento atteso. La gestione dei falsi allarmi si basa su tre strategie. Prima: calibrazione delle soglie. Le soglie predefinite dei tool di monitoraggio sono generiche e vanno personalizzate per ogni server e ogni carico di lavoro. Un server SQL che ha normalmente il 60% di CPU non deve generare alert al 65%. Secondo: esclusioni temporali. I picchi noti (backup notturni, scansioni antivirus, elaborazioni batch) vengono esclusi dalle regole di alert nelle fasce orarie previste. Terzo: correlazione e deduplicazione. Se un server viene riavviato per manutenzione programmata, il sistema deve sapere che gli alert 'servizio down' generati durante il riavvio sono attesi e non devono essere notificati. BullTech dedica i primi 30 giorni di servizio alla calibrazione fine del monitoraggio, analizzando ogni falso allarme e aggiustando le regole fino a raggiungere un tasso di falsi positivi inferiore al 5%.
Il monitoraggio funziona sia per server fisici che per server cloud?
Sì, il monitoraggio copre sia server fisici (on-premise) che server virtuali (VMware, Hyper-V) e server cloud (Azure, AWS, Google Cloud), ma con approcci e strumenti parzialmente diversi. Per i server fisici, l'agente di monitoraggio raccoglie sia le metriche software (CPU, RAM, disco, servizi) sia le metriche hardware tramite IPMI o interfacce di management proprietarie (iDRAC per Dell, iLO per HPE, IMM per Lenovo): temperatura, stato alimentatori, stato ventole, stato RAID, errori memoria ECC. Per i server virtuali, oltre alle metriche del sistema operativo guest, si monitorano anche le metriche dell'hypervisor: overcommit di CPU e RAM, thin provisioning dello storage, performance dei datastore, stato della replica VMware vSphere o Hyper-V. Per i server cloud, il monitoraggio si integra con le API native del cloud provider (Azure Monitor, AWS CloudWatch) per raccogliere metriche specifiche della piattaforma (crediti CPU su istanze burstable, stato dello storage blob, metriche dei servizi PaaS), combinandole con il monitoraggio dell'agente installato all'interno della VM. BullTech gestisce ambienti ibridi — server fisici on-premise + server virtuali + server cloud — con una vista unificata in NinjaOne.
Quanto costa il monitoraggio server 24/7 per una PMI?
Il costo del monitoraggio server 24/7 dipende dal numero di server, dal livello di servizio e dalla complessità dell'ambiente. Per una PMI tipica italiana con 2-5 server (uno o due server fisici + VM), i costi indicativi sono: monitoraggio base con alert e notifica (senza intervento) 30-50 euro/server/mese; monitoraggio con intervento in orario lavorativo (8x5) 80-150 euro/server/mese; monitoraggio con intervento 24/7 incluso 150-300 euro/server/mese. Per ambienti più complessi (cluster, virtualizzazione, multi-site), i costi possono essere superiori ma vengono tipicamente negoziati come pacchetto complessivo. BullTech include il monitoraggio server nel contratto di assistenza IT gestita 'Always On', senza costi aggiuntivi per singolo server — il pricing è basato sulla dimensione complessiva dell'infrastruttura. Questo modello è più vantaggioso per le PMI perché elimina l'incentivo a non monitorare server per risparmiare, garantendo copertura completa di tutta l'infrastruttura. Considerando che un singolo downtime di un server critico può costare migliaia di euro, il ROI del monitoraggio è tipicamente positivo già dal primo incidente prevenuto.
Il monitoraggio server è compatibile con il GDPR?
Sì, il monitoraggio server è pienamente compatibile con il GDPR e, anzi, contribuisce alla conformità. Il GDPR richiede 'misure tecniche e organizzative adeguate per garantire un livello di sicurezza adeguato al rischio' (art. 32) — il monitoraggio continuo è una di queste misure. Tuttavia, è importante che il monitoraggio stesso sia implementato nel rispetto del GDPR. I dati raccolti dal sistema di monitoraggio (log di sistema, metriche di performance, event log) possono contenere dati personali indirettamente (nomi utente nei log, IP address). Il trattamento di questi dati deve essere regolato da un contratto di nomina a responsabile del trattamento (DPA — Data Processing Agreement) tra l'azienda e il provider del servizio di monitoraggio. BullTech, in qualità di responsabile del trattamento, garantisce: DPA conforme all'art. 28 GDPR incluso nel contratto di servizio; dati di monitoraggio archiviati in data center UE (NinjaOne utilizza infrastruttura cloud europea); accesso ai dati limitato ai soli tecnici autorizzati con autenticazione MFA; retention dei dati di monitoraggio definita contrattualmente (tipicamente 12 mesi per i log, 24 mesi per le metriche aggregate); cancellazione dei dati al termine del contratto. Il monitoraggio server non monitora le attività degli utenti finali (email, navigazione, file personali) — si concentra esclusivamente sullo stato tecnico del server.
I tuoi server meritano un monitoraggio professionale 24/7. Se vuoi eliminare la "zona cieca" notturna e prevenire i downtime non pianificati, contattaci per un assessment gratuito dei tuoi server. Analizzeremo lo stato di salute di ogni server, verificheremo i backup e ti proporremo un piano di monitoraggio personalizzato. Scopri anche il nostro servizio di gestione server e il monitoraggio proattivo IT per una protezione completa della tua infrastruttura.