「服务器半夜出问题，谁能第一个知道？」——这是我们给自己提的需求原话。答案很扎心：没人知道，除非有一套会自己喊人的东西。开源监控告警系统搭建最快的路径是一条 Docker 命令：拉起 Apache HertzBeat，打开 1157 端口、用默认账号登录、加监控、配阈值、配通知渠道，四步走完就能收到告警。下面按项目拆解的方式把每个环节和官方写明的坑一次说清。
项目背景与目标
我们的需求很具体：不装 Agent、能采集、能判阈值、能发到钉钉和飞书、还要看得到历史曲线，缺一条这套系统就等于白搭。
选 HertzBeat 的理由也简单。Apache 软件基金会项目，Apache 2.0 许可证，无监控数量限制；采集走 HTTP、SSH、SNMP、JMX、JDBC、Prometheus 这些原生协议，被监控的机器不用装任何东西，网页里填 IP、端口和账号即可。它把采集、告警、通知做在同一个平台里，官方 FAQ 还专门对比过：Prometheus + Grafana 要额外配 Alertmanager 才具备告警能力，也没有内置的多渠道通知。仓库地址 github.com/apache/hertzbeat。
这套「采集 → 判阈值 → 分级 → 通知」的链路，跟我们做网站侧监控时是同一个思路。给关键词监控表定三级预警时我们就发现，难的不是采集，是分级——这次只是把它搬到服务器侧。
约束条件：这台机器能给什么
硬件上，官方 FAQ 给的下限是 2 核 CPU、4GB 内存（推荐 8GB）、磁盘 10GB 起步，普通云主机都能满足。
运行时，Docker 方式要求 Docker 20.10 及以上；走源码则按仓库主干当前的要求是 Maven 3+、Java 25、lombok，前端要 Node.js 与 pnpm，跑在 4200 端口。这几个版本号变动很快，动工前请回仓库 README 复核，以仓库最新说明为准。
有件事必须交代：我整理这份流程的机器没有 Docker 环境（命令行里 docker 指令不存在），所以下面的命令是对照官方文档与仓库脚本整理的路径，不是本机实跑的输出。参数、端口、配置文件名请以你拉取的镜像版本为准。镜像方面官方给了两个源，Docker Hub 上是 apache/hertzbeat，拉不动时换 quay.io/tancloud/hertzbeat。
执行过程：从一条命令到能收到告警
最小启动只有一行：
docker run -d -p 1157:1157 -p 1158:1158 --name hertzbeat apache/hertzbeat1157 是网页和 API 端口，1158 是集群与采集器的通信端口，两个都要映射，只映射 1157 的话后面加采集器会卡住。起完访问 http://你的IP:1157，默认账号 admin、密码 hertzbeat；生产环境第一件事就是去 sureness.yml 改掉账号体系，带着默认口令上线等于把控制台送人。
这条命令只适合试玩，因为它没挂卷。生产写法至少要把数据目录挂出来，并设好时区：
-v $(pwd)/data:/opt/hertzbeat/data -e TZ=Asia/Shanghai加监控以 Linux 主机为例：监控中心新增操作系统监控，填目标主机（IP 或域名，不带协议头）、SSH 端口默认 22、超时默认 6000 毫秒、是否复用连接默认关闭，填完在监控详情里就能看到指标。
配告警要连做三件事，漏一件就发不出去：先在告警里建阈值规则（实时规则或周期规则，用表达式判定指标并指定级别）；再在通知里建接收人，配好邮件、钉钉、飞书、企业微信、Webhook 之一；最后建通知策略并把接收人启用。
要上生产就别停在单容器。仓库 script/docker-compose 下有五套组合，官方推荐 PostgreSQL + GreptimeDB 那套：元数据库用 MySQL 或 PostgreSQL，时序数据交给 VictoriaMetrics、IoTDB、TDengine 或 GreptimeDB。这套 compose 默认把端口绑在 127.0.0.1，需要远程采集器接入时改 HERTZBEAT_BIND_ADDRESS，并且只把 1158 暴露给采集器所在网段——官方原话强调，改 0.0.0.0 之前必须先换掉默认凭据并加防火墙或 TLS。
结果：这套东西到底能给你什么
先把边界说清楚：默认部署下元数据存在内置 H2 文件里，指标只保留最近一小时的内存数据，历史图表不存在。想看一周趋势、想做容量规划，时序库这一步绕不过去。
它能给的也实在：一个收敛了采集、告警、通知的控制台；一套不用在被监控机器装东西的接入方式；告警的分组收敛、静默、抑制；以及可以对外发布的服务状态页。对中小团队来说，这几样凑齐已经够替代一大堆零散脚本。
成本要自己算。采集频率乘以监控目标数就是请求量，我们在指数采集上的经验是每天几百个词的规模接口成本约十几块，服务器侧虽不花钱，但把周期压到秒级会把对方连接数打满。还有一点是设计出来的：采集有周期，告警就一定有滞后，指数数据本身就不是实时的，别指望靠调阈值把滞后抹平。
可复用的部分
一是阈值分级。把关键词监控里的三级预警直接搬过来：紧急的走即时消息，一般的走群通知，可观察的只进告警中心不打扰人。分级不做，告警就会退化成噪音，最后被全员静音。
二是协议可配置带来的扩展性。它把监控类型定义成 YML 模板，协议、指标、采集方式都写在模板里，网页上就能改。遇到文档里没覆盖的中间件，照着现有模板改一份 YML 就能接入，不用写 Java。
三是采集器集群。跨机房或监控隔离网络时单独起一个采集器容器，用 IDENTITY 给唯一名称、MODE 选 public 或 private、MANAGER_HOST 指向主服务、MANAGER_PORT 默认 1158，主控在控制台里能看到注册上来的采集器。
不值得复制的部分
拿默认 H2 加不挂卷跑生产是最典型的一条。容器一删，监控配置和告警规则全没，历史指标更是从来没存过——官方把 /opt/hertzbeat/data 标成了重点卷。真要升级，Docker 方式就是停旧容器、拉新镜像、起新容器，前提是卷挂对了，否则升级等于清库。
二是网络地址。HertzBeat 和数据库都跑在同一台机器的容器里时，用 localhost 或 127.0.0.1 连不上，因为 Docker 默认的 bridge 模式下容器访问不到宿主机。官方给了两个解法：把连接地址改成宿主机对外 IP，或者启动时加 --network host。这种事我们在起其它开源项目时踩过同一类坑，属于容器网络通病。
三是时区。不设 TZ 图表时间会整体偏移，国内环境统一加 -e TZ=Asia/Shanghai，否则排查时告警时间和日志对不上，白耗几小时。
四是告警规则忘了绑接收人：告警中心有记录但没人收到消息，这种「系统工作了但等于没工作」的状态最难被发现。
剩下的属社区经验而非官方承诺：图表断续先看采集周期是否过长，存储盘写满会直接导致曲线大面积中断。出问题时第一动作永远是确认底层链路通不通——在被监控机上手动跑一次 ssh 或 curl，先排除网络和账号，再回来看 docker logs。这个排查顺序在任何部署场景都成立。
完整说明与部署脚本都在 Apache HertzBeat 仓库，本文命令与参数以仓库最新说明为准；监控第三方系统前请确认你有对应权限并遵守相关规范。
常见问题
Q：1157 打不开，页面一片白？
先看端口占用（netstat -tuln | grep 1157），再看 docker logs hertzbeat 里有没有启动报错；若换了外部数据库，确认库已建好且网络可达。
Q：历史图表弹窗提示要配时序数据库，是坏了么？
不是坏了，是设计如此。默认只留最近一小时内存数据，要历史曲线就在 application.yml 里配 VictoriaMetrics、IoTDB、TDengine 或 GreptimeDB，配完确认对应开关是 true。
Q：图表时间比本地差八小时？
容器没设时区，启动时加 -e TZ=Asia/Shanghai 再重启。社区里被反复提到，属于必踩项。
Q：采集器在控制台注册不上来？
三点挨个查：MANAGER_HOST 要填主服务对外 IP，容器场景填 127.0.0.1 必连不上；1158 端口两台机器之间要通；IDENTITY 在集群内必须唯一。最后看 docker logs hertzbeat-collector。
Q：告警中心有记录，钉钉群却没消息？
按链路倒查：阈值规则是否启用、通知策略是否启用、接收人有没有被策略选中。有记录没推送，问题一定在通知侧，多半是 Webhook 地址或加签密钥填错；渠道配置页一般有测试按钮，先发一条把错误逼出来。
