Monitoraggio di Linux

L'installazione dell'agente Linux avviene tramite un pacchetto RPM o DEB. La necessità di un pacchetto RPM o DEB dipende dalla distribuzione Linux su cui vuoi installare il pacchetto:

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

Dopo aver recuperato il pacchetto RPM o DEB e, se necessario, averlo copiato sull'host da monitorare utilizzando scp, WinSCP o altri mezzi, l'installazione avviene con un solo 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 usare questo comando per aggiornare un agente esistente alla versione attuale e usare lo stesso comando per gli aggiornamenti futuri dell'agente.

L'installazione del pacchetto DEB e l'aggiornamento vengono eseguiti dall'utente root con il comando dpkg -i:

In questo caso il pacchetto è stato installato per la prima volta su un host precedentemente privo di agent. È stato creato l'utente cmk-agent ed è stato configurato systemd. Tra poco affronteremo l'avviso provvisorio relativo a insecure mode, ovvero la modalità legacy pull.

Le edizioni commerciali dispongono di un modulo software, l'Agent bakery, che consente di confezionare automaticamente agenti personalizzati. Una descrizione dettagliata di questo modulo si trova nell'articolo generale sugli agenti. L'installazione dei pacchetti Baked avviene nello stesso modo descritto sopra per i pacchetti inclusi.

A partire da Checkmk Cloud è possibile utilizzare l'Agent bakery anche per fornire pacchetti di agenti con 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 e la registrazione manuale, descritta nel capitolo successivo, non è più necessaria.

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

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

Esiste una funzione speciale quando l'agent è stato installato per la prima volta con l'Agent Controller: l'agente switcha alla modalità legacy pull non crittografata in modo che il server Checkmk non sia tagliato fuori dai dati di monitoraggio e possa continuare a visualizzarli. Questo vale sia per una nuova installazione che per l'aggiornamento dell'agente della versione 2.0.0 e precedenti.

Riceverai un avviso della modalità legacy pull attivata nell'output del comando durante l'installazione dell'agente. L'aspetto sarà il seguente nel monitoraggio:

L'istanza Checkmk riconosce dall'output dell'agente che l'Agent Controller è presente e che quindi la crittografia TLS è possibile, ma non ancora abilitata. Il servizio Check_MK Agent passa allo stato WARN e rimane tale fino a quando non viene registrato. Dopo la registrazione, per la comunicazione viene utilizzata solo la modalità legacy pull. La modalità legacy pull è disattivata e rimarrà tale. Tuttavia, se necessario, può essere attivata nuovamente tramite comando.

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

Nel prossimo capitolo, potrai determinare se puoi procedere con la registrazione testando l'Agent Controller e l'ambiente di sistema.

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

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

Fanno eccezione i pacchetti preconfigurati per la registrazione automatica e scaricati tramite l'agent bakery: questi pacchetti eseguono la registrazione automaticamente dopo l'installazione.

In tutti gli altri casi, devi eseguire la registrazione manuale subito dopo l'installazione dell'agente. Questo capitolo mostra come eseguire la registrazione.

La registrazione e quindi l'instaurazione della relazione di fiducia reciproca viene eseguita da un utente Checkmk con accesso all'API REST. Per questo, una buona scelta è l'utente automazione agent_registration che ha solo il permesso di registrare gli agenti e viene creato automaticamente ad ogni installazione di Checkmk. Puoi randomizzare la password di automazione corrispondente(password di automazione) con il simbolo.

Crea il nuovo host tramite Setup > Hosts > Add host.Un host deve esistere nell'ambiente di configurazione prima di poter essere registrato.

A partire da Checkmk Cloud 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.

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

È 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 es. 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 dà certezze, poiché systemd potrebbe mancare anche in un sistema Linux attuale se è stato "solo" aggiornato nel corso degli anni.

Oltre alla versione di systemd, devono essere soddisfatti altri 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, cosa a cui faremo riferimento più volte in questo capitolo.

