Monitoraggio di Linux

Puoi installare l'agente Linux installando il pacchetto RPM o DEB. La scelta tra RPM e DEB dipende dalla distribuzione Linux su cui vuoi installare il pacchetto:

Prima dell'installazione dovrai scaricare il pacchetto e trasferirlo sull'host (ad esempio con scp o WinSCP) dove vuoi che l'agente venga eseguito.

Dopo aver scaricato il pacchetto RPM o DEB e, se necessario, averlo copiato sull'host da monitorare utilizzando scp, WinSCP o altri mezzi, l'installazione viene completata con un unico comando.

Il pacchetto RPM viene installato come utente root con il comando rpm -U:

A proposito, l'opzione -U sta per "aggiornamento", ma può anche eseguire correttamente un'installazione iniziale. Ciò significa anche che puoi utilizzare questo comando per aggiornare un agente esistente alla versione corrente e utilizzare lo stesso comando per futuri aggiornamenti del pacchetto dell'agente.

L'installazione del pacchetto DEB — e un aggiornamento — viene eseguita come utente root con il comando dpkg -i:

Qui il pacchetto è stato installato per la prima volta su un host che prima non aveva alcun agente. L'utente cmk-agent è stato creato e systemd è stato configurato. Tra un attimo parleremo dell'avviso provvisorio relativo a insecure mode, ovvero la modalità pull legacy.

Le edizioni commerciali dispongono di un modulo software, Agent Bakery, per il packaging automatico di agenti personalizzati. Una descrizione dettagliata è disponibile nell'articolo generale sugli agenti. L'installazione dei pacchetti creati con Agent Bakery avviene allo stesso modo descritto sopra per i pacchetti inclusi.

In Checkmk Ultimate puoi inoltre utilizzare Agent Bakery per fornire ai pacchetti degli agenti una configurazione per la registrazione automatica, che facilita la creazione automatica degli host. In questo caso, la registrazione dell'agente avviene automaticamente dopo l'installazione del pacchetto dell'agente e la registrazione manuale, come descritta nel capitolo seguente, non è più necessaria.

Se utilizzi l'Agent Bakery, puoi anche impostare gli aggiornamenti automatici dell'agente. Questi aggiornamenti sono descritti in un articolo a parte.

Se durante l'installazione è stato possibile configurare l'Agent Controller con unsystemd, il passo successivo è la registrazione, che imposta la crittografia TLS in modo che l'output crittografato dell'agente possa essere decrittografato dal server Checkmk e quindi visualizzato nel monitoraggio.

C'è una particolarità quando l'agente è stato installato con l'Agent Controller per la prima volta. In questo caso l'agente passa alla modalità pull legacy non crittografata in modo che il server Checkmk non venga tagliato fuori dai dati di monitoraggio e possa continuare a visualizzarli. Questo vale sia per una nuova installazione che per un aggiornamento di un agente della versione 2.0.0 e precedenti.

Riceverai un avviso relativo alla modalità pull legacy attivata nell'output del comando durante l'installazione dell'agente. Nel monitoraggio apparirà così:

Il sito Checkmk riconosce dall'output dell'agente che l'Agent Controller è presente e quindi la crittografia TLS è possibile, ma non ancora abilitata. Il servizio Check_MK Agent passa allo stato "WARN" e rimane tale finché non lo registri. Dopo la registrazione, per la comunicazione viene utilizzata solo la modalità pull crittografata. La modalità pull legacy viene disattivata e rimarrà tale. Tuttavia, se necessario, può essere riattivata tramite comando.

La situazione è diversa se durante l'installazione non è stato possibile registrare l'Agent Controller come daemon con systemd. Senza l'Agent Controller, la registrazione non è possibile e l'unico percorso di comunicazione rimane la modalità legacy.

Nel prossimo capitolo potrai verificare se è possibile procedere con la registrazione testando l'Agent Controller e l'ambiente di sistema.

Nota: nel set di regole di Checkmk Agent installation auditing troverai varie impostazioni per controllare lo stato dell'agente e renderlo visibile nel monitoraggio. Tra le altre cose, qui puoi specificare quale stato dovrebbe avere il servizio Check_MK Agent se la configurazione TLS non è stata ancora eseguita.

Subito dopo l'installazione dell'agente (anche come aggiornamento di un agente della versione 2.0.0 e precedenti), nella modalità pull legacy è possibile solo la comunicazione non crittografata. Una trasmissione dati esclusivamente crittografata può essere attivata solo una volta stabilita una relazione di fiducia.

Fanno eccezione i pacchetti preconfigurati per la registrazione automatica e scaricati tramite Agent Bakery. Questi pacchetti eseguono la registrazione automaticamente dopo l'installazione.

In tutti gli altri casi, esegui la registrazione manuale subito dopo aver installato l'agente. Questo capitolo mostra come eseguire la registrazione.

