Monitoraggio di Windows

Si installa l'agente Windows durante l'installazione del pacchetto MSI.

Prima dell'installazione, devi procurarti il pacchetto e trasferirlo sull'host su cui verrà eseguito l'agente (ad esempio con scp o WinSCP).

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 del pacchetto MSI generato avviene allo stesso modo descritto sopra per il pacchetto incluso.

In Checkmk Ultimate puoi inoltre utilizzare l'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 una volta installato il pacchetto dell'agente, e la registrazione manuale, come descritta nel capitolo seguente, non sarà più necessaria.

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

Durante l'installazione, il pacchetto MSI salva i file specifici del programma in C:\Program Files (x86)\checkmk\service\ e quelli specifici dell'host in C:\ProgramData\checkmk\agent\. Non è necessario personalizzare i file specifici del programma. I file specifici dell'host servono a salvare i plug-in, i file di log e di configurazione e a configurare il comportamento dell'agente.

Nota: per impostazione predefinita, l'intera directory C:\ProgramData è nascosta in Windows.

L'agente legge tre file di configurazione in successione:

Se un'opzione è stata impostata in più file, è l'ultimo file letto a determinare il contenuto di tale opzione. Per lavorare manualmente con l'agente, quindi, è rilevante solo l'ultimo file di configurazione check_mk.user.yaml, poiché viene letto per ultimo e ha quindi l'ultima parola. Se non si utilizza agent bakery, questo è di fatto l'unico file in cui è possibile apportare personalizzazioni alla configurazione dell'agente.

Come avrai già notato dall'estensione dei file di configurazione, il formato utilizzato è YAML.

Dopo aver installato l'agente, compreso l'Agent Controller, 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 visualizzato nel monitoraggio.

C'è una particolarità quando l'agente viene installato con l'Agent Controller per la prima volta. In questo caso l'agente passerà alla modalità legacy pull 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.

Nel monitoraggio apparirà così:

Il sito Checkmk riconosce dall'output dell'agente che l'Agent Controller è presente e quindi che 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 verrà utilizzata solo la modalità pull crittografata. La modalità legacy pull viene disattivata e rimarrà tale. Tuttavia, se necessario, può essere riattivata tramite comando.

La situazione sarà diversa quando si utilizza un agente legacy su un sistema Windows molto vecchio. Senza l'Agent Controller la registrazione non è possibile. Pertanto, per gli agenti legacy le uniche sezioni rilevanti nel capitolo Registrazione sono l'aggiunta dell'host al Setup e poi al monitoraggio. Nel capitolo Test e risoluzione dei problemi devi omettere il test per la chiamata all'Agent Controller, poiché questo non è disponibile per un agente legacy. Poiché senza l'Agent Controller non è disponibile nemmeno la crittografia TLS, dovrai utilizzare altri metodi di crittografia se necessario. In questo caso ti consigliamo di utilizzare la crittografia integrata (simmetrica) tramite la regola Symmetric encryption (Linux, Windows).

Nota: nel set di regole "Checkmk Agent installation auditing" troverai varie impostazioni per verificare lo stato dell'agente e renderlo visibile nel monitoraggio. Tra le altre cose, qui puoi specificare quale stato deve 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à legacy pull è possibile solo la comunicazione non crittografata. Una trasmissione dati esclusivamente crittografata può essere attivata solo una volta stabilita una relazione di fiducia.

Sono da considerare eccezioni i pacchetti preconfigurati per la registrazione automatica e sottoposti a scaricamento tramite 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 del rapporto di fiducia reciproca avviene tramite un utente Checkmk con accesso alla API REST. A tal fine, 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 generare una password di automazione casuale (password di automazione) con il simbolo . Devi salvare l’utente prima di poter utilizzare la nuova password.

Nota: poiché non è presente un Agent Controller, e quindi non sono disponibili il registro e la crittografia TLS, sui sistemi Windows molto vecchi dovrai utilizzare metodi di crittografia alternativi, se necessario. In questo caso ti consigliamo di utilizzare la crittografia integrata (simmetrica) tramite la regola Symmetric encryption (Linux, Windows).

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'Agent Controller cmk-agent-ctl, 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 devi inviare una richiesta all'istanza Checkmk con diritti di amministratore:

