HertzBeat : monitoring sans agent avec Docker

Vous voulez surveiller des serveurs, des sites web et des bases de données sans installer un agent sur chaque machine ? Ce guide déploie Apache HertzBeat 1.8 avec Docker, puis vous fait créer votre premier monitor, lire les métriques collectées et régler une alerte sur seuil. HertzBeat interroge ses cibles à distance via des protocoles standards (HTTP, SNMP, SSH, JDBC), ce qui évite le déploiement d'agents. Public visé : administrateurs et DevOps à l'aise avec Docker Compose, débutants en supervision compris.

Ce que vous allez apprendre

Déployer HertzBeat avec Docker en quelques minutes
Naviguer dans le tableau de bord et comprendre son modèle
Ajouter un monitor pour surveiller un site ou un serveur
Lire les métriques collectées à distance
Configurer un seuil qui déclenche une alerte
Passer en production avec une base de données externe
Sécuriser l'accès avant toute exposition

Qu'est-ce que HertzBeat ?

Apache HertzBeat est un système de supervision temps réel open source, projet de l'Apache Software Foundation sous licence Apache-2.0. Sa particularité tient en un mot : sans agent. Là où beaucoup d'outils imposent d'installer un collecteur sur chaque machine surveillée, HertzBeat interroge ses cibles à distance, en parlant leur protocole natif.

Cette approche repose sur des modèles YAML : chaque type de cible (site web, serveur Linux, base PostgreSQL, équipement SNMP) est décrit par un modèle qui liste les métriques à collecter et le protocole à employer. HertzBeat sait ainsi parler HTTP, Ping, SNMP, SSH, JDBC, JMX ou Prometheus sans code supplémentaire, et de nouveaux types s'ajoutent en éditant un fichier de configuration.

La version 1.8 élargit le périmètre au-delà des seules métriques : collecte de logs, alertes centralisées avec règles de seuil, notifications multi-canaux et une page de statut publique. L'ensemble tient dans une image Docker unique pour l'évaluation, avec une architecture en collecteurs distribués pour les déploiements plus larges.

HertzBeat, Uptime Kuma ou Prometheus ?

Ces trois outils se recoupent en partie, mais visent des usages différents. Ce tableau évite de choisir au hasard.

Besoin	Outil adapté
Checks de disponibilité simples, page de statut	Uptime Kuma
Supervision multi-cible sans agent (serveurs, bases, réseau)	HertzBeat
Métriques applicatives haute fréquence, écosystème cloud-native	Prometheus

En clair : Uptime Kuma brille pour surveiller que des services répondent. Prometheus est la référence des métriques applicatives, mais suppose des exporters. HertzBeat occupe l'espace intermédiaire, quand on veut superviser un parc hétérogène (serveurs, sites, bases, équipements SNMP) sans déployer d'agent partout ni monter une pile complète.

Prérequis

Un hôte Linux avec Docker Engine et le plugin Compose, voir installer Docker
Un accès sudo sur cet hôte
De quoi joindre l'interface en local, ou un reverse proxy devant si vous l'exposez

Installer HertzBeat avec Docker

Pour découvrir l'outil, une image suffit : HertzBeat embarque une base H2 qui lui permet de démarrer seul, sans dépendance externe. Cette configuration est parfaite pour évaluer, pas pour la production (voir plus loin).

Créer un fichier compose.yaml. Le port de l'interface est publié sur la loopback uniquement, pour ne pas exposer l'outil pendant la découverte.

services:
  hertzbeat:
    image: apache/hertzbeat@sha256:75d48a62748fe42e4b2354e393ce567f51f7d46764b404763ec885cd23d74a0d  # 1.8.0
    container_name: hertzbeat
    ports:
      - "127.0.0.1:1157:1157"   # interface web
      - "127.0.0.1:1158:1158"   # port de collecte (collecteurs distants)
    volumes:
      - hertzbeat-data:/opt/hertzbeat/data
    restart: unless-stopped

volumes:
  hertzbeat-data: {}

Démarrer le conteneur.
Fenêtre de terminal
```
docker compose up -d
```
Attendre le démarrage. HertzBeat est une application Java, le premier lancement prend une trentaine de secondes. Vérifiez que l'interface répond :
Fenêtre de terminal
```
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:1157/
```
Un code 200 signale que l'interface est prête.

Ouvrez ensuite http://127.0.0.1:1157 dans un navigateur. La page de connexion s'affiche, avec les identifiants par défaut admin / hertzbeat.

Page de connexion de HertzBeat 1.8

Découvrir le tableau de bord

