Apache HertzBeat : collecter métriques et logs sans installer d'agent
An AI-powered next-generation open source real-time observability system.
En bref
- De quoi s’agit-il ?
- HertzBeat réunit collecte, alerting et diffusion de notifications dans une seule application Java, avec des modèles de collecte décrits en YAML. Le point à vérifier avant de l'adopter est la gouvernance de ces fichiers de modèles, pas la liste des protocoles pris en charge.
- À qui s’adresse-t-il ?
- HertzBeat convient aux équipes qui doivent surveiller des ressources hétérogènes (SNMP, JDBC, SSH, JMX) sans déployer d'agent sur chaque cible, et qui acceptent de gérer leurs définitions de collecte comme du code versionné. Il ne convient pas à qui cherche une base de séries temporelles à très longue rétention ou un écosystème d'exportateurs déjà standardisé : dans ce cas Prometheus reste le bon outil.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 2 jours.
- En quel langage est-il écrit ?
- Principalement Java, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème : surveiller ce qui n'accepte pas d'agent
Beaucoup d'éléments d'un système d'information ne peuvent pas recevoir de collecteur installé localement. Un commutateur, une base de données ancienne, un serveur dont personne ne veut modifier l'image : pour ceux-là, il faut interroger depuis l'extérieur, avec le protocole que la cible expose déjà. HertzBeat part de ce constat. Sa promesse tient en une phrase du README : rendre configurables les protocoles Http, Jmx, Ssh, Snmp, Jdbc et Prometheus, de sorte qu'ajouter un type de surveillance revienne à écrire un fichier de modèle YML plutôt qu'à développer un plugin. Le public visé est donc l'équipe d'exploitation qui gère un parc mixte et qui veut un seul endroit pour la collecte, les seuils d'alerte et l'envoi des notifications, plutôt que trois outils reliés par des scripts. Le README annonce la prise en charge des services applicatifs, bases de données, caches, systèmes d'exploitation, middleware, serveurs web, réseaux et objets cloud-native. Cette liste est une intention de couverture, pas un inventaire vérifié : c'est aux modèles livrés de la concrétiser.
Deux processus, un port de contrôle et un port de données
L'architecture sépare le manager et les collectors. Le manager porte l'interface, les règles d'alerte et la diffusion des messages. Les collectors exécutent la collecte et remontent leurs résultats. Le README documente deux variables d'environnement qui matérialisent ce lien : MANAGER_HOST pour l'adresse du manager et MANAGER_PORT, dont la valeur par défaut est 1158. Une troisième variable, IDENTITY, donne au collector un nom unique, ce qui permet de distinguer plusieurs collectors dans une même installation. Le mode d'exécution se choisit avec MODE, soit public pour un cluster classique, soit private pour un scénario cloud-edge. Cette séparation a une conséquence pratique : un collector placé dans un réseau isolé peut interroger des cibles que le manager ne voit pas, et seul le flux collector vers manager doit être autorisé. Le README mentionne aussi la possibilité d'étendre horizontalement le nombre de collectors. C'est le mécanisme de montée en charge annoncé, et il repose sur le manager comme point de convergence, donc comme élément à dimensionner en conséquence.
Les modèles YML sont le vrai centre de gravité
La personnalisation passe par un fichier YML décrivant quoi interroger et comment interpréter la réponse. Le README donne l'exemple de K8s ou Docker : on adapte un nouveau type de surveillance en le configurant en ligne, sans écrire de code Java. C'est un choix d'ingénierie assumé et il a un revers. Un modèle est une pièce logicielle : il encode des noms de champs, des chemins de réponse, parfois des unités. Quand la cible change de version et renomme un compteur, le modèle casse silencieusement ou remonte des valeurs fausses. HertzBeat ne supprime pas ce travail, il le déplace du compilateur vers un fichier de configuration. La bonne pratique qui découle de cette conception est de traiter les modèles comme du code : les versionner, les relire, les tester contre une instance réelle avant de les appliquer à la production. Le README ne décrit pas de mécanisme de validation des modèles, et je n'ai pas trouvé dans les éléments fournis de garantie sur ce point. À considérer comme une zone à explorer soi-même.
Installation : une commande, puis un fichier à relire
Le démarrage rapide tient en une commande Docker : docker run -d -p 1157:1157 -p 1158:1158 --name hertzbeat apache/hertzbeat. Le port 1157 sert l'interface web, accessible sur http://localhost:1157, avec le compte par défaut admin/hertzbeat. Le port 1158 est celui que les collectors contactent. Ajouter un collector se fait avec une seconde commande, où l'on remplace les valeurs par les vôtres : 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. Une installation par paquet est également documentée : télécharger apache-hertzbeat-xx-bin.tar.gz, ajuster si besoin hertzbeat/config/application.yml, puis lancer ./bin/startup.sh. Deux points méritent votre attention avant toute mise en production. Le premier est le compte admin/hertzbeat : changez-le avant d'exposer le port 1157. Le second est le fichier application.yml : le README le présente comme optionnel, mais c'est là que se règlent les paramètres d'instance, et la documentation liée est la seule source fiable à ce sujet. Le README précise que l'installation fonctionne sur x86 et arm64.
Alertes et diffusion : la partie qui remplace le bricolage
Le regroupement des alertes dans HertzBeat couvre deux flux. Les alertes internes, issues des seuils définis sur les métriques collectées, et les alertes externes, poussées par d'autres systèmes. Le README mentionne des règles à seuil, en temps réel ou périodiques, ainsi que le regroupement, la mise en silence et la suppression. Ce dernier point compte : la suppression d'alertes est ce qui évite qu'une panne réseau génère mille notifications identiques. La diffusion se fait ensuite par Email, Discord, Slack, Telegram, DingTalk, WeChat, FeiShu, SMS, Webhook ou ServerChan. La présence d'un canal Webhook générique est ce qui rend l'outil intégrable dans une chaîne existante sans attendre un connecteur dédié. Le README indique aussi l'intégration de sources de logs via le protocole OTLP, ce qui place HertzBeat en récepteur de logs autant qu'en collecteur de métriques. Je n'ai pas de détail sur la façon dont ces logs sont stockés ou indexés : le README ne le dit pas, et je ne peux donc pas me prononcer sur la rétention ou la recherche.
Ce que HertzBeat ne fait pas bien
La compatibilité Prometheus est mise en avant, mais elle ne fait pas de HertzBeat un Prometheus. Prometheus est d'abord une base de séries temporelles locale, avec un langage de requête et un modèle de rétention conçus pour l'analyse historique. HertzBeat se présente comme une plateforme de collecte, d'analyse et d'alerting unifiée, et le README ne décrit ni moteur de requête comparable à PromQL, ni politique de rétention longue. Si votre besoin principal est de conserver des années de métriques et de les interroger finement, l'approche diffère : Prometheus stocke et interroge, HertzBeat collecte et alerte. Autre limite, la liste de protocoles. Elle est fermée dans le README : Http, Jmx, Ssh, Snmp, Jdbc, Prometheus. Un protocole qui n'y figure pas suppose d'écrire un modèle, et un modèle ne peut décrire que ce que ces protocoles permettent d'atteindre. Enfin, le projet est en Java, avec les contraintes de mémoire et de démarrage que cela implique, contraintes que le README ne chiffre pas. Enfin, la mention AI-powered et MCP Server reste, dans le matériel fourni, une étiquette sans description de mécanisme : ne bâtissez pas une décision d'adoption sur cette partie.
Maintenance, licence et coût de mise à jour
Le rythme de publication est régulier : 1.8.0 en janvier 2026, v1.7.3 en août 2025, v1.7.2 en juin 2025, pour un dernier push sur master en septembre 2026. Cela indique un projet actif, pas une garantie de compatibilité entre versions. Le vrai coût de mise à jour ne vient pas du binaire mais des modèles YML que vous aurez écrits ou modifiés : une montée de version peut changer le format attendu, et c'est ce que vous devrez tester. Prévoyez de conserver vos modèles hors de l'image Docker, dans un dépôt, pour pouvoir les comparer d'une version à l'autre. Sur la licence, HertzBeat est distribué sous Apache-2.0, une licence permissive qui autorise l'usage commercial et la modification, avec obligation de conserver les mentions de copyright et le texte de licence, et une clause de brevets. Le projet est un projet Apache, avec une liste de diffusion dev-subscribe@hertzbeat.apache.org pour suivre les décisions. Ce paragraphe décrit la licence telle qu'identifiée dans le dépôt ; il ne constitue pas un avis juridique, et une intégration dans un produit distribué mérite une relecture par vos propres responsables licence.
Conclusion éditoriale
HertzBeat convient aux équipes qui doivent surveiller des ressources hétérogènes (SNMP, JDBC, SSH, JMX) sans déployer d'agent sur chaque cible, et qui acceptent de gérer leurs définitions de collecte comme du code versionné. Il ne convient pas à qui cherche une base de séries temporelles à très longue rétention ou un écosystème d'exportateurs déjà standardisé : dans ce cas Prometheus reste le bon outil. Avant de vous engager, vérifiez deux choses concrètement : le contenu réel du fichier hertzbeat/config/application.yml pour la version que vous téléchargez, et si les modèles YML fournis couvrent vos équipements, sachant qu'un protocole absent de la liste documentée (Http, Jmx, Ssh, Snmp, Jdbc, Prometheus) signifie un modèle à écrire vous-même, donc du travail de maintenance à votre charge.
Notes de la communauté