Per questo motivo, prima di tutto controlla che sull'host su cui deve essere installato l'agente sia in esecuzione systemd e in quale versione:

L'output del comando qui sopra mostra che systemd è installato nella versione corretta. Se systemd non è in esecuzione o lo è 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 controlla se l'Agent Controller può essere avviato:

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

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

Il motivo è che Linux utilizza un'architettura 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 è quello di scoprire quale programma è in attesa di richieste sulla porta 6556:

In questo caso si tratta di cmk-agent-ctl. In questo modo i requisiti per una comunicazione criptata sono soddisfatti. Se invece systemd, xinetd o inetd sono tra le parentesi, i prerequisiti per l'utilizzo dell'Agent Controller non sono soddisfatti. In questo caso, completa anche la configurazione come descritto nell'articolo Monitorare Linux in modalità legacy.

La registrazione avviene tramite l'Agent Controller cmk-agent-ctl, che fornisce un'interfaccia di comando per la configurazione delle connessioni. Puoi visualizzare la guida ai comandi con cmk-agent-ctl help, anche per i sottocomandi specifici 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 dice all'Agent Controller in quale modalità deve operare durante la registrazione.

Ora vai all'host che deve essere registrato e, con i privilegi di root, fai una richiesta all'istanza Checkmk:

Il nome dell'host che segue l'opzione --hostname deve essere esattamente lo stesso che è stato creato nel Setup. Le opzioni --server e --site specificano il nome dell'istanza Checkmk e del sito. Il nome del server può anche essere l'indirizzo IP, mentre 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'istanza web. Se ometti l'opzione --password, la password verrà richiesta in modo interattivo.

Se i valori specificati sono corretti, ti verrà chiesto di confermare l'identità dell'istanza Checkmk a cui vuoi connetterti. 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 criptata è stata stabilita. Tutti i dati saranno ora trasmessi in modulo compresso attraverso 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 sarà automaticamente 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.

A partire da Checkmk Cloud, Checkmk offre la possibilità di creare automaticamente gli host al momento della registrazione. Per la registrazione automatica, oltre a un utente con il permesso di registrare gli host, è necessaria almeno una cartella configurata per contenere gli host da creare automaticamente.

Se queste condizioni sono soddisfatte, puoi effettuare la registrazione e la creazione automatica degli host anche tramite la linea di comando.

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

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

Il fatto che l'host venga creato in modalità pull, push o non venga creato affatto è definito dalle tue impostazioni nel set di regole Agent registration. Dopo una registrazione andata a buon fine, potrebbero essere necessari alcuni minuti prima che l'host venga visualizzato nel monitoraggio.

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

Se le informazioni sono necessarie in formato leggibile, aggiungi il parametro aggiuntivo --json per recuperare l'output formattato come oggetto JSON.

Nota: può esserci sempre e 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 sarà scollegata e non saranno più forniti dati dell'agente di monitoraggio all'host!

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ò essere trasferito all'host di destinazione e importato. Anche in questo caso, come in precedenza, l'host registrato nel lavoro deve essere già configurato sul sito.

Per prima cosa, su qualsiasi host presente nel Setup, la registrazione viene eseguita tramite proxy. In questo caso, ovviamente, il server Checkmk si rivela utile, dato che di solito è il primo host ad essere configurato. Come nell'esempio precedente, puoi passare la password tramite un'opzione o chiederla in modo interattivo se ometti l'opzione --password. Nell'esempio reindirizziamo l'output JSON a un file:

Successivamente trasferiamo il file /tmp/mynewhost3.json all'host per il quale ci siamo registrati e lo importiamo:

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

Una volta completata la registrazione, esegui un test di connessione e una ricerca di servizi nel Setup del server Checkmk. Quindi, come ultimo passo, includi i servizi scoperti 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 cancellare la registrazione di un host.

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

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

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

Completa la deregistrazione sul server Checkmk: nel menu di configurazione, alla pagina Properties of host, seleziona la voce di menu Host > Remove TLS registration e conferma il prompt.

Se preferisci la linea di comando: sul server Checkmk, per ogni connessione di un host in monitoraggio, c'è un soft link con l'UUID che punta alla cartella con l'output dell'agente:

A partire da Checkmk Cloud puoi switchare gli host dalla modalità push a quella pull e viceversa. Questo può essere necessario in singoli casi se sono in sospeso modifiche alla topologia della rete o se si deve effettuare un downgrade a Checkmk Enterprise, in cui è possibile solo la modalità pull.

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

Lo script agente è un semplice script di shell che ottiene i dati sul sistema e li restituisce sotto forma di testo non formattato. Puoi richiamare questo script direttamente dalla linea di comando. Poiché l'output può essere un po' lungo, l'opzione less per scorrere l'output è molto utile. Puoi uscire con il tasto Q:

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

A proposito, non è necessario essere root per chiamare l'agente. Tuttavia, l'output mancherà di alcune informazioni che richiedono i privilegi di root per essere ottenute (es. le informazioni sul multipath e gli output di ethtool).

Per evitare che l'output di errore di plug-in o comandi inattivi "contamini" i dati richiesti, lo script agent generalmente sopprime il canale di errore standard (STDERR). Se stai cercando un problema specifico, puoi riattivare STDERR chiamando lo script agent in una speciale modalità di debug.

Prima di tutto, devi verificare che lo script agente e l'Agent Controller in modalità dump forniscano un output identico e, se necessario, garantire un ambiente identico. Questo può essere fatto impostando delle variabili d'ambiente in un plug-in dell'agente o nel check locale o nella shell. Puoi creare un dump dell'ambiente aggiungendo la riga

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

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

Se la registrazione di un host fallisce anche prima della presentazione di un certificato, la conoscenza delle modalità di comunicazione può aiutare a identificare il problema e, naturalmente, a risolverlo.

Dopo aver inserito il comando cmk-agent-ctl register, l'Agent Controller chiede 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 riflette il comportamento dell'Agent Controller in questa fase. La risposta è costituita da pochi byte, contenenti il numero di porta dell'Agent Receiver. Per il primo sito di solito è solo 8000, per il secondo 8001 e così via. I problemi più comuni relativi a questa richiesta sono:

Quando il comando curl fallisce, potresti modificare le impostazioni del routing o del firewall per consentire l'accesso.

Se l'host che stai cercando di registrare utilizza un proxy HTTP, curl lo utilizzerà, ma cmk-agent-ctl non lo farà con le configurazioni 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 annotarla. Per farlo, esegui il login sul server Checkmk come utente dell'istanza Checkmk:

Ora puoi specificare la porta quando inserisci il comando per la registrazione. In questo modo salti la prima richiesta all'API REST e la comunicazione avviene direttamente con l'Agent Receiver senza alcuna deviazione:

Anche la porta 8000 deve essere raggiungibile dall'host. In caso contrario, riceverai questo messaggio di errore:

Equivalente alla porta 443 (o 80) di cui sopra, puoi ora regolare le impostazioni del 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à successo.

Se le policy di sicurezza vietano l'accesso all'Agent Receiver, esiste la possibilità di utilizzare la registrazione tramite proxy sul server Checkmk.

L'Agent Controller dispone del sottocomando dump che visualizza l'intero output dell'agente nel momento in cui arriva al monitoraggio:

Questo permette di verificare che i dati dello script agente siano arrivati all'Agent Controller. Questo output non dimostra ancora che l'agente sia accessibile in rete.

In alcuni casi, l'output sarà simile a questo:

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

Se cmk-agent-ctl dump fallisce di nuovo, controlla se e quale programma è in ascolto sulla porta 6556:

Se l'output è vuoto o tra le parentesi c'è 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 plug-in dell'agente installati vengono eseguiti correttamente, puoi verificare 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 l'handshake TLS può avere luogo. Poiché tutto il resto è criptato TLS, non è possibile effettuare un controllo più dettagliato.

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 del server Checkmk.

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

Nota: per ulteriori diagnosi da eseguire sul server Checkmk, consulta l'articolo generale sul monitoraggio degli agenti.

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

In base all'età dell'output dell'agente nella cache, puoi determinare se la trasmissione regolare è andata a buon fine o se è stata interrotta, ad esempio, da problemi di rete sporadici.

Inoltre, con il comando systemctl status cmk-agent-ctl-daemon puoi visualizzare lo stato delle ultime trasmissioni e dei tentativi di trasmissione sull'host. Linee come la seguente 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 viene riavviato un host), tutte le altre connessioni verranno rimosse, ad eccezione di quella configurata per la registrazione automatica. Questo riguarda, ad esempio, gli host in cui le connessioni a più siti sono state impostate prima dell'installazione del pacchetto Baked agent, oppure le connessioni sono state aggiunte manualmente dopo l'installazione del pacchetto agent.

Puoi annullare temporaneamente questo comportamento impostando la variabile keep_existing_connections a true nel file C:\ProgramData\checkmk\agent\pre_configured_connections.json dell'host. Puoi ottenere una modifica permanente durante l'aggiornamento dell'agente impostando Keep existing connections a yes nel set di regole di cui sopra.

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

Se una connessione in modalità pull a un altro sito è stata aggiunta successivamente a un host inizialmente configurato in modalità push, passeranno fino a cinque minuti prima che venga aperta la porta 6556. 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. Poiché l'agente di monitoraggio è installato su ogni server monitorato, un problema di sicurezza avrebbe conseguenze particolarmente gravi.

Per questo motivo la sicurezza è stata enfatizzata nella progettazione di Checkmk ed è stata un principio assoluto fin dai primi giorni di Checkmk:l'agente non legge i dati dalla rete. Questosignifica che è impossibile per un utente malintenzionato iniettare comandi o componenti di script attraverso la porta di monitoraggio 6556.

Per un aggressore, tuttavia, anche un elenco di processi può essere un primo approccio per trarre delle conclusioni su obiettivi interessanti. Per questo motivo, la crittografia del trasporto tra l'agente e il server Checkmk con Transport Layer Security (TLS) è obbligatoria a partire dalla versione di Checkmk 2.1.0. In questo caso, il server Checkmk "pinga" l'host monitorato, il quale stabilisce la connessione TLS al server Checkmk e trasmette l'output dell'agente su di essa. Poiché solo i server Checkmk con i quali esiste un rapporto di fiducia possono avviare questo trasferimento di dati, non c'è il rischio che i dati finiscano nelle mani sbagliate.

Per proteggere la connessione TLS, Checkmk utilizza un certificato self-signed 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, cioè senza un Agent Controller funzionante, possono perdere la loro registrazione alla scadenza e devono quindi essere registrati di nuovo. 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 quelli 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 è prevista alcuna ulteriore restrizione di accesso. Naturalmente è possibile bloccare la porta 6556 contro gli 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, potrebbe essere attiva la crittografia integrata (simmetrica ), che viene eseguita dallo script dell'agente stesso. Se la crittografia TLS e la crittografia integrata sono attive allo stesso tempo, l'entropia dei dati trasmessi è talmente alta che la compressione, attiva a partire dalla versione 2.1.0, non salverà i dati trasmessi e appesantirà la CPU dell'host e del server Checkmk con processi aggiuntivi di crittografia e decrittografia.

Per questo motivo, devi disattivare la crittografia integrata subito dopo aver switchato a TLS.

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

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

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

La disattivazione della crittografia con l'Agent bakery procede in questo modo: con il primo passo, la modifica della regola Symmetric encryption (Linux, Windows), hai quasi finito. Devi solo confezionare 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, cioè la modifica della regola Enforce agent data encryption.

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

Lo script agente di /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 trovati automaticamente dalla scoperta del servizio. Questo include tutti i monitoraggi importanti per il sistema operativo.

Inoltre, esiste la possibilità di estendere l'agente con dei plug-in dell'agente: si tratta di piccoli script o programmi che vengono richiamati dall'agente e lo estendono con sezioni aggiuntive contenenti dati di monitoraggio supplementari. Il progetto Checkmk offre una serie di plug-in di questo tipo che, se correttamente installati e configurati, forniscono automaticamente nuovi servizi attraverso la scoperta del servizio.

Perché questi plug-in non sono semplicemente codificati nell'agente? Per ognuno dei plug-in ci sarà una delle seguenti ragioni:

I plug-in inclusi in Linux e Unix si trovano tutti sul server Checkmk all'indirizzo ~/share/check_mk/agents/plugins.

Sono anche disponibili nella pagina di download degli agenti nel menu di configurazione (come descritto nel capitolo sull'installazione ) nel box Plugins:

Per tutti i plug-in dell'agente che forniamo, esistono plug-in di controllo che possono 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 vi troverai informazioni importanti sull'uso corretto del plug-in.

L'installazione vera e propria è quindi semplice: copia il file su /usr/lib/check_mk_agent/plugins. Assicurati che sia eseguibile. In caso contrario, utilizza chmod 755, altrimenti il plug-in dell'agente non verrà eseguito. Tieni presente che, soprattutto se non trasferisci i file tramite scp ma li prelevi 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à invocato automaticamente dall'agente e verrà creata una nuova sezione nell'output dell'agente. Questa sezione ha solitamente 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 poter funzionare. Per altri, la configurazione è facoltativa e permette di ottenere funzioni speciali o personalizzazioni. Altri ancora funzionano semplicemente così come sono. Esistono diverse fonti di informazioni su un plug-in:

Come nel caso di MRPE, è possibile eseguire i plug-in in modo asincrono, il che è molto utile se i plug-in hanno un lungo tempo di esecuzione e i dati di stato ottenuti non devono essere rigenerati ogni minuto.

L'esecuzione asincrona non viene configurata tramite un file, ma si crea 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 si specifica un tempo minimo di attesa con il numero di secondi prima che il plug-in venga eseguito di nuovo. Se il plug-in dell'agente viene interrogato di nuovo prima dello scadere del tempo, utilizza i dati in cache dell'ultima volta che il plug-in è stato eseguito. Questo ti permette di configurare un intervallo di tempo più lungo per il plug-in rispetto al tipico minuto.

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

Nota: alcuni plug-in implementano automaticamente l'esecuzione asincrona, tra cui mk_oracle. Installa questi plug-in direttamente su /usr/lib/check_mk_agent/plugins.

Nelle edizioni commerciali, i plug-in dell'agente possono essere configurati tramite l'Agent bakery, che si occupa sia dell'installazione del plug-in vero e proprio che 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 hanno bisogno di alcune variabili d'ambiente impostate dall'agente per trovare, ad esempio, il loro file di configurazione. 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 buone ragioni per continuare a usare i plug-in di controllo di 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 auto-scritti in Perl o shell.

Il secondo motivo è il vero monitoraggio end-to-end. Supponiamo di avere un 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 i valori della connessione tra il server web e il server database.

L'agente Checkmk fornisce un semplice meccanismo per soddisfare questi due requisiti:MK's Remote Plugin Executor ( MRPE ). Il nome è volutamente un'analogia con l'NRPE di Nagios, che svolge lo stesso compito.

L'MRPE è integrato nell'agente e si configura con un semplice file di testo, che si crea come /etc/check_mk/mrpe.cfg. Qui si specifica una chiamata del plug-in per riga, insieme al nome che si desidera che Checkmk utilizzi per il servizio che crea automaticamente. Ecco un esempio:

Nota: i plug-in di Nagios non devono essere collocati nella directory /usr/lib/check_mk_agent/plugins. Questa directory è riservata ai plug-in dell'agente. Oltre a questa directory, puoi scegliere liberamente, purché l'agente possa trovare ed eseguire i plug-in in questa directory.

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

I codici 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 = SCONOSCIUTO.

Il resto verrà fatto automaticamente da Checkmk. Una volta invocata la scoperta del servizio per l'host, i due nuovi servizi verranno visualizzati come disponibili. L'aspetto sarà il seguente:

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 gli spazi corrisponde all'esadecimale 20):

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

Se hai bisogno di un'esecuzione prolungata dei plug-in, dovresti switcharli all'esecuzione asincrona, evitando così questo tipo di problemi. Per configurare un timeout di cinque minuti, imposta l'espressione (interval=300) dopo il nome del servizio in mrpe.cfg:

Questa funzione offre diversi vantaggi:

Questo ti permette di eseguire test che richiedono un tempo di calcolo maggiore o intervalli di tempo più lunghi, senza dover configurare nulla sul server Checkmk.

Gli utenti delle edizioni commerciali possono anche configurare MRPE con l'Agent Bakery. Il responsabile è il set di regole Setup > Agents > Windows, Linux Solaris, AIX > Agent Rules > Generic Options > Execute MRPE checks. Qui puoi configurare le stesse cose descritte in precedenza. Il file mrpe.cfg verrà poi generato automaticamente dall'Agent Bakery.

I moderni dischi rigidi sono quasi sempre dotati di S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology). Questo sistema registra continuamente dati sullo stato di monitoraggio 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 dell'agente è installato, i dati vengono recuperati automaticamente e aggiunti all'output dell'agente. In Checkmk puoi anche attivare direttamente i nuovi servizi:

