Monitoring - Aussetzer in der Datenerfassung

Mir ist aufgefallen, dass zu Spitzenzeiten nicht alle Daten erfasst werden (Daher z. B. auch die extremen Schwankungen bei den DHCP Leases, sowie bei dem FFRL Durchsatz). Bevor wir jetzt noch alle Maschinen der “neuen” Domänen da drauf werfen, sollten wir dem nachgehen. Ggf. ist die Maschinen für die Statistiken am Limit, es werden ja doch recht viele I/Os produziert.

Es kann natürlich auch an den collectd-Clients liegen, die größten Aussetzer sind mir bislang bei GW parad0x aufgefallen. Außerdem sollten wir darüber nachdenken über öffentliche Adressen mit dem Monitoring-Server zu sprechen, denn so wie es jetzt ist sind wir blind, wenn das Netz ausfällt.

Ich würde dann mal die Frage stellen ob wir mir Graphite auf Basis von Whisper überhaupt richtig unterwegs sind. Ich hab da mal ein Blick geworfen und finds gruselig. Nichtmal simples WAL hat das Ding.

Auf den Kisten auf denen wir so unterwegs sind wird IO immer “nicht toll sein”. Von daher würde ich vorschlagen nach nem anderen Storage Backend zu suchen oder Graphite ersetzen. ELK? :wink:

Wen es interessiert: Whisper kann man sich hier mal anschauen, ist echt stumpf:
http://bazaar.launchpad.net/~graphite-dev/graphite/main/view/head:/whisper/whisper.py

Hier mal ne Meinung von jemand der auch Anwender ist:
http://dieter.plaetinck.be/post/on-graphite-whisper-and-influxdb/ (und InfluxDB vorschlägt)
http://dieter.plaetinck.be/post/influxdb-as-graphite-backend-part2/

Vielleicht keine Top Prio aber wenn die schwindsüchtige DB die Update Rate nicht packt sinkt der Nutzen. Dank collectd ist eine Änderung oder Experiment ja simpel.