Il nome host che segue l'opzione --hostname deve essere esattamente lo stesso di quando è stato creato nel Setup. 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 automazione. Se ometti l'opzione --password, la password ti verrà richiesta in modo interattivo.

Attenzione, trappola per gli incauti: se amministri principalmente macchine Unix, sei abituato a racchiudere percorsi o parametri con spazi o caratteri speciali tra virgolette singole (apostrofi, 0x27). Windows interpreta questo carattere come parte della chiamata — in questo caso la password — e la registrazione fallirà. Usa invece le virgolette doppie (virgolette, 0x22).

Se i valori specificati erano corretti, ti verrà chiesto di confermare l'identità dell'istanza Checkmk a cui vuoi effettuare la connessione. 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 check 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 C:\ProgramData\checkmk\agent\registered_connections.json.

Checkmk Ultimate offre la possibilità di creare host automaticamente al momento della registrazione. Per tale registrazione automatica, oltre a un utente con il permesso di registrare host, è necessaria almeno una cartella configurata per contenere gli host che devono essere creati 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 C:\ProgramData\checkmk\agent\pre_configured_connections.json nel pacchetto dell'agente ed esegue la registrazione automaticamente durante l'installazione. Il comando da riga di comando qui presentato viene quindi utilizzato principalmente per il test e il debug, ad esempio per provare le proprie etichette 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 nell'istanza Checkmk. Il nome dell'host è quello memorizzato nella variabile d'ambiente %COMPUTERNAME%. 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 sull'istanza.

Per prima cosa, su qualsiasi host nel Setup, 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:

Una volta completata la registrazione, esegui un test di connessione e una scoperta del servizio 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'affidabilità. Qui, 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 effettuare il ripristino della modalità legacy pull, inserisci il seguente comando:

Dopodiché, l'agente si comporterà come dopo l'installazione iniziale e prima della prima registrazione, inviando i propri 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 usare la riga 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:

In Checkmk Ultimate puoi switchare dagli host dalla modalità push alla modalità pull e viceversa. 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 SCONOSCIUTO 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 check successivo utilizzando cmk-agent-ctl status mostrerà quindi un nuovo UUID e una modalità coerente con la modifica apportata nel Setup.

Per verificare che la configurazione sia stata letta come previsto, chiama il programma agente con l'opzione showconfig. Con questa opzione non solo otterrai la configurazione attualmente utilizzata dall'agente, ma verranno sempre visualizzate anche le variabili d'ambiente e i file di configurazione in uso.

Se ti interessa solo una determinata parte della configurazione, puoi limitare l'output a quella parte specifica. Qui, ad esempio, si verifica se le opzioni nella sezione ps sono state impostate correttamente:

In questo modo ottieni una rapida panoramica di come i tre diversi file di configurazione sono stati uniti e utilizzati dal programma agente. Gli errori saranno immediatamente visibili.

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

Una volta 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 l'istanza iniziale di solito è semplicemente 8000, per l'istanza seconda 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 identificare la porta dell'Agent Receiver e annotarla. Per farlo, sul server Checkmk, dopo aver effettuato l'accesso come utente dell’istanza, esegui:

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 impediscono l'accesso all'Agent Receiver, c'è comunque la possibilità di utilizzare la registrazione tramite proxy sul server Checkmk.

Poiché il programma agente deve essere eseguito con l'account LocalSystem per fornire esattamente i dati che arrivano al monitoraggio, non dovresti mai avviarlo in una shell. Se vuoi esaminare l'output dell'agente localmente, usa l'Agent Controller in modalità dump (sottocomando dump). Questo avvia il programma agente con l'ambiente corretto e con l'ID utente corretto, quindi visualizza il risultato.

Dato che l'output può essere un po' lungo, il pager 'more' è molto utile in questo caso. Puoi uscire con il tasto Q:

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

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

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

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

Per ulteriori diagnostiche da eseguire sul server Checkmk, consulta l'articolo generale sugli agenti di monitoraggio. In particolare, puoi anche eseguire un test di connessione utilizzando l'interfaccia Checkmk. Otterrai il risultato nella box "Agent:".

Se durante il test di connessione non ottieni alcuna informazione o ricevi solo un messaggio di errore di timeout, come nell'esempio sopra, dovresti controllare l'Inbound Rules del firewall di Windows sull'host.

