Come installare Checkmk su Ubuntu 22.04 LTS

Checkmk su Ubuntu 22.04 LTS: la strada pulita è partire dal pacchetto giusto

Se l’obiettivo è avere un monitoraggio serio su Ubuntu 22.04 LTS, Checkmk è una scelta solida perché unisce raccolta metriche, discovery dei servizi, alerting e inventario in un unico flusso. L’installazione non è complessa, ma il punto non è “farlo partire”: il punto è farlo partire bene, con un sito Checkmk separato, un account amministrativo iniziale controllato e una base pronta per aggiungere host senza dover correggere tutto dopo.

Su Ubuntu 22.04 LTS conviene usare il pacchetto ufficiale del ramo stabile compatibile con la release del sistema. Evito di dare per scontato il nome esatto del file scaricato, perché cambia con la versione di Checkmk. La logica corretta è: si verifica il ramo disponibile, si installano le dipendenze minime, poi si crea il sito, si avvia il servizio e solo dopo si aggiungono gli host da monitorare.

Prima di installare: cosa serve davvero

Checkmk gira bene su una VM piccola, ma se vuoi evitare colli di bottiglia inutili conviene partire con risorse realistiche. Per un ambiente piccolo o di test, 2 vCPU e 4 GB di RAM sono un minimo sensato; per un uso più ampio, la CPU conta meno della memoria e dell’I/O disco, soprattutto quando il numero di host e servizi cresce.

Verifica anche queste condizioni prima di toccare il sistema:

• Hostname stabile e risolvibile, meglio se con FQDN coerente con il certificato che userai in seguito.
• Accesso root o sudo con privilegi sufficienti per installare pacchetti e avviare servizi systemd.
• Spazio disco libero, in particolare su `/` e sul filesystem che ospiterà i dati del sito Checkmk.

Un controllo rapido evita sorprese banali:

hostnamectl
lsb_release -a
df -h
free -h

Se il server è dietro firewall o security group, tieni presente che l’interfaccia web di Checkmk userà una porta dedicata del sito creato, non la classica 80/443. In fase iniziale è utile aprire l’accesso solo dalla tua rete amministrativa, poi stringere le regole quando hai finito il setup.

Installazione del pacchetto Checkmk su Ubuntu 22.04

Il flusso corretto è scaricare il pacchetto Debian/Ubuntu del ramo compatibile e installarlo con `apt`. In ambienti reali preferisco evitare installazioni “a mano” sparse in directory casuali: il pacchetto ufficiale integra meglio dipendenze, permessi e servizi.

Prima aggiorna l’indice dei pacchetti e installa le dipendenze base più comuni. I nomi possono variare in base al ramo Checkmk, ma questo è lo scheletro corretto:

sudo apt update
sudo apt install -y wget ca-certificates xinetd

Se il pacchetto Checkmk che hai scaricato si chiama, per esempio, `check-mk-raw-..._amd64.deb` oppure `check-mk-enterprise-..._amd64.deb`, l’installazione avviene così:

sudo dpkg -i check-mk-*_amd64.deb
sudo apt -f install -y

Il secondo comando chiude le dipendenze mancanti, se presenti. Se `dpkg` segnala errori, non forzare la mano: leggi l’output, perché spesso il problema è una libreria mancante o un pacchetto non allineato alla release di Ubuntu.

Al termine dell’installazione, il sistema crea gli strumenti necessari per gestire il sito Checkmk. È normale non vedere ancora una dashboard: prima va creato il sito vero e proprio.

Creazione del sito: il passaggio che molti fanno in fretta e poi pagano dopo

Checkmk non si comporta come un singolo demone da avviare e basta. Il suo modello operativo prevede un “site” separato, con utente, directory e servizi dedicati. Questo è uno dei motivi per cui è ordinato da amministrare: ogni ambiente resta isolato.

Per creare il sito usa il comando fornito dal pacchetto. Il nome esatto del comando dipende dalla variante installata, ma la procedura è sempre quella: creazione del site, definizione della password iniziale dell’utente amministratore e avvio del servizio. Un esempio tipico è il seguente:

sudo omd create monitoring
sudo omd start monitoring

