Checkmk
DeutschEnglish
master2.3.0
to checkmk.com
Important

This is a machine translation based on the English version of the article. It might or might not have already been subject to text preparation. If you find errors, please file a GitHub issue that states the paragraph that has to be improved.

1. Introduzione

1.1. Il sistema di monitoraggio dovrebbe intervenire?

Verrebbe da pensare che sia ovvio che un sistema di monitoraggio non debba mai intervenire negli eventi, ma piuttosto che debba, beh, monitorare. E probabilmente è una buona idea lasciarlo così.

È tuttavia un'idea certamente allettante che un sistema in grado di identificare in modo affidabile i problemi possa anche correggerli, a condizione che funzioni in modo automatico.

Si possono facilmente immaginare alcuni esempi calzanti:

  • Riavviare un servizio che è crashato.

  • L'attivazione di un garbage collector se una Java-VM sta esaurendo la memoria.

  • Ricostruire un canale VPN se è definitivamente fuori uso.

Se si accetta questo, allora bisogna pensare al monitoraggio in modo diverso. Da un sistema che si limita a osservare e che è "non necessario" per le operazioni, un processo graduale porta il monitoraggio a diventare un organo vitale nel data center.

Ma correggere i problemi non è l'unica cosa che il monitoraggio può fare automaticamente quando identifica un problema. Molto utile, ma anche innocua, è la raccolta di dati diagnostici aggiuntivi al momento di un guasto. Senza dubbio ti verrebbero in mente numerosi altri casi in cui si potrebbero utilizzare i gestori di avvisi come punto di partenza.

1.2. Gestori di avvisi in Checkmk

CEE I gestori di avvisi sono script che scrivi tu stesso e che vengono eseguiti da Checkmk nelle edizioni commerciali se viene rilevato un problema - o, più precisamente, se un host o un servizio cambia stato.

I gestori di avvisi sono molto simili alle notifiche e si configurano in modo analogo, ma ci sono alcune differenze importanti:

  • I gestori di avvisi sono indipendenti dai tempi di manutenzione programmati, dai periodi di notifica, dalle conferme e da controlli simili.

  • I gestori di avvisi vengono attivati al primo tentativo (se sono stati configurati più tentativi di controllo).

  • I gestori di avvisi sono indipendenti dagli utenti e dai gruppi di contatto.

  • I gestori di avvisi sono disponibili solo nelle edizioni commerciali.

Si può anche dire che i gestori di avvisi sono molto "di basso livello". Non appena un host o un servizio cambia stato, i gestori di avvisi che hai configurato si attivano immediatamente. In questo modo un gestore di avvisi può persino eseguire una riparazione con successo prima che venga generato un vero e proprio avviso.

Naturalmente, come sempre in Checkmk, puoi utilizzare le regole per definire le condizioni in cui un determinato gestore di avvisi deve essere eseguito. In questo articolo scoprirai come farlo e tutto il resto sui gestori di avvisi.

CRE Un consiglio per gli utenti dellCREi della Comunità Checkmk: puoi anche far sì che il monitoraggio esegua automaticamente delle azioni. Usa gli "event handler" di Nagios per questo. Configurali con file di configurazione manuali in sintassi Nagios alla voce "~/etc/nagios/conf.d/". Gli event handler sono ben documentati. Puoi trovare informazioni semplicemente tramite Google.

2. Configurazione dei gestori di avvisi

2.1. Salvataggio degli script nella directory corretta

I gestori di avvisi sono script che vengono eseguiti sul server Checkmk. Devono essere salvati nella directory ~/local/share/check_mk/alert_handlers/ e possono essere scritti in qualsiasi linguaggio supportato da Linux, ad esempio BASH, Python o Perl. Non dimenticare di rendere gli script eseguibili con l'opzione chmod +x.

