hertzbeat

一个监控告警平台，凭什么进入 Apache 基金会？

想象一下：你维护着十几台服务器，上面跑着 MySQL、Redis、Nginx、K8s 集群，还有自己写的微服务。半夜三点，手机响了——某个节点的 CPU 打满了。如果有一套系统能提前感知这个问题，在它演变成故障之前就通知你，你会需要什么？

Apache HertzBeat 就是为这个场景诞生的。这是一个由 Apache 软件基金会孵化的开源可观测性平台，核心理念是把指标采集、日志分析、告警通知三大能力融为一体，配合 AI 驱动的智能分析，让运维从被动救火变成主动防御。截至目前，该项目已在 GitHub 收获超过 7250 颗星，并获得 OpenSSF 最佳实践认证。

图2：Apache 软件基金会官方项目

背景：为什么需要统一的可观测性平台？

传统的监控方案往往是"烟囱式"的：Prometheus 处理指标，Grafana 做可视化，ELK 处理日志，PagerDuty 处理告警。每一个工具都是业界精品，但组合在一起就变成了一场配置噩梦——数据孤岛、告警疲劳、运维复杂度飙升。

HertzBeat 的作者敏锐地捕捉到了这个痛点，决定打造一个统一平台来解决所有问题。项目最初发布于 2021 年，2022 年 donated 给 Apache 软件基金会，2023 年毕业成为 Apache 顶级项目（TLP）。这条成长路径本身就说明了一个问题：业界对"统一可观测性"的需求是真实且迫切的。

HertzBeat 是什么？用生活场景来类比

如果把运维系统比作一个小区物业，HertzBeat 就是那个全能型物业管家：

• 采集 = 物业每天巡检，记录每栋楼的温度、湿度、水压、电梯运行状态
• 分析 = 物业根据历史数据判断"这个时间点这个水压正常"
• 告警 = 物业发现异常，立刻通过微信群、短信、电话通知相关人员
• 统一平台 = 你不需要分别装水务 app、供电 app、消防 app，一个平台搞定一切

但 HertzBeat 更聪明的地方在于，它内置了 AI 驱动的智能能力。通过 hertzbeat-ai 模块，平台能对采集的时序数据进行智能分析，检测异常模式，预测潜在故障。

核心架构：模块化设计，各司其职

HertzBeat 采用了清晰的多模块 Maven 项目结构，整个系统由以下核心模块组成：

协议驱动：无需写代码就能监控新类型

这是 HertzBeat 最有特色的设计之一。与传统监控工具需要写插件不同，HertzBeat 通过 YAML 模板来定义监控类型。

例如，要监控一台 Linux 服务器，只需要创建一个 app-linux.yml 文件，定义好要采集的指标（如 CPU 使用率、内存占用、磁盘 I/O）和对应的 SSH/JMX 协议参数即可。这种"配置即监控"的理念大大降低了自定义监控的门槛。

目前 HertzBeat 开箱即用支持 100+ 种监控类型，覆盖：

• 数据库：MySQL、PostgreSQL、Redis、ElasticSearch、MongoDB、ClickHouse、IoTDB 等
• 中间件：Nginx、Tomcat、Kafka、RabbitMQ、Apache
• 操作系统：Linux、Windows、AIX
• 云原生：K8s、Docker、Prometheus
• 自定义：通过 Http Api、Jdbc、Shell 脚本自定义采集

告警能力：从规则到智能的全链路覆盖

HertzBeat 的告警系统支持多维度配置：

1. 实时阈值告警：当指标超过设定值时立即触发
2. 周期阈值告警：针对周期性指标（如每日流量峰值）设置
3. 告警收敛：相同告警自动合并，避免告警风暴
4. 告警静默：在维护窗口期静默告警
5. 多通道通知：支持 Email、Discord、Slack、Telegram、钉钉、微信、飞书、短信、Webhook 等

AI + MCP：可观测性与大模型的结合

hertzbeat-ai 模块是 HertzBeat 的"智慧大脑"，目前仓库中包含 37 个与 MCP（Model Context Protocol）相关的文件。MCP Server 的内置意味着：

• 外部 AI 助手可以通过标准协议查询 HertzBeat 的监控数据
• 告警事件可以被自动摘要和根因分析
• 自然语言查询监控状态成为可能

这代表了可观测性平台发展的一个重要方向：让 LLM 能读懂监控数据。

部署体验：一条命令跑起来

HertzBeat 提供多种部署方式：

• Docker Compose（推荐）：一行命令启动完整集群，script/docker-compose/ 下提供了适配不同数据库（MySQL+TDengine、PostgreSQL+GreptimeDB 等）的配置文件
• Helm Chart：原生支持 Kubernetes 部署，配合 Helm 一键管理集群
• 传统部署：下载安装包，配置 JDK 17+ 和数据库，手动启动

Web UI 方面需要单独拉取 submodule（webui 目录为独立 git submodule），配置略微繁琐，是这个小平台美中不足的地方。

局限与争议

HertzBeat 并不是完美的，以下几点值得注意：

• 数据库依赖：生产环境强烈建议使用 TDengine 或 IoTDB 等时序数据库，MySQL 作为时序存储性能有限
• Web UI 体验：界面美观度与 Grafana 相比仍有差距，对于习惯了 Grafana 的团队有一定学习成本
• 规模上限：单节点默认配置可支撑数百台机器的监控，大规模集群需要额外配置集群模式
• Java 生态绑定：作为 Java 项目，对非 Java 团队来说二次开发有一定门槛

行业意义：统一可观测性是大势所趋

在云原生时代，可观测性已经从"nice to have"变成了基础设施的标配。随着 Prometheus+Grafana 组合的流行，业界越来越意识到：数据的统一和工具的整合，比单纯的采集能力更重要。

HertzBeat 代表了一个方向：用一个平台解决所有可观测性需求。它的 Apache 顶级项目身份、活跃的社区、以及 AI 驱动的战略布局，都预示着这个项目还有很大的成长空间。

如果你正在寻找一个开源的 Prometheus 替代方案，或者需要一个能同时处理指标、日志、告警的统一平台，HertzBeat 值得关注。