Une fois connecté, le tableau de bord donne la vue d'ensemble : le nombre de cibles par catégorie (bases, cache, système, middleware), la répartition des états, et l'activité des collecteurs. C'est le point de départ pour juger d'un coup d'oeil la santé du parc.

Tableau de bord de HertzBeat

La barre latérale organise les fonctions : Monitors pour les cibles supervisées, Threshold et Alarms pour les alertes, Log Stream pour les journaux, Notification pour les canaux. La barre de recherche en haut propose même une assistance conversationnelle pour interroger l'état de l'observabilité.

Ajouter un monitor

Un monitor est une cible surveillée. HertzBeat en propose des dizaines de types, chacun avec ses métriques. Pour un premier essai, supervisons un site web, le type le plus parlant.

Ouvrir le formulaire. Dans Monitors, cliquez sur New Monitor, puis choisissez le type Website.
Renseigner la cible. Le formulaire demande l'hôte, un nom de tâche, le port et, en option, une URI et l'activation HTTPS.
Régler l'intervalle. La section Advanced expose le collecteur, le type de planification et l'intervalle de collecte (60 secondes par défaut). On peut aussi attacher des labels pour organiser les cibles.
Valider. HertzBeat lance une première collecte immédiatement. La cible apparaît dans la liste avec son état, Up si la collecte réussit.

Le champ hôte accepte une adresse IP ou un nom de domaine. Pour surveiller un service interne, veillez à ce que le conteneur HertzBeat puisse le joindre sur le réseau Docker.

Consulter les métriques collectées

L'intérêt d'un monitor n'est pas seulement de savoir s'il répond, mais de lire ce qu'il mesure. Cliquez sur le nom d'une cible pour ouvrir son détail. Deux onglets structurent la vue : le temps réel et l'historique.

Détail d'un monitor avec ses métriques

La partie Summary liste les métriques du dernier relevé, comme le temps de réponse en millisecondes pour une sonde de disponibilité. L'onglet historique trace ces valeurs dans le temps, ce qui permet de repérer une dégradation progressive avant qu'elle ne devienne une panne. Chaque type de cible expose ses propres métriques : un serveur Linux remonte CPU et mémoire, une base de données son nombre de connexions.

Configurer une alerte sur seuil

Collecter ne sert à rien sans alerter. HertzBeat sépare proprement deux notions : le seuil décide quand déclencher, la notification décide à qui et comment le signaler. On commence par le seuil, dans Threshold.

Gestion des règles de seuil

Une règle de seuil associe une métrique (par exemple le temps de réponse d'un site) à une expression (supérieur à une valeur), un niveau de gravité et un message d'alarme. Cliquez sur New pour en créer une, choisissez la métrique et l'expression, puis liez-la aux cibles concernées par des labels. Dès qu'un relevé dépasse le seuil, HertzBeat crée une alarme visible dans le centre d'alertes, qu'un canal de notification (email, Slack, webhook) peut ensuite relayer.

Passer en production

La base H2 embarquée convient à l'évaluation, mais elle n'est pas taillée pour un usage sérieux : volumétrie limitée, pas de séparation entre données relationnelles et séries temporelles. En production, HertzBeat s'appuie sur une base PostgreSQL pour la configuration et une base de séries temporelles (VictoriaMetrics, GreptimeDB, IoTDB ou TDengine) pour les métriques.

Le projet fournit des fichiers Compose prêts à l'emploi pour ces combinaisons. Le plus courant associe PostgreSQL et VictoriaMetrics :

git clone https://github.com/apache/hertzbeat.git
cd hertzbeat/script/docker-compose/hertzbeat-postgresql-victoria-metrics
docker compose up -d

Ce dossier contient la configuration application.yml déjà câblée sur les deux bases. Adaptez les mots de passe avant tout démarrage réel, et prévoyez la sauvegarde des volumes PostgreSQL.

Sécuriser HertzBeat

HertzBeat expose une interface d'administration complète et un compte par défaut connu de tous. Trois précautions s'imposent avant toute mise en service.

Changer le compte admin / hertzbeat dès la première connexion. C'est la faille la plus évidente, et la plus exploitée.
Ne pas publier le port directement. Gardez 127.0.0.1:1157 en local, ou placez un reverse proxy avec authentification pour tout accès distant. L'interface donne accès à la configuration complète et aux métriques de tout le parc.
Isoler le port de collecte 1158 au strict nécessaire : seuls les collecteurs distants légitimes doivent l'atteindre.

Le port 1158 sert aux collecteurs, le 1157 à l'interface web. Distinguer les deux dans vos règles de pare-feu évite d'exposer l'un en croyant n'ouvrir que l'autre.

Dépannage

Les trois quarts des blocages au démarrage viennent de la même cause : HertzBeat est une application Java, et son interface ne répond pas tant que le contexte Spring n'est pas initialisé. Ne concluez donc pas à un échec avant d'avoir laissé passer une minute et lu docker compose logs. Les deux autres lignes touchent la connectivité depuis le conteneur, qui n'est pas celle de votre poste, et la persistance, qui dépend entièrement du volume monté.

Symptôme	Cause probable	Solution
L'interface ne répond pas au démarrage	Application Java encore en initialisation	Attendre 30 à 60 s, vérifier `docker compose logs hertzbeat`
Un monitor reste `hors ligne`	Cible injoignable depuis le conteneur	Tester la connectivité réseau, vérifier hôte et port
Les données disparaissent après redémarrage	Volume non monté	Vérifier le volume `hertzbeat-data:/opt/hertzbeat/data`
Perte de performance avec beaucoup de cibles	Base H2 saturée	Migrer vers PostgreSQL et une base de séries temporelles
Connexion refusée sur le port 1157	Port publié en loopback	Passer par un reverse proxy pour l'accès distant

FAQ : questions fréquentes

Ces questions portent sur ce qui décide de l'adoption : le modèle de licence, ce que recouvre exactement le monitoring sans agent, les identifiants de première connexion, l'aptitude à la production, le positionnement face à Prometheus et l'étendue des protocoles collectés.

HertzBeat est-il gratuit ?

Oui, HertzBeat est entièrement open source et gratuit. C'est un projet de l'Apache Software Foundation sous licence Apache-2.0, sans édition payante ni fonction bridée.

Que veut dire monitoring sans agent ?

Sans agent signifie qu'aucun logiciel n'est installé sur les machines surveillées. HertzBeat interroge ses cibles à distance via leur protocole natif (HTTP, SNMP, SSH, JDBC), depuis le serveur central. Cela simplifie le déploiement et évite de maintenir un agent par machine.

Quels identifiants pour la première connexion à HertzBeat ?

Le compte par défaut est admin avec le mot de passe hertzbeat. Ce couple est public et identique sur toutes les installations : il faut le changer immédiatement après la première connexion.

Peut-on utiliser HertzBeat en production ?

Oui, mais pas avec la base H2 embarquée du démarrage rapide. En production, HertzBeat utilise PostgreSQL pour la configuration et une base de séries temporelles (VictoriaMetrics, GreptimeDB, IoTDB ou TDengine) pour les métriques. Le projet fournit des fichiers Docker Compose prêts à l'emploi.

HertzBeat ou Prometheus, lequel choisir ?

Prometheus est la référence des métriques applicatives dans l'écosystème cloud-native, mais suppose des exporters. HertzBeat vise la supervision multi-cible sans agent d'un parc hétérogène (serveurs, bases, réseau) avec une interface prête à l'emploi. HertzBeat est d'ailleurs compatible avec les cibles Prometheus.

Quels protocoles HertzBeat sait-il collecter ?

HertzBeat collecte via HTTP, Ping, Port, SNMP, SSH, JDBC, JMX et Prometheus, entre autres. Chaque type de cible est décrit par un modèle YAML qui liste les métriques et le protocole, et de nouveaux types s'ajoutent en éditant un fichier de configuration.

À retenir

HertzBeat est un système de supervision sans agent, projet Apache sous licence Apache-2.0, qui interroge ses cibles à distance.
L'installation d'évaluation tient dans une image Docker avec base H2 ; garder le port en loopback.
Un monitor décrit une cible et son protocole ; les types couvrent sites, serveurs, bases et équipements réseau.
Le seuil décide quand alerter, la notification décide comment : les deux sont séparés.
En production, remplacer H2 par PostgreSQL plus une base de séries temporelles, via les Compose officiels.
Changer le compte par défaut admin / hertzbeat et ne jamais exposer l'interface sans reverse proxy authentifié.

Prochaines étapes

Uptime Kuma Le moniteur de disponibilité à comparer, plus simple pour des checks basiques.

Prometheus La référence des métriques applicatives pour l'écosystème cloud-native.

Reverse proxy Traefik Placer une authentification devant HertzBeat avant de l'exposer.

Installer Docker Mettre en place Docker Engine et Compose sur votre serveur.

Plus d'infos

Site officiel Apache HertzBeat : documentation et guides de déploiement.
Dépôt GitHub : code source, modèles de collecte et releases.