L'agente crea già una regola nel firewall di Windows durante l'installazione, in modo che l'Agent Controller sia raggiungibile dall'esterno tramite la porta 6556. Quando si utilizza la modalità push, di solito non è necessario modificare le impostazioni. Se utilizzi una configurazione del firewall molto rigida, le regole in uscita per le connessioni al server di monitoraggio devono essere configurate in modo che almeno la porta 8000 (per una registrazione più semplice, anche 80 o 443) sia raggiungibile.

Nelle versioni attuali di Windows puoi trovare l'Windows Defender Firewall with Advanced Securitye tramite Impostazioni di Windows (Settings > Windows Security) oppure avviarlo richiamando wf.msc dalla riga di comando:

Se non trovi questa voce nelle impostazioni del Windows Firewall, puoi aggiungerla proprio qui. Per farlo, clicca su New Rule nel menu Action.

Si aprirà una procedura guidata per la creazione di una nuova regola del firewall. Imposta le cinque opzioni come segue:

In alternativa, puoi automatizzare questo passaggio e impostare la regola direttamente dalla riga di comando. Modifica il seguente comando in base al tuo percorso di installazione personalizzato, se necessario:

Nota: il comando è stato suddiviso in quattro righe per facilitarne la lettura.

Nella cartella ~/var/agent-receiver/received-outputs/ dell'istanza 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 Checkmk, 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 esito positivo o se è stata interrotta, ad esempio, da problemi di rete sporadici.

Inoltre, puoi dare un'occhiata al file di log C:\ProgramData\checkmk\agent\log\check_mk sull'host (i percorsi potrebbero essere configurati in modo diverso). 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ù istanze 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 in seguito a un 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.

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 Checkmk 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 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. In questo caso, il server Checkmk "pinga" l'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 self-signed che viene sostituito automaticamente poco prima della scadenza della sua validità. L'Agent Controller si occupa del rinnovo del 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.

Nota: poiché sui sistemi Windows molto vecchi non è presente l'Agent Controller, e quindi non ci sono né registro né crittografia TLS, dovrai scegliere altri metodi di crittografia se necessario. In questo caso ti consigliamo di utilizzare la crittografia integrata (simmetrica) tramite la regola Symmetric encryption (Linux, Windows).

È possibile configurare la limitazione dell'accesso a specifici indirizzi IP anche tramite il firewall. Tuttavia, l'agente stesso offre anche la possibilità di ignorare semplicemente le richieste provenienti da indirizzi IP esterni. Basta aggiungere la seguente restrizione al file di configurazione nelle opzioni globali. Tieni presente che nel file di configurazione potrebbero esserci altri parametri impostati prima o dopo questo, e che questo è solo un frammento:

Come puoi vedere nell'esempio, puoi consentire un numero qualsiasi di sottoreti. Ad esempio, con /32 specifichi una sottorete di dimensione 1, in modo che sia consentito solo questo indirizzo, mentre con 192.168.42.0/24 consenti tutti gli indirizzi compresi tra 192.168.42.0 e 192.168.42.255.

In agent bakery, puoi configurare gli indirizzi IP consentiti utilizzando il seguente set di regole: Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Allowed agent access via IP address (Linux, Windows) .

Soprattutto durante l'aggiornamento dell'agente, può capitare che sia attiva la crittografia integrata (simmetrica), eseguita dal programma agente stesso. Se la crittografia TLS e quella integrata sono attive contemporaneamente, l’entropia dei dati trasmessi è così elevata che la compressione, attiva dalla versione 2.1.0 in poi, 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 switch 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, sull'host dell'agente, nel file di configurazione C:\ProgramData\checkmk\agent\check_mk.user.yml, modifica il valore del parametro encrypted impostandolo su no:

Nel terzo e ultimo passaggio, 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 procede in questo modo: Con il primo passo, ovvero la modifica della regola Symmetric encryption (Linux, Windows), hai quasi finito. Devi solo compilare e distribuire i nuovi agenti. Il file di configurazione C:\ProgramData\checkmk\agent\check_mk.user.yml verrà modificato automaticamente per te e incluso nei pacchetti degli agenti. Rimane solo il terzo passo, ovvero la modifica della regola Enforce agent data encryption.

Dopo il prossimo aggiornamento automatico dell'agente, la crittografia del programma 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.

