Monitoraggio di Windows

L'installazione dell'agente Windows avviene tramite un pacchetto MSI.

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

Le edizioni commerciali dispongono di un modulo software, l'Agent bakery, per il confezionamento automatico di agenti personalizzati. Una descrizione dettagliata di questo modulo si trova nell'articolo generale sugli agenti. L'installazione del pacchetto MSI Baked avviene nello stesso modo descritto sopra per il pacchetto incluso.

A partire da Checkmk Cloud è possibile utilizzare l'Agent bakery 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 sarà più necessaria.

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

Durante l'installazione, il pacchetto MSI memorizza i file specifici del programma in C:\Program Files (x86)\checkmk\service\ e i file specifici dell'host in C:\ProgramData\checkmk\agent\. Non è necessario personalizzare i file specifici del programma. I file specifici dell'host vengono utilizzati per memorizzare i plug-in, i file di log e di configurazione e per 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 determina il contenuto di questa opzione. Per il lavoro manuale con l'agente, quindi, solo l'ultimo file di configurazione check_mk.user.yaml è rilevante, perché viene letto per ultimo e quindi ha l'ultima parola. Se non si utilizza l'Agent bakery, questo è di fatto l'unico file in cui si possono effettuare le personalizzazioni della configurazione dell'agente.

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

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

Esiste una funzione speciale quando l'agent è stato installato per la prima volta con l'Agent Controller: in questo caso 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 o precedente.

L'aspetto del monitoraggio sarà il seguente:

L'istanza 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 fino a quando non viene registrato. Dopo la registrazione, per la comunicazione verrà utilizzata solo la modalità pull crittografata. La modalità legacy pull è disattivata e rimarrà tale. Tuttavia, se necessario, può essere attivata nuovamente tramite comando.

La situazione sarà diversa se si utilizza un agente legacy su un sistema Windows molto vecchio. Senza l'Agent Controller non è possibile effettuare la registrazione. Pertanto, per gli agenti legacy le uniche sezioni rilevanti del 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 dell'Agent Controller, perché non è disponibile per un agente legacy. Poiché senza Agent Controller non c'è nemmeno la crittografia TLS, dovrai usare altri metodi di crittografia se necessario. In questo caso ti consigliamo di usare la crittografia integrata (simmetrica) usando la regola Symmetric encryption (Linux, Windows).

Nota: nel set di regole Checkmk Agent installation auditing troverai diverse impostazioni per controllare 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 è 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 del rapporto di fiducia reciproca avviene con un utente Checkmk che ha 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.

Nota: poiché non c'è Agent Controller e quindi non c'è la crittografia del registro e di TLS, nei sistemi Windows molto vecchi dovrai utilizzare metodi di crittografia alternativi, se necessario. In questo caso ti consigliamo di utilizzare la crittografia integrata (simmetrica) utilizzando la regola Symmetric encryption (Linux, Windows).

Per prima cosa 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.

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. Qui devi fare una richiesta all'istanza Checkmk con i diritti di amministratore:

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.

Attenzione, una 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( 0x22).

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 questa registrazione automatica, oltre a un utente con il permesso di registrare gli host, è necessaria almeno una cartella configurata per contenere gli host che devono essere creati automaticamente.

Se queste condizioni sono soddisfatte, puoi anche effettuare la registrazione, compresa la creazione automatica degli host, 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 utilizzata principalmente per i 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 %COMPUTERNAME%. 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 un 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:

Una volta completata la registrazione, esegui un test di connessione e una ricerca di servizi nel Setup del server Checkmk. Poi, 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 la modalità legacy pull, inserisci il seguente comando:

In seguito, l'agente si comporterà come dopo l'installazione iniziale e prima della prima registrazione e invierà i suoi dati in modo non criptato.

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 usare 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 Checkmk:

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.

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 anche visualizzate le variabili d'ambiente e i file di configurazione in uso.

Se solo una certa parte della configurazione è di interesse, puoi limitare l'output a quella specifica parte. In questo caso, ad esempio, viene controllato se le opzioni della sezione ps sono state impostate correttamente:

In questo modo otterrai 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 anche prima della presentazione di un certificato, la conoscenza dei metodi di comunicazione può aiutare a identificare il problema e, naturalmente, a risolverlo.

Una volta 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 del tipo curl:

Il parametro --insecure indica a curl di saltare la verifica del certificato. Questo comportamento riflette il comportamento dell'Agent Controller in questa fase. La risposta è costituita da pochi byte e contiene 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. Usa l'opzione aggiuntiva --detect-proxy per indicare a cmk-agent-ctl di utilizzare un proxy configurato tramite le impostazioni di sistema.

Tuttavia, spesso è più semplice identificare la porta dell'Agent Receiver e annotarla. Per farlo, sul server Checkmk, loggato come utente dell'istanza Checkmk, esegui:

Ora puoi specificare la porta quando inserisci il comando per la registrazione. In questo modo salta 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.

Poiché il programma agente deve essere chiamato con l'account LocalSystem per fornire esattamente i dati che arrivano nel 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). In questo modo il programma agente viene avviato con l'ambiente corretto e con l'account utente corretto e poi produce il risultato.

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