Se inserisci un commento nella seconda riga dello script (con l'hash #), questo apparirà come nome dello script nell'elenco di selezione della regola:

~/local/share/check_mk/alert_handlers/myhandler
#!/bin/bash
# Foobar handler for repairing stuff
...
Copia il contenuto del file negli appunti
Contenuto del file copiato con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

2.2. Un semplice gestore di avvisi da provare

Come per le notifiche, lo script ottiene tutte le informazioni relative all'host o al servizio sotto forma di variabili d'ambiente, tutte precedute dal prefisso ALERT_.

Per verificare esattamente quali variabili d'ambiente compaiono nello script, puoi usare il seguente gestore di avvisi per un test:

~/local/share/check_mk/alert_handlers/debug
#!/bin/bash
# Dump all variables to ~/tmp/alert.out

env | grep ^ALERT_ | sort > $OMD_ROOT/tmp/alert.out
Copia il contenuto del file negli appunti
Contenuto del file copiato con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

  • env visualizza tutte le variabili d'ambiente.

  • grep ^ALERT_ seleziona quelle che iniziano con ALERT_.

  • sort ordina l'elenco risultante in ordine alfabetico.

2.3. Attivazione del gestore di avvisi

L'attivazione del gestore viene eseguita tramite Setup > Events > Alert handlers.

Procedi come segue:

  1. Salva lo script in ~/local/share/check_mk/alert_handlers/debug.

  2. Rendilo eseguibile tramite chmod +x debug.

  3. Apri la pagina di configurazione tramite Setup > Events > Alert handlers.

  4. Lì, definisci una nuova regola con Add rule.

Il modulo per la selezione del gestore di avvisi consente l'accesso diretto e mostra il titolo che viene registrato nella seconda riga dello script. Inoltre puoi aggiungere argomenti, che inserisci nei campi di testo. Questi saranno interpretati come argomenti della riga di comando nello script. Nella tua shell puoi accedervi con $1, $2, ecc.

alert handler arguments

Dopo aver salvato la regola, il gestore di avvisi sarà immediatamente attivo e verrà eseguito ad ogni cambiamento di stato per qualsiasi host o servizio!

2.4. Test e diagnosi dei guasti

Per eseguire un test, imposta manualmente un servizio, ad esempio, da Fake check results a CRIT. Ora il file dovrebbe essere stato creato con le variabili. Ecco le sue prime venti righe:

OMD[mysite]:~$ head -n 20 ~/tmp/alert.out
ALERT_ALERTTYPE=STATECHANGE
ALERT_CONTACTNAME=check-mk-notify
ALERT_CONTACTS=
ALERT_DATE=2016-07-19
ALERT_HOSTADDRESS=127.0.0.1
ALERT_HOSTALIAS=myserver123
ALERT_HOSTATTEMPT=1
ALERT_HOSTCHECKCOMMAND=check-mk-host-smart
ALERT_HOSTCONTACTGROUPNAMES=all
ALERT_HOSTDOWNTIME=0
ALERT_HOSTFORURL=myserver123
ALERT_HOSTGROUPNAMES=check_mk
ALERT_HOSTNAME=myserver123
ALERT_HOSTNOTESURL=
ALERT_HOSTNOTIFICATIONNUMBER=1
ALERT_HOSTOUTPUT=Packet received via smart PING
ALERT_HOSTPERFDATA=
ALERT_HOSTPROBLEMID=0
ALERT_HOSTSHORTSTATE=UP
ALERT_HOSTSTATE=UP
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Un file di log relativo all'esecuzione (o alla mancata esecuzione) del gestore di avvisi si trova in~/var/log/alerts.log . La sezione relativa all'esecuzione del gestore di avvisidebug , per il servizioFilesystem / sull'hostmyserver123 sarà simile a questa:

~/var/log/avvisi.log
2016-07-19 15:17:22 Got raw alert (myserver123;Filesystem /) context with 60 variables
2016-07-19 15:17:22 Rule ''...
2016-07-19 15:17:22  -> matches!
2016-07-19 15:17:22 Executing alert handler debug for myserver123;Filesystem /
2016-07-19 15:17:22 Spawned event handler with PID 6004
2016-07-19 15:17:22 1 running alert handlers:
2016-07-19 15:17:22 PID: 6004, object: myserver123;Filesystem /
2016-07-19 15:17:24 1 running alert handlers:
2016-07-19 15:17:24 PID: 6004, object: myserver123;Filesystem /
2016-07-19 15:17:24 Handler [6004] for myserver123;Filesystem / exited with exit code 0.
2016-07-19 15:17:24 Output:

Un paio di altri consigli utili:

  • I testi generati dai gestori di avvisi sull'output standard compaiono nel file di log insieme a Output:.

  • Verrà registrato anche il codice di uscita dello script (exited with exit code 0).

  • I gestori di avvisi diventano davvero utili quando eseguono un comando sull'host di destinazione. Checkmk offre una soluzione pronta all'uso per Linux che verrà spiegata più avanti.

3. Configurazione rule-based

Come mostrato nell'esempio introduttivo, gli eventi che devono attivare i gestori di avvisi vengono definiti tramite regole. Questo funziona in modo del tutto analogo alle notifiche, solo in forma leggermente semplificata. Nell'esempio non abbiamo specificato alcuna condizione, cosa che ovviamente non è realistica nella pratica. L'esempio seguente mostra una condizione che un gestore di avvisi definisce per host e servizi specifici:

alert handlers rule condition

Il gestore di avvisi verrà attivato solo

  • per gli host myhost123 e myhost124 ,

  • per il servizio JVM CaramKern Memory,

  • se lo stato cambia da OK o WARN a CRIT,

  • e solo al secondo tentativo di check.

Affinché l'handler venga attivato, in questo esempio è necessario utilizzare una regola Maximum number of check attempts for service per impostare il numero minimo di tentativi di controllo a 2. Per sopprimere una notifica in caso di garbage collector riuscito, il numero dovrebbe essere impostato su 3 — poiché se l'handler riesce a risolvere il problema subito dopo il secondo tentativo, il terzo tentativo dovrebbe rilevare uno stato OK e quindi non sarà necessaria alcuna ulteriore notifica.

Tip

A differenza di altre parti di Checkmk, ogni regola di gestione degli avvisi verrà eseguita se le condizioni corrispondono. Anche se due regole chiamano lo stesso gestore di avvisi, quest’ultimo verrà effettivamente eseguito due volte. L’assistente agli avvisi (spiegato nel prossimo capitolo) sopprimerà la seconda esecuzione con un messaggio di errore, poiché lo stesso gestore di avvisi non deve essere eseguito più volte contemporaneamente. Tuttavia, si consiglia di impostare le regole in modo che questo caso non si verifichi.

4. Come vengono eseguiti i gestori di avvisi

4.1. Esecuzione asincrona

Gli gestori di avvisi vengono spesso utilizzati per accedere in remoto a una macchina interessata tramite SSH o un altro protocollo e, una volta lì, eseguire un'azione controllata da uno script. Dato che questa macchina sta riscontrando un problema, non si può escludere che la connessione richieda molto tempo o che addirittura vada in timeout.

Affinché il monitoraggio non si blocchi e altri gestori di avvisi non rimangano inattivi durante questo periodo, per principio i gestori di avvisi vengono eseguiti in modo asincrono. Un processo ausiliario — l'assistente agli avvisi — è responsabile di questa funzione e viene avviato dal CMC. Per ridurre l'overhead, ciò avviene solo se è stata creata almeno una regola per un gestore di avvisi. Nell'cmc.loge vedrai quindi la seguente riga:

~/var/log/cmc.log
2016-07-19 15:17:00 [5] Alert handlers have been switched on

Ad ogni cambiamento di stato di un host o di un servizio, l'assistente agli avvisi riceve una notifica dal CMC contenente tutte le informazioni rilevanti per l'evento. Valuta quindi tutte le regole di avvisi e determina se un gestore di avvisi debba essere attivato. Se sì, lo script appropriato verrà avviato ed eseguito in background come processo esterno.

4.2. Arresto del nucleo di monitoraggio

Quando arresti il CMC (ad es. tramite omd stop o spegnendo il server di monitoraggio), tutti gli assistenti agli avvisi ancora in esecuzione verranno interrotti. Questi non verranno ripetuti in un secondo momento, dato che chissà quando sarà quel "secondo momento"? È possibile che riavviare un servizio o simili possa essere più dannoso che utile!

4.3. Timeout

Per proteggersi dall'avvio di troppi processi in caso di errore, quando un gestore di avvisi è in esecuzione viene applicato un timeout di 60 secondi (configurabile). Alla fine di questo tempo il gestore verrà arrestato. In dettaglio, ciò significa che alla fine del timeout verrà inviato un Segnale 15 (SIGTERM) al gestore di avvisi. In questo modo ha la possibilità di arrestarsi in modo pulito. Dopo altri 60 secondi (doppio timeout) verrà infine "terminato" con un Segnale 9 (SIGKILL).

4.4. Sovrapposizione

Checkmk impedisce l'esecuzione simultanea di assistenti agli avvisi se questi si applicano allo stesso host/servizio ed eseguirebbero lo stesso script con gli stessi parametri. Una situazione del genere indica che il primo gestore di avvisi è ancora in esecuzione e che non avrebbe senso avviare una seconda copia dello stesso gestore di avvisi: il secondo gestore di avvisi verrebbe immediatamente eliminato e identificato come "fallito".

4.5. Codici di uscita e output

L'output e i codici di uscita del gestore di avvisi vengono valutati in modo affidabile e restituiti al core, dove vengono salvati nella cronologia di monitoraggio. Inoltre, puoi attivare una notifica (vedi sotto).

4.6. Impostazioni globali

Esistono diverse impostazioni globali per l'esecuzione dei gestori di avvisi:

alert handlers options

L'Alert handler log levele influenza la registrazione nel file di log dell'assistente agli avvisi (~/var/log/alerts.log).

4.7. Controllo master

alert handlers master control off

Con un clic nello snap-in "Master control" puoi disattivare globalmente i gestori di avvisi. I gestori attualmente in esecuzione non ne saranno influenzati e continueranno a funzionare fino al completamento.

Non dimenticare di riportare il switch su verde non appena possibile! Altrimenti potresti farti ingannare da un falso senso di sicurezza, pensando che il monitoraggio stia risolvendo tutto…​


5. Gestori di avvisi nella cronologia

I gestori di avvisi creano voci nella cronologia di monitoraggio. In questo modo hai una tracciabilità migliore rispetto al solo file di log alerts.log. Viene creata una voce non appena un gestore di avvisi si avvia e un'altra quando termina.

I gestori di avvisi vengono quindi considerati alla stregua dei tipici plug-in di monitoraggio: ciò significa che dovrebbero produrre una riga di testo e restituire uno dei quattro codici di uscita 0 (OK), 1 (WARN), 2 (CRIT) o 3 (SCONOSCIUTO). Tutti gli errori che impediscono fin dall'inizio l'esecuzione di un gestore (interruzione dovuta a esecuzione duplicata, script mancante, timeout, ecc.) vengono automaticamente contrassegnati con SCONOSCIUTO.

Ad esempio, chiamando questo handler molto semplice…​

~/local/share/check_mk/alert_handlers/dummy
#!/bin/bash
# Dummy handler for testing

sleep 3
echo "Everything is fine again"
exit 0
Copia il contenuto del file negli appunti
Contenuto del file copiato con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

... produce un risultato come quello sopra riportato nella cronologia del servizio in questione (come sempre, il messaggio più recente si trova in cima):

alert handler history

C'è anche una visualizzazione generica Monitor > System > Alert handler executions , che fornisce una visualizzazione globale di tutti i gestori di avvisi in esecuzione.

6. Notifica tramite gestori di avvisi

L'esecuzione di un gestore di avvisi — o, più precisamente, il completamento di un'esecuzione — è un evento che attiva una notifica. In questo modo puoi essere informato che un gestore ha completato il suo compito. Ci sono due tipi di eventi che puoi filtrare in una regola di notifica:

alert handler notif condition

Puoi quindi distinguere tra gestori eseguiti con successo (codice di uscita 0 - OK) e quelli che hanno fallito (tutti gli altri codici). La notifica via e-mail di Checkmk non mostra l'output del controllo, ma l'output del gestore di avvisi.

7. Gestore di avvisi per ogni esecuzione di un check

I gestori di avvisi vengono normalmente richiamati solo quando lo stato di un host o di un servizio cambia (o durante i tentativi di riprova in caso di problemi). Le semplici esecuzioni di controllo senza cambiamento di stato non attivano alcun gestore di avvisi.

Con l'opzione "Global settings > Alert handlers > Types of events that are being processed > All check executions!" puoi impostare esattamente questo comportamento. Ogni esecuzione di un check può potenzialmente attivare un gestore di avvisi. Puoi, ad esempio, utilizzare questa funzione per trasferire dati dal monitoraggio attivo ad altri sistemi.

Fai attenzione a questa impostazione! L'avvio di processi e l'esecuzione di script consumano molte risorse della CPU. Checkmk può facilmente eseguire 1000 controlli al secondo, ma Linux non sarebbe certamente in grado di gestire 1000 script di gestori di avvisi al secondo.

Per rendere questa operazione fattibile, Checkmk offre la possibilità di scrivere i gestori di avvisi come funzioni Python, che vengono poi eseguite inline, senza creare processi. Questi gestori inline possono essere salvati nella stessa directory degli script degli handler normali. Il seguente esempio funzionante mostra la struttura di un gestore inline:

~/local/share/check_mk/alert_handlers/foo
#!/usr/bin/python
# Inline: yes

# Do some basic initialization (optional)
def handle_init():
    log("INIT")

# Called at shutdown (optional)
def handle_shutdown():
    log("SHUTDOWN")

# Called at every alert (mandatory)
def handle_alert(context):
    log("ALERT: %s" % context)
Copia il contenuto del file negli appunti
Contenuto del file copiato con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Questo script non ha una funzione centrale, ma definisce semplicemente tre funzioni, anche se è richiesta solo la funzione handle_alert(). Questa viene richiamata dopo ogni esecuzione di un check e nel suo argomento context riceve un dizionario Python con variabili come "HOSTNAME" , "SERVICEOUTPUT" , ecc. Queste rappresentano le variabili d'ambiente che ricevono anche i gestori normali - tuttavia qui senza il prefisso ALERT_. L'esempio sopra riportato può essere utilizzato per effettuare una visualizzazione del contenuto di context.

Tutti gli output generati dalla funzione ausiliaria log() vengono salvati in ~/var/log/alert.log. Entrambe le variabili globali omd_root e omd_site si basano rispettivamente sulla directory home e sul nome dell'istanza Checkmk.

Le funzioni handle_init() e handle_shutdown() vengono richiamate da Checkmk all’avvio o all’arresto del nucleo di monitoraggio e consentono un’inizializzazione, ad esempio quando si stabilisce una connessione a un database.

Ulteriori informazioni:

  • Presta attenzione a # Inline: yes nella seconda riga.

  • Il core deve essere riavviato dopo ogni modifica allo script (omd restart cmc).

  • import I comandi sono consentiti.

  • Gli assistenti agli avvisi di Checkmk richiamano le tue funzioni in modo sincrono. Assicurati che non si verifichino stati di attesa!

8. Esecuzione remota su Linux

8.1. Principi di base

Ogni versione di Checkmk include un gestore di avvisi integrato che consente l'esecuzione affidabile di script sui sistemi Linux monitorati. Le caratteristiche più importanti di questa soluzione sono:

  • Gli script vengono richiamati tramite SSH con restrizione dei comandi.

  • Non è possibile utilizzare comandi arbitrari, ma solo quelli definiti da te.

  • Tutto questo può essere implementato utilizzando l'agent bakery.

I gestori di avvisi remoti Linux sono costituiti dai seguenti elementi:

  • Il gestore di avvisi "linux_remote" con il titolo "Linux via SSH" sul server Checkmk.

  • The script "mk-remote-alert-handler" sul sistema di destinazione.

  • Gli script ("gestori remoti") scritti da te sul sistema di destinazione.

  • Voci in .ssh/authorized_keys per gli utenti sul sistema di destinazione che li eseguiranno.

  • Regole in Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Linux Agent > Remote alert handlers (Linux) che generano chiavi SSH.

  • Regole del gestore di avvisi che richiamano linux_remote.

8.2. Configurazione

Supponiamo di voler eseguire lo script di /etc/init.d/foo restart sul sistema Linux myserver123 ogni volta che il servizio Process FOO diventa critico (che abbiamo già configurato). Procedi come segue:

Codifica dell'handler remoto

Successivamente, scrivi lo script da eseguire sul sistema di destinazione. Dato che stiamo lavorando con agent bakery, installa lo script sul server Checkmk (non sul sistema di destinazione!). La directory corretta per questo è ~/local/share/check_mk/agents/linux/alert_handlers. Anche qui il commento nella seconda riga fornisce un titolo per la selezione nell'interfaccia utente:

~/local/share/check_mk/agents/Linux/alert_handlers/restart_foo
#!/bin/bash
# Restart FOO service

/etc/init.d/foo restart || {
    echo "Could not restart FOO."
    exit 2
}
Copia il contenuto del file negli appunti
Contenuto del file copiato con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Rendi lo script eseguibile:

OMD[mysite]:~$ cd local/share/check_mk/agents/linux/alert_handlers
OMD[mysite]:~/local/share/check_mk/agents/linux/alert_handlers$ chmod +x restart_foo
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Il nostro script di esempio è strutturato in modo tale che, in caso di errore, termini con un Codice 2, in modo che il gestore di avvisi lo valuti come "CRIT".

Preparazione del pacchetto agente con il gestore

Qui descriveremo la procedura con agent bakery. I consigli per l'installazione manuale sono riportati più in basso.

Definisci una regola sotto "Setup > Agents > Windows, Linux, Solaris, AIX > Agent rules > Linux Agent > Remote alert handlers (Linux)". Nelle proprietà è visibile il gestore remoto Restart FOO service che hai appena definito. Selezionalo per l'installazione:

alert handlers install remote

Una volta salvata, vedrai la regola nell'elenco: è stata generata automaticamente una coppia di chiavi SSH per richiamare l'handler e la cui impronta digitale apparirà nella regola. L'impronta digitale stessa è stata abbreviata per adattarsi alla larghezza di questa schermata:

alert handlers install remote2

La chiave pubblica è destinata all'agente. La chiave privata sarà richiesta in seguito dal server Checkmk in modo che uno script installato in questo modo possa essere richiamato senza dover inserire una password.

È anche possibile utilizzare un altro utente comroote, naturalmente solo se dispone dei diritti appropriati per l'azione richiesta. L'agente Checkmk effettuerà l'installazione della chiave SSH solo sui sistemi in cui questo utente esiste già.

Creazione dell'agente

Ora crea nuovi agenti con button bake agents. Nell'elenco degli agenti pronti dovrebbe ora apparire una voce in cui sono visibili il tuo gestore remoto e la chiave SSH. Anche qui lo screenshot è stato abbreviato. Questa volta in base al numero di pacchetti che possono essere sottoposti a scaricamento:

alert handlers baked handler

Installa l'agente

Successivamente, installa il pacchetto RPM o DEB sul tuo sistema di destinazione (l'installazione dell'archivio TGZ non consente di configurare la chiave SSH ed è quindi incompleta). Con l'installazione avvengono le seguenti operazioni:

  • Verrà effettuata l'installazione del tuo script di gestione remota.

  • Verrà effettuata l'installazione del programma ausiliario mk-remote-alert-handler.

  • Per gli utenti selezionati (in questo caso root) verrà creata una voce in authorized_keys che abiliterà l'esecuzione dell'handler.

  • Verranno create, se necessario, la directory .ssh e il file authorized_keys.

Con un'installazione tramite DEB, il risultato sarà simile a questo:

root@myserver123:~# dpkg -i check-mk-agent_2016.07.19-9d3ab34905da4934_all.deb
Selecting previously unselected package check-mk-agent.
(Reading database ... 515080 files and directories currently installed.)
Preparing to unpack ...check-mk-agent_2016.07.19-9d3ab34905da4934_all.deb ...
Unpacking check-mk-agent (2016.07.19-9d3ab34905da4934) ...
Setting up check-mk-agent (2016.07.19-9d3ab34905da4934) ...
Reloading xinetd...
 * Reloading internet superserver configuration xinetd                            [ OK ]
Package 9d3ab34905da4934: adding SSH keys for Linux remote alert handlers for user root...
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Dando un'occhiata alla configurazione SSH per root si nota:

root@myserver123:~# cat /root/.ssh/authorized_keys
command="/usr/bin/mk-remote-alert-handler restart_foo",no-port-forwarding,no-x11-forwarding,no-agent-forwarding ssh-rsa  AAAAB3NzaC1yc2EAAAADAQABAAACAQCqoDVNFEbTqYEmhSZhUMvRy5SqGIPp1nE+EJGw1LITV/rej4AAiUUBYwMkeo5aBC6VOXkq78CdRuReSozec3krKkkwVbgYf98Wtc6N3WiljS85PLAVvPadJiJCkXFctbxyI2xeF5TQ1VKDRvzbBjXE9gjTnLWbPy77RC8SVXLoOQgabixpWQquIIdGyccPsWGTRgeI7Ua0lgWZQUJt7OIKQ0X7Syv2VHKJNqtW28IWu8y2hBEY/TERip5EQoNT/VclhHqjDG2y3F45PswcXD5in6y30EnfHGcwk+PD6fgp7jPGbO2+QBUwYgW67GmRpbaVQ97CqXFJvORNF+C6+O8DNweyH3ogspjfKvM7eN+M4NIJzjMRyNBMzqF3VmrMeqpzRjfFj2BS/8UbXGgHzZRapwrK3+GXX1pG49n77cIs+GWos9xb1DxX1pEu2tgQwRBBhYcTkk2eKkH18LKzFUyObxtQmf40C24cdQOp6USbwzsniqehsLIHH2unQ7bW6opF/GiaEjZamGbgsPOe8rmey5Vcd//e8cS+OsmcPZNybsTJpBeHpes+5bw0e1POw9GD9qptylrQLYIO5R467Ov8YlRFgYKyaDFHD40j5/JHPzmtp4vjH8Si7YZZOzvTRgBYEoEgbLS5dgdr/I5ZMRKfDPCpRUbGhp9kUEdGX99o5Q== mk-remote-alert-handler-9d3ab34905da4934
Copia i comandi negli appunti
Comandi copiati con successo negli appunti!
L'accesso in scrittura agli appunti è stato negato!

Tieni presente che il tuo sistema potrebbe essere configurato in modo tale che l'accesso SSH come root non sia generalmente possibile. In questo caso puoi passare tramite un altro utente e lì utilizzare sudo, che è configurato in modo tale che il comando desiderato possa essere eseguito senza password.

Chiamata dell'handler tramite una regola

Abbiamo quasi raggiunto il nostro obiettivo. L'agente è pronto. Ora manca solo una regola per richiamare effettivamente il gestore di avvisi. La procedura è quella descritta all'inizio di questo articolo e si ottiene creando una regola appropriata. Questa volta scegli Linux via SSH come gestore di avvisi, inserisci l'utente per il quale deve essere effettuata l'installazione della chiave SSH e seleziona il tuo gestore di avvisi remoto:

alert handlers rule foo

Imposta anche una condizione sensata nella regola, altrimenti verrà tentata una connessione SSH ad ogni avviso di servizio!

Test

Quando, ad esempio, imposti ora manualmente il servizio in questione su CRIT, nella cronologia del servizio vedrai a breve:

alert handlers foo failing

Naturalmente, se non esiste alcun servizio foo, anche /etc/init.d/foo restart non può funzionare. Si può tuttavia vedere che questo comando è stato elaborato e che lo stato di errore è stato segnalato correttamente. Allo stesso modo, Checkmk ha attivato una notifica che è stata bloccata da un gestore di avvisi.

Il messaggio "Warning: Permanently added '127.0.0.1' (ECDSA) to the list of known hosts." è innocuo, tra l'altro, e appare solo al primo contatto con l'host. Per evitare il dispendioso scambio manuale della chiave host, SSH viene chiamato con "-o StrictHostKeyChecking=false". Alla prima connessione la chiave verrà memorizzata per un uso futuro.

8.3. Configurazione senza agent bakery

Naturalmente funziona anche la preparazione manuale di un agente. In tal caso ti consigliamo di eseguire la procedura di agent bakery su un sistema di prova, quindi esaminare i dati rilevanti e replicarli manualmente sul tuo sistema. Qui trovi un elenco dei percorsi dei file.

In questo caso è importante anche che in agent bakery crei una regola per l’installazione dell’handler remoto, perché in questa regola verranno generate le chiavi SSH per l’accesso e anche per l’uso da parte del gestore di avvisi! La chiave pubblica per l’installazione in authorized_keys si trova nel file di configurazione ~/etc/check_mk/conf.d/wato/rules.mk (o in una sottocartella in rules.mk).

9. File e directory

9.1. Percorsi sul server Checkmk

Percorso Funzione

~/var/log/alerts.log

File di log con tutti gli eventi rilevanti per il gestore di avvisi (registrati dall'assistente agli avvisi).

~/var/log/cmc.log

File di log per il core. Qui vengono memorizzate anche alcune informazioni relative al gestore di avvisi.

~/local/share/check_mk/alert_handlers/

Salva qui i tuoi gestori di avvisi personalizzati.

~/var/check_mk/core/history

Qui viene memorizzato il file di log della cronologia di monitoraggio, che viene anche valutato dal core.

~/local/share/check_mk/agents/linux/alert_handlers/

Gestori di avvisi remoti da eseguire su sistemi Linux.

9.2. Percorsi sull'host Linux monitorato

Percorso Funzione

/usr/bin/mk-remote-alert-handler

Script ausiliario per l'esecuzione dei gestori remoti.

/usr/lib/check_mk_agent/alert_handlers/

Gestori remoti scritti da te.

/root/.ssh/authorized_keys

Configurazione SSH per l'utente root.

~harri/.ssh/authorized_keys

Configurazione SSH per l'utente harri.
Last modified: Thu, 05 Feb 2026 14:58:34 GMT via commit 4776cff3b
In questa pagina