用 Docker 部署 HertzBeat 之前我先说说为什么会对这套无代理监控方案产生兴趣。在监控告警这个领域部署最费劲的从来不是服务端而是被监控端。Zabbix 要装 Agent、Prometheus 要装 Exporter、云厂商的监控要装插件不管哪个方案只要机器一多光是把采集端铺到每台机器上就够喝一壶。HertzBeat 好就好在把“无代理”和“实时监控”揉在了一起服务端主动去探测被监控机器什么都不用装再配合容器化部署整个告警平台的落地难度比传统方案低一个量级。如果你正在纠结用什么做监控或者已经受够了维护一堆采集代理这篇内容应该对你有用。我会按自己实际部署的顺序把从环境准备到日常维护的完整路子讲一遍该避的坑也一并列出来。1. 为什么我最终选了 HertzBeat无代理监控到底省了什么1.1 传统监控方案的“最后一公里”问题说起监控很多人的第一反应是 Zabbix、Prometheus 或者 Grafana但真正上手过的人心里都清楚这套东西的常态是“服务端半天装好被监控端能折腾你半个月”。我早年用 Zabbix 给客户做监控最烦的不是配置模板而是给每台机器装 Agent。公司内部环境还能用自动化脚本批量分发一旦到了客户的生产环境要么安全部门要求审批要么机器不允许临时开端口要么装机脚本被杀软干掉基本每一步都在扯皮。Prometheus 好一点但 node_exporter 一样要装、要维护、要升级。等你花大力气把所有采集器都装好业务早迭代好几轮了。这也是我后来更偏好无代理方案的原因。监控系统的意义是让被监控端尽量无感而不是抢业务的资源、惹业务的烦。HertzBeat 把“无代理”作为核心设计最大的价值不是省掉了那点 Agent 占用的 CPU 和内存而是省掉了整个分发、升级、权限管理的流程。这个转变在监控对象少的时候不明显一旦到了几十台甚至上百台差距就是天壤之别。1.2 无代理监控的原理它到底怎么“看见”你的机器HertzBeat 并不是用什么“隐形的 Agent”在干活它的思路很朴素把采集逻辑全部放在服务端通过一个个协议去主动访问被监控对象。比如监控一台 Linux 主机它用 SSH 连上去执行命令读取系统指标也支持 SNMP监控 MySQL它用 JDBC 连接数据库去查状态变量监控 Redis它向 Redis 发一条 INFO 指令监控 JVM它走 JMX监控网站或 API它发 HTTP 请求把返回码、响应时间、内容大小这些信息拿回来。所有动作都由 HertzBeat 服务端按你设定的采集周期发起指标收回来后落到存储里再通过 Web 控制台以图表方式呈现。你可以把它想象成物业安排的巡逻保安而不是在每户门口装一个 24 小时值班的哨兵。好处是零部署、零常驻进程坏处是巡逻频率受服务端能力和网络质量影响不可能做到像 Agent 那样线程级的高频采样。理解这一点很重要因为它决定了后续应该如何设置采集周期也决定了无代理模式适合什么场景、不适合什么场景。1.3 无代理不是银弹边界与取舍不过我得泼一盆冷水无代理模式解决的是“部署和管理”问题没办法解决全部监控需求。它要求监控机能直接访问被监控端的网络和管理口像 SSH、JDBC、JMX 这种凭据型采集意味着高权限账号会存在 HertzBeat 的存储里安全上要格外谨慎服务端主动轮询也会带来额外的网络开销监控机离被监控端太远、抖动太大采集周期和数据质量都会受影响。再有就是无代理采集到的指标往往是操作系统或中间件暴露出来的结果而不是进程内部的深入可观测数据。如果你要给 Java 应用做调用链分析那还是老老实实用 APM Agent。所以我在实际选型时通常把 HertzBeat 放在“快速覆盖主机、数据库、中间件的可用性指标”这个定位上而不是把它当成全量采集的唯一方案。小团队、个人开发者、边缘节点监控、快速补充监控覆盖这些场景它非常舒服但如果你有严格的合规要求和超大规模采集需求还是得按场景混合使用。2. Docker 环境准备踩过的坑一次说清2.1 先把运行环境摸清楚HertzBeat 本身是 Java 写的官方镜像打包得很完善对宿主机的要求其实很低。你只要有一个能正常跑容器的 Docker 环境就行。我建议 Docker Engine 20.10 以上Compose V2 是标配。Linux 上通常通过安装 docker-compose-plugin 来获得 compose 命令Windows 和 macOS 直接装 Docker Desktop。装完先别急着跑容器用一句docker version验证一下。能看到 client 和 server 两段都正常返回才说明 Docker 的后台服务真的起来了。很多人明明装好了执行docker ps也能看列表但一创建容器就报连接 Docker API 失败多半是 Docker Desktop 的 Linux 后端还没就绪或者 WSL2 内核版本太旧。遇到这种情况别瞎折腾把 Docker Desktop 完全退出再启动一次往往就好。2.2 装 Docker 时最常碰到的三个问题还是那句老话环境问题占了部署问题的一半。我把自己遇到最多的三件事列出来第一Windows 上启动 Docker Desktop 报 Virtualization support not detected。这是 BIOS 或 Windows 功能没开完。先看 BIOS 里 VT-x 或 AMD-V 有没有开启再检查“启用或关闭 Windows 功能”里的 Hyper-V、虚拟机监控程序和 Windows Subsystem for Linux 是否打勾然后重启。别嫌重启麻烦这步跳过后面会反复出问题。第二镜像下载慢。HertzBeat 镜像和数据库镜像都是从 Docker Hub 拉取网络不好时会卡到怀疑人生。建议在 Docker 配置里设置 registry mirror 来解决。Windows 在 Docker Desktop 的 Settings 里改Linux 在/etc/docker/daemon.json里加 registry-mirrors 字段改完重启 Docker。这里强调一句镜像源地址一定要通过正规渠道获取不要执行网上来路不明的一键脚本免得被塞了恶意镜像。第三Linux 下权限问题。普通用户执行 docker 命令报 permission denied把当前用户加入 docker 组重新登录终端就好。不要图省事去修改 docker socket 的权限那种做法等于给机器开了个大后门后面出了问题追都追不回来。2.3 数据目录和资源预算HertzBeat 的配置、监控历史、告警记录、用户信息都会产生数据。默认情况下这些数据写在容器内部容器一删就没了。所以第一步就得把目录挂出来。我习惯在宿主机建立一个/opt/hertzbeat目录下面分 data 和 logs 两个子目录容器启动时把对应路径挂载进去。资源方面如果监控 10 台以内的机器2 核 4G 够用监控 30 台以上或要接多套中间件建议 4 核 8G。内存是关键毕竟 Java 应用加数据库都要占内存。磁盘按指标保留周期和采集频率规划通常预留 30GB 以上不会心慌。别等磁盘满了再清理那时监控数据早就开始丢失了。3. 用 Docker Compose 拉起来一套 HertzBeat3.1 一个能跑的 Compose 文件我先把结论放在前面第一次部署别追求完美架构先把一套能跑的简单 Compose 拉起来后面再按规模去接外部存储。下面是我常用的一份放在/opt/hertzbeat/docker-compose.ymlservices: hertzbeat: image: apache/hertzbeat:latest container_name: hertzbeat ports: - 1157:1157 environment: TZ: Asia/Shanghai volumes: - hertzbeat-data:/opt/hertzbeat/data - hertzbeat-logs:/opt/hertzbeat/logs restart: always volumes: hertzbeat-data: hertzbeat-logs:这份配置本身没有接独立数据库用的是镜像内置数据库对个人和中小团队来说初期完全够用。两个命名卷分别挂 data 和 logs容器升级或重建时数据不会丢。TZ 设置为 Asia/Shanghai目的是让告警时间和界面时间跟本地一致否则后面看告警记录会对不上时间。restart: always 保证机器重启后监控服务自动拉起省了手动干预的麻烦。3.2 启动、看日志、进控制台执行步骤很简单cd /opt/hertzbeat docker compose up -d docker compose logs -f hertzbeat第一次启动会拉取镜像并初始化数据库耐心等一两分钟。看到日志里输出启动成功信息后浏览器访问http://服务器IP:1157就能打开控制台。默认账号 admin默认密码 hertzbeat具体以当前版本官方文档为准。如果你用的是云服务器别忘了安全组放行 1157 端口。页面打不开时先docker ps看容器状态再docker compose logs看异常日志这两步能解决大部分问题。3.3 第一次登录先做这三件事第一修改默认密码。默认密码是公开写在文档里的服务器一旦暴露到公网不马上改密等于裸奔。第二把管理员通知信息配好尤其是邮箱后面告警配置和找回密码都用得上。第三花几分钟翻一下“监控类型”列表。你会发现系统内置了相当多监控模板从 Linux、MySQL、Redis到 Elasticsearch、Nginx、Tomcat、网站、Ping 等每个模板都预置好了采集指标和对应协议不需要写代码就能快速扩展监控对象。这一点对新手特别友好因为很多监控系统想要新加一个自定义采集项至少得改配置、重新加载而 HertzBeat 把监控类型做成了可配置资产直接在界面上往模板里套目标就行。所以你第一天上手就已经拥有一套覆盖几十种常见监控对象的平台剩下的工作只是“填 IP、填账号、选指标”。4. 上手添加监控一台 Linux 主机的无代理监控全过程4.1 从界面到第一台服务器的步骤具体操作顺序我建议这样做在左侧菜单进入“监控”点击“新增监控”。选择“Linux”类型。填写被监控主机的 IP 地址SSH 端口默认 22认证方式选密码或密钥填上可登录的账号。设置采集周期一般 60 秒即可需要更实时可以调成 30 秒但要评估服务端压力。勾选指标组CPU、内存、磁盘、网络这些尽量全选后续就不用反复补。点“保存并开始采集”等几秒进入详情页。能正常看到曲线图说明这套无代理采集已经跑通了。如果采集失败页面会给出错误提示比如连接超时、认证失败直接按提示调整就好。这一步走通之后你对 HertzBeat 的采集逻辑基本就有数了后面再加别的监控类型都是同一个套路。4.2 填参数时最容易错的几个地方这部分全是我踩过的坑。一是网络层不通。云主机的安全组规则经常一层套一层监控机所在网段被拦在中间SSH 端口根本连不上。我一般先在监控机上用 telnet 或 nc 试一下被监控端的端口通了再加到 HertzBeat。二是账号权限不对。SSH 采集至少得能执行 free、df、cat /proc/stat 这类命令如果账号被限制成 SFTP-only或者没有 shell 登录权限采集一定会失败。所以监控账号和普通运维账号最好分开建权限给到“能读系统状态”就够了。三是端口改了忘了填。生产环境里 SSH 端口经常不是 22如果照搬模板死活连不上。四是特殊字符密码。密码里有 $、、空格时从别处复制过来很容易带隐藏字符填完可以保存再编辑检查一遍。五是采集周期调太激进。我见过有人为了“实时”把周期改成 10 秒指标组还全勾结果监控机本身的 CPU 先被打满了。实时监控要的是效果不是数字够用就行。4.3 同一套思路扩展数据库和中间件监控Linux 主机能监控之后数据库和中间件也是同样的套路。拿 MySQL 举例新增监控类型选 MySQL填 JDBC URLjdbc:mysql://IP:3306/mysql再填一个有最小查询权限的账号HertzBeat 通过 JDBC 连接获取连接数、慢查询、InnoDB 状态等指标。Redis 更直接填 IP、端口、密码它定期执行 INFO 命令。Nginx 则可以借助已有的 HTTP 状态模块或通过端口探测方式实现基础可用性监控。整个过程都不需要在目标服务器上安装任何插件这是无代理方案最舒服的地方。实际工作中遇到生产环境不让动、安全策略严格的情况无代理几乎是唯一不扯皮又合规的补充手段。不过要记住给监控账号最小权限别图省事拿 root这和前面 SSH 监控的原则是一样的。5. 告警平台不是“有通知就行”规则和通知渠道的调教经验5.1 告警阈值设计怎么定才不炸群我刚开始用 HertzBeat 时默认配了一堆阈值结果一天几百条告警群里全是噪音。后来才明白告警规则的关键不是“触发条件”而是“触发什么条件下才值得打扰人”。我现在的做法是单点阈值要留余地同时附上持续时长。比如 CPU 使用率超过 90% 并且持续 5 分钟才触发告警这样能过滤掉大量瞬时抖动。磁盘使用率这种增长型指标阈值可以设低一点比如 80% 就告警因为从收到告警到扩容需要时间。内存和网络流量这种波动大的指标还要结合采集周期的历史数据来看不能只盯单点。告警级别也要区分严重级别走群通知普通级别走邮件不然大家很快会对所有告警免疫。阈值这种东西没有标准答案一定要根据业务特点调。5.2 通知渠道接入从邮件到钉钉/企业微信/WebhookHertzBeat 的通知渠道覆盖了大多数团队的需求邮件、钉钉、企业微信、飞书、Webhook还有短信类可以按官方文档扩展。配置方式都不复杂就是在通知渠道页面填对应的 webhook 地址、密钥或账号信息。我的建议是邮件必须配因为它是兜底方案不会因为群机器人被移除而彻底失联同时给常用内部群配一个机器人比如企业微信或钉钉这样手机能第一时间收到。Webhook 则适合做联动你可以把它接到自己的工单系统或者写一个脚本做自动处理。这里有一个安全提醒webhook 地址本质上是一个“谁拿到谁就能往群里发消息”的入口别把它截图发到群里也别写死在公开项目里用环境变量来管理更稳妥。配置完成后记得到测试页面发一条测试消息别等出了故障才发现渠道是断的。5.3 告警收敛与升级少发、精发、能闭环收到告警只是第一步能不能有效处理才是告警平台的真正考验。建议打开“恢复通知”HertzBeat 在告警恢复后能自动发一条恢复通知这样值班的人不用再去翻平台确认。还要给同类告警设置收敛比如同一台机器同一个指标15 分钟只发一次通知避免网络一抖动就刷屏。级别处理上白天普通告警发邮件夜间严重告警发群并且可以配升级规则如果你们有工单系统通过 Webhook 把告警联动进去这样每一条告警都有记录、有负责人、有闭环。最怕的就是告警规则太多太乱最后所有人都静音监控平台形同虚设。我在接手过的环境里见过一天一千多条通知的情况那种局面已经不是监控工具的问题而是规则治理的问题。6. 维护、升级与几个让我头大的坑6.1 数据备份和升级流程备份这件事说破天也就是一个词定期。如果用的是内置数据库把挂载目录打一个 tar 包就够了后来接了 PostgreSQL用pg_dump导出。我习惯用 crontab 每天凌晨打包保留最近 7 天存到独立磁盘或者对象存储。升级的流程是先在有备份基础上执行docker compose pull再docker compose up -d。如果用了指定版本号要先改好 tag 再执行。升级完进控制台看版本号和监控任务是否正常镜像有大的版本跳级时建议先到官方 release 页面看看有没有破坏性变更。我身边有人因为图快升级从不看 release note结果配置格式不兼容整个平台直接起不来教训很深刻。6.2 一份很实用的故障排查清单日常使用中我总结了一份排查清单基本能覆盖高频问题现象大概率原因处理办法页面打不开端口未映射或云防火墙拦截docker ps 看端口映射ss 查看监听安全组放行 1157容器反复重启数据目录权限不对或配置错误查看 docker logs检查挂载目录属主和容器内用户新增监控一直失败协议端口不通、凭据错误telnet 测试端口查看采集详情里的错误信息告警没通知通知渠道配置错误或 webhook 失效在通知配置里发测试消息检查白名单界面时间差了 8 小时时区环境变量缺失设置 TZAsia/Shanghai 后重建容器磁盘占用增长快指标保留周期太长或采集频率过高调整保留周期评估采集频率排查时记住一个原则先看网络通不通再看凭据行不行最后才看配置。很多问题其实就出在最基础的网络连通性上一上来就怀疑软件 bug往往白费功夫。6.3 一段时间的真实使用感受最后聊点我自己的使用感受。HertzBeat 最让我舒服的一点是“捡起来快、放下也快”。临时要观察几台机器十分钟内就能上线项目结束停掉容器就行不会在每台机器上留下要清理的 Agent。对中小团队和个人开发者来说这种克制的部署方式比什么都重要。如果后续监控规模上到几百台、指标量很大我会考虑把存储换成独立的时序数据库HertzBeat 本身支持这种扩展监控定义很灵活存储层替换也不会伤筋动骨。写这篇的时候我顺手看了下官方仓库最近更新很频繁监控模板也越来越全这种活跃维护的开源项目用在生产环境里至少不用担心放着放着就凉了。对我个人来说无代理这个定位就是最大竞争力部署简单、覆盖够广刚好卡在中小场景最痛的那块需求上。