Come funziona Checkmk: architettura, autodiscovery e Microcore
Checkmk adotta principalmente un'architettura client-server. Sugli host possono essere installati agenti leggeri che raccolgono metriche e informazioni di stato. Nella modalità standard (pull), è il server Checkmk che interroga periodicamente gli agenti per recuperare i dati. Checkmk supporta inoltre il monitoraggio agentless tramite SNMP e tramite integrazioni/API (ad esempio REST, HTTP, SSH, IPMI/Redfish e altri special agent) per sistemi sui quali non è possibile installare un agente.
Il cuore tecnico delle edizioni enterprise è il Checkmk Microcore (CMC). CMC gestisce centinaia di migliaia di servizi monitorati con un consumo di risorse significativamente inferiore rispetto agli scheduler tradizionali, mantenendo latenze di check nell’ordine dei millisecondi anche su larga scala.
Il flusso operativo si articola in tre livelli:
- Autodiscovery automatica: quando un nuovo host si connette alla rete, Checkmk lo rileva e configura automaticamente i check pertinenti, senza intervento manuale. Questo vale per server fisici, VM, container Docker, nodi Kubernetes, dispositivi di rete e istanze cloud su AWS, Azure e GCP.
- Check engine e soglie adattive: oltre 2.000 check preconfigurati coprono OS, applicazioni, middleware, storage e dispositivi di rete. Le soglie di alert possono essere definite staticamente o lasciate alla calibrazione automatica basata sulla baseline storica.
- Correlazione e riduzione del rumore: il motore raggruppa gli alert correlati, distingue la causa radice dai sintomi derivati e applica policy di scheduled downtime per evitare notifiche durante le finestre di manutenzione pianificate.
L’architettura supporta sia deployment single-server per ambienti di piccole dimensioni, sia configurazioni distributed monitoring con siti multipli collegati a un’istanza di management centralizzata, essenziale per organizzazioni multi-sede o provider di servizi gestiti, adattandosi così alle principali tipologie di organizzazioni.
Monitoraggio tradizionale vs Checkmk: il confronto diretto
Il passaggio verso infrastrutture ibride e multi-cloud ha reso strutturalmente inadeguati gli strumenti di monitoring costruiti per ambienti statici e on-premise.
Monitoraggio tradizionale |
Checkmk |
|
|
Il punto critico non è solo la funzionalità tecnica: è il time-to-value. Con strumenti legacy, configurare il monitoraggio di un nuovo segmento di rete può richiedere giorni di intervento manuale. Con Checkmk, la copertura operativa su un nuovo ambiente si ottiene in poche ore.
3 casi d’uso in settori critici
La scalabilità di Checkmk è uno dei vantaggi strutturali: la piattaforma è progettata per crescere insieme all’infrastruttura, dalla PMI con poche decine di host all’enterprise con oltre 100.000 nodi monitorati. Ma è nei settori ad alta criticità che il valore si esprime con più chiarezza.
Finanza e banking
In un ambiente dove ogni minuto di down ha un costo misurabile in perdite transazionali e rischio regolatorio, la visibilità in tempo reale non è un nice-to-have. Checkmk è utilizzato per il monitoraggio H24 di core banking, sistemi di pagamento e infrastrutture di trading, con alert configurati su SLA stringenti e dashboard dedicate per i team NOC.
Sanità
Le infrastrutture sanitarie combinano sistemi clinici legacy, dispositivi medicali connessi e ambienti cloud per i dati paziente. Checkmk gestisce questa eterogeneità con un unico layer di osservabilità, monitorando la disponibilità di HIS, RIS, PACS e infrastrutture di rete ospedaliera, con supporto per le finestre di manutenzione pianificate.
Manufacturing e High Tech
Negli ambienti dove IT e OT convergono, la visibilità si estende oltre i server tradizionali fino ai dispositivi industriali e ai sistemi SCADA. Checkmk supporta il monitoraggio SNMP di device eterogenei e si integra con sistemi di supervisione industriale, offrendo una vista unificata che riduce i silos tra team IT e operations.
Checkmk e la conformità NIS2: perché il monitoraggio è un obbligo normativo
Il tema della visibilità infrastrutturale non è più solo operativo. In Italia, la Direttiva NIS2 è stata recepita con il D.Lgs. 138/2024, con l’ACN designata come autorità competente. Le organizzazioni notificate nell’aprile 2025 hanno visto partire un countdown concreto: obbligo di notifica degli incidenti da gennaio 2026, con piena conformità alle misure di sicurezza attesa entro ottobre 2026.
NIS2 impone obblighi che si traducono direttamente in requisiti tecnici di monitoring:
- Early warning entro 24 ore: il CSIRT Italia deve essere notificato entro 24 ore dalla rilevazione di un incidente significativo. Senza un sistema di monitoraggio continuo che rileva e registra l’anomalia in tempo reale, questo obbligo è strutturalmente impossibile da rispettare.
- Notifica completa entro 72 ore: il report dettagliato richiede informazioni sul tipo di incidente, sui sistemi coinvolti e sull’impatto stimato. I log centralizzati e gli audit trail automatici di Checkmk diventano la fonte primaria di questa documentazione.
- Monitoraggio continuo e risk management: NIS2 richiede misure proporzionate di rilevazione e risposta. Un sistema di IT monitoring strutturato è la condizione tecnica necessaria, non sufficiente ma imprescindibile, per dimostrare l’adeguatezza delle misure adottate.
Un aspetto spesso sottovalutato è la sovrapposizione NIS2-GDPR: un incidente che coinvolge dati personali può attivare parallelamente gli obblighi di notifica verso CSIRT Italia (NIS2) e il Garante Privacy (GDPR), con tempistiche e canali diversi. La disponibilità di log centralizzati e timeline degli eventi in Checkmk semplifica la gestione di questa doppia reportistica.
Per i settori classificati come essential o important da NIS2 (energia, sanità, finanza, infrastrutture digitali, PA, telecomunicazioni), il monitoraggio continuo non è una scelta architetturale: è un requisito normativo.
Come valutare una soluzione di monitoraggio IT: i criteri che contano
Scegliere la piattaforma di IT monitoring richiede una valutazione strutturata su più dimensioni. Non basta che uno strumento “funzioni” in ambiente di test: deve reggere sotto carico, scalare con l’infrastruttura, integrarsi con gli strumenti ITSM esistenti e rimanere sostenibile sul piano dei costi nel lungo periodo. I criteri su cui concentrare la valutazione sono almeno dodici, e riguardano sia l’aspetto tecnico sia quello economico e organizzativo:
- Copertura: la soluzione monitora l’intera infrastruttura, inclusi ambienti on-premise, cloud e container?
- Scalabilità: può crescere con le esigenze future dell’organizzazione, anche in ambienti ibridi e cloud-native?
- Alerting: gli alert sono intelligenti, personalizzabili e con opzioni di escalation verso tool ITSM?
- Performance a scala: il monitoraggio rimane veloce e affidabile anche con decine di migliaia di host?
- Costo e TCO: il modello di licenza scala in parallelo con l’infrastruttura senza salti di costo significativi?
- Consolidamento: permette di sostituire più tool con un’unica piattaforma, riducendo complessità e costi operativi?
Questi criteri — e altri quattro altrettanto rilevanti su deployment, customizzazione, vendor trust e maturità del prodotto — sono raccolti in una checklist di valutazione completa pensata per IT Manager e sysadmin che devono portare in azienda una raccomandazione fondata.
Stai valutando una soluzione di monitoraggio IT per la tua infrastruttura?
Scarica la guida How to Choose the Right IT Monitoring Solution: trovi la checklist completa dei 12 criteri di valutazione, il confronto tra approcci di monitoring e i casi reali di aziende come IONOS e Siemens che hanno scelto Checkmk per ambienti enterprise ad alta complessità.
