Venerdì sera, ore 22. Il server del gestionale si blocca. Sabato mattina il ransomware cripta tutto. Lunedì mattina lo scopri, e i backup di venerdì sono andati. Non è fantascienza: secondo Mandiant 2025, il 76% degli attacchi ransomware avviene nei weekend o di notte, quando nessuno guarda. I tuoi server ospitano il gestionale, il database clienti, la posta, i file condivisi. Quando si fermano, l'azienda si ferma. Il monitoraggio 24/7 è una sentinella che non dorme mai: rileva anomalie, previene guasti e protegge il business anche a ufficio vuoto.
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 Atera
- 10. Domande Frequenti
1. Perché il Monitoraggio 24/7 È Imprescindibile
I problemi server non rispettano gli orari d'ufficio. Su oltre 10.000 incidenti server gestiti da MSP nel 2025, il 42% dei guasti hardware (dischi, alimentatori, ventole) si manifesta fuori orario. Per gli attacchi informatici, la percentuale sale al 76%: i criminali scelgono weekend e notti apposta, perché sanno che nessuno sta guardando.
Quanto costa un'ora di fermo server? Dipende, ma i numeri fanno male. Una PMI manifatturiera con 50 persone: il server ERP fermo blocca ordini, produzione e spedizioni — 2.000-5.000 euro/ora. Uno studio professionale con 20 persone: il gestionale contabile fermo durante le scadenze fiscali significa penali, ritardi e clienti arrabbiati. Un e-commerce: ogni ora di fermo è fatturato perso, misurabile al centesimo.
Il monitoraggio 24/7 non è un lusso: è un'assicurazione che costa una frazione del danno che previene. Esempio: un agente di monitoraggio rileva un disco RAID in stato "predictive failure" alle 2 di notte. La mattina dopo lo sostituisci, zero fermo. Senza monitoraggio, quel disco si guasta, il RAID degrada, e se un secondo disco cede prima della sostituzione (capita spesso con dischi della stessa età), perdi i dati. La differenza tra "sostituzione programmata a caldo" e "ripristino da backup dopo perdita RAID" è la differenza tra zero fermo e 8-24 ore.
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
Non basta sapere che il server è "acceso". Può rispondere al ping e intanto avere il gestionale bloccato, il backup fallito e un disco che sta per morire. Serve monitorare ogni strato — hardware, sistema operativo, servizi e applicazioni. Ecco le metriche critiche.
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 Atera 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 Atera 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 Atera 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. Il primo passo fondamentale è l'apertura automatica del ticket: con una piattaforma come Atera, ogni anomalia genera un ticket in tempo reale, 24/7/365, senza alcun intervento manuale. Questo elimina il collo di bottiglia più critico del monitoraggio tradizionale. 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). Atera, 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 Atera
BullTech Informatica offre un servizio di gestione server completo che include il monitoraggio 24/7 come componente fondamentale. La piattaforma Atera 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 quattro elementi. Primo, il ticket automatico 24/7/365: quando Atera rileva un'anomalia su un server — disco in pre-failure, servizio critico arrestato, CPU al 95% — apre automaticamente un ticket nel nostro sistema di gestione. Questo avviene in tempo reale, 24 ore su 24, 365 giorni all'anno, festivi inclusi. Nessun ritardo umano: l'alert diventa ticket istantaneamente, e per le criticità alte scatta l'escalation automatica verso il tecnico reperibile. Secondo, 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. Terzo, 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. Quarto, 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?
Tutto cio che conta. Hardware: CPU (percentuale, temperatura, throttling), ventole, alimentatori ridondanti, stato RAID (disco guasto o degradato), indicatori S.M.A.R.T. dei dischi (che prevedono i guasti con giorni di anticipo), errori memoria ECC. Software: RAM, spazio disco, velocita I/O dei dischi, stato dei servizi critici (Active Directory, SQL Server, gestionale, backup), log di sistema, aggiornamenti di sicurezza mancanti, stato dell'antivirus, certificati in scadenza. Rete: utilizzo delle interfacce, connessioni attive. Applicazioni: tempi di risposta, connessioni al database, errori nei log. Atera raccoglie tutto questo con un singolo agente installato sul server.
Come ricevo gli alert del monitoraggio?
Dipende dalla gravita. Per ogni anomalia rilevata, Atera apre automaticamente un ticket con tutte le informazioni diagnostiche — 24/7/365, senza ritardo umano. Alert informativi (bassa priorita): il ticket viene gestito nel flusso normale e ricevi una email riepilogativa giornaliera o settimanale. Warning (media priorita): ticket + email immediata al referente IT durante l'orario di lavoro. Alert critici: ticket + SMS e/o chiamata telefonica al tecnico reperibile, 24 ore su 24, 7 giorni su 7, festivi inclusi. Il tecnico parte gia con la diagnosi pronta perche il ticket contiene tutti i dati: quale server, quale metrica, da quanto tempo, quale soglia e stata superata. Se vuoi, possiamo integrare anche notifiche su Microsoft Teams o Slack.
Come si gestiscono i falsi allarmi nel monitoraggio server?
I falsi allarmi sono la sfida numero uno. Un picco di CPU durante il backup notturno non e un'anomalia, e il comportamento normale. Come li gestiamo? Tre modi. Primo: calibriamo le soglie server per server. Un SQL Server che usa normalmente il 60% di CPU non deve generare alert al 65%. Secondo: esclusioni temporali. I picchi noti (backup, scansioni antivirus, elaborazioni batch) vengono esclusi nelle fasce orarie previste. Terzo: se un server viene riavviato per manutenzione, il sistema lo sa e non manda 10 alert 'servizio down'. Nei primi 30 giorni di servizio, BullTech calibra tutto fino a portare i falsi positivi sotto il 5%.
Il monitoraggio funziona sia per server fisici che per server cloud?
Si, copre tutto: server fisici in ufficio, macchine virtuali (VMware, Hyper-V) e server cloud (Azure, AWS). Cambia un po' l'approccio: sui server fisici monitoriamo anche l'hardware (temperatura, alimentatori, ventole, RAID, memoria ECC) tramite le interfacce iDRAC (Dell), iLO (HPE) o XCC (Lenovo). Sui virtuali monitoriamo anche l'hypervisor: overcommit di CPU e RAM, performance dello storage, stato della replica. Sul cloud ci integriamo con Azure Monitor o AWS CloudWatch per le metriche specifiche della piattaforma. BullTech gestisce ambienti ibridi — fisici + virtuali + cloud — con una dashboard unificata in Atera.
Quanto costa il monitoraggio server 24/7 per una PMI?
Dipende da quanti server hai e dal livello di servizio. Per una PMI con 2-5 server, i costi indicativi sono: solo monitoraggio e alert (senza intervento) 30-50 euro/server/mese; monitoraggio con intervento in orario lavorativo 80-150 euro/server/mese; monitoraggio con intervento 24/7 incluso 150-300 euro/server/mese. BullTech include il monitoraggio server nel contratto di assistenza 'Always On', senza costi extra per singolo server. Paghi in base alla dimensione complessiva dei tuoi sistemi, cosi non hai l'incentivo a non monitorare qualche server per risparmiare. Considerando che un singolo fermo di un server critico puo costare migliaia di euro, l'investimento si ripaga gia dal primo problema prevenuto.
Il monitoraggio server e compatibile con il GDPR?
Si, e anzi aiuta la conformita. Il GDPR richiede 'misure tecniche adeguate per garantire la sicurezza' (art. 32) — il monitoraggio continuo e una di queste. I dati raccolti (log, metriche, eventi) possono contenere dati personali indiretti (nomi utente, indirizzi IP), quindi serve un contratto DPA (Data Processing Agreement) tra te e il fornitore del monitoraggio. BullTech garantisce: DPA incluso nel contratto; dati in data center UE (Atera usa infrastruttura europea); accesso limitato ai tecnici autorizzati con MFA; conservazione definita (12 mesi per i log, 24 per le metriche aggregate); cancellazione a fine contratto. Importante: non monitoriamo le attivita degli utenti (email, navigazione, file personali) — solo lo stato tecnico del server.
I tuoi server meritano qualcuno che li tenga d'occhio anche di notte. Se vuoi eliminare la "zona cieca" e prevenire i fermi non pianificati, chiamaci per un checkup gratuito dei tuoi server. Controlliamo lo stato di salute di ogni macchina, verifichiamo i backup e ti proponiamo un piano di monitoraggio su misura. Scopri anche il nostro servizio di gestione server e il monitoraggio proattivo IT per una protezione completa dei tuoi sistemi.