La registrazione e quindi la creazione del rapporto di fiducia reciproco viene eseguita come utente Checkmk con accesso alla REST-API. A tal fine, una buona scelta è l'utente di automazione agent_registration, che ha solo il permesso di registrare gli agenti e viene creato automaticamente ad ogni installazione di Checkmk. Puoi generare una password di automazione casuale (automation secret) con l'icona . Devi salvare l'utente prima di poter utilizzare la nuova password.

L'agente con l'Agent Controller richiede una distribuzione Linux csystemd, più precisamente systemd nella versione 219 o successive.

È molto probabile che questo requisito sia soddisfatto sul tuo host, poiché dal 2015 la maggior parte delle distribuzioni Linux ha adottato systemd come sistema di init, sostituendo altri sistemi di init come SysVinit, ad esempio SUSE Linux Enterprise Server dalla versione 12, openSUSE dalla versione 12.1, Red Hat Enterprise Linux dalla versione 7, Fedora dalla versione 15, Debian dalla versione 8 e Ubuntu dalla versione 15.04. Purtroppo, il solo confronto del numero di versione non offre alcuna certezza, poiché systemd potrebbe mancare anche su un sistema Linux attuale se è stato "solo" aggiornato nel corso degli anni.

Oltre alla versione di systemd, devono essere soddisfatti alcuni ulteriori prerequisiti, che verranno spiegati in questo capitolo.

Attenzione: la modalità push e la registrazione automatica dipendono necessariamente dall'Agent Controller e non sono quindi utilizzabili in modalità legacy, un aspetto a cui faremo riferimento più volte in questo capitolo.

Pertanto, verifica innanzitutto sull'host su cui deve essere installato l'agente se systemd è in esecuzione e in quale versione:

L'output del comando sopra riportato mostra che è installata la versione corretta dell'systemd. Se l'systemd non è in esecuzione o è in esecuzione in una versione troppo vecchia, l'Agent Controller non può essere utilizzato. Completa la configurazione come descritto nell'articolo Monitoraggio di Linux in modalità legacy.

Ora verifica se è possibile avviare l'Agent Controller:

Il numero di versione dovrebbe essere visualizzato nell'output, ad esempio:

In rari casi, potrebbe apparire il seguente messaggio di errore:

Il motivo è che il tuo sistema Linux utilizza un'architettura di computer diversa da x86_64, ad esempio la vecchia x86 a 32 bit o ARM. In questo caso, l'Agent Controller non può essere utilizzato.

Completa la configurazione come descritto nell'articolo Monitoraggio di Linux in modalità legacy.

Il passo successivo è scoprire quale programma sta aspettando le richieste sulla porta 6556:

Eccolo qui: cmk-agent-ctl. In questo modo i requisiti per una comunicazione crittografata sono stati soddisfatti. Se invece tra le parentesi compaiono systemd, xinetd o inetd, i prerequisiti per l'utilizzo dell'Agent Controller non sono soddisfatti. In tal caso, completa comunque la configurazione come descritto nell'articolo Monitorare Linux in modalità legacy.

Per prima cosa crea il nuovo host tramite Setup > Hosts > Add host. Un host deve essere presente nell'ambiente di configurazione prima di poter essere registrato.

In Checkmk Ultimate troverai l'opzione "Checkmk agent connection mode" nelle proprietà dell'host, nella sezione dedicata agli agenti di monitoraggio. Qui puoi attivare la modalità push per l'agente Checkmk in alternativa alla modalità pull, disponibile in tutte le edizioni.

La registrazione avviene tramite l'cmk-agent-ctl dell'Agent Controller, che fornisce un'interfaccia a comando per configurare le connessioni. Puoi visualizzare la guida ai comandi con cmk-agent-ctl help, anche per specifici sottocomandi disponibili, ad esempio con cmk-agent-ctl help register.

Il fatto che l'host sia configurato per la modalità pull o push non fa alcuna differenza per gli esempi di comando. L'Agent Receiver comunica all'Agent Controller in quale modalità deve operare durante la registrazione.

Ora vai sull'host che deve essere registrato. Qui, con i privilegi di root, effettua una richiesta al sito Checkmk:

Il nome dell'host che segue l'opzione --hostname deve essere esattamente lo stesso di quando è stato creato nella configurazione. Le opzioni --server e --site specificano il nome del server Checkmk e del sito. Il nome del server può essere anche l'indirizzo IP, il nome del sito (qui mysite) corrisponde a quello che vedi nel percorso URL dell'interfaccia web. Le opzioni sono completate dal nome e dalla password utilizzati dall'utente dell'automazione. Se ometti l'opzione --password, la password ti verrà richiesta in modo interattivo.

Se i valori specificati sono corretti, ti verrà chiesto di confermare l'identità del sito Checkmk a cui vuoi collegarti. Per chiarezza, qui abbiamo abbreviato il certificato del server da confermare:

Conferma con Y per completare il processo.

Se non viene visualizzato alcun messaggio di errore, la connessione crittografata sarà stata stabilita. Tutti i dati verranno ora trasmessi in forma compressa tramite questa connessione.

