企业官网建设流程全解析

最近一直在折腾 Tongweb 的监控，起因很简单：现场环境里跑着一个监听 80909 端口的 Tongweb 实例，业务方三天两头问「服务到底活着没有」「JVM 堆是不是又要爆了」，光靠人工登录服务器看日志和进程，效率太低，也没法提前预警。后来我用 Prometheus（普罗米修斯）加 Grafana 把这事给办了——Prometheus 负责采集和存储 Tongweb 相关的指标，Grafana 负责把指标画成看得懂的图表，再配上报警规则，服务一有异常苗头就能收到通知。

这套方案我在多个环境里反复搭过，中间踩了不少坑，从端口不通到指标空白，再到图表数据对不上，几乎每个环节都有容易翻车的地方。这篇文章把我自己的实操过程完整梳理一遍，从整体架构到具体配置，再到常见问题的排查思路，都写清楚。如果你也正打算监控 Tongweb，或者已经在监控但总是差那么点火候，这篇应该能帮你省不少时间。

1. 整体设计与监控思路

1.1 为什么要用 Prometheus 加 Grafana 监控 Tongweb

Tongweb 本身是一款国产的企业级应用服务器中间件，很多生产系统跑在它上面。它启动之后会监听一个业务端口，比如标题里的 80909，应用的所有 HTTP 请求都从这个口进来。但光知道端口活着还不够，监控要解决的是更深层的问题：JVM 内存是不是在持续上涨、活跃线程数是不是逼近上限、GC 频率是不是异常、请求处理耗时是不是突然变高。这些指标如果不提前收集，等用户反馈「系统卡了」再去排查，往往已经晚了。

Prometheus 这个项目在云原生监控领域几乎成了事实标准，它抓取指标的方式简单直接，通过 HTTP 周期性拉取 exporter 暴露的数据，存成自带时间序列的格式。Grafana 则负责把 Prometheus 里存的指标变成图表，支持拖拽式仪表盘，也能设置告警。这两个工具组合起来，相当于搭了一个「采集 + 存储 + 可视化 + 告警」的完整闭环。

选这套方案还有一个很实际的理由：社区生态成熟。Prometheus 有大量的 exporter 可以复用，Tongweb 又是 Java 系的应用服务器，直接用 JMX exporter 就能把 JVM 和中间件内部状态暴露出来，不需要在 Tongweb 里塞额外的 Agent，侵入性很小。对于生产环境来说，少改动、少重启，本身就是最大的优点。

1.2 监控架构与数据流向

整条链路的组件划分是这样的：Tongweb 进程内部通过 JMX（Java Management Extensions）暴露运行时数据，JMX exporter 作为一个独立的小进程，把 JMX 里的 MBean 属性转换成 Prometheus 认识的 metrics 格式，然后在自己的 HTTP 端口上等着被抓取。Prometheus 根据配置文件里的 job 设置，定期访问 JMX exporter 的 HTTP 接口，把指标拉走存起来。最后 Grafana 连上 Prometheus，用 PromQL 查询语句把指标画成面板。

数据流向可以简单理解为「Tongweb → JMX exporter → Prometheus → Grafana」。这里要注意，Tongweb 的 80909 是业务端口，负责处理应用请求；而监控数据的出口在 JMX exporter 那边，走的是另一个端口。很多新手容易犯一个错误，以为直接抓 80909 端口就能看到监控指标，实际上你把浏览器打开http://服务器IP:80909/metrics，看到的十有八九是应用页面或者 404，而不是指标数据。

我在设计时把 Prometheus 和 Grafana 放在一台独立的监控服务器上，Tongweb 那边只部署 JMX exporter。这样监控采集和业务运行互相隔离，即使监控服务器挂了也不会影响 Tongweb 对外服务。如果你的环境里机器紧张，也可以把 Prometheus 和 Grafana 装在同一台，但至少不要让它们和业务服务混部，否则监控本身反而成了隐患。

