Http_check mit TLSv1.3

Hallo zusammen,

ich versuche gerade einen Healthcheck abzurufen, scheitere aber offenbar am SSL Handshake.

Laut curl -vv:

* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20): ```

Ansonsten liefert curl die erwartete Antwort zurĂĽck.

In CheckMK kann ich allerdings maximal TLSv1.2 auswählen und bekomme sowohl damit, als auch mit auto-negotiate einen SSL-Fehler. 

`CRITICAL - Cannot make SSL connection.` 

Bin mir nicht sicher wie ich hier weiter vorgehen sollte um dem Problem auf den Grund zu gehen. 

Hier noch mein eingerichteter Check:

![Bildschirmfoto 2023-05-02 um 16.32.44|420x500](upload://lp5Oz9STOiUGNMVRH2gxCSSPrNA.png)

Danke fĂĽr alle Hinweise wo ich hier eventuell einen Fehler habe! Danke!

@Hannsr,

nur zur Info. Du hast leider alles in einen Quote-Block gepackt. Dadurch ist es schwer, deinen Text vom Konsolen-Output zu unterscheiden. Zudem wird dadurch das Bild nicht angezeigt.

Da sich scheinbar sonst keiner verantwortlich fĂĽhlte dir das mitzuteilen :wink:

Neben dem Problem mit dem nicht sichtbaren Bild wäre hier noch recht wichtig die verwendete Version von CMK.
In den Classic Monitoringplugins hat sich einiges getan ĂĽber die letzten 1-2 Jahre.

Hier aber auch ein Frage a @LaMi - warum ist trotz relativ aktueller Version von den Monitoring Plugins das dort enthaltene check_curl nicht vorhanden in der aktuellen CMK 2.2 Beta?
Das sollte ja mittlerweile eher verwendet werden wie check_http.

2 Likes

Hallo,

danke euch, und Mist, war etwas in Hektik und hab die Formatierung nicht gecheckt. Jetzt kann ich es nicht mehr bearbeiten.

Zur Version:

CMK version: 2.1.0p19
OS version:Debian Bullseye (server) Ubuntu 20.10 (host)

Der Screenshot:

Was mir mittlerweile aber aufgefallen ist, ist dass mein eigentliches Ziel mit dem Check wohl eh nicht umsetzbar ist und wir hier etwas eigenes bauen mĂĽssen.

Ziel: Auf der Seite wird ein Queue Worker Status angezeigt, der u.A. ausgibt, wie lang die Queue aktuell ist. Hier soll dann checkmk eine notification ausgeben, falls diese Queue zu lang wird, damit wir eingreifen können. Ich kann zwar prüfen, ob ein bestimmter Wert ausgegeben wird, aber soweit ich verstanden hab kann ich keine Grenzwerte setzen und den Wert auslesen lassen. Dafür müssten wir einen eigenen Check schreiben. Oder hat sich hier etwas getan bzw. ich etwas übersehen?

Eine quick and dirty Lösung wäre den OK Wertebereich der Queue Länge mit “Regular expression to expect in content” abzufragen:

QueueSize=([0-9]|1[0-5])\b

0-9 oder 10-15 ist ok, alles andere wĂĽrde nicht matchen und somit zu einem Critical fĂĽhren.

3 Likes

check_curl ist schon seit längerem auf dem Feature Portal gelistet:

1 Like

Ein generisches Plugin für genau solche Fälle ist schon seit längerem auf dem Feature Portal:

1 Like

Jup - das check_curl ist ja “eigentlich” ganz normal in den Monitoring Plugins enthalten.
Es ist nur nicht ersichtlich warum es nicht mit “gebaut” wird bei der Erstellung des CheckMK Paketes.
Das sollte eigentlich schnell zu klären sein.

1 Like

Hey,

ich komme gerade erst aus dem Urlaub, daher etwas spätes Feedback. Danke für den Tipp, das scheint so weit zu funktionieren!
Ich bekomme allerdings nur den Output
HTTP OK: HTTP/1.1 200 OK - 2329 bytes in 0.130 second response time
Kein Pattern found o.ä. - ist das so normal?

Da ich keinen Fehler bekomme wĂĽrde ich erstmal davon ausgehen, aber bei einem Fehler bekomme ich ja z.B. pattern not found ausgegeben. Das unterschiedliche Handling von Fehler/kein Fehler verwirrt mich nur etwas.

Nachtrag: Und danke fĂĽr den Hinweis, ich hab mal nen upvote fĂĽr das feature Request hinterlassen.

Wenn der Regex matched wird keine “Pattern found” oder so ausgegeben. Auf der Konsole kannst Du check_http mit -v aufrufen dann siehst du den ganzen Content inkl. HTTP Headers.

Als alternative kann das check_http auch direkt via “Integrate Nagios plugins” aufgerufen werden. Mit dem Parameter -B (check_http -B …) wird der Content der Seite mitausgeben und im Checkmk GUI in den Details angezeigt:

Das eignet sich aber nur fĂĽr Aufrufe, die keine ganze HTML-Webseite ausgeben.

1 Like

Ah, verstehe, dann scheint es ja zu passen jetzt, vielen Dank.

Auch für die Ergänzung, das gucke ich mir auf jeden Fall mal an. Sind in unserem Fall auch nur 2 Zeilen die ausgegeben werden, daher wäre das ggf. interessant um bei einer Warnung/Crit direkt zu sehen was nicht stimmt.

Weil es mir gerade wieder einfiel und falls noch wer auf den Fehler stößt: Wir haben auf dem Server mehrere Domains laufen, daher musste ich dem Check noch den passenden vHost mitgeben, damit die SSL Connection erfolgreich klappte.