Senticor · Open Source · Pre-Alpha
Vaktaro: Verfügbarkeitsprüfungen und OpenTelemetry
Ein Open-Source-Projekt von Senticor verbindet selbst betriebene Dienstprüfungen mit vorhandener Überwachung: mit eindeutigen Ergebniszuständen und geprüftem Datenweg bis zur Auswertung.
Ausgangslage: Eine weitere Messkomponente braucht einen Zweck
Ein Dienst kann aus einem Netz erreichbar sein und aus einem anderen nicht. Mehr Messungen helfen nur, wenn Betreiber sie einordnen, einem Standort zuordnen und unterscheiden können: Ist der Dienst ausgefallen oder fehlt lediglich ein Ergebnis?
- Grafana Cloud Synthetic Monitoring bietet bereits öffentliche und eigene Messpunkte mit Ergebnissen in der betriebenen Cloud-Plattform.
- Uptime Kuma bietet Verfügbarkeitsprüfungen, Benachrichtigungen und Statusseiten im Eigenbetrieb.
- Prometheus mit dem Blackbox Exporter ergänzt Dienstprüfungen in einer selbst verwalteten Überwachungsumgebung.
Vaktaro untersucht unabhängig betriebene Knoten, Ergebnisse in vorhandenen Auswertungssystemen und die künftige Zusammenarbeit eingeladener Teilnehmer. Das ist eine konkrete Projekthypothese in einem bestehenden Markt. Der Nutzen automatisierter Zusammenarbeit zwischen Knoten muss noch nachgewiesen werden.
Aufgabe und mein Beitrag
Meine Arbeit umfasste die Implementierung der Prüfungen, das Telemetriemodell, die Collector-Anbindung und die Validierung der Beispielinstallation. Die unmittelbare Aufgabe war ein nutzbarer einzelner Knoten: konfigurierte Webdienste prüfen, Ergebnisse lokal speichern und auswertbare Nachweise in eine bestehende Betriebsumgebung liefern.
Die Architektur trennt das Prüfen von Transport, Auswertung und Störungsbearbeitung. Damit übernimmt ein neuer Monitoring-Agent nicht zugleich jede Betriebsfunktion. Die Anbindung und ihre möglichen Fehler bleiben ausdrücklich Teil der Aufgabe.
Maßnahmen: Messungen für den Betrieb nutzbar machen
Festlegen, was eine Prüfung tatsächlich belegt
HTTP(S)-Prüfungen erfassen Antwortstatus, Dauer und Zertifikatsablauf. Zertifikate werden validiert; erlaubte Ziele, Weiterleitungen und Zeitlimits sind begrenzt. Eine erfolgreiche Anfrage belegt die Erreichbarkeit aus Sicht dieses Knotens. Sie bestätigt weder alle Nutzerabläufe noch alle Netzwege.
Lokale Ergebnisse von der Weiterleitung trennen
Der Knoten speichert Ergebnisse und gibt strukturierte JSON-Ereignisse aus. Grafana Alloy übernimmt die Weiterleitung. Die Beispielinstallation schreibt Protokolle nach Loki für Grafana-Abfragen; eine Alternative überführt Ereignisse in OpenTelemetry-Logdatensätze für ein konfigurierbares Ziel. Das sind alternative Datenwege. Der Knoten braucht kein eigenes Dashboard, keinen Alarmversand und keinen nativen OpenTelemetry-Exporter, um Prüfergebnisse bereitzustellen.
Zustände und Datenstruktur für die Diagnose auslegen
Ausstehende Prüfungen, fehlende Daten und gemeldete Fehler müssen unterscheidbar bleiben. Die Ansichten zeigen diese Zustände, statt fehlende Ergebnisse als bestätigten Ausfall zu behandeln. Die Kennung des Messpunkts ermöglicht Vergleiche. Ziel-URLs bleiben im Ereignisinhalt oder in strukturierten Metadaten, statt pro Ziel einen eigenen indexierten Protokollstrom zu erzeugen.
Den vollständigen Datenweg testen
Der Integrationsaufbau betreibt einen echten Knoten, Collector und Speicher und führt die Dashboard-Abfragen aus. Er prüft Übertragung, OpenTelemetry-Felder und jede Beispielabfrage, auch bei Installation in einem anderen Kubernetes-Namensraum. So werden Konfigurationsannahmen sichtbar, die ein laufender Container oder ein Screenshot nicht belegen. Geprüft werden die Daten hinter der Darstellung.
Kapazitätsmessungen für die nächste Änderung nutzen
Messungen unter Ressourcenlimits vergleichen geplante und tatsächliche Prüfausführung. Sie identifizierten den Aufwand des Thread-Modells pro Ziel als Skalierungsgrenze und begründeten eine geplante Überarbeitung der Nebenläufigkeit. Mess-Builds mit erhöhten Limits sind ausdrücklich vom unterstützten Knoten getrennt; ihre Werte sind keine Zusage zur produktiven Kapazität.
Ergebnisse: funktionierende Umsetzung und ihre Grenzen
Umgesetzt
Das Repository enthält HTTP(S)-Prüfungen, lokale Ergebnisse, einen definierten Ereignisstrom, Collector-Konfiguration und ein reproduzierbares Loki/Grafana-Beispiel. Getrennte Messpunkte lassen sich in der gemeinsamen Ansicht vergleichen. Die OpenTelemetry-Anbindung überträgt derzeit Logdatensätze.
Nachweise zur Prüfung verfügbar
Quellcode, Spezifikationen, Integrationstests und Messverfahren sind öffentlich. Sie zeigen sowohl das geprüfte Verhalten als auch die Grenzen der jeweiligen Messung. Umsetzung und Beispiele lassen sich unabhängig von einer Produktvorführung nachvollziehen.
Betriebsgrenze
Vaktaro bleibt Pre-Alpha. Peer-Netzwerk, automatisierte gemeinsame Bewertungen sowie native OpenTelemetry-Metriken und -Spans sind geplant. Bestehende Alarmierung bleibt für Benachrichtigungen zuständig. Die mitgelieferte Testumgebung hat weder dauerhaften Speicher noch Anmeldung. Für den Einsatz müssen Aufbewahrung, Zugriff, Wartung und Störungsbearbeitung verantwortet werden. Geringere Kosten oder kürzere Ausfälle sind nicht nachgewiesen.
Erkenntnisse für Monitoring-Entscheidungen
- Ungewissheit vor der Automation modellieren: Unbekannt, verspätet und fehlgeschlagen sind unterschiedliche Grundlagen einer Störungsentscheidung. Wer sie zusammenfasst, erzeugt unberechtigte Sicherheit.
- Die Anbindung nachvollziehbar halten: Ereignisbedeutung, Knotenkennung, Speicherfelder und Abfragen müssen zusammenpassen. Ein Monitoring-Produkt umfasst diese Vereinbarungen ebenso wie die eigentliche Messung.
- Die relevante Arbeitslast messen: Rechtzeitige und vollständige Prüfungen sind die erbrachte Leistung. CPU- und Speicherlimits allein belegen keine Kapazität; vereinfachte Tests und geänderte Mess-Builds brauchen klare Grenzen.
- Schrittweise einführen: Den vollständigen Datenweg zunächst begrenzt validieren, vorhandene Alarmwege erhalten und Zuständigkeiten festlegen, bevor das neue Signal Entscheidungen trägt.
Projekt und Dokumentation
Architektur: Prüfknoten und Telemetrie-Vertrag
Die Darstellung trennt aktive Prüfungen, lokale Ergebnisse und Weiterleitung. Die beiden dokumentierten Ausgabepfade sind Alternativen; die geplante Zusammenarbeit von Knoten steht außerhalb des heutigen Datenflusses.
Textbeschreibung des Diagramms
- Der Prüfknoten sendet HTTP(S)-Anfragen an konfigurierte Dienste. Status, Antwortzeit und Zertifikatsinformationen gelten für die Sicht dieses Messpunkts.
- Lokale Ergebnisse und strukturierte JSON-Ereignisse bilden die Übergabe an die Datensammlung. Fehlende Daten, ausstehende Prüfungen und bestätigte Fehler bleiben unterscheidbar.
- Grafana Alloy liest den Ereignisstrom. Im Beispiel gehen die Logs an Loki; Grafana fragt sie ab. Alternativ werden Ereignisse zu OpenTelemetry-Logeinträgen und über OTLP an ein gewähltes Backend weitergegeben.
- Diese Wege folgen nicht hintereinander. Es gibt keinen Loki-zu-OTLP-Pfad und keinen nativen Metrik- oder Span-Export des Prüfknotens.
- Der Testaufbau prüft die Ankunft der Ergebnisse und die Dashboard-Abfragen. Das getrennte Zukunftsfeld steht für geplante Kooperation eingeladener Knoten; die bestehende Alarmierung bleibt außerhalb des Knotens.