1.3 端口 80909 在监控任务里的角色

标题里专门写了 80909，说明这就是 Tongweb 实例的业务监听端口。在配置监控时，我习惯先在服务器上用ss -lntp | grep 80909确认这个端口确实被 Tongweb 进程监听了，这是后续所有监控动作的前提。

实际上监控任务里关心的端口有两个：一个是业务端口 80909，它是我们要保护的对象，所以监控的目标是「这个端口对应的服务是否健康」；另一个是 JMX exporter 暴露指标的端口，比如我习惯用 9101。这两个端口要分清，在 Prometheus 抓取配置里填的是 9101，不是 80909。

有些版本 Tongweb 也支持开启自带的监控组件，会额外监听一个管理端口，具体端口号看安装目录下的配置。这个后面在采集配置章节我会专门讲。总之，80909 是业务入口，监控不直接碰它，碰的是旁边那个 exporter。

2. 环境准备与组件选型

2.1 监控组件版本选择与关键考量

先列一下我实际使用的组件版本和选择原因。

版本选择上，我的建议是「不用追最新，但别用太老」。Prometheus 的 2.x 系列接口基本稳定，升级迁移成本不高；Grafana 的 10.x 版本对告警和面板的体验都做得很好；JMX exporter 尽量选官方 GitHub 仓库里的 release 版本，不要用网上随便找的旧包，否则可能出现 Java 版本不兼容的问题。

还有一点很多人忽略：Tongweb 是基于 Java 的应用服务器，所以监控机的 Java 环境和目标机的 Java 环境都要提前确认。JMX exporter 是跑在目标机上的普通 Java 进程，如果你的目标机没有装 JDK，那 exporter 都起不来。我在现场遇到过目标机只有 JRE 的情况，后面又补装了 JDK 才解决。

2.2 Prometheus 安装与初始化

Prometheus 的安装方式有二进制包、Docker 容器、包管理器等。我在生产环境里更偏好二进制包方式，因为依托 systemd 管理，开机自启和日志处理都方便。

解压之后立即用配置启动可能有点太心急。因为 prometheus.yml 里默认会配置抓取 Prometheus 自身的指标，所以第一次启动其实不用改动配置，直接运行就能在自带的界面上看到监控自己的数据，用这个来验证「Prometheus 有没有正常工作」是最快的办法。

启动完成后，Prometheus 默认监听在 9090 端口。浏览器打开http://监控服务器IP:9090，可以在 Status → Targets 页面看到抓取目标列表。这时候只有一个prometheus的 job，状态应该是 UP，说明抓取链路正常。这个页面后面经常用到，配置 Tongweb 抓取任务之后，基本每个目标的状态都能在这里一眼看明白。

2.3 Grafana 安装与初始化

Grafana 的安装同样提供了多种方式。二进制包解压后运行./bin/grafana-server就能启动，默认端口是 3000。第一次访问会要求设置管理员账号密码，这里我的建议是设置一个强密码，因为 Grafana 一旦暴露到公网，弱密码是很危险的。

初始化完成后，第一件事不是急着配数据源，而是先把 Grafana 的语言和时区调整好。虽然默认英文界面也能用，但中文环境下图表里的时间显示不对会很影响判断。我习惯在 User Preferences 里把 Language 改为中文（如果安装的语言包支持的话），时区设置为 Asia/Shanghai。

Grafana 本身不存储监控数据，它只是一个展示层。所以配好 Grafana 之后，下一步是去配置 Prometheus 数据源。在 Configuration → Data Sources 里选择 Prometheus，填上 Prometheus 的访问地址，比如http://127.0.0.1:9090，保存之后点 Save & Test，如果显示绿色成功提示，就说明 Grafana 和 Prometheus 的通道已经打通。

3. Tongweb 指标采集配置

3.1 Tongweb 的指标从哪里来