Come si vede nella schermata, se cmd_timeout si verifica occasionalmente, switcha il plug-in all'esecuzione asincrona a intervalli di qualche minuto.

IPMI (Intelligent Platform Management Interface) è un'interfaccia per la gestione dell'hardware che consente anche di monitorarlo. A questo scopo Checkmk utilizza freeipmi per accedere all'hardware direttamente e senza interfaccia di rete.freeipmi viene installato dai sorgenti dei pacchetti ed è pronto per l'uso immediato, in modo che i dati vengano trasmessi la volta successiva che Checkmk viene chiamato.

Se freeipmi non è disponibile o se ci sono altri motivi per non installarlo, si può usare anche ipmitool.ipmitool è spesso già presente sul sistema e deve solo essere fornito di un driver di dispositivo IPMI, come quello fornito dal pacchetto openipmi. Anche in questo caso, non è necessario fare altro dopo l'installazione e i dati saranno 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:

Se è stato installato ipmitool, puoi verificare 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 via SNMP. Per poter recuperare questi dati e fornirli a Checkmk, è necessario soddisfare i seguenti prerequisiti:

I nuovi servizi per il monitoraggio dell'hardware supportati vengono quindi rilevati automaticamente e non sono necessari altri plug-in.

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

L'impostazione della 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 la scoperta del servizio, i nuovi servizi scoperti saranno abilitati come di consueto.

Quando l'agente viene disinstallato, l'user cmk-agent creato dallo script di installazione viene mantenuto. Questo serve a indicare allo script post-installazione che l'agente era già installato su questo sistema. In questo caso, durante una successiva reinstallazione non verrà attivata alcuna modalità legacy pull. Di conseguenza, dopo l'esecuzione di cmk-agent-ctl delete-all e la successiva reinstallazione dell'agente, non sarà possibile alcuna connessione sulla porta 6556.

Se si desidera riabilitare la modalità legacy pull non criptata, ad esempio per consentire la comunicazione di un sito 2.0.0 con un agente 2.2.0, dovrai abilitare esplicitamente questa modalità.