Installare e configurare CheckMK per il monitoraggio Linux

Obiettivo e scelta dell’architettura

Checkmk è adatto quando vuoi monitorare Linux con un approccio scalabile: host, servizi, metriche, alert e discovery automatico. La scelta architetturale più comune è un server Checkmk centrale che interroga gli host Linux tramite agent locale, eventualmente affiancato da SNMP o API per apparati e servizi esterni. Per un ambiente Linux puro, l’agente Checkmk è la via più semplice e affidabile: riduce il rumore, espone metriche già normalizzate e richiede meno tuning rispetto a soluzioni più generiche.

Se stai partendo da zero, l’obiettivo pratico è questo: installare il server, registrare il primo host Linux, verificare che l’agente risponda, fare service discovery e attivare notifiche con una soglia minima di rischio. Il resto viene dopo: template, business rules, dashboard e tuning degli alert.

Prerequisiti minimi

Prima di installare, assicurati di avere:

• un server Linux dedicato o VM con accesso stabile alla rete degli host da monitorare;
• DNS funzionante oppure almeno risoluzione coerente tra server e client;
• porta web del sito Checkmk raggiungibile dagli operatori;
• ora di sistema corretta via NTP;
• spazio disco sufficiente per log, cache e storico metriche.

Per iniziare bene, separa il ruolo del server di monitoraggio da quello di altri servizi pesanti. Checkmk non è un componente da mettere a caso su un host già saturo di database o applicazioni ad alta I/O.

Se l’ambiente è piccolo, va bene una singola istanza. Se prevedi crescita, valuta da subito una macchina con margine su CPU e RAM, perché discovery, check e retention possono crescere rapidamente con il numero di host e servizi.

Installazione del server Checkmk

Il metodo più semplice è usare il pacchetto ufficiale per la tua distribuzione. Il nome del file cambia in base alla versione e alla distro, quindi qui il punto non è copiare un comando unico, ma seguire il flusso corretto: scaricare il pacchetto, installarlo con il package manager e inizializzare il sito Checkmk.

Flusso tipico su una distribuzione Debian/Ubuntu:

sudo apt update
sudo apt install ./check-mk-*.deb

Flusso tipico su RHEL/CentOS/Rocky/Alma:

sudo dnf install ./check-mk-*.rpm

Dopo l’installazione, crea il sito e avvialo secondo le istruzioni del pacchetto o della documentazione della tua versione. In molte installazioni moderne il sito viene creato durante la procedura di setup o tramite strumenti specifici forniti dal pacchetto.

Verifica subito che il servizio web del sito sia attivo e raggiungibile:

sudo omd status

Atteso: il sito risulta in stato running e i componenti principali sono up. Se il sito non è attivo, non andare avanti con l’onboarding degli host: prima risolvi il layer di base.

Primo accesso e configurazione iniziale

Accedi all’interfaccia web del sito Checkmk con l’utente amministrativo creato in fase di setup. La prima attività è impostare i parametri essenziali: timezone, notifiche, eventualmente branding e ruoli utente se ci sono più operatori.

Le impostazioni iniziali utili sono:

• timezone coerente con i server monitorati;
• utente amministratore separato da eventuali account operativi;
• policy di password e accesso web;
• integrazione SMTP per gli alert;
• eventuale proxy se il server non esce direttamente in rete.

Se non configuri subito la posta, rischi di avere un sistema “apparentemente attivo” ma cieco lato alerting. La parte di notifica va trattata come requisito, non come optional.

Installare l’agente Checkmk sugli host Linux

L’agente è il componente che espone metriche e check dal sistema monitorato. In pratica il server Checkmk interrogherà l’host sulla porta dell’agente, di solito 6556, e riceverà un output testuale già pronto per l’interpretazione.

Su molti sistemi è disponibile un pacchetto ufficiale. Il procedimento è semplice: scarichi il pacchetto corretto per la distro, lo installi e verifichi il servizio o l’accesso TCP. In alternativa, in ambienti molto chiusi, puoi distribuire l’agente con strumenti di gestione centralizzata.

Verifiche da fare sull’host Linux:

sudo systemctl status checkmk-agent

oppure, se il tuo pacchetto non usa un servizio systemd dedicato, verifica la porta:

ss -lntp | grep 6556

