Geschichten aus der Technik,
nicht nur Projektnamen.

Die selbst programmierte App. In der App wähle ich eine Übung aus und erfasse Trainingsdatum, Gewichte und Wiederholungen für jeden Satz direkt. Die gespeicherten Einheiten bilden die Grundlage für Verlauf, Volumenberechnung und Fortschrittsdiagramme. Die öffentliche Kraftwerk-Seite zeigt eine reine Leseansicht dieses Trainingsverlaufs. Wie Kraftwerk entstanden ist →

Daten mit Kontext. Sitzungskennzahlen, Gesamtvolumen, Schritte und Zeitbereichskontrollen sorgen dafür, dass einzelne Trainingseinheiten innerhalb von Wochen- und Monatsmustern aussagekräftig sind.

Gebaut, um sich weiterzuentwickeln. CSV- und Gesundheitsdatenimporte sorgen dafür, dass historische Informationen übertragbar sind, während die Präsentationsebene neue Kennzahlen abrufen kann, ohne die zugrunde liegenden Datensätze neu schreiben zu müssen.

KRAFTWERK / MISSION LOG

Von Papier zu Fortschritt.

Vier Stationen einer App, die aus meinem eigenen Training entstand.

01Die Kladde02Digitalisierung03Meine eigene App04Fortschritt heute

Station 1 / 4

Am Anfang stand die Kladde.

Die passende Trainings-App fand ich nicht. Also notierte ich Datum und Wiederholungen von Hand. Das ist meine ursprüngliche Push-up-Seite.

Kleine Umgebung, wachsende blinde Flecken. Am Anfang standen nur eine Handvoll Server und Skripte, die Logfiles analysierten. Mit dem Wachstum stieß dieser Ansatz an Grenzen: Er skalierte nicht ausreichend und konnte die zunehmende Komplexität nicht mehr abbilden. Vor allem war er reaktiv – er zeigte, was bereits passiert war.

Chef und Kunden sind keine Monitoring-Werkzeuge. Warum ein Problem erst bemerken, wenn es schon eingetreten ist? Wenn der Chef oder gar ein Kunde als Erster eine Störung meldet, läuft der Betrieb der Situation bereits hinterher. Neben dem eigentlichen Ausfall steht dann auch das Vertrauen in die Arbeit des Teams auf dem Spiel – nach innen wie nach außen.

Der Klassiker: auslaufende TLS-Zertifikate. 2000 gab es die heute vertrauten Möglichkeiten zur automatischen Zertifikatserneuerung noch nicht in dieser Form. Let’s Encrypt kam erst deutlich später, 2015. Wir mussten bevorstehende Ablaufdaten überwachen, statt sie durch eine fehlgeschlagene Verbindung zu entdecken. Anforderungen und Zertifikatsanbieter können unterschiedlich sein; auch eine automatisierte Erneuerung muss überwacht werden.

Erkennen, melden und Daten behalten. Unsere erste Wahl waren Nagios und Zabbix. Wir brauchten Prüfungen, die Probleme erkannten, und Meldungen, die jemanden erreichten, der handeln konnte. Die Benachrichtigungen gingen insbesondere an das 24/7-Bereitschaftsteam, damit Störungen rund um die Uhr bearbeitet werden konnten. Aus Kostengründen hatte die Website damals noch keine High-Availability-Architektur. Zuverlässige Erkennung und schnelle Reaktion waren deshalb entscheidend, um eine möglichst hohe Servicequalität zu sichern; das Monitoring selbst beseitigte das Ausfallrisiko nicht. Über die Jahre kamen unterschiedliche Meldewege zum Einsatz, darunter SMS, WhatsApp und PagerDuty. Das beschreibt die spätere Entwicklung, nicht einen vollständigen Werkzeugkasten von 2000.

Vom einzelnen Alarm zur Entwicklung über Zeit. Aufgezeichnete Performancemetriken ermöglichten den Blick über den einzelnen Alarm hinaus: Wie entwickelten sich Last, Latenzen und verfügbare Kapazität? Später ergänzten Grafana und Checkmk die Werkzeuglandschaft. Das Ziel blieb, Verschlechterungen früher zu erkennen und anhand der Daten zu verstehen, wohin sich die Systeme entwickelten.

Der Gedanke dahinter. Monitoring ist mehr als eine Sammlung von Dashboards. Es soll dem Team die Chance geben, zu handeln, bevor jemand anders auf ein Problem aufmerksam machen muss.

Historische Quelle: Ankündigung des ersten öffentlichen Let’s-Encrypt-Zertifikats (2015).