Tongweb 作为 Java 中间件，运行时状态基本都挂在 JMX MBean 上。JMX 是 Java 平台自带的管理扩展机制，应用服务器会把线程、内存、类加载、连接数等关键信息注册成 MBean，外部工具可以通过 JMX 协议远程读取这些属性。

但 Prometheus 本身不认识 JMX，它只认 HTTP 接口返回的文本格式指标。所以中间需要 JMX exporter 这个翻译官。JMX exporter 启动时配置一个 JSON 格式的规则文件，里面写明要抓取哪些 MBean 的哪些属性，以及怎么把这些属性里的值重命名成 Prometheus 指标名。它启动成功后，一方面连接到本机的 Tongweb JMX 端口，另一方面开放自己的 HTTP 端口给 Prometheus 拉数据。

这里要多说一句：Tongweb 的老版本和新版本在 JMX 配置上会有细微差别，但从监控角度来说，只要 JMX 远程端口能连上，exporter 就能工作。我碰到的多数问题其实不是配置格式的问题，而是 Tongweb 启动时压根没开 JMX 远程端口，导致 exporter 连不上，这个在第 6 章排查部分会重点讲。

3.2 JMX Exporter 部署与规则文件配置

JMX exporter 的部署分三步：准备 JAR 包、准备配置文件、启动进程。

第一步，从 GitHub 仓库下载jmx_prometheus_javaagent-0.19.0.jar到 Tongweb 所在服务器的一个固定目录，比如/opt/monitoring/。我习惯用 Java agent 模式而不是 standalone 模式。Java agent 模式是把 exporter 作为一个代理和 Tongweb 进程绑定在一起，通过给 Tongweb 启动命令加-javaagent参数来生效，这样 JMX 连接是走本机回环地址，更安全。

第二步，编写规则文件tongweb.yaml。这个文件的核心作用是把 JMX 里的 MBean 属性映射成 Prometheus 指标。最简单粗暴的方式是用pattern正则匹配所有 MBean，但那样导出的指标会非常多，很多是无用的噪声。我一开始就是这么干的，结果 Prometheus 里塞满了java.lang包下的各种底层计数器，核心指标反而被淹没了。

后面我把规则收敛了，只留几类核心 MBean：

rules: - pattern: 'java.lang<type=OperatingSystem><>ProcessCpuLoad' name: tongweb_process_cpu_load - pattern: 'java.lang<type=Memory><HeapMemoryUsage>used' name: tongweb_heap_memory_used - pattern: 'java.lang<type=Threading><ThreadCount>' name: tongweb_thread_count - pattern: 'Catalina<type=GlobalRequestProcessor><>requestCount' name: tongweb_request_count_total

上面只是一部分示例。真实场景里你要先搞清楚 Tongweb 到底注册了哪些 MBean，这个可以用 JDK 自带的jconsole工具连上 JMX 端口去看，看到确定的 MBean 路径之后，再写对应的 pattern 规则，这样配出来最精准。

第三步，在 Tongweb 的启动脚本里加上 javaagent 参数。Tongweb 的启动脚本通常在安装目录的bin下，比如startserver.sh或类似名称。找到 Java 进程启动那行，在java命令参数里追加：

JAVA_OPTS="-javaagent:/opt/monitoring/jmx_prometheus_javaagent-0.19.0.jar=9101:/opt/monitoring/tongweb.yaml"

这个参数的意思是：启动这个 Java 进程时加载 JMX prometheus agent，exporter 监听 9101 端口，规则文件用/opt/monitoring/tongweb.yaml。加完参数后重启 Tongweb。重启完成，立刻检查 9101 端口有没有进入监听状态：

ss -lntp | grep 9101

如果能看到监听，再用浏览器或者 curl 访问http://127.0.0.1:9101/metrics，应该能看到一堆以tongweb_和jvm_开头的指标。看到这些，就说明 exporter 已经成功把 Tongweb 的运行时状态变成 Prometheus 的指标了。

3.3 Tongweb 自带监控接口的使用

有些版本 Tongweb 会自带监控模块，可以通过 HTTP 接口暴露一些状态信息。这类接口的具体路径需要看版本对应的文档，有的是/monitor，有的是在管理控制台里。不过以我的经验，自带的监控接口更多是给人看的，格式不一定是 Prometheus 想要的 text 格式，指标也不一定全，直接用它来喂 Prometheus 有时候还得写额外的转换脚本，反而麻烦。

所以我在实际项目里，始终以 JMX exporter 为主。只有在目标环境修改 Tongweb 启动参数受限、不允许动启动脚本的情况下，才考虑用 standalone 模式的 JMX exporter 去连接远程 JMX 端口。但 standalone 模式多一层网络配置，还要把 JMX 的 RMI 端口开出来，风险更高，能不用就不用。

还有一个要点：修改 Tongweb 启动参数之前，先备份原脚本。我见过不止一次改完脚本漏了一个空格导致 Tongweb 起不来的情况，备份了原脚本至少能快速恢复。这是运维的基本素养，但关键时刻真的能救命。

4. Prometheus 抓取配置与验证

4.1 prometheus.yml 抓取任务配置

Prometheus 的所有抓取任务都写在prometheus.yml文件里。为了让配置清晰，我通常把自定义的抓取任务独立成单独的配置文件，然后在主配置里使用rule_files和scrape_config_files引进来，避免所有内容堆在一个文件里。

针对 Tongweb 的抓取配置，我写了一个独立配置文件tongweb.yml：

scrape_configs: - job_name: 'tongweb-biz' static_configs: - targets: ['10.0.10.20:9101'] labels: app: tongweb port: '80909' env: prod

上面的 targets 填的是 Tongweb 所在服务器的 IP 和 JMX exporter 的端口 9101。labels 里的port: 80909是我额外加的一个标识标签，目的是在图表里清楚地显示这个监控对象对应的是 80909 端的业务实例。这个标签只起说明作用，不会影响实际的抓取逻辑。

写完后，在主配置文件prometheus.yml的末尾加上引用：

scrape_config_files: - /etc/prometheus/tongweb.yml

然后重新加载 Prometheus 配置。Prometheus 支持热加载，不需要重启进程，命令是：

curl -X POST http://127.0.0.1:9090/-/reload

也可以发送 SIGHUP 信号给 Prometheus 进程，效果一样。热加载的好处是不中断监控，生产环境推荐这种方式。

4.2 验证抓取目标与指标查询

配置加载之后，马上到 Prometheus 的 Targets 页面看状态。正常情况下，tongweb-biz这个 job 对应的 target 状态应该是 UP。如果显示 DOWN，说明网络不通或者 exporter 进程有问题，顺着链路查下去就行。

Targets 状态确认正常之后，再验证一下数据能不能查到。在 Prometheus 的 Graph 页面，输入框里输入一个指标名，比如tongweb_heap_memory_used，点 Execute，如果能看到时间序列数据，说明整个采集链路已经完整跑通了。

我习惯每一步都验证完再往下走，不要一口气把所有东西配完再去查问题。这种增量式的验证方式看起来慢，实际上是最快的，因为每一步出了问题，怀疑范围都很小，一查一个准。

Prometheus 的命令行工具promtool也可以用来检查配置格式：

promtool check config /etc/prometheus/prometheus.yml

如果输出SUCCESS，说明语法没问题。不过它能查的只是语法层面的错误，目标地址通不通、exporter 返回的指标格式对不对，它管不着，最终还是要在 Targets 页面看状态。

5. Grafana 可视化与告警配置

5.1 添加 Prometheus 数据源

Grafana 的可视化功能再强，没有数据源也画不出东西。添加数据源的入口在 Configuration → Data Sources，选择 Prometheus 类型，在 URL 一栏填http://127.0.0.1:9090。

这里有个细节：Grafana 和 Prometheus 如果装在同一台机器上，URL 直接填http://localhost:9090就行；如果它们是两台机器，URL 要填监控服务器的实际 IP，而且要注意 Grafana 所在机器的防火墙要对 Prometheus 的 9090 端口放行。

保存之后，Grafana 会发一个测试请求到 Prometheus 的 API 接口。如果返回成功，界面上会显示绿色提示；如果失败，最常见的原因就是网络不通或者 Prometheus 没启动。排查方法很简单，在 Grafana 所在机器上执行curl http://127.0.0.1:9090/api/v1/status/healthy，看返回结果就知道问题在哪一层。

数据源配置成功之后，我可以到 Explore 页面，输入刚才在 Prometheus 里验证过的指标名，比如tongweb_heap_memory_used，点 Run query，Grafana 应该能拉出一张对应的时间序列图。

5.2 构建 Tongweb 监控仪表盘

仪表盘建设我建议从核心指标开始，先画几块业务方最关心的面板，再逐步补充细节。画面板的入口是 Dashboards → New Dashboard → Add visualization，数据源选择刚才配好的 Prometheus，然后设置查询表达式和图标样式。

对于 Tongweb 监控，我优先画的几个面板是：

• JVM 堆内存使用量，用tongweb_heap_memory_used绘制面积图，能直观看到内存是否存在持续上涨趋势。
• 活跃线程数，用tongweb_thread_count绘制折线图，线程数突然飙升往往是请求积压的信号。
• 请求总次数和请求耗时，分别用计数类指标和直方图类指标展示，能看出请求量波动和响应时间。
• 进程 CPU 负载，用tongweb_process_cpu_load画折线图，观察是否存在 CPU 长时间打满的情况。

面板的查询表达式不一定只是简单选一个指标，更多时候要配合 PromQL 函数。比如把内存值从字节转换成 MB，可以这样写：

tongweb_heap_memory_used / 1024 / 1024

再比如想画过去 5 分钟内请求数的速率，可以这样写：

rate(tongweb_request_count_total[5m])

这些表达式其实都是 Grafana 图形编辑器的 Query 栏里直接输入的 PromQL。写完之后，把面板的标题改成中文，比如「堆内存使用量（MB）」，坐标轴单位设置成 MB，图例名称设置成对应端口或实例名，这样看仪表盘的人不需要费劲解读。

面板数量和展示信息量之间要平衡。我一开始为了展示全面，一口气拉了二十多块面板，结果界面非常密，看的人反而抓不住重点。后面精简成八块核心面板，再把每块面板的单位、阈值、颜色都调清楚，实用度反而更高。

5.3 配置告警规则的基础思路

告警是监控闭环里很重要的环节，没有告警的监控只能算事后追溯。Grafana 的 Alerting 功能可以基于面板查询设置规则，当指标超过阈值时，立刻通过邮件、Webhook 等方式通知。

我的告警规则一般从这些角度设计：堆内存使用率超过 85% 持续 5 分钟、活跃线程数超过 200 持续 5 分钟、进程突然从 Prometheus 抓取目标里消失。阈值不是拍脑袋定的，而是根据 Tongweb 实例的物理内存、业务类型和日常基线综合判断的。比如实例最大堆是 2GB，日常使用率在 30% 到 50% 波动，那阈值定在 85% 就比较合理，留够了反应时间。

提示：告警规则刚配好时，很多人容易收到一堆误报。原因是阈值定得太接近日常波动的最高点。可以先观察一个星期，看看指标的日常分布，再回过头调阈值。

告警通知渠道方面，如果公司有钉钉或者企业微信机器人，可以用 Webhook 方式接入 Grafana。如果你的环境暂时没有这些，邮件通知是最基础的选择。收到告警后，第一件事是去 Prometheus 的 Graph 页面手动查询对应指标，看趋势是持续走高还是偶发抖动，判断到底要不要人工介入。

6. 常见问题与排查技巧实录