Atteso: la porta ascolta o il servizio è presente secondo il metodo di installazione adottato. Se l’agente non ascolta, il problema è locale all’host, non al server Checkmk.

Controlla anche il firewall locale. Se usi firewalld, nftables o ufw, consenti l’accesso alla porta dell’agente solo dagli IP del server di monitoraggio. Non esporre 6556 al mondo intero.

Registrare un host Linux in Checkmk

Nel sito Checkmk crea un nuovo host inserendo nome, indirizzo IP o FQDN e, se serve, tag di classificazione. Per un ambiente semplice, bastano hostname e IP. Se hai più ambienti, usa tag come produzione, staging, Linux server, database, web.

Le impostazioni che contano davvero per il primo host sono:

• tipo di address: IP fisso o DNS;
• check via agent;
• eventuale gruppo di host;
• eventuali credenziali per servizi aggiuntivi;
• policy di discovery.

Dopo aver salvato l’host, esegui il service discovery. È il passaggio che evita di dover creare a mano ogni singolo check. Checkmk rileva filesystem, CPU, RAM, processi, interfacce, swap, load e altri componenti in base ai dati ricevuti dall’agente.

Se il discovery non trova niente, non forzare subito la configurazione: prima verifica che l’agente risponda davvero e che il traffico dal server al client non venga bloccato.

Service discovery e attivazione delle modifiche

Il flusso corretto è: aggiungi host, fai discovery, revisiona i servizi trovati, poi attiva le modifiche. Non saltare l’ultimo passaggio, perché in Checkmk la configurazione resta in staging finché non viene applicata.

Durante la revisione dei servizi, cerca questi punti:

• filesystem con mount point corretti;
• interfacce di rete che ti aspetti davvero di monitorare;
• load e memoria con soglie ragionevoli;
• servizi applicativi che non vuoi perdere, come nginx, apache, mysql, postgresql, ssh.

Se un servizio non serve, disabilitalo. Il rumore in monitoraggio è un problema operativo reale: più falsi positivi hai, meno affidabili diventano gli alert.

Attiva le modifiche solo dopo aver verificato che i servizi elencati siano plausibili. Se il server è un host generico, non dovresti vedere decine di check bizzarri o duplicati.

Regole base per soglie e alert

Per partire, non serve una politica di alert complessa. Servono soglie sensate su pochi indicatori ad alto valore:

• filesystem: warning al 80%, critical al 90%;
• load average: soglie correlate al numero di CPU, non fisse a caso;
• RAM: attenzione a swap e memory pressure, non solo alla RAM “free”;
• servizi critici: stato down come critical immediato;
• latenza e packet loss se monitori la rete.

Le soglie vanno adattate al profilo dell’host. Un server DB e un web server non hanno gli stessi pattern di saturazione. Se applichi template troppo generici, avrai rumore o cecità.

Se non sai da dove iniziare, usa i default del sistema e correggili dopo qualche giorno di osservazione. L’errore più comune è personalizzare tutto subito senza dati storici.

Configurare le notifiche

Le notifiche sono utili solo se arrivano al canale giusto e con un contenuto utile. La configurazione minima richiede un relay SMTP affidabile o un servizio di posta esterno autorizzato. Imposta mittente, destinatari, gruppi e orari di reperibilità.

Controlla che il messaggio includa almeno:

• host coinvolto;
• servizio o metrica in allarme;
• stato attuale e soglia superata;
• timestamp;
• link diretto alla pagina del check.

Per il primo test, forza un alert in modo controllato, ad esempio fermando temporaneamente un servizio non critico su un host di test. Poi verifica che la notifica arrivi e che il ripristino chiuda l’evento in modo pulito.

Se la posta non parte, controlla log del sito Checkmk e del relay SMTP. Molto spesso il problema non è Checkmk ma l’autenticazione SMTP, il blocco di rete o un sender non accettato dal server di posta.

Controlli lato rete e firewall

La comunicazione standard tra server Checkmk e host Linux deve essere chiara e limitata. In genere il server parla verso l’agente sulla porta 6556/TCP. Se usi altre sorgenti di dati, aggiungi solo le porte necessarie.

Verifica dal server di monitoraggio:

nc -vz IP_HOST 6556

