Apache HertzBeat: Monitoring ohne Agent, aber mit YML-Templates

Welche Lücke HertzBeat schließen will

Die meisten Monitoring-Stacks wachsen als Sammlung: Prometheus für Metriken, eine separate Pipeline für Logs, ein Alertmanager, dazu ein Werkzeug für Statusseiten. HertzBeat setzt dagegen auf eine einzige Anwendung, die Sammlung, Analyse, Alarmierung und Benachrichtigung zusammenführt. Das README beschreibt das als Integrationsversprechen und nennt als Zielgruppe Anwender, die ihre Observability-Anforderungen schnell und bequem abdecken wollen. Der praktische Nutzen liegt weniger in einem einzelnen Feature als in der Reduktion der Anzahl beweglicher Teile: ein Dienst, eine Oberfläche, ein Regelwerk.

Der zweite Unterschied ist die Konfiguration. Protokolle wie Http, Jmx, Ssh, Snmp, Jdbc und Prometheus sind dem README zufolge konfigurierbar, ein neuer Überwachungstyp entsteht durch das Anlegen eines YML-Templates. Wer schon einmal einen Exporter geschrieben, gebaut und in eine Container-Registry geschoben hat, erkennt den Unterschied sofort: Die Anpassung passiert in einer Datei, nicht in einem Repository. Das ist ein echter Vorteil für Teams ohne dedizierte Plattformentwicklung, und ein Nachteil für alle, die ihre Monitoring-Logik versionieren und testen wollen wie Anwendungscode.

Agentenlos heißt nicht ohne Gegenstelle

HertzBeat erhebt Metriken ohne installierten Agenten auf dem Zielsystem. Die Sammlung erfolgt über die genannten Protokolle, also über Schnittstellen, die das Ziel ohnehin anbietet oder die sich per Konfiguration aktivieren lassen. Für Betriebssysteme bedeutet das in der Regel Zugriff über SSH, für Java-Anwendungen über JMX, für Netzgeräte über SNMP. Der Vorteil ist offensichtlich: keine Paketverteilung, keine Neustarts, kein Agent, der nach einem Betriebssystem-Upgrade nicht mehr startet. Der Preis ist ebenso klar: Wo keine Schnittstelle existiert, gibt es nichts zu erheben.

Für Logs geht HertzBeat einen anderen Weg. Das README nennt das OTLP-Protokoll als Weg, über den mehrere Log-Quellen eingespeist werden. Das setzt voraus, dass die Quelle OTLP spricht oder ein entsprechendes Forwarding vorhanden ist. Wer ausschließlich Dateien auf einem Server liegen hat und keinen OTLP-Pfad dorthin baut, hat mit dem Log-Teil von HertzBeat nichts gewonnen. Diese Trennung zwischen agentenloser Metrik-Erhebung und protokollgebundener Log-Aufnahme sollte man vor der Evaluation verstehen, sonst plant man mit falschen Annahmen.

Manager, Collector und die Frage der Netzsegmente

Die Architektur trennt eine zentrale Instanz von optionalen Collectorn. Der Manager läuft auf Port 1157 für die Oberfläche und 1158 für die Kommunikation mit den Collectorn. Ein Collector wird über Umgebungsvariablen angebunden: IDENTITY setzt einen eindeutigen Namen, MANAGER_HOST und MANAGER_PORT zeigen auf die Hauptinstanz. MODE unterscheidet zwischen public und private, also zwischen einem öffentlichen Cluster und einer Cloud-Edge-Konstellation. Das README beschreibt die Cluster-Variante als horizontal erweiterbar und nennt explizit die Überwachung mehrerer isolierter Netze.

Das ist der architektonische Kern des Projekts. In Umgebungen mit getrennten Netzzonen steht der Collector in der Zone, die er beobachten soll, und leitet die Ergebnisse an den zentralen Manager weiter. Der Manager selbst braucht dann keinen Zugang in jede Zone. Wer nur ein Netz und eine Handvoll Hosts überwacht, kann auf den Collector verzichten und mit der Einzelinstanz arbeiten. Die Cluster-Fähigkeit ist eine Option, keine Voraussetzung, und sie kostet zusätzliche Betriebsarbeit: mehr Container, mehr Zertifikate, mehr Stellen, an denen die Verbindung zum Manager abbrechen kann.