Se vuoi disabilitare il controllo interattivo del certificato — ad esempio per automatizzare completamente la registrazione — puoi utilizzare il parametro aggiuntivo --trust-cert. In questo caso, il certificato trasferito verrà automaticamente considerato attendibile. Tieni presente che dovresti adottare altre misure per verificare l'integrità del certificato. Questo può essere eseguito (manualmente o tramite script) ispezionando il file /var/lib/cmk-agent/registered_connections.json.

Checkmk Ultimate offre la possibilità di creare host automaticamente al momento della registrazione. Per la registrazione automatica, oltre a un utente con l'autorizzazione a registrare host, è necessaria almeno una cartella configurata per contenere gli host da creare automaticamente.

Se queste condizioni sono soddisfatte, puoi anche eseguire la registrazione, inclusa la creazione automatica degli host, tramite la riga di comando.

Di solito si utilizza la procedura di configurazione di Agent Bakery, che include il file di configurazione /var/lib/cmk-agent/pre_configured_connections.json nel pacchetto dell'agente ed esegue la registrazione automaticamente durante l'installazione. La chiamata da riga di comando qui presentata è quindi destinata principalmente al test e al debug, ad esempio per provare le proprie etichette degli agenti con l'opzione --agent-labels <KEY=VALUE>.

La differenza principale qui è il sottocomando modificato register-new, che viene utilizzato per richiedere la registrazione e la creazione di un nuovo host nel sito Checkmk. Il nome dell'host è quello memorizzato nella variabile d'ambiente $HOSTNAME. La successiva conferma del certificato è la stessa mostrata nell'ultima sezione.

Se l'host viene creato in modalità pull, in modalità push o per niente dipende dalle tue impostazioni nel set di regole Agent registration. Dopo una registrazione riuscita, potrebbero volerci alcuni minuti prima che l'host appaia nel monitoraggio.

Il comando cmk-agent-ctl status ora mostra esattamente una relazione di fiducia con il server Checkmk:

Se hai bisogno delle informazioni in un formato leggibile dal computer, aggiungi il parametro aggiuntivo --json per ottenere l'output formattato come oggetto JSON.

Nota: può esserci solo una relazione di fiducia tra host e sito. Ad esempio, se registri un host già registrato mynewhost con un nome diverso (mynewhost2) ma con lo stesso indirizzo IP, la nuova connessione sostituirà quella esistente. La connessione da mynewhost al sito verrà interrotta e non verranno più forniti dati dell'agente all'host per il monitoraggio.

Per facilitare la registrazione di più host, qualsiasi host su cui è installato l'agente può eseguire una registrazione per conto di altri host. Il processo di registrazione esporta un file JSON, che può poi essere trasferito all'host di destinazione e importato lì. Anche in questo caso, come prima, l'host registrato nel job deve essere già configurato sul sito.

Per prima cosa, su qualsiasi host nella configurazione, la registrazione viene eseguita tramite proxy. Qui, ovviamente, il server Checkmk torna utile, poiché di solito è il primo host ad essere configurato. Come nell'esempio sopra, puoi passare la password tramite opzione o ti verrà richiesta in modo interattivo se ometti l'opzione --password. Nell'esempio reindirizziamo l'output JSON in un file:

Successivamente trasferiamo il file /tmp/mynewhost3.json sull'host che abbiamo registrato e importiamo quel file:

Questo processo è possibile anche in un unico passaggio utilizzando una pipeline in cui l'output di cmk-agent-ctl proxy-register viene passato come input a ssh hostname cmk-agent-ctl import:

Una volta completata la registrazione, esegui un test di connessione e un rilevamento dei servizi nella configurazione del server Checkmk. Quindi, come ultimo passo, includi i servizi rilevati nel monitoraggio attivando le modifiche.

Se il test di connessione fallisce, consulta il capitolo seguente per informazioni sui test e sulla risoluzione dei problemi.

Puoi anche rimuovere un host.

Su un host connesso al server Checkmk, puoi revocare l'autorizzazione. In questo caso, nel comando seguente, l'Universally Unique Identifier (UUID) da specificare è quello generato dal comando `cmk-agent-ctl status`:

Per eliminare tutte le connessioni dall'host e ripristinare inoltre la modalità pull legacy, inserisci il seguente comando:

Dopodiché, l'agente si comporta come dopo l'installazione iniziale e prima della prima registrazione e invia i suoi dati in chiaro.

Completa la cancellazione della registrazione sul server Checkmk: In "Setup", nella pagina "Properties of host", seleziona la voce di menu "Host > Remove TLS registration" e conferma la richiesta.

Se preferisci la riga di comando: Sul server Checkmk, per ogni connessione di un host in monitoraggio, c'è un collegamento simbolico con l'UUID che punta alla cartella con l'output dell'agente:

In Checkmk Ultimate puoi passare dalla modalità push a quella pull e viceversa per gli host. Questo potrebbe essere necessario in casi specifici se sono in corso modifiche alla topologia di rete o se si deve effettuare un downgrade a Checkmk Pro , dove è possibile solo la modalità pull.