6.1 目标状态 DOWN，端口连不上

这是整套监控搭建过程中我遇到最多的一个问题。Targets 页面里tongweb-biz状态是 DOWN，用telnet 目标IP 9101发现端口不通。

排查思路先分清是哪一层的问题。在 Tongweb 所在服务器上执行：

ss -lntp | grep 9101

如果这里能看到监听，说明 exporter 进程是正常的，问题出在网络上，去查防火墙和云平台安全组规则。如果这里本身就看不到监听，那问题就在 exporter 进程上，去 Tongweb 的日志里看 javaagent 是否加载成功。

我这边的实际案例是：exporter 进程起了，9101 端口也在监听，但 Prometheus 那边还是 DOWN。后来发现是云平台安全组只放行了 80 和 443 端口，9101 不在白名单里。把这些监控端口加进安全组之后，状态立刻变成了 UP。所以遇到端口不通，先别急着改配置，把链路每一段的连通性测一遍再说。

6.2 指标抓到了但全是空值

还有一次，target 状态已经是 UP 了，但在 Graph 页面输入指标名却查不到数据，或者查到了全是空值。这种情况通常是规则文件里的 MBean 路径和 Tongweb 实际注册的路径对不上。

JMX 里的 MBean 路径变化很常见，比如 Tongweb 版本升级，某个对象的 ObjectName 从Catalina前缀变成了Tongweb前缀，或者域名变了。我当时的做法是，先用jconsole连上 Tongweb 的 JMX 端口，把真实存在的 MBean ObjectName 逐条列出来，再对照之前写的tongweb.yaml，发现确实有个核心指标的前缀写错了，导致 pattern 匹配不到任何数据。

排查空值的快捷方式是直接访问 exporter 的输出：

curl http://127.0.0.1:9101/metrics | grep tongweb | head

如果 curl 结果里能看到的指标名和你在 Prometheus 里查的不一致，说明 exporter 和 Prometheus 之间有人改了指标名或者指令配置有差异。如果 curl 输出为空，说明规则文件没有匹配到任何 MBean，需要去改规则。

6.3 重启与版本升级注意事项

生产环境里 Tongweb 重启是最敏感的操作。修改启动脚本或者升级 JMX exporter 规则之后，势必要重启 Tongweb，这里一定要做好预案。

我的建议是操作前先执行一次配置备份，包括启动脚本、tongweb.yaml、prometheus.yml 和 Grafana 数据源配置。然后选择业务低峰期操作，提前通知业务方会有短暂中断。重启完成后，先确认 80909 端口恢复监听，再确认 9101 端口有指标输出，最后到 Prometheus Targets 页面确认状态为 UP，整个流程才算闭环。

升级 JMX exporter 版本时，建议先在测试环境验证规则文件的兼容性。我之前从 0.15.0 升到 0.19.0 时，就遇到旧的 pattern 语法在新版本里不再被支持，导致一堆指标抓不到。升级前看一眼官方仓库的 CHANGELOG，能省掉很多事。

结语

这套 Prometheus 加 Grafana 监控 Tongweb 的方案，我在本地实验环境和生产环境都跑过，整体稳定。最有价值的一点是，它把中间件监控这个容易被人忽略的事情，变成了一个低门槛、高回报的基础设施能力。

实际操作中我的体会是，监控的建设不是一锤子买卖，它需要持续迭代。刚开始你画面板、定阈值，看着很完整，但用一段时间你就会发现，真正关键的告警可能还没配全，或者某些指标的含义理解得还不够透彻。所以我会定期回顾一下面板和告警规则，把用不上的删掉，把缺的补上。

最后再分享一个小技巧：把整个部署过程写成一份可复用的脚本和配置模板，存在公司的运维仓库里。这样下次再遇到一个新增的 Tongweb 实例，照着模板改改 IP 和端口就能快速上线监控，省下的时间足够你多喝两杯咖啡了。