Start in einer Zeile, Konfiguration in einer Datei

Der schnellste Einstieg ist der Docker-Befehl aus dem README: docker run -d -p 1157:1157 -p 1158:1158 --name hertzbeat apache/hertzbeat. Danach ist die Oberfläche unter http://localhost:1157 erreichbar, die Anmeldung erfolgt mit admin/hertzbeat. Dass ein Standardpasswort dokumentiert ist, gehört zu den Dingen, die man vor jedem produktiven Einsatz ändert.

Ein Collector kommt über ein zweites Kommando dazu: docker run -d -e IDENTITY=custom-collector-name -e MANAGER_HOST=127.0.0.1 -e MANAGER_PORT=1158 --name hertzbeat-collector apache/hertzbeat-collector. Die Werte für IDENTITY und MANAGER_HOST sind dabei an die eigene Umgebung anzupassen, der Port 1158 ist der dokumentierte Standard.

Alternativ nennt das README das Paket apache-hertzbeat-xx-bin.tar.gz, die Konfigurationsdatei hertzbeat/config/application.yml und den Start über ./bin/startup.sh. Sowohl x86 als auch arm64 werden unterstützt. Wer die Anwendung aus dem Quellcode baut, findet im README einen Verweis auf die Deployment-Dokumentation, die hier nicht vollständig vorliegt. Die Angaben zu den unterstützten Java-Versionen und zum Ressourcenbedarf lassen sich aus dem vorliegenden Material nicht ableiten.

Alarme weiterleiten ist der unterschätzte Teil

HertzBeat verarbeitet nicht nur selbst erzeugte Alarme, sondern nimmt laut README auch externe Alarmquellen auf und führt sie mit den internen zusammen. Dazu kommen Funktionen, die man sonst in einem separaten Alertmanager sucht: Gruppierung, Zusammenfassung, Stummschaltung und Unterdrückung. Für die Zustellung nennt das README Email, Discord, Slack, Telegram, DingTalk, WeChat, FeiShu, SMS, Webhook und ServerChan.

Bemerkenswert ist die Bandbreite der Kanäle, die auf den asiatischen Markt zielt. DingTalk, WeChat, FeiShu und ServerChan sind dort verbreitet, in europäischen Unternehmen selten anzutreffen. Wer diese Kanäle nicht nutzt, gewinnt durch sie nichts. Die relevante Frage ist eine andere: Wie viele der genannten Zustellwege sind in der eigenen Umgebung tatsächlich getestet, und was passiert, wenn ein Webhook nicht antwortet? Das README beschreibt die Kanäle, aber nicht das Verhalten bei Zustellfehlern. Das ist eine Lücke, die man in einem Testsystem selbst klären muss, bevor man Produktionsalarme darauf umstellt.

Wo HertzBeat das falsche Werkzeug ist

Die Template-basierte Erweiterung hat eine Grenze. Solange ein Ziel über Http, Jmx, Ssh, Snmp, Jdbc oder Prometheus erreichbar ist, lässt sich die Erhebung per YML beschreiben. Sobald eine Messung eine eigene Berechnung, eine Zustandsmaschine oder eine nicht unterstützte Protokollvariante erfordert, endet der Konfigurationsweg. Dann braucht es Änderungen am Collector selbst, und damit wird aus einem Konfigurationsprojekt wieder ein Entwicklungsprojekt.

Ein zweiter Fall: Wer bereits in PromQL denkt, wird die Ausdrucksmöglichkeiten von HertzBeat vermissen, wenn dort nur Schwellenregeln auf einzelnen Metriken vorgesehen sind. Das README nennt flexible Echtzeit- und periodische Schwellenregeln, aber keine Abfragesprache über Zeitreihen. Für Korrelationen über mehrere Metriken hinweg ist das eine Einschränkung, die man vor der Migration prüfen sollte.