Per prima cosa specifica la modalità di accesso in Setup, nelle proprietà dell’host, con l’opzione Checkmk agent connection mode. Entro un minuto, tutti i servizi assumeranno lo stato UNKNOWN poiché non vengono ricevuti dati di monitoraggio. Quindi esegui una nuova registrazione. Durante questa nuova registrazione, l’Agent Receiver del server Checkmk comunica all’Agent Controller se si aspettano dati in modalità pull o push. Un controllo successivo utilizzando cmk-agent-ctl status mostrerà quindi un nuovo UUID e una modalità coerente con la modifica apportata nel Setup.

Lo script dell'agente è un semplice script di shell che ottiene dati dal tuo sistema e li visualizza come testo in formato libero. Puoi richiamare questo script direttamente dalla riga di comando. Dato che l'output può essere un po' lungo, l'opzione less per scorrere l'output è molto utile in questo caso. Puoi uscire con il tasto Q:

Questo ti permette di verificare se lo script dell'agente, i tuoi plug-in e i controlli locali sono installati correttamente.

A proposito, non è necessario essere un amministratore per richiamare l'agente. Tuttavia, l'output risulterà privo di alcune informazioni che richiedono i privilegi d'amministratore per essere ottenute (ad es. informazioni sui percorsi multipli e gli output di ethtool).

Per evitare che eventuali messaggi di errore provenienti da plug-in o comandi inattivi "contaminino" i dati richiesti, lo script dell'agente in genere sopprime il canale di errore standard (STDERR). Se stai cercando un problema specifico, puoi riattivare lo STDERR richiamando lo script dell'agente in una speciale modalità di debug.

Prima di farlo, dovresti verificare se lo script dell'agente e l'Agent Controller in modalità dump forniscono un output identico e, se necessario, assicurarti che l'ambiente sia identico. Questo può essere fatto impostando delle variabili in un controllo plug-in/locale o nella shell. Puoi creare un dump dell'ambiente aggiungendo la riga

a un file di plug-in e controllando poi il contenuto del file dopo l'esecuzione da parte dell'Agent Controller.

Le informazioni di debug aggiuntive vengono quindi visualizzate utilizzando l'opzione "-d". Verranno visualizzati anche tutti i comandi della shell eseguiti dallo script. Per poter lavorare con "less" in questo caso, devi combinare l'output standard (STDOUT) e il canale di errore con "2>&1":

Se la registrazione di un host fallisce prima ancora che venga presentato un certificato, conoscere le modalità di comunicazione può aiutare a identificare il problema — e, ovviamente, a risolverlo.

Dopo aver inserito il comando cmk-agent-ctl register, l'Agent Controller chiede innanzitutto al server Checkmk la porta dell'Agent Receiver utilizzando l'API REST. Come secondo passo viene stabilita una connessione con l'Agent Receiver per richiedere il certificato. Puoi simulare la prima richiesta sull'host con un programma come curl:

Il parametro --insecure indica a curl di saltare il controllo del certificato. Questo comportamento rispecchia quello dell'Agent Controller in questa fase. La risposta è di pochi byte e contiene il numero di porta dell'Agent Receiver. Per il primo sito di solito è semplicemente 8000, per il secondo 8001 e così via.

I problemi più comuni relativi a questa richiesta sono:

Se la richiesta sopra indicata fallisce, potresti modificare le impostazioni di routing o del firewall per abilitare l'accesso.

Nel caso in cui l'host che stai cercando di registrare utilizzi un proxy HTTP, curl lo utilizzerà, ma cmk-agent-ctl non lo farà con le impostazioni predefinite. Utilizza l'opzione aggiuntiva --detect-proxy per indicare a cmk-agent-ctl di utilizzare un proxy configurato tramite le impostazioni di sistema.

Tuttavia, spesso può essere più semplice scoprire la porta dell'Agent Receiver e prenderne nota. Per farlo, sul server Checkmk, dopo aver effettuato l'accesso come utente del sito:

Ora puoi specificare la porta quando inserisci il comando per la registrazione. Questo salta la prima richiesta all'API REST. La comunicazione avviene quindi direttamente con l'Agent Receiver senza deviazioni:

Anche la porta 8000 deve essere raggiungibile dall'host. Se non lo è, riceverai questo messaggio di errore:

Equivalente alla porta 443 (rispettivamente 80) menzionata sopra, ora puoi modificare le impostazioni di routing o del firewall in modo che l'host da registrare possa raggiungere il server Checkmk sulla porta dell'Agent Receiver (8000 o 8001…​)

Nel caso di una registrazione in modalità push vale quanto segue: Se la registrazione ha funzionato, anche il trasferimento minuto per minuto dell'output dell'agente avrà esito positivo.

Se le politiche di sicurezza nel tuo ambiente non consentono l'accesso all'Agent Receiver, c'è comunque la possibilità di utilizzare la registrazione tramite proxy sul server Checkmk.

L'Agent Controller fornisce un proprio sottocomando dump che visualizza l'output completo dell'agente non appena arriva nel monitoraggio:

Questo ti permette di verificare che i dati provenienti dallo script dell'agente siano arrivati all'Agent Controller. Questo output non dimostra ancora che l'agente sia accessibile anche tramite la rete.

In alcuni casi, l'output avrà questo aspetto:

Questo accade quando il socket dell'agente non è in esecuzione in background, ad esempio subito dopo un aggiornamento. Riavvia questo processo in background:

Se l'cmk-agent-ctl dumpe fallisce di nuovo, controlla se e quale programma sta ascoltando sulla porta 6556:

Se l'output è vuoto o se tra le parentesi è presente un comando diverso da cmk-agent-ctl, i requisiti di sistema per l'utilizzo dell'Agent Controller non sono stati soddisfatti. In questo caso, completa la configurazione come descritto nell'articolo Monitorare Linux in modalità legacy.

Se in modalità pull è stato verificato che lo script dell'agente e i suoi plug-in installati vengono eseguiti correttamente, puoi quindi controllare tramite netcat (o nc) se la porta 6556 è raggiungibile tramite l'indirizzo IP esterno dell'host:

L'output 16 indica che la connessione è stata stabilita con successo e che ora può avvenire l'handshake TLS. Poiché tutto il resto qui è crittografato con TLS, non è possibile effettuare ulteriori verifiche dettagliate.

Se un test di connessione remota fallisce, di solito è dovuto alle impostazioni del firewall. In questo caso, configura iptables o nftables per consentire l'accesso alla porta TCP 6556 dal server Checkmk.

Se la comunicazione tra l'agente e il server Checkmk è ancora non crittografata (come nella modalità pull legacy), o è e rimarrà non crittografata (come nella modalità legacy), questo comando ti fornirà l'output completo non crittografato dell'agente invece dell'16.

Nota: per ulteriori diagnostiche da eseguire sul server Checkmk, consulta l'articolo generale sugli agenti di monitoraggio.

Nella cartella ~/var/agent-receiver/received-outputs/ del tuo sito Checkmk, per ogni host registrato troverai un collegamento simbolico che utilizza l'UUID dell'host come nome. Per gli host in modalità push questo collegamento simbolico punta alla cartella con l'output dell'agente, per gli host in modalità pull punta a un file inesistente con il nome dell'host utilizzato nel monitoraggio.

In base all’età dell’output dell’agente memorizzato nella cache, puoi determinare se la trasmissione regolare ha avuto successo o se è stata interrotta, ad esempio, da problemi di rete sporadici.

Inoltre, puoi visualizzare lo stato delle ultime trasmissioni e dei tentativi di trasmissione sull'host con il comando systemctl status cmk-agent-ctl-daemon. Righe come le seguenti indicano problemi di connessione:

Se un host è stato configurato per la registrazione automatica con il set di regole Agent controller auto-registration e l'opzione Keep existing connections è impostata su no, ogni volta che il servizio cmk-agent-ctl-daemon viene riavviato (ad esempio, quando un host viene riavviato), tutte le altre connessioni verranno rimosse, tranne quella configurata per la registrazione automatica. Questo riguarda, ad esempio, gli host in cui sono state configurate connessioni a più siti prima dell'installazione del pacchetto dell'agente precompilato, oppure in cui le connessioni sono state aggiunte manualmente dopo l'installazione del pacchetto dell'agente.

Puoi ignorare temporaneamente questo comportamento impostando la variabile keep_existing_connections su true nel file C:\ProgramData\checkmk\agent\pre_configured_connections.json sull'host. Puoi ottenere una modifica permanente con l'aggiornamento del pacchetto dell'agente impostando Keep existing connections su yes nel set di regole sopra indicato.

Quando si registra automaticamente un host, in genere passano circa due minuti prima che l'host appaia nel monitoraggio.

Se successivamente è stata aggiunta una connessione in modalità pull verso un altro sito a un host inizialmente configurato per la modalità push, trascorreranno fino a cinque minuti prima che la porta 6556 venga aperta. Puoi aprire la porta immediatamente riavviando il servizio cmk-agent-ctl-daemon.

La sicurezza è un criterio importante per qualsiasi software, e il monitoraggio non fa eccezione. Dato che l'agente di monitoraggio è installato su ogni server monitorato, un problema di sicurezza in questo caso avrebbe conseguenze particolarmente gravi.

Ecco perché la sicurezza è stata messa in primo piano nella progettazione di Checkmk ed è stata un principio fondamentale fin dai primi giorni di Checkmk: l'agente non legge i dati dalla rete. Punto. Questo significa che è impossibile per un hacker inserire comandi o parti di script tramite la porta di monitoraggio 6556.

Per un hacker, tuttavia, anche un semplice elenco di processi può essere un primo indizio per individuare obiettivi interessanti. Pertanto, la crittografia del trasporto tra l'agente e il server Checkmk con Transport Layer Security (TLS) è obbligatoria a partire dalla versione 2.1.0 di Checkmk. In questo caso, il server Checkmk invia un "ping" all'host monitorato, che quindi stabilisce la connessione TLS con il server Checkmk e trasmette l'output dell'agente attraverso di essa. Poiché solo i server Checkmk con cui esiste un rapporto di fiducia possono avviare questo trasferimento di dati, non c'è alcun rischio che i dati finiscano nelle mani sbagliate.

Per proteggere la connessione TLS, Checkmk utilizza un certificato autofirmato che viene sostituito automaticamente poco prima della scadenza della sua validità. L'Agent Controller si occupa di rinnovare il certificato in tempo prima della scadenza. Solo gli agenti che sono rimasti inattivi per un periodo di tempo prolungato, ovvero senza un Agent Controller in esecuzione, possono perdere la loro registrazione alla scadenza e devono quindi essere registrati nuovamente. La durata del certificato può essere specificata tramite l'impostazione globale Agent Certificates > Lifetime of certificates.

Poiché solo i server Checkmk autorizzati possono recuperare i dati e i server non autorizzati falliscono dopo pochi byte di handshake, il rischio di un attacco Denial of Service (DoS) è molto basso. Per questo motivo, al momento non sono previste ulteriori restrizioni di accesso. Naturalmente puoi bloccare la porta 6556 contro accessi non autorizzati tramite iptables. Qualsiasi regola esistente e trasferita ai client tramite l'Agent Bakery per limitare l'accesso a determinati indirizzi IP viene ignorata dall'Agent Controller.

Soprattutto durante l'aggiornamento dell'agente, può capitare che sia attiva la crittografia integrata (simmetrica), eseguita dallo script dell'agente stesso. Se la crittografia TLS e quella integrata sono attive contemporaneamente, l'entropia dei dati trasmessi è così elevata che la compressione, attiva a partire dalla versione 2.1.0, non salverà alcun dato trasmesso — e graverà sulle CPU sia dell'host che del server Checkmk con ulteriori processi di crittografia e decrittografia.

Per questo motivo, dovresti disattivare la crittografia integrata subito dopo il passaggio a TLS.

Come primo passo, disattiva la crittografia nella regola esistente in Setup > Agents > Access to agents > Checkmk agent > Symmetric encryption (Linux, Windows).

Come secondo passo, rinomina il file di configurazione /etc/check_mk/encryption.cfg sull'host dell'agente.

Come terzo e ultimo passo, usa la regola "Enforce agent data encryption" per specificare che il server Checkmk accetti solo dati crittografati tramite TLS. Per farlo, seleziona il valore "Accept TLS encrypted connections only" nella regola.

Disattivare la crittografia con Agent Bakery funziona così: Con il primo passo, ovvero modificare la regola Symmetric encryption (Linux, Windows), hai quasi finito. Devi solo creare i pacchetti e distribuire i nuovi agenti. Il file di configurazione /etc/check_mk/encryption.cfg verrà modificato automaticamente per te e incluso nei pacchetti degli agenti. Rimane solo il terzo passo, ovvero modificare la regola Enforce agent data encryption.

Dopo il prossimo aggiornamento automatico dell'agente, la crittografia dello script dell'agente verrà disabilitata, ma la crittografia sarà garantita dall'Agent Controller. Tieni presente che dopo l'aggiornamento automatico dell'agente, solo gli host registrati potranno fornire dati di monitoraggio.

Lo script dell'agente /usr/bin/check_mk_agent contiene un'intera serie di sezioni che forniscono dati di monitoraggio per vari plug-in di controllo, che vengono poi individuati automaticamente dal servizio di rilevamento. Questo include tutto il monitoraggio importante per il sistema operativo.

Inoltre, c'è la possibilità di estendere l'agente con i plug-in dell'agente. Si tratta di piccoli script o programmi che vengono chiamati dall'agente e lo estendono con sezioni aggiuntive contenenti ulteriori dati di monitoraggio. Il progetto Checkmk fornisce un'intera serie di tali plug-in che, se correttamente installati e configurati, forniscono automaticamente nuovi servizi tramite il service discovery.

Perché questi plug-in non sono semplicemente hard-coded nell'agente? Per ciascuno dei plug-in ci sarà uno dei seguenti motivi:

I plug-in inclusi in Linux e Unix si trovano tutti nella pagina di download degli agenti nel menu Setup (come descritto nel capitolo sull'installazione) nella casella Plugins:

Per tutti i plug-in degli agenti che forniamo, ci sono plug-in di controllo corrispondenti in grado di valutare i dati dell’agente e creare servizi. Questi sono già installati, in modo che i servizi appena trovati possano essere rilevati e configurati immediatamente.

Nota: prima di installare un plug-in su un host, dai un'occhiata al file corrispondente. Spesso lì troverai informazioni importanti sull'uso corretto del plug-in.

L'installazione vera e propria è poi semplice: Copia il file in /usr/lib/check_mk_agent/plugins. Assicurati che sia eseguibile. Se non lo è, usa un chmod 755, altrimenti l'agente non eseguirà il plug-in. Tieni presente che, specialmente se non trasferisci i file tramite scp ma li scarichi via HTTP dalla pagina di download, il permesso di esecuzione andrà perso.

Una volta che il plug-in è eseguibile e si trova nella directory corretta, verrà automaticamente richiamato dall'agente e verrà creata una nuova sezione nell'output dell'agente. Questa sezione di solito ha lo stesso nome del plug-in. I plug-in complessi, come ad esempio mk_oracle, creano addirittura un'intera serie di nuove sezioni.

Alcuni plug-in richiedono un file di configurazione in /etc/check_mk/ per funzionare. Per altri, la configurazione è facoltativa e consente di attivare funzionalità speciali o personalizzazioni. Altri ancora funzionano semplicemente così come sono. Esistono diverse fonti di informazioni su un plug-in:

I plug-in degli agenti vengono solitamente eseguiti in sequenza. In alternativa, puoi far eseguire i plug-in in modo asincrono. Questo è molto utile se i plug-in hanno un tempo di esecuzione lungo e i dati di stato raccolti non devono comunque essere rigenerati ogni minuto.

L'esecuzione asincrona non viene configurata tramite un file, ma creando una sottodirectory all'interno di /usr/lib/check_mk_agent/plugins il cui nome è un numero: un numero di secondi. I plug-in in questa directory non solo vengono eseguiti in modo asincrono, ma allo stesso tempo puoi specificare un tempo di attesa minimo in secondi prima che il plug-in venga eseguito di nuovo. Se l'agente viene interrogato di nuovo prima che scada il tempo, utilizza i dati memorizzati nella cache dall'ultima volta che il plug-in è stato eseguito. Questo ti permette di configurare un intervallo più lungo per il plug-in rispetto al tipico minuto.

L'esempio seguente mostra come modificare il plug-in my_foo_plugin da esecuzione sincrona a esecuzione asincrona con un intervallo di 5 minuti (o 300 secondi):

Nota: alcuni plug-in implementano automaticamente l'esecuzione asincrona. Tra questi c'è mk_oracle. Installa questi plug-in direttamente su /usr/lib/check_mk_agent/plugins.

Nelle edizioni commerciali, i plug-in inclusi possono essere configurati tramite Agent Bakery. Questo si occupa sia dell'installazione del plug-in vero e proprio, sia della corretta creazione del suo file di configurazione, qualora fosse necessario.

Ogni plug-in viene configurato tramite una regola dell'agente. Puoi trovare i set di regole appropriati in Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Agent Plugins:

Poiché i plug-in dell'agente sono programmi eseguibili, puoi anche eseguirli manualmente a scopo di test e diagnostica. Tuttavia, ci sono plug-in che richiedono determinate variabili d'ambiente impostate dall'agente per trovare il proprio file di configurazione, ad esempio. Imposta queste variabili manualmente prima dell'esecuzione:

Alcuni plug-in utilizzano anche opzioni di chiamata speciali per il debug. Basta dare un'occhiata al file del plug-in.

Ci sono due buoni motivi per continuare a usare i plug-in Nagios su Checkmk. Se hai migrato il tuo monitoraggio da una soluzione basata su Nagios a Checkmk, puoi continuare a usare i vecchi plug-in di controllo per i quali non esiste ancora un equivalente in Checkmk. In molti casi si tratta di plug-in scritti in proprio in Perl o shell.

Il secondo motivo è il vero monitoraggio end-to-end. Supponiamo che tu abbia il tuo server Checkmk, un server web e un server database distribuiti in un grande data center. In questo caso, i tempi di risposta del server database misurati dal server Checkmk non sono molto significativi. È molto più importante conoscere questi valori per la connessione tra il server web e il server database.

L'agente Checkmk fornisce un meccanismo semplice per soddisfare questi due requisiti: il Remote Plugin Executor di Checkmk, o MRPE in breve. Il nome è volutamente un'analogia con l'NRPE di Nagios, che svolge lo stesso compito in quel contesto.

L'MRPE è integrato nell'agente e si configura con un semplice file di testo, che crei come /etc/check_mk/mrpe.cfg. Lì specifichi una chiamata al plug-in per riga, insieme al nome che vuoi che Checkmk usi per il servizio che crea automaticamente per esso. Ecco un esempio:

Nota: i plugin di Nagios non possono essere inseriti nella directory /usr/lib/check_mk_agent/plugins. Questa directory è riservata ai plugin dell'agente. A parte questa directory, sei libero di scegliere dove metterli, purché l'agente riesca a trovarli ed eseguirli.

Se ora esegui l'agente localmente, troverai una nuova sezione per ogni plugin chiamata <<mrpe>> che contiene il nome, il codice di uscita e l'output del plugin. Puoi verificarlo con il seguente pratico comando grep:

I valori 0 e 1 nell'output rappresentano i codici di uscita dei plug-in e seguono lo schema convenzionale: 0 = OK, 1 = WARN, 2 = CRIT e 3 = UNKNOWN.

Il resto verrà ora eseguito automaticamente da Checkmk. Una volta avviata la ricerca dei servizi per l'host, i due nuovi servizi appariranno come disponibili. Avrà questo aspetto:

A proposito, a causa della sintassi del file, il nome non può contenere spazi. Tuttavia, puoi sostituire uno spazio con %20 utilizzando la stessa sintassi degli URL (il codice ASCII 32 per lo spazio è 20 in esadecimale):

Tieni presente che tutti i plug-in elencati in mrpe.cfg verranno eseguiti in modo sincrono in ordine. Per questo motivo, i plug-in non dovrebbero avere un tempo di esecuzione troppo lungo. Se un plug-in richiede troppo tempo, l'esecuzione di tutti gli altri verrà ritardata. Ciò può portare al timeout dell'esecuzione completa dello script dell'agente e impedire il monitoraggio affidabile dell'host.

Se hai davvero bisogno di plug-in che richiedono più tempo, dovresti impostarli in esecuzione asincrona come per i normali plug-in dell'agente, evitando così tali problemi. Questo si ottiene specificando un tempo in secondi durante il quale un risultato calcolato deve rimanere valido. Per configurare un timeout di cinque minuti, imposta l'espressione (interval=300) dopo il nome del servizio in mrpe.cfg:

Questa funzionalità offre diversi vantaggi:

Questo ti permette quindi di eseguire test che richiedono un po' più di tempo di elaborazione e intervalli più lunghi, senza dover configurare nulla sul server Checkmk.

Gli utenti delle edizioni commerciali possono anche configurare MRPE con Agent Bakery. A questo serve il set di regole "Setup > Agents > Windows, Linux Solaris, AIX > Agent Rules > Generic Options > Execute MRPE checks". Lì puoi configurare le stesse cose descritte sopra. Il file "mrpe.cfg" verrà poi generato automaticamente da Agent Bakery.

I dischi rigidi moderni dispongono quasi sempre della tecnologia S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology). Questo sistema registra continuamente i dati relativi allo stato dell'HDD o dell'SSD e Checkmk può recuperare questi valori con il plug-in smart e valutarne i più importanti. Affinché il plug-in funzioni dopo l'installazione, devono essere soddisfatti i seguenti requisiti:

Se questi requisiti sono soddisfatti e il plug-in è installato, i dati vengono recuperati automaticamente e aggiunti all'output dell'agente. In Checkmk puoi quindi attivare direttamente anche i nuovi servizi:

Come si vede nella schermata, se cmd_timeout si verifica occasionalmente, imposta il plug-in su esecuzione asincrona a intervalli di pochi minuti.

IPMI (Intelligent Platform Management Interface) è un'interfaccia per la gestione dell'hardware che consente anche il monitoraggio dell'hardware. Checkmk utilizza freeipmi a questo scopo per accedere all'hardware direttamente e senza rete. freeipmi viene installato dai repository dei pacchetti ed è quindi pronto per l'uso immediato, in modo che i dati vengano trasmessi già alla successiva chiamata di Checkmk.

Se l'freeipmi non è disponibile o se ci sono altri motivi per non installarlo, è possibile utilizzare anche ipmitool. ipmitool è spesso già presente sul sistema e deve solo essere fornito di un driver per dispositivi IPMI, come quello fornito dal pacchetto openipmi. Anche in questo caso, non devi fare nient'altro dopo l'installazione e i dati verranno raccolti automaticamente da Checkmk.

Per la diagnosi degli errori puoi anche eseguire gli strumenti manualmente in una shell host. Una volta installato il pacchetto freeipmi, puoi verificarne le funzioni con questo comando:

Se ipmitool è stato installato, puoi controllare l'output dei suoi dati con il seguente comando:

Molti grandi produttori di server forniscono anche i propri strumenti per raccogliere le informazioni sull'hardware e renderle disponibili tramite SNMP. Per recuperare questi dati e fornirli a Checkmk, devono essere soddisfatti i seguenti prerequisiti:

I nuovi servizi per il monitoraggio hardware supportati da questo vengono quindi rilevati automaticamente e non sono necessari ulteriori plug-in.

È possibile configurare una scheda di gestione per ogni host e recuperare dati aggiuntivi tramite SNMP. I servizi rilevati in questo modo vengono quindi assegnati anche all’host.

Configurare la scheda di gestione è molto semplice. Basta inserire il protocollo, l'indirizzo IP e i dati di accesso per SNMP nelle proprietà dell'host e salvare queste nuove impostazioni:

Con un rilevamento dei servizi, i servizi appena rilevati verranno poi abilitati come di consueto.

Quando l'agente viene disinstallato, l'utente cmk-agent creato dallo script di installazione verrà mantenuto. Questo serve come indicatore per lo script post-installazione che l'agente era già installato su questo sistema. In questo caso, la modalità pull legacy non verrà attivata durante una successiva reinstallazione. Di conseguenza, dopo aver eseguito cmk-agent-ctl delete-all e aver successivamente reinstallato l'agente, non sarà possibile alcuna connessione sulla porta 6556.

Se desideri riattivare la modalità pull legacy non crittografata, dovrai abilitare esplicitamente questa modalità.