oppure, se vuoi vedere il contenuto esposto dall’agente:

curl -v telnet://IP_HOST:6556

Atteso: connessione aperta e risposta dell’agente. Se ottieni timeout, il problema è quasi sempre firewall, routing o binding dell’agente. Se ricevi connection refused, il servizio non ascolta o la porta è chiusa localmente.

Su host esposti a reti non fidate, limita l’accesso con regole firewall o con restrizioni lato agente. La superficie d’attacco va ridotta, soprattutto se monitori ambienti con segmenti separati.

Tuning iniziale del monitoraggio

Una volta che il primo host è online, dedica tempo al tuning. Il monitoraggio utile non è quello che genera più allarmi, ma quello che segnala davvero i problemi. Rivedi i servizi scoperti e disabilita i check inutili. Poi correggi le soglie in base alla realtà operativa.

Osserva per qualche giorno:

• quali check vanno in warning senza impatto reale;
• quali soglie sono troppo strette;
• quali servizi non sono abbastanza coperti;
• se ci sono finestre di manutenzione da escludere;
• se gli alert si concentrano sempre sugli stessi host.

Se i servizi critici generano falsi positivi, non abbassare subito la severità: prima capisci se il problema è di soglia, di raccolta dati o di capacità reale.

Integrazione con Linux systemd e controlli operativi

Su Linux moderno, molti servizi da monitorare sono gestiti da systemd. Questo è utile perché Checkmk può intercettare stato, restart e failure in modo coerente. Per i servizi più importanti, verifica che l’unità sia stabile anche fuori dal monitoraggio:

systemctl status nginx
systemctl status mariadb
systemctl status sshd

Atteso: active (running) o stato coerente con il ruolo della macchina. Se un servizio è in restart loop, Checkmk lo vedrà, ma il problema vero è a monte e va risolto sul sistema.

Per file system e storage, tieni d’occhio anche inode, latenza disco e capacità residua. Spesso il primo sintomo di un problema serio non è il 100% di spazio, ma la crescita anomala della latenza o l’esaurimento degli inode.

Errori comuni da evitare

Ci sono alcuni errori che si ripetono spesso nelle installazioni iniziali:

1. installare il server senza verificare prima rete, DNS e ora di sistema;
2. esporre l’agente su tutte le reti senza restrizioni;
3. accettare tutti i servizi scoperti senza revisione;
4. usare soglie uguali per host molto diversi;
5. attivare notifiche prima di validare SMTP e destinatari;
6. ignorare il tuning e lasciare il sistema in stato rumoroso.

Se eviti questi sei punti, il deployment iniziale è già molto più solido della media.

Verifica finale del primo rollout

Il primo rollout è riuscito quando puoi dimostrare tutti questi punti:

• il sito Checkmk è online;
• almeno un host Linux risponde tramite agente;
• il service discovery mostra servizi attesi;
• le modifiche sono state attivate;
• una notifica di test arriva al canale corretto;
• un check critico si ripristina correttamente dopo il fix.

Per una verifica rapida, dal server di monitoraggio esegui il controllo della porta dell’agente e poi apri la pagina dell’host in Checkmk. Se vedi dati freschi, servizi corretti e nessun errore di comunicazione, la base è a posto.

Da qui in poi puoi estendere la configurazione: più host, regole per gruppi, dashboard, integrazione con ticketing e automazioni. Ma la sequenza giusta resta la stessa: osservabilità prima, tuning poi, automazione dopo.

Scalare oltre il primo host

Quando il primo host è stabile, replica il modello con template e regole. Raggruppa gli host per funzione o ambiente, non solo per sistema operativo. Questo ti permette di applicare soglie e notifiche coerenti a web server, database, bastion, storage e nodi applicativi.

Se il numero di host cresce, osserva tre metriche operative del sistema di monitoraggio stesso: tempi di check, backlog di esecuzione e consumo risorse del server Checkmk. Se il monitoraggio diventa lento o perde freschezza, non stai solo avendo un problema di performance: stai perdendo affidabilità sull’intero impianto di osservabilità.

In sintesi, l’installazione di Checkmk su Linux funziona bene quando segui una sequenza ordinata: server, agente, discovery, soglie, notifiche, tuning. Saltare uno di questi punti rende il sistema meno utile e più rumoroso.