Und schließlich die Größenordnung. Für einen einzelnen Server mit einer Handvoll Diensten ist der Betrieb eines Managers plus Datenhaltung mehr Aufwand als ein schlanker Exporter mit einem Sammler. HertzBeat spielt seine Stärken aus, wenn viele verschiedene Zieltypen und mehrere Netzzonen zusammenkommen.

Prometheus und Zabbix als Vergleich

Der naheliegendste Vergleich ist Prometheus. Dessen Modell besteht aus Scrape-Jobs, einer eigenen Abfragesprache und Exportern, die pro Zielsystem geschrieben und gepflegt werden. HertzBeat setzt dagegen auf ein zentrales Regelwerk aus YML-Templates und eine Oberfläche, in der sich diese bearbeiten lassen. Der Unterschied liegt nicht in der Erfassung, sondern in der Erweiterung: Prometheus verlangt Code, HertzBeat verlangt Konfiguration. HertzBeat bezeichnet sich im README als Prometheus-kompatibel. Wie weit diese Kompatibilität reicht, ob also bestehende Prometheus-Endpunkte unverändert abgefragt werden können und wie die Metriken abgebildet werden, geht aus dem vorliegenden Material nicht hervor. Das ist eine der ersten Fragen, die man an eine Testinstallation stellen sollte.

Der zweite Vergleich ist Zabbix, das ebenfalls agentenlos arbeitet und dessen Template-Modell dem Ansatz von HertzBeat ähnelt. Der Unterschied liegt weniger im Konzept als im Zustandekommen: HertzBeat ist ein Apache-Projekt mit einer Governance-Struktur, die Entscheidungen über die Community und nicht über einen einzelnen Anbieter trifft. Ob das im eigenen Fall ein Argument ist, hängt davon ab, wie stark man auf kommerziellen Support angewiesen ist. Für HertzBeat nennt das README keinen Support-Anbieter, sondern verweist auf Mailingliste und Chat.

Lizenz, Wartung und was vor dem Rollout zu klären ist

HertzBeat steht unter Apache-2.0. Das erlaubt den kommerziellen Einsatz, Veränderungen und die Weitergabe in veränderter Form, solange die Lizenzhinweise erhalten bleiben. Wer die Software verändert und weitergibt, muss die Änderungen kennzeichnen. Das ist eine übliche permissive Lizenz, und sie stellt keine Hürde für den internen Betrieb dar. Eine rechtliche Bewertung des eigenen Falls ersetzt dieser Absatz nicht.

Zum Wartungsaufwand lässt sich aus dem Material nur wenig Sagen: Die letzte Veröffentlichung ist 1.8.0 vom 31. Januar 2026, davor erschienen v1.7.3 im August 2025 und v1.7.2 im Juni 2025. Das deutet auf einen Rhythmus von mehreren Monaten zwischen Releases hin. Ob Minor-Versionen Konfigurationsformate brechen, ob es Migrationsskripte für die Datenhaltung gibt und welche Java-Version die Anwendung voraussetzt, geht aus dem README nicht hervor. Wer die Template-Sammlung über mehrere Versionen hinweg pflegt, sollte diese Fragen vor einem Upgrade klären, nicht danach. Der Verweis auf die Deployment-Dokumentation im README ist der Ort, an dem diese Angaben zu erwarten wären.

Redaktionelles Fazit

Wer viele heterogene Ziele mit einem einzigen Werkzeug abdecken will und dafür Konfiguration über Code akzeptiert, findet in HertzBeat einen sinnvollen Kandidaten. Wer Prometheus-PromQL bereits im Betrieb hat, sollte vorher prüfen, wie weit die Kompatibilität tatsächlich reicht. Vor dem Rollout im eigenen Netz ist zu klären, ob die Ports 1157 und 1158 durch die Firewall dürfen und ob die Collector-Variante mit MODE=public oder MODE=private zum Netzzuschnitt passt.

Offizielle Quellen

1. apache/hertzbeat on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases