Per un miglior check_http: Background tecnico

check_http gestito da Monitoring-Plugins.org è uno dei più importanti check attivi per i sistemi di monitoraggio che hanno le loro radici in Nagios. Oltre a Checkmk, questi sistemi includono Icinga, Naemon e Zabbix. In questa prima parte è possibile leggere le motivazioni tecniche che hanno portato alla decisione di avviare una nuova implementazione e apprendere tutto ciò che è necessario sapere sull'installazione su sistemi di monitoraggio diversi da Checkmk e sull'utilizzo alla riga di comando.

Questo articolo è basato su un intervento di 30 minuti all'OSMC. Una seconda parte tratterà presto la configurazione tramite la GUI di Checkmk e suggerimenti per una migrazione più efficiente delle regole esistenti per check_http.

Il precedente check_http ha più di 20 anni. Nel corso del tempo, vari sviluppatori hanno aggiunto il supporto per SSL, proxy e altre funzionalità. Una conseguenza è che il check non valuta alcuni parametri della riga di comando per certe call e dà la precedenza a quelli specifici (ad esempio, non è possibile controllare sia la durata del certificato che il codice di stato in una singola call). In Checkmk visualizziamo tali restrizioni nell'interfaccia grafica, in modo che gli utenti sappiano immediatamente che sono necessarie due regole e quindi due call di controllo. Migliorare le opzioni di login e rivedere il comportamento in caso di utilizzo di SSL avrebbe richiesto molto lavoro.

L'ultimo punto è particolarmente importante per molti utenti di Checkmk: si aspettano che il check si comporti come un browser. Ad esempio, dovrebbe passare allo stato CRIT se una chiamata protetta da SSL fallisce nel browser.

Nel decidere se lavorare sul check esistente o iniziare una nuova implementazione, abbiamo dovuto considerare anche la compatibilità. Poiché raggiungere una bug compatibility sarebbe stato difficile per un check in uso da oltre 20 anni, abbiamo optato per una nuova implementazione. Altre discriminanti sono state il pesante onere che un gran numero di pull request avrebbe comportato per i manutentori e il fatto che le dipendenze aggiuntive avrebbero potuto influire sulla portabilità dei plug-in di monitoraggio. Abbiamo quindi deciso di realizzare una nuova implementazione internamente.

Il passo successivo è stato quello di scegliere il linguaggio di programmazione per il nuovo check. C/C++, Python e Rust sono i linguaggi che utilizziamo principalmente in Checkmk, ma attualmente stiamo abbandonando il C/C++ per concentrarci su Rust per i componenti critici dal punto di vista delle prestazioni. C/C++ avrebbe permesso di aggiungere il check - potenzialmente come check_httpv2 - nella raccolta di plug-in di monitoraggio, ma questo metodo è più difficile da mantenere rispetto alle altre due opzioni.

Python ha la più grande comunità di programmatori all'interno di Checkmk, ma la sua implementazione come special agent avrebbe intaccato la compatibilità con altri sistemi di monitoraggio. Il fattore decisivo è stato che il modo attuale di chiamare sia i check attivi che gli special agent - ovvero tramite un processo creato e terminato per ogni call - non era sufficientemente competitivo in termini di prestazioni con Python.

Alla fine, Rust ha vinto la gara: offre prestazioni simili a C/C++ e ha già dimostrato il suo valore in azienda con l'Agent Controller. Questo linguaggio moderno e compilato aveva tutto dalla sua parte.

Se si utilizza un sistema di monitoraggio che non include o non include ancora check_httpv2, è sufficiente adattarlo. I programmi scritti in Rust possono essere compilati in pochi minuti grazie alla tool chain di rapida installazione. Il codice sorgente disponibile sotto licenza GPLv2 è contenuto nel repository Github di Checkmk(check-http e check-cert); il nostro esempio mostra l'installazione su Debian e Ubuntu.

Per prima cosa, assicuriamoci della presenza di alcune dipendenze:

apt install git curl
apt install build-essential libssl-dev pkg-config

Quindi, installiamo e rendiamo disponibile la toolchain di Rust nell'ambiente di shell corrente:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
. “$HOME/.cargo/env”

Per accedere ai codici sorgente è necessario clonare localmente l'intero repository di Checkmk. L'operazione richiede pochi minuti, durante i quali si può "andare a prendere un tè caldo":

Consigliamo di utilizzare l'ultima versione stabile, che al momento della stesura di questo articolo del blog era la 2.3.0:

git checkout 2.3.0

Segue la compilazione e quindi il consumo del tè caldo preparato in precedenza:

cd checkmk/packages/check-http/
cargo build --release

Se non volete utilizzare una versione di Checkmk-2.3.0, il comando cd:

cd checkmk/packages/site/check-http 

Possiamo adesso eseguire il binario appena compilato direttamente dalla directory di build:

ls -lah target/release/
time ./target/release/check_http --url https://docs.checkmk.com/
echo $?

Se il test ha successo, installiamo il nuovo check in una directory adatta, come /usr/local/bin o la directory contenente i plug-in di monitoraggio. Si consiglia di nominarla check_httpv2:

install -m 0755 ./target/release/check_http /usr/local/bin/check_httpv2

Il vantaggio principale rispetto al noto check_http è la capacità di valutare vari parametri di configurazione del server, di stato del certificato e di carico in una gamma più ampia di scenari. Ad esempio, oltre a una soglia di tempo di risposta compresa tra 0,2s (WARN) e 0,5s (CRIT), è possibile verificare anche il codice di risposta 200, la disponibilità di TLS 1.3 e un periodo di validità del certificato di almeno 7 o 15 giorni:

check_httpv2 \
    --timeout 2 \
    --response-time-levels 0.2,1.0 \
    --min-tls-version tls13 \
    --certificate-levels 15,7 \
    --status-code 200 \
    --url https://docs.checkmk.com/

Per un elenco di tutti i parametri della riga di comando, possiamo utilizzare l'opzione --help. In alternativa, possiamo configurare un'installazione di prova con Checkmk (si può fare in cinque minuti), configurare check_httpv2 e recuperare la riga di comando generata dai dettagli del servizio:

1. Navighiamo fino a "Check HTTP web service" nella ricerca delle impostazioni.
2. Creiamo una regola con le impostazioni desiderate per un endpoint accessibile.
3. Troviamo i parametri della riga di comando nei dettagli del servizio per il check

Oltre a check_httpv2, abbiamo sviluppato anche check_cert, un altro check attivo scritto in Rust. Utilizzatelo non solo per verificare la validità residua dei certificati ma anche per verificare altri aspetti, come la lunghezza della chiave o l'emittente, anche se nessun endpoint HTTPS espone i certificati.

Il codice sorgente si trova in checkmk/packages/check-cert. La compilazione e la determinazione della linea di comando sono simili a check_httpv2. Dato il focus sulla verifica dei certificati, metodi più dettagliati saranno aggiunti qui piuttosto che in check_httpv2.