Il programma agente check_mk_agent.exe contiene un'intera serie di sezioni che forniscono dati di monitoraggio per vari plug-in di controllo, che vengono poi individuati automaticamente dalla scoperta del servizio. Questo include tutto il monitoraggio importante del 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 richiamati dall'agente e lo estendono con sezioni aggiuntive contenenti ulteriori dati di monitoraggio. Il progetto Checkmk fornisce una serie di plug-in di questo tipo che, se installati e configurati correttamente, forniscono automaticamente nuovi servizi nell'ambito della scoperta del servizio.

Perché questi plug-in non sono semplicemente integrati nell'agente? Per ciascuno dei plug-in c'è uno dei seguenti motivi:

I plug-in inclusi per Windows si trovano tutti sull'host monitorato nella directory di installazione dell'agente sotto C:\Program Files (x86)\checkmk\service\plugins. Sono memorizzati lì in modo da essere direttamente disponibili. In alternativa, i plug-in per Windows si trovano anche sul server Checkmk sotto ~/share/check_mk/agents/windows/plugins.

Sono disponibili anche dalla pagina di download dell'agente nel menu di configurazione (come descritto nel capitolo di installazione) nella box Plugins:

Per tutti i plug-in degli agenti che forniamo, ci sono plug-in di controllo corrispondenti in grado di valutare i loro dati e generare servizi. Questi sono già installati, in modo che i servizi appena individuati vengano immediatamente riconosciuti e possano essere configurati.

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

L'installazione vera e propria è poi semplice: Copia il file in C:\ProgramData\checkmk\agent\plugins.

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

Alcuni plug-in necessitano di un file di configurazione in C:\ProgramData\checkmk\agent\config per funzionare. Per altri, la configurazione è facoltativa (ad es. mssql.vbs) e consente di utilizzare funzionalità speciali o personalizzazioni. Altri ancora funzionano semplicemente così. Hai diverse fonti da cui ottenere informazioni:

Per i linguaggi speciali (di scripting), potrebbe essere necessario abilitarli prima nella configurazione dell'agente. Ad esempio, gli script Python non verranno eseguiti a meno che non siano esplicitamente abilitati. Puoi farlo estendendo le estensioni dei file nel file di configurazione check_mk.user.yml nella sezione global, come mostrato nel seguente estratto:

Importante: l'uso di tali plug-in richiede che i file possano essere richiamati anche in una normale riga di comando senza percorsi speciali. Nel caso di Python, deve essere installato correttamente e il percorso dell'interprete deve essere presente nelle variabili d'ambiente. Le istruzioni su come configurare correttamente Python sono disponibili direttamente sulle pagine della Python Software Foundation.

Ogni plug-in può essere eseguito in diverse modalità. Le seguenti opzioni sono disponibili per l'inserimento nel file di configurazione.

Una configurazione per il plug-in Veeam appare quindi, ad esempio, in questo modo (l'estratto è abbreviato e contiene solo la parte rilevante per l'esempio):

In base alla configurazione di esempio sopra riportata, il plug-in nella directory dei dati C:\ProgramData\checkmk\agent\plugins viene eseguito in modo asincrono ogni cinque minuti (300 secondi) e può durare al massimo due minuti (120 secondi). Se il plug-in raggiunge questo timeout, proverà una seconda volta a ottenere un risultato.

Nelle edizioni commerciali, i plug-in inclusi possono essere configurati tramite agent bakery. Questo si occupa sia dell'installazione del plug-in stesso sia della corretta creazione del 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 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. Se necessario, impostale manualmente se sono richieste nello script o nel programma.

Ci sono due buoni motivi per continuare a usare i plug-in Nagios con 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 end-to-end monitoring. 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 semplice meccanismo per soddisfare questi due requisiti: MK's Remote Plugin Executor (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 ed è controllato da vari file di configurazione.

In alternativa alla configurazione diretta su un host nel file di configurazione specifico dell'utente, puoi anche definire i tuoi plug-in MRPE direttamente nel menu Setup. Per farlo, usa il set di regole "Setup > Agents > Windows, Linux, Solaris, AIX > Agent > Agent rules > Execute MRPE checks". La voce necessaria verrà quindi creata automaticamente nel file di configurazione di agent bakery.