Il nome `monitoring` è solo un esempio. In produzione conviene usare un nome coerente con il contesto, ad esempio il dominio interno o il ruolo della piattaforma, purché resti chiaro per chi la gestisce. Durante la creazione ti verrà chiesto di impostare la password dell’utente amministrativo del sito.

Per entrare nel contesto del site e lavorare con i suoi comandi, usa l’utente dedicato:

sudo su - monitoring

Da lì puoi verificare lo stato del sito con:

omd status

Lo stato corretto mostra i servizi principali attivi. Se qualcosa non parte, non cambiare subito configurazioni a caso: controlla prima i log del site, perché quasi sempre lì c’è la causa reale.

Primo accesso alla web UI e hardening minimo

Una volta avviato il sito, l’interfaccia web è raggiungibile sulla porta assegnata da Checkmk, che di norma viene mostrata nei messaggi di creazione o nello stato del site. Il primo accesso serve a confermare che web server, backend e autenticazione siano coerenti. Non limitarti a vedere la pagina di login: entra, verifica il menu e controlla che l’utente amministratore abbia i permessi corretti.

Se devi individuare la porta del sito, il modo più semplice è leggere l’output del comando di stato o la configurazione del site. Un controllo utile è:

sudo omd status monitoring
sudo omd config monitoring show

Appena entri nella UI, fai tre cose subito:

1. Verifica il timezone del sito e allinealo al contesto operativo, soprattutto se devi correlare eventi con altri sistemi.
2. Controlla lingua, formato data e notifiche base, perché incideranno su audit e lettura degli alert.
3. Imposta un account amministrativo nominativo diverso dall’utente iniziale, così puoi disabilitare o limitare l’account bootstrap dopo il setup.

Dal punto di vista della sicurezza, il minimo sindacale è non esporre la porta del sito a Internet senza protezione. Se devi pubblicarla, passa da reverse proxy con TLS, access control e, se possibile, una rete di amministrazione separata. Checkmk non è il posto giusto per improvvisare esposizioni dirette.

Installazione dell’agent su un host Linux monitorato

Un Checkmk installato senza agenti è solo metà lavoro. Il valore vero arriva quando il server inizia a raccogliere dati dal sistema monitorato in modo coerente e poco invasivo. Su Linux, l’agent è leggero e si installa in pochi minuti.

Dal server Checkmk puoi scaricare il pacchetto agent per l’host target. Il pacchetto dipende dalla distribuzione dell’host, ma il principio è identico. Su un server Ubuntu/Debian tipicamente installerai un `.deb`, poi verificherai che il servizio sia esposto correttamente oppure che il controllo via SSH sia configurato secondo la tua policy.

Se vuoi un controllo rapido dal lato host, dopo l’installazione esegui:

check_mk_agent

Il comando deve restituire blocchi di dati leggibili, con sezioni come filesystem, CPU, memoria e servizi. Se non ottieni output, il problema è quasi sempre uno di questi tre: agent non installato, permessi errati, oppure metodo di accesso non coerente con la configurazione del server Checkmk.

Un approccio pragmatico è aggiungere il server monitorato alla UI, poi fare la discovery dei servizi. In Checkmk la parte utile non è solo “vedere l’host”, ma scoprire automaticamente cosa ha senso monitorare: dischi, mount point, interfacce, processi e servizi applicativi.

Discovery, regole e perché non conviene lasciare tutto di default

Il primo errore tipico è accettare il risultato iniziale senza rifarlo dopo aver capito il server. Il secondo è creare regole troppo generiche. Checkmk funziona bene quando il modello è: scoperta iniziale, revisione manuale, regole mirate per classi di host, poi standardizzazione.

Quando fai service discovery, controlla sempre se ci sono servizi che non ti interessano o, al contrario, risorse che dovrebbero essere tracciate ma non lo sono. Un filesystem temporaneo può generare rumore; un mount critico mancato può nascondere il problema vero.

Una regola sensata per ambienti piccoli è questa:

• Monitorare tutti i filesystem persistenti.
• Escludere pseudo filesystem e mount effimeri se producono falsi positivi.
• Impostare soglie diverse per host di produzione, staging e sviluppo.

Se usi più server, conviene ragionare per tag e gruppi. In questo modo le regole non diventano una collezione di eccezioni difficili da ricordare. Il rischio più grosso, nel tempo, non è il guasto: è la configurazione ingestibile.

Controllo della porta, firewall e accesso iniziale

Se la web UI non risponde, il problema spesso non è Checkmk ma il layer di rete. Prima di aprire ticket o cambiare configurazioni, verifica la porta in ascolto e la reachability dal client amministrativo.

sudo ss -ltnp | grep -i omd
curl -I http://127.0.0.1:<porta>/

Dal tuo PC o da una macchina della stessa rete:

curl -I http://IP_DEL_SERVER:<porta>/

Se il primo comando funziona ma il secondo no, il problema è quasi certamente firewall, security group o routing. Se entrambi falliscono, il sito non è partito o il servizio web interno non è in salute. In quel caso torna a `omd status` e ai log del site.

Con `ufw`, un’apertura minima e reversibile può essere questa, sempre solo se la policy del tuo ambiente lo consente:

sudo ufw allow from 192.0.2.0/24 to any port <porta> proto tcp
sudo ufw status numbered

Il rollback è altrettanto semplice: rimuovi la regola numerata dopo aver completato il setup o dopo aver posizionato un reverse proxy più controllato.

Backup, aggiornamenti e manutenzione ordinaria

Un’installazione di Checkmk non finisce quando vedi la dashboard. La parte seria è mantenere il sistema aggiornato senza perdere configurazioni, regole e storico. Prima di ogni cambio di versione, fai sempre un backup del site e conserva la copia in un posto separato.

Il backup del sito può essere gestito con gli strumenti OMD/Checkmk o con snapshot della VM, ma la regola è la stessa: prima salvi, poi cambi. Se l’ambiente è piccolo, uno snapshot coerente può bastare; se è importante, meglio avere anche un export applicativo o una procedura di restore testata.

Per la manutenzione ordinaria tieni d’occhio almeno questi punti:

• Versione del pacchetto Checkmk installato.
• Spazio disco del site e crescita dei log.
• Tempo di esecuzione dei check e numero di host/service in stato critico.
• Eventuali errori nei log del site, soprattutto dopo aggiornamenti del sistema operativo.

Un controllo utile, da schedulare, è la verifica della salute del sito e della coda di elaborazione. Se il sistema rallenta, il sintomo iniziale spesso è un aumento della latenza nella visualizzazione degli eventi o un refresh più lento della dashboard, non un crash netto.

Una configurazione minima che regge nel tempo

Per evitare di rifare il lavoro tra qualche mese, la configurazione base dovrebbe già includere alcuni criteri semplici. Non serve complicarsi la vita con decine di regole speciali all’inizio. Serve invece una struttura leggibile, con naming coerente e ruoli chiari.

Una buona baseline è questa:

1. Un site Checkmk dedicato per ambiente o per dominio operativo, non un contenitore promiscuo per tutto.
2. Host raggruppati per funzione, non per ordine casuale di inserimento.
3. Template di regole separati per produzione, test e infrastruttura di supporto.
4. Accesso amministrativo ristretto e, se possibile, autenticazione centralizzata.

Questo approccio riduce il rumore operativo. Quando l’alert scatta, sai dove guardare e non devi decifrare una configurazione nata male. E questa, in monitoraggio, è spesso la differenza tra sistema utile e sistema decorativo.

Verifica finale: come capire che l’installazione è davvero ok

La verifica finale non è solo “si apre la pagina web”. Devi confermare quattro cose: il site è in esecuzione, l’interfaccia web risponde, l’agent restituisce dati e almeno un host compare con discovery coerente.

sudo omd status monitoring
curl -I http://127.0.0.1:<porta>/
check_mk_agent

Se questi tre controlli sono a posto, la base è sana. A quel punto puoi passare alla fase successiva: integrazione con mail relay per le notifiche, eventuale reverse proxy con TLS, policy di soglie e definizione dei contatti operativi.

Se qualcosa non torna, la priorità resta sempre la stessa: osserva prima, cambia dopo. Checkmk è uno strumento da amministratore, non da indovino. Se gli dai un’installazione pulita e una configurazione sobria, ti restituisce una vista utile dell’infrastruttura. Se lo riempi di eccezioni e scorciatoie, ti restituisce rumore. La differenza la fa quasi sempre il primo giorno.