Su Ubuntu 22.04 LTS Jammy, Checkmk si installa in modo pulito se tratti il nodo come host di monitoraggio dedicato: pacchetto corretto, dipendenze minime, porte coerenti e primo accesso verificato subito dopo il setup. L’errore tipico non è l’installazione in sé, ma saltare la verifica della versione o ignorare il layer di rete tra browser, firewall e servizio web di Checkmk.
Qui trovi una procedura lineare per installare Checkmk Raw su Jammy, avviare il sito, entrare nella GUI e preparare il monitoraggio dei primi host. Se usi Edition diversa, il flusso resta simile ma cambia il nome del pacchetto e in alcuni casi il repository: il punto critico è sempre allineare versione di Ubuntu, architettura e release di Checkmk.
Prerequisiti reali: cosa deve esserci prima di partire
Prima di scaricare il pacchetto, verifica che la macchina sia aggiornata, abbia spazio disco sufficiente e un hostname stabile. Checkmk non è un tool “leggero” da buttare su un server qualunque senza pensarci: database interni, log, cache e code di verifica crescono rapidamente se inizi a monitorare più host e servizi.
Il minimo sensato è questo:
- Ubuntu 22.04 LTS Jammy aggiornato.
- Accesso root o sudo.
- DNS o `/etc/hosts` coerente per il nome del server.
- Porta TCP 80 o 443 disponibile verso la GUI, più eventuale 6557 per gli agenti distribuiti solo se ti serve esposizione diretta.
Se il server è dietro firewall o security group, decidi subito da dove accederai alla GUI. È una banalità che poi diventa tempo perso: se il browser non raggiunge la porta, l’installazione sembra rotta anche quando il servizio è perfettamente operativo.
Verifica base del sistema su Ubuntu 22.04
Controlla release, architettura e stato del disco prima di installare. Checkmk per Linux viene distribuito come pacchetto `.deb`, quindi l’architettura deve essere compatibile e il filesystem non deve essere al limite.
lsb_release -a
uname -m
df -h /
free -h
Atteso: Ubuntu 22.04, architettura `x86_64` o compatibile col pacchetto scelto, spazio libero adeguato su `/` e memoria sufficiente per il carico previsto. Se il disco è quasi pieno, risolvi prima: un’installazione che parte su storage saturo ti porta a errori intermittenti e log non affidabili.
Installazione del pacchetto Checkmk Raw
Per questa guida uso l’edizione Raw. La logica è semplice: scarichi il pacchetto `.deb` per Ubuntu 22.04, lo installi con `apt` o `dpkg`, poi crei il sito Checkmk. Il nome esatto del file cambia in base alla versione, quindi non fissarti sul nome: prendi sempre il pacchetto coerente con Jammy e con l’edizione che vuoi usare.
Se preferisci il flusso da repository, puoi usare il pacchetto disponibile dal sito ufficiale. In ambiente operativo, però, conviene scaricare il `.deb` esplicito e conservarne la versione: hai tracciabilità e rollback più semplici.
cd /tmp
wget https://download.checkmk.com/checkmk/<VERSIONE>/check-mk-raw-<VERSIONE>-jammy_0.amd64.deb
sudo apt install ./check-mk-raw-<VERSIONE>-jammy_0.amd64.deb
Se il download fallisce, non andare a tentativi: verifica direttamente l’URL e la versione disponibile sul sito ufficiale. Il problema più comune è un nome file copiato male o una release non più presente nel percorso indicato.
Al termine dell’installazione, controlla che il comando `omd` sia presente:
omd version
Atteso: viene mostrata la versione installata. Se il comando non esiste, l’installazione non è andata a buon fine oppure il pacchetto non è stato installato correttamente. In quel caso il primo punto da guardare è l’output di `apt` e l’eventuale errore di dipendenze.
Creazione del sito Checkmk
Checkmk gira come uno o più “siti” separati sotto il gestore OMD. Questa scelta è utile perché isola configurazione, dati e processo web per ogni istanza. Anche se ne avrai una sola, il modello mentale corretto è: pacchetto installato a livello sistema, sito creato a livello applicativo.
Crea il sito con un nome breve e leggibile, senza spazi e senza caratteri speciali. Un nome come `monitoring` o `cmk` è sufficiente.
sudo omd create monitoring
Dopo la creazione, avvia il sito:
sudo omd start monitoring
Controlla lo stato dei processi interni:
sudo omd status monitoring
Atteso: i demoni del sito risultano in esecuzione. Se uno o più componenti sono fermi, il problema va letto nel log del sito prima di fare altro. La directory di riferimento è sotto `/omd/sites/monitoring/`, con log e configurazioni del sito separati dal sistema host.
Primo accesso alla GUI e password iniziale
Checkmk crea un utente amministratore iniziale, di solito `cmkadmin`, con password generata o impostata durante la creazione del sito. Se non l’hai definita nel comando di creazione, recupera le indicazioni nel prompt o imposta una password sicura subito dopo. Non lasciare credenziali deboli: la GUI di monitoraggio è un punto ad alto valore perché espone stato servizi, topologia e spesso dettagli di infrastruttura interna.
Per cambiare la password dell’utente amministrativo del sito, puoi usare il comando dedicato dal contesto del sito o dall’utente `monitoring`:
sudo su - monitoring
cmk-passwd cmkadmin
Se il tuo pacchetto o la tua versione non includono `cmk-passwd`, il metodo alternativo è gestire la password dalla GUI al primo login oppure consultare la documentazione specifica della release. Non indovinare il comando: cambia tra versioni e distro, e qui il gap si chiude guardando `omd help` o l’help della release installata.
Apri quindi il browser e raggiungi l’URL del sito. In genere la forma è simile a:
http://<IP-o-hostname>/monitoring/
Se hai configurato reverse proxy o HTTPS esterno, l’URL reale cambia. Il punto non è il protocollo in sé ma arrivare alla pagina di login senza errori 404, 502 o redirect loop.
Firewall, porte e accesso remoto
Su Ubuntu 22.04, se usi `ufw`, apri almeno la porta della GUI. Per un’installazione standard, la porta dipende dalla configurazione del sito e dal web server interno, ma il caso più comune è accesso via HTTP/HTTPS davanti a un reverse proxy oppure diretto sul web server del sito. Non aprire porte a caso: verifica prima quale socket ascolta davvero.
Controlla i listener:
sudo ss -ltnp
Atteso: il processo web del sito ascolta sulla porta prevista. Se non vedi alcun listener, il sito non è partito o il web service ha fallito all’avvio.
Se usi UFW e devi consentire accesso al server da una rete amministrativa specifica, limita la sorgente invece di aprire tutto il mondo:
sudo ufw allow from <IP-amministrazione> to any port <PORTA> proto tcp
sudo ufw status numbered
Atteso: regola presente e visibile nell’elenco. Se hai già un firewall perimetrale, allinea anche quello: il problema classico è sbloccare UFW ma dimenticare il security group o il filtro upstream.
Verifica della salute del sito e dei log
Prima di passare alla configurazione dei target, controlla i log del sito. È qui che trovi errori di bootstrap, permessi, porte occupate o problemi di compatibilità. Il percorso esatto dipende dal sito, ma la struttura tipica è sotto `/omd/sites/monitoring/var/log/`.
sudo tail -n 50 /omd/sites/monitoring/var/log/mk*.log
sudo tail -n 50 /omd/sites/monitoring/var/log/automation.log
Se trovi errori di permessi, controlla proprietario e gruppo della directory del sito. Se trovi errori di binding sulla porta, verifica conflitti con altri servizi. Se trovi errori Python o dipendenze mancanti, il problema è quasi sempre un pacchetto incompleto o una release non allineata al sistema.
Aggiungere il primo host monitorato
Una volta che la GUI è raggiungibile, il primo obiettivo non è “fare dashboard”, ma ottenere un host con stato e servizi corretti. Il modo migliore per testare l’installazione è aggiungere il server stesso o un host Linux noto e raggiungibile via ICMP/SSH.
Dal pannello di Checkmk, vai in Setup, poi Hosts, e aggiungi un host con nome DNS o IP. Se il sistema è già nel DNS, usa il nome completo: riduci ambiguità e problemi con certificati, agenti e notifiche future.
Dopo aver creato l’host, esegui il discovery dei servizi. Questo passaggio è fondamentale: Checkmk non “indovina” i servizi in modo permanente, ma li rileva e poi li consolida nella configurazione attiva.
Il flusso operativo è:
- Aggiungi l’host.
- Avvia la service discovery.
- Seleziona i servizi rilevati.
- Salva e attiva le modifiche.
Atteso: l’host passa a stato raggiungibile e i servizi mostrano valori coerenti. Se tutto rimane “PENDING” o “UNKNOWN”, il problema è quasi sempre legato all’agent, al firewall o alla risoluzione del nome.
Installare l’agent Checkmk su un host Linux
Per ottenere metriche di sistema serie, non basta il ping. Devi installare l’agent sul nodo che vuoi monitorare. Su Ubuntu e Debian il flusso è semplice: scarichi il pacchetto dell’agent, lo installi e poi verifichi che risponda sulla porta o via comando locale.
Dal server Checkmk, nella pagina dell’host o nella sezione degli agenti, scarica il pacchetto appropriato. Su un host Ubuntu tipico, puoi installarlo così:
sudo apt install ./check-mk-agent_<VERSIONE>_all.deb
Verifica la presenza dell’agent localmente:
check_mk_agent
Atteso: output con sezioni di sistema, filesystem, CPU, memoria e processi. Se il comando non esiste, il pacchetto non è stato installato o il binario non è nel PATH. Se l’output è vuoto o incompleto, guarda i permessi e gli eventuali plugin aggiuntivi installati in `/usr/lib/check_mk_agent/` o percorsi equivalenti della release.
Se stai monitorando host remoti, non esporre l’agent su Internet senza motivo. È una superficie d’attacco inutile. Limita l’accesso con firewall, ACL o tunneling, e usa credenziali o meccanismi di cifratura se il tuo scenario lo richiede.
Configurazione iniziale utile: notifiche, utenti e permessi
Dopo l’installazione tecnica, la parte che spesso viene trascurata è la governance degli accessi. Non lasciare l’utente admin condiviso tra più operatori. Crea utenti nominali, assegna ruoli minimi e separa chi guarda gli allarmi da chi cambia la configurazione.
In una gestione pulita, almeno tre profili hanno senso:
- Amministratore tecnico.
- Operatore di monitoraggio.
- Utente sola lettura per stakeholder o NOC esterno.
Le notifiche vanno testate subito: email, webhook o integrazioni esterne devono essere verificati con un alert di prova. Non aspettare il primo guasto reale per scoprire che il relay SMTP blocca l’invio o che il token dell’integrazione è scaduto.
Problemi tipici su Jammy e come leggerli
Su Ubuntu 22.04 i problemi più frequenti non sono “bug misteriosi”, ma disallineamenti banali:
- Pacchetto Checkmk non coerente con Jammy.
- Firewall che blocca la porta della GUI.
- Hostname non risolvibile dal client.
- Agent non raggiungibile o non installato.
- Spazio disco insufficiente su `/omd` o sul filesystem del sito.
La sequenza corretta di troubleshooting è sempre la stessa: prima stato del servizio, poi log, poi rete, poi discovery. Andare subito a riscrivere configurazioni o reinstallare tutto è quasi sempre il modo più veloce per perdere tempo e traccia del problema.
Un controllo sintetico utile è questo:
sudo omd status monitoring
sudo ss -ltnp
sudo tail -n 100 /omd/sites/monitoring/var/log/*.log
Se il sito è attivo ma la GUI non risponde, il layer da controllare è la rete o il reverse proxy. Se la GUI risponde ma gli host restano offline, il problema è quasi sempre a livello agent o discovery. Se il sito non parte, la causa è locale: porta occupata, dipendenze, permessi o disco.
Backup e rollback prima di toccare la configurazione
Ogni volta che fai modifiche al sito, conserva un punto di ritorno. Checkmk separa bene i dati del sito, quindi il rollback è più semplice se hai una copia della directory del sito e della configurazione esportata prima dei cambiamenti.
Un backup minimo del sito può essere eseguito fermando il sito e archiviando la directory corrispondente. Il rischio qui è operativo: il sito non resta disponibile durante il dump, quindi fallo in finestra di manutenzione o su ambiente non produttivo.
sudo omd stop monitoring
sudo tar -czf /root/monitoring-backup-$(date +%F).tar.gz /omd/sites/monitoring
sudo omd start monitoring
Rollback: ripristini l’archivio, riavvii il sito e verifichi la GUI. Se invece hai toccato solo la configurazione tramite interfaccia, esporta almeno la change request o annota gli oggetti modificati. Senza questo, il rollback diventa manuale e lento.
Checklist finale di installazione corretta
Una installazione fatta bene non si misura dal fatto che il pacchetto ha finito senza errori, ma dal fatto che il sito è raggiungibile, gli host si aggiungono e i servizi vengono rilevati con dati sensati. Se questi tre punti sono veri, puoi considerare l’installazione funzionale.
- `omd status monitoring` mostra tutti i processi attivi.
- La GUI risponde all’URL del sito senza errori di rete o redirect anomali.
- Un host di test passa discovery e salva la configurazione attiva.
- L’agent Linux restituisce output completo se lo hai installato.
- I log non mostrano errori ripetuti su permessi, porte o dipendenze.
Assunzione operativa: il server è dedicato o almeno ben dimensionato per il carico di monitoraggio previsto; se devi usare lo stesso nodo per altri servizi critici, valuta bene collisioni di porte, consumo RAM e impatto dei job di check.
Con questa base, Checkmk su Ubuntu 22.04 LTS Jammy diventa un’installazione prevedibile: pacchetto corretto, sito creato, accesso validato, agenti controllati e rollback sempre possibile. Il resto è tuning della retention, regole di notifica e ottimizzazione dei check, ma la parte importante è avere una piattaforma che risponde in modo pulito già dal primo avvio.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.