Tausende "Ssl"-Threads nagios

Moin,

mein icinga2 fing irgendwann mal an für den eigenen Host alle Services als DOWN zu melden mit dem Kommentar "CHECK_NRPE: Error - Could not complete SSL-Handshake".

Dass der SSL-Handshake generell jedoch klappt war mir klar und konnte ich auch verifizieren. Ich hab also gedacht: Ok, vielleicht hat sich da etwas verhakt und einfach den icinga2 Prozess sowie den "nagios-nrpe-server"-Dienst neu zu starten. Aber dadurch ließ sich das Problem nicht beheben. Nach einem Neustart des Nodes kam es jedoch nach einigen Tagen wieder. Ich hab mir das mal als "zu untersuchen" mit niedriger Priorität vermerkt und es ist nun soweit, dass ich es bearbeiten möchte.

Jetzt ist mir aufgefallen: wenn diese Meldung vorkommt sind im Munin die #Threads an einem bestimmten Level und steigen nach Neustart auch intervalartig wieder an:Bildschirmfoto 2018-05-08 um 19.05.41.png

Man erkennt ganz gut, wo ich neugestartet habe (immer wenn es abfällt).

Also hab ich jetzt gewartet bis es wieder soweit ist (jetzt wie man sieht) und mal geschaut was mir ps so sagt.

Dabei sind mir viele Einträge mit folgendem Schema aufgefallen:

UID   PID          PENDING          BLOCKED          IGNORED           CAUGHT STAT TTY        TIME COMMAND
110     - 0000000000000000 0000000000000000 0000000000001000 0000000180004223 Ssl  -          0:00 -

uid 110 ist "nagios" unter dem der Dienst nagios-nrpe-server u.a. läuft (dass ich auf den lokalen Host nicht per local-Conncetion, sondern per NRPE connecte sollte ja egal sein?).

Ein bisschen erschrocken war ich darüber wie viele solcher Threads existieren:

root@myFancyHost:~# ps axms | grep Ssl | wc -l
12065

Ich weiß jetzt nicht, ob diese Thread-Schwelle ursächlich für den Fehlschlag der Nagios-NRPE-Checks ist, aber ich finde dass dort eine auffällige Korrelation besteht (quasi an der Threshold von 12k Threads). Hat jemand eine Idee

• ob es daran liegen könnte (etwas wie Threadlimit pro User hab ich im Kopf?)
• wieso die #Threads so intervalartig anspringen (der Server wird quasi nur zum Monitoren genutzt)
• warum überhaupt so viele Threads dieses Users offen sind

OS ist ein Ubuntu 16.04

Gefühlt habe ich 80% meiner Threads hier im Kundenforum danach selbst gelöst. Irgendwie lustig. Die gute alte Gummiente...

Der Weg:

1. Googlen nach "0000000180004223": Ein Suchergebnis: ein issue auf github zu icinga2 (YES!)
2. Dort ein anderes Issue verlinkt mit dem Titel "API queries cause memory leaks" (Jackpott: Ich benutze nämlich auch die icinga2 API)
3. Feststellen dass bugfix für Version 2.4.2 existiert (issue aus 2016)
4. Erschrocken feststellen, dass man selbst icinga v2.4.1 nutzt, weil aus offiziellen Ubuntu-Paketquellen
5. Augenrollen
6. Icinga2 Paketquellen hinzufügen
7. Auf aktuelle Version 2.8.4 [sic!] upgraden
8. Service neustarten
9. Kaffee
10. Watch 'em drop
    Bildschirmfoto 2018-05-08 um 19.30.06.png

Zitat von Skulduggery

Ich möchte jetzt mal hoffen das du bei Nutzung der IDO nicht einfach den Icinga Core 2.8.4 drauf gebügelt hast ohne jegliches Schema Update. Wissenswertes zu Icinga 2: Es hat nicht mehr wirklich was mit Nagios zu tun. Das sorgt für Verwirrung.

Zweiter Punkt warum NRPE wenn Icinga 2 einen Agent mit SSL verschlüsselter API anbietet?

Danke für die unangenehmen bzw. informativen Fragen. Hab ich mir mal vorgemerkt mir das anzugucken. Ich sag mal so; da sind eh n paar interessante Sachen bei und ich könnte dir grade nicht einmal sagen, wo icinga überhaupt die Nutzdaten outputtet (in einer Datenbank scheinbar nicht )

$ icinga2 feature list
Disabled features: debuglog elasticsearch gelf graphite icingastatus influxdb livestatus opentsdb perfdata syslog
Enabled features: api checker command compatlog mainlog notification statusdata