HertzBeat

定义

HertzBeat 是一个把监控、告警与通知合并在同一平台的实时监控系统，主要面向网站、API、端口、数据库、操作系统、中间件、云原生组件等对象^[2]。项目以 Java 编写、以 Apache 2.0 许可证发布，源码托管在 Apache 软件基金会的代码仓库中^[4]。

它的核心设计是把各种采集协议当作可以配置的内容：HTTP、JMX、SSH、SNMP、JDBC、Prometheus 等协议被抽象为监模板，用户只要编写或修改 YML 模板，就能定义新的监控类型和指标^[5]。因此，它并不要求被监控的一端安装专有采集程序，这一点与需要逐个节点部署代理的监控方案不同^[6]。

原理

系统运行时由服务端获取采集任务，并分发给采集器执行。服务端借助基于 Netty 的自定义 TCP 协议与外部采集器通信，并用一致性哈希把任务尽量均匀地分配到各采集器上；服务端内部还内置一个主采集器，因此没有外部采集器时也能以单机模式运行。

采集器收到任务后交由定时调度模块按设定间隔触发，采集任务进入队列，由专用线程与工作线程池并发执行；每次任务调用对应协议的采集策略，从目标系统拉取指标。这与推模式的采集思路不同，数据由服务端主动拉取。

结果回传后分成两条处理路径：一条进入告警队列，由实时告警计算模块按用户设定的阈值表达式判断是否触发；另一条进入存储队列，由后台线程批量写入时序数据库，供图表与历史查询使用。采集间隔 $T$ 与单次采集耗时 $t$ 之间需满足 $T > t$，否则任务会在队列中堆积。

阈值分为实时阈值与周期阈值两类。前者在指标更新时即时评估，适合对响应速度要求高的场景；后者按周期或定时任务评估，适合开销较大的聚合指标，从而降低计算成本^[6]。告警产生后还要经过分组收敛、抑制与静默等环节，再按通知策略分发到邮件、钉钉、飞书、Slack、Telegram、短信、Webhook 等渠道^[7]。

flowchart LR

M[服务端 Manager] -->|Netty TCP 任务分发| C[采集器 Collector]

C -->|按协议拉取指标| T[被监控目标]

C --> Q[结果队列]

Q --> A[告警计算]

Q --> S[时序数据库存储]

A --> N[通知渠道]

S --> U[Web 界面展示]

发展历程

项目于 2021 年启动，2022 年 1 月在代码托管平台开源，由 Dromara 开源社区孵化、TanCloud 开源，早期版本支持网站、API、PING、端口、数据库等监控类型^[8]。早期代码按 manager、collector、scheduler、warehouse、alerter 等模块拆分，模块之间保持低耦合，便于定制开发^[9]。

2023 年 8 月，集群版本发布。此前项目只有单机版本，采集数量上限受单节点限制，也难以统一纳管处于不同隔离网络中的资源；集群版重写了任务调度，使采集器可独立部署，并支持多隔离网络与云边协同^[10]。2023 年 12 月发布的 1.4.3 版本加入了对 Prometheus 生态的兼容，并支持使用 VictoriaMetrics 作为指标存储^[11]。

2024 年 4 月 5 日，项目通过 Apache 软件基金会的投票，进入 Apache 孵化器^[1]。同年 6 月 15 日，它发布第一个 Apache 版本 1.6.0；孵化期间共发布 5 个符合基金会规范的版本，新增 IPMI、PLC、Redfish 等协议支持，并补充了周期性阈值、告警抑制与静默、服务发现、多语言界面等能力^[3]。2025 年 8 月 21 日，Apache 董事会通过毕业决议，项目结束 17 个月孵化，成为 Apache 顶级项目^[3]。

当前版本在原有指标采集之外，还强调日志统一收集、告警集中分发与智能分析，并通过 OTLP 协议接收多来源日志，同时内置 MCP Server 等对外接口^[12]。

应用

典型用法是在监控中心新建监控任务并选择目标类型，填入连接信息后先测试连通性再保存；之后可在任务详情页查看实时数值与历史趋势图，并为关键指标建立阈值规则^[6]。以内置的 PostgreSQL 监控为例，系统会连接数据库执行查询，采集缓存命中率、事务统计等指标；JMX 监控则直接连接 JVM 进程，读取类加载、线程数与堆内存等信息^[6]。

官方内置了大量监控模板，覆盖 MySQL、PostgreSQL、Redis、ElasticSearch、MongoDB、Kafka、Zookeeper、Tomcat、Kubernetes、Docker、Linux、Windows 以及多家厂商的交换机等对象，用户也可以导入自定义模板扩展类型^[11]。除阈值告警外，系统还提供状态页构建功能，用于对外展示服务运行状态^[2]。

部署方式包括 Docker 容器、安装包与源码启动，CPU 架构支持 x86 与 arm64，也提供 Helm 方式在 Kubernetes 环境中安装^[2][6]。在需要覆盖多个互不相通网络的场景中，可以在各网络内部署边缘采集器，由中心服务统一调度与展示^[10]。项目提案中列出创维、科大讯飞、国家电网等曾作为用户使用该系统^[8]。

局限

无代理架构依赖目标系统开放可访问的协议接口，采集能力受对端协议支持范围约束，对没有标准接口的对象往往需要借助脚本或自定义模板间接获取数据^[5]。采集采用拉取方式，被监控对象与采集器之间的网络连通性是前提，处于隔离网络中的节点须依靠边缘采集器覆盖^[10]。

系统对关系型数据库与时序数据库存在部署依赖，早期文档说明至少需要 MySQL 5 以上版本与 TDengine 2 以上版本配合运行^[9]。监控类型数量依赖社区持续适配，新增类型需要有人编写并维护对应模板，这与模板生态的活跃程度直接相关^[8]。

在功能定位上，它把采集、存储、告警与界面打包在同一产品中，与由多个独立组件拼接的监控方案相比，模块替换与深度定制的自由度有所不同^[6]。阈值判断基于表达式计算，告警准确性取决于规则设计与指标口径，规则设置不当会产生无效告警，因此系统另行提供分组收敛、抑制与静默机制来处理告警噪声^[7]。

参见

• Prometheus —— 开源监控与告警工具，HertzBeat 兼容其生态并可与其实时数据对接

• Apache 软件基金会 —— HertzBeat 于 2025 年从该基金会孵化器毕业，成为顶级项目

• 时序数据库 —— 存放 HertzBeat 采集指标数据的存储基础

• 简单网络管理协议 —— HertzBeat 采集交换机、路由器等网络设备指标所用的协议

• JMX —— 用于采集 Java 应用运行指标的规范

• Dromara —— HertzBeat 开源之初的孵化社区