企业官网建设流程全解析

用 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 拉起来一套 HertzBeat

3.1 一个能跑的 Compose 文件

我先把结论放在前面：第一次部署别追求完美架构，先把一套能跑的简单 Compose 拉起来，后面再按规模去接外部存储。下面是我常用的一份，放在/opt/hertzbeat/docker-compose.yml：

services: 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 从界面到第一台服务器的步骤

具体操作顺序我建议这样做：

1. 在左侧菜单进入“监控”，点击“新增监控”。
2. 选择“Linux”类型。
3. 填写被监控主机的 IP 地址，SSH 端口默认 22，认证方式选密码或密钥，填上可登录的账号。
4. 设置采集周期，一般 60 秒即可；需要更实时可以调成 30 秒，但要评估服务端压力。
5. 勾选指标组，CPU、内存、磁盘、网络这些尽量全选，后续就不用反复补。
6. 点“保存并开始采集”，等几秒进入详情页。

能正常看到曲线图，说明这套无代理采集已经跑通了。如果采集失败，页面会给出错误提示，比如连接超时、认证失败，直接按提示调整就好。这一步走通之后，你对 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 通知渠道接入：从邮件到钉钉/企业微信/Webhook

HertzBeat 的通知渠道覆盖了大多数团队的需求：邮件、钉钉、企业微信、飞书、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 一份很实用的故障排查清单

日常使用中我总结了一份排查清单，基本能覆盖高频问题：

排查时记住一个原则：先看网络通不通，再看凭据行不行，最后才看配置。很多问题其实就出在最基础的网络连通性上，一上来就怀疑软件 bug，往往白费功夫。

6.3 一段时间的真实使用感受

最后聊点我自己的使用感受。HertzBeat 最让我舒服的一点是“捡起来快、放下也快”。临时要观察几台机器，十分钟内就能上线；项目结束，停掉容器就行，不会在每台机器上留下要清理的 Agent。对中小团队和个人开发者来说，这种克制的部署方式比什么都重要。

如果后续监控规模上到几百台、指标量很大，我会考虑把存储换成独立的时序数据库，HertzBeat 本身支持这种扩展，监控定义很灵活，存储层替换也不会伤筋动骨。写这篇的时候我顺手看了下官方仓库，最近更新很频繁，监控模板也越来越全，这种活跃维护的开源项目用在生产环境里，至少不用担心放着放着就凉了。对我个人来说，无代理这个定位就是最大竞争力，部署简单、覆盖够广，刚好卡在中小场景最痛的那块需求上。