Certstream - Ressourcenverbrauch

vorhergehende Artikel in: Linux TeleGrafana Security
24.05.2019

In meinem letzten Artikel zur Auswertung globaler Zertifikatslog war unter anderem ein Screenshot zu sehen, der die Systembelastung des für die Durchführung der Tests benutzten Raspberry Pi darstellte.

Diese Ergebnisse brachten mich dazu, diese Analysen nicht ständig laufen zu lassen - denn abgesehen vom gestiegenen Energiebedarf lag die Temperatur meines passiv gekühlten Pi dabei auch gerne mal über 70 Grad Celsius. Das ist eine Temperatur, die ich einem Gerät nicht gestatte, wenn ich nicht im Haus oder zumindest auf dem Grundstück bin.

Dazu kommt noch, dass dieser spezielle Anwendungsfall - was die Last angeht - schwer abzuschätzen ist: Da die Anzahl der im Strom auftretenden Zertifikate sehr stark schwankt kann es sein, dass diese 70 Grad Celsius noch nicht das Maximum darstellen.

Daher hatte ich schon längere Zeit vor, dem Mysterium der hohen Auslastung nachzugehen und idealerwese Mittel und Wege zu finden, sie abzustellen. Dazu nahm ich mir nunmehr die Zeit. Zunächst wollte ich feststellen, was genau eigentlich für diese extrem hohe Last sorgt.

Die Anwendung arbeitet derzeit so, dass die Daten im Strom empfangen und aufbereitet werden, danach werden die einzelnen Datensätze analysiert, aufbereitet und nachdem das Ranking berechnet wurde an InfluxDB weitergeleitet. All das geschieht in dem aktuell von mir dazu bnutzten Python-Progrämmchen in einem Callback. Aktuell führt das dazu, dass auf dem Pi in top eine Prozessorlast von 100% für python3 gelistet wird. Daher schaltete ich den Callback komplett aus - das führte zu einem Wert von 98% in top.

Völlig überraschend für mich war also keineswegs mein Code zur Auswertung und Speicherung schuld - sondern de Code, der den Stream entgegennahm und aufbereitete, um dann die einzelnen Daten anden Callback zu geben.

An diesem Punkt experimentierte ich weiter - schließlich ist Python nicht die einzige Möglichkeit der Anbindung zur Konsumierung des Zertifikats-Stroms: andere Möglichkeiten sind Java, Go und Javascript. Ich testete Go und Java, weil - sind wir doch mal ehrlich: Javascriopt? ewww!.

Diese Tests fanden nicht mehr auf dem Pi statt, da das Installieren neuer Anwendungen dort ganz schön zur Geduldsprobe verkommen kann. Statt dessen führte ich den Test mit dem abgespeckten Python Programm ohne Callback nochmals auf einem PC (Ubuntu Linux 18.04) durch und stellte das Ergebnis entsprechenden Implementierungen in Go und Java gegenüber. Das Ergebnis sieht man in der untenstehenden Tabelle:

ProgrammierspracheAuslastung laut top
Python>20
Java<10
Go>5

Damit hatte ich deutliche Hinweise, auch wenn die Messungen ungenau und mit großer Unsicherheit beaufschlagt waren, ließ sich für mich ein klarer Trend ablesen, der es rechtfertigte, nun doch Go auf dem Raspi zu installieren und zu sehen, wie sich das Testprogramm dort schlagen würde.

Leider wurde meine Hoffnung nicht erfüllt - auf dem Pi listete top das Go-Programm immer noch mit ungefähr 40% Last (stark schwankend), so dass aus meiner Sicht (vor allem, da sämtliche Auswertung noch fehlte und ich ein völliger Go-Neuling bin) die Umstellung des Programms zur ständigen Überwachung des CertStream nicht lohnte. Interessant war in diesem Zusammenhang noch, dass

vcgencmd measure_clock arm

nur sehr selten das mögliche Maximum der Taktfrequenz anzeigte: meistens dümpelte diese bei 600MHz herum. Das erklärt eventuell auch die Tatsache, dass ein inzwischen über 12 Jahre alter Centrino-Laptop bei der Ausführung des Go-Programms lediglich eine Auslastung von 15% in top erreichte.

Das reichte trotzdem aus, zu versuchen ob dieser alte Laptop vielleicht das Mittel der Wahl sein könnte, den CertStream kontinuierlich zu überwachen. Ich benutzte für diesen Test das bereits vorhandene Python-Programm und musste leider erkennen, dass auch das keine Option ist - bei Benutzung von Pythen steigt die Auslastung lat top auf zwischen 60 und 70% an und der Lüfter ist kontinuierlich hörbar. Ein solcher Stress ist für über 12 Jahre alte Teile höchstwahrscheinlich nicht gut, daher brach ich den Test nach einem halben Tag wieder ab.

Artikel, die hierher verlinken

Grafana: Alarmierung mit XMPP

01.09.2019

Nachdem bei mir im "Home-Lab" Grafana kombiniert mit Influxdb prächtig funktioniert, habe ich mir über das Thema Alarmierung Gedanken gemacht...

Alle Artikel rss Wochenübersicht Monatsübersicht Github Repositories Gitlab Repositories Mastodon Über mich home xmpp


Vor 5 Jahren hier im Blog

  • Brian May, Kerry Ellis & Vittorio Grigolo: Bohemian Rhapsody

    19.05.2019

    Eine andere Sicht auf den schönen Queen-Klassiker

    Weiterlesen...

Neueste Artikel

  • sQLshell, SQLite und Redis - oh my!

    Ich habe in letzter Zeit hin und wieder mit der sQLshell und SQLite herumgespielt - Neulich wurde ich gefragt, ob die sQLshell eigentlich auch Redis kann...

    Weiterlesen...
  • bad-certificates Version 3.0.0

    Das bereits vorgestellte Projekt zur automatisierten Erzeugung von Zertifikaten mit allen möglichen Fehlern wurde um eine weitere Kategorie von Zertifikaten erweitert

    Weiterlesen...
  • Erste Vor-Version eines Gis-Plugin für die sQLshell

    Wie bereits in einem früheren Artikel erwähnt plane ich, demnächst ein Plugin für die sQLshell anzubieten, das eine Visualisierung von Daten mit räumlichem Bezug im Stil eines Geoinformationssystems erlaubt.

    Weiterlesen...

Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.

Wer daran teilhaben und eventuell sogar davon profitieren möchte, muß damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.

Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...

PS: Meine öffentlichen GitHub-Repositories findet man hier - meine öffentlichen GitLab-Repositories finden sich dagegen hier.