In questo modo puoi verificare che i dati del programma agente siano arrivati all'Agent Controller. Questo output non dimostra ancora che l'agente sia accessibile in rete.

Se in modalità pull è stato verificato che il programma 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 se la connessione è stata stabilita con successo e se l'handshake TLS può avere luogo. Poiché tutto il resto è criptato TLS, non è possibile effettuare un controllo più dettagliato.

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

Per ulteriori diagnosi 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 nel box Agent:.

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

L'agente crea già una regola nel firewall di Windows durante la sua 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 sue impostazioni. Se si utilizza una configurazione del firewall molto rigida, le Regole in uscita per le connessioni all'agente di monitoraggio devono essere configurate in modo che sia raggiungibile almeno la porta 8000 (per una registrazione più semplice, anche le porte 80 o 443).

Nelle versioni attuali di Windows puoi trovare Windows Defender Firewall with Advanced Security tramite le Impostazioni di Windows (Settings > Windows Security) o avviarlo richiamando wf.msc dalla linea di comando:

Se non trovi una voce del genere nelle impostazioni di Windows Firewall, puoi aggiungerla in questa esatta posizione. 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 scelte come segue:

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

Nota: il comando è stato diviso in quattro righe per facilitare la lettura.

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

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 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.

Nota: poiché nei sistemi Windows molto vecchi non esiste l'Agent Controller e quindi la crittografia del registro e del TLS, dovrai scegliere altri metodi di crittografia se necessario. In questo caso ti consigliamo di utilizzare la crittografia integrata (simmetrica) utilizzando la regola Symmetric encryption (Linux, Windows).

La restrizione dell'accesso a indirizzi IP specifici può essere configurata anche tramite il firewall. Tuttavia, l'agente stesso offre anche la possibilità di ignorare semplicemente le richieste provenienti da indirizzi IP estranei. È sufficiente aggiungere la seguente restrizione al file di configurazione nelle opzioni globali. Tieni presente che potrebbero esserci altri parametri impostati nel file di configurazione 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 da consentire solo questo indirizzo, mentre con 192.168.42.0/24 consentirai tutti gli indirizzi compresi tra 192.168.42.0 e 192.168.42.255.

Nell'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, potrebbe essere attiva la crittografia integrata (simmetrica), che viene eseguita dal programma 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, dovresti 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, sull'host dell'agente, nel file di configurazione C:\ProgramData\checkmk\agent\check_mk.user.yml, cambia il valore del parametro encrypted in no:

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 Bakedery procede in questo modo: con il primo passo, la modifica della regola Symmetric encryption (Linux, Windows), hai quasi finito. Devi solo preparare 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, cioè la modifica della regola Enforce agent data encryption.

Dopo il prossimo aggiornamento automatico dell'agente, la crittografia del programma agente è disabilitata, ma la crittografia è garantita dall'Agent Controller. Nota che dopo l'aggiornamento automatico dell'agente, solo gli host registrati saranno in grado di 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 trovati automaticamente dalla scoperta del servizio. Questo include tutti i monitoraggi importanti del sistema operativo.

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

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

I plug-in dell'agente 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 anche disponibili nella pagina di download dell'agente nel menu di configurazione (come descritto nel capitolo Installazione ) nel box Plugins:

Per tutti i plug-in dell'agente che forniamo, ci sono plug-in di controllo corrispondenti che possono valutare i loro dati e generare servizi. Questi sono già installati, in modo che i servizi appena trovati vengano immediatamente riconosciuti e possano essere configurati.

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

L'installazione vera e propria è poi semplice: copia il file all'indirizzo 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, che di solito ha lo stesso nome del plug-in. I plug-in complessi (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 (es. mssql.vbs) e consente di ottenere funzioni speciali o personalizzazioni. Altri ancora funzionano semplicemente in questo modo. Hai diverse fonti per ottenere informazioni:

Per quanto riguarda i linguaggi speciali (di scripting), potrebbe essere necessario abilitarli prima nella configurazione dell'agent. 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 questi plug-in richiede che i file possano essere richiamati anche da una normale linea di comando senza percorsi speciali. Nel caso di Python, è necessario che sia installato correttamente e che il percorso dell'interprete sia 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 possono essere inserite nel file di configurazione.

Una configurazione per il plug-in di Veeam può apparire ad esempio come questa (l'estratto è abbreviato e contiene solo la parte rilevante per l'esempio):

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

Nelle edizioni commerciali, i plug-in dell'agente possono essere configurati tramite l'Agent bakery, che si occupa sia dell'installazione del plug-in stesso che 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 necessitano di alcune variabili d'ambiente impostate dall'agente per trovare il loro file di configurazione, ad esempio. Se necessario, impostale manualmente se sono necessarie nello script o nel programma.

Ci sono due buone ragioni per continuare a usare i plug-in di controllo di 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 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 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 plug-in dell'agente MRPE direttamente nel menu Setup. Per farlo, utilizza il set di regole Setup > Agents > Windows, Linux, Solaris, AIX > Agent > Agent rules > Execute MRPE checks. La voce necessaria viene quindi creata automaticamente nel file di configurazione dell'Agent bakery.