监控 on Liangweidong's blog

Prometheus 监控告警体系：从主节点到多 Exporter 一站式部署

Sat, 15 Mar 2025 00:00:00 +0800

容器时代，监控从"对单台机器"变成了"对一组动态拉起的服务"。Prometheus（普罗米修斯）凭借 pull 模型、时序数据库、丰富的 Exporter 生态，几乎成了云原生监控的事实标准。这篇文章把零散在多个笔记里的部署、配置、关键指标、踩坑细节，整理成"从主节点拉起→多 Exporter 接入→告警落地"的一条完整路径。

阅读对象：需要在中小规模环境（几台到几十台主机/容器）做统一监控的开发者、运维同学
覆盖范围：Prometheus 主节点（v3.x 时代）、node-exporter / mysqld-exporter / cAdvisor / alertmanager 全套部署、prometheus.yml 配置、MySQL 关键指标解读、Grafana 仪表盘推荐、配置热加载

一、为什么是 Prometheus

在引入 Prometheus 之前，团队通常在几种监控方案之间反复横跳：

Zabbix：传统 SNMP/Agent 模式，重型、关系型数据库后端，容器场景适配差
Nagios：古老、以被动检查为主，配置繁琐
云厂商自带监控：阿里云云监控、AWS CloudWatch 等，绑定厂商、跨云复杂
自研脚本 + 定时任务：简单但难以横向扩展、缺少时序聚合

Prometheus 的优势恰好打在云原生的痛点上：

特性	价值
Pull 模型	服务主动注册，部署新节点只要改主节点 `prometheus.yml`
时序数据库（TSDB）	自带压缩、聚合、PromQL 查询语言
多维标签	`node_cpu_seconds_total{mode="idle", instance="web-01"}` 这种查询极简
生态丰富	官方/社区 Exporter 覆盖 Linux、Windows、MySQL、Redis、K8s、Docker 等
告警分离	Prometheus 只产生告警状态，alertmanager 负责去重/路由/通知
与 Grafana 深度集成	一键导入仪表盘（Dashboard ID）

When to use：当你要监控的对象是"会动态拉起/销毁的服务"，或者主机数量超过两位数且需要统一的指标查询能力，Prometheus 几乎是首选。它也已经成为 Kubernetes 监控（kube-prometheus-stack）的默认后端。

二、架构总览

整套体系由"主节点"和"应用节点"两类组成：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


主节点（监控中心）
 ├── Prometheus :9090 # 拉取并存储指标
 ├── AlertManager :9093 # 告警去重/路由/通知
 ├── Grafana :3000 # 可视化（消费 Prometheus 数据源）
 └── webhook-adapter :80 # 适配企业微信/钉钉（可选）

应用节点（被监控对象）
 ├── node-exporter :9100 # Linux 主机硬件/OS 指标
 ├── cAdvisor :8080 # 容器资源指标
 └── mysqld-exporter :9104 # MySQL 指标

架构选择：如果是单机小规模（< 5 台），所有主节点组件跑在同一台机器即可。如果规模稍大（10+ 节点），主节点独立部署更便于容灾。Prometheus 本身不支持集群，但可以通过 Thanos / Cortex / Mimir 等上层方案扩展，本文不展开。

三、镜像清单

本批次部署涉及的镜像如下（版本号按本批次落地时锁定）：

组件	镜像	端口
Prometheus	`prom/prometheus:v3.4.1`	9090
alertmanager	`prom/alertmanager:latest`	9093
node-exporter	`prom/node-exporter:v1.9.1`	9100
cAdvisor	`gcr.nju.edu.cn/cadvisor/cadvisor:v0.47.2`	8080
mysqld-exporter	`prom/mysqld-exporter`	9104
Grafana	`grafana/grafana:10.0.1`	3000
webhook-adapter	`guyongquan/webhook-adapter:latest`	80

镜像源说明：cAdvisor 原镜像托管在 gcr.io，国内直连困难，建议用 gcr.nju.edu.cn/cadvisor/cadvisor（南京大学开源镜像）做中转。

四、主节点部署

4.1 Prometheus（核心）

准备配置目录：

1
2
3


mkdir -p /home/docker/prometheus
cd /home/docker/prometheus
touch prometheus.yml

核心 prometheus.yml（合并多个 job 后的生产配置）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44


global:
 scrape_interval: 15s  # 每 15s 拉取一次
 evaluation_interval: 15s  # 规则评估间隔

alerting:
 alertmanagers:
 - static_configs:
 - targets: ["{{ALERTMANAGER_HOST}}:9093"]

rule_files:
 - /etc/prometheus/rules/*.yml

scrape_configs:
 # 监控 Prometheus 自身
 - job_name: "prometheus"
 static_configs:
 - targets: ["{{PROM_HOST}}:9090"]

 # Linux 主机（多节点）
 - job_name: "node"
 static_configs:
 - targets: ["{{NODE_1}}:9100"]
 labels:
 nodeName: "dev-01"
 instance: "dev-01"
 - targets: ["{{NODE_2}}:9100"]
 labels:
 nodeName: "prod-01"
 instance: "prod-01"

 # 容器
 - job_name: "cadvisor"
 static_configs:
 - targets: ["{{NODE_1}}:8080"]
 labels:
 instance: "dev-01"

 # MySQL
 - job_name: "mysql_exporter"
 static_configs:
 - targets: ["{{NODE_1}}:9104"]
 labels:
 nodeName: "mysql-dev"
 instance: "mysql-dev"

配置铁律：prometheus.yml 文件内容及注释强烈建议不要使用中文，否则因编码格式不一致会导致 Prometheus 重启失败。

启动 Prometheus（带热加载 + 管理 API）：

1
2
3
4
5
6


docker run --name=prometheus -d -p 9090:9090 --restart=always \
 -v /home/docker/prometheus:/etc/prometheus \
 prom/prometheus:v3.4.1 \
 --config.file=/etc/prometheus/prometheus.yml \
 --web.enable-lifecycle \
 --web.enable-admin-api

修改配置后无需重启容器，热更新即可：

1

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

端口规划建议：主节点容器使用默认 9090/9093/3000，应用节点对外暴露用 3000+ 偏移（如 3101/3080/3104）避免冲突。

4.2 AlertManager（告警路由）

1
2


mkdir -p /home/docker/alertmanager
vim /home/docker/alertmanager/alertmanager.yml

最小可用 alertmanager.yml（路由到 webhook）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


global:
 resolve_timeout: 5m

route:
 group_by: ['alertname']
 group_wait: 10s
 group_interval: 10s
 repeat_interval: 1h
 receiver: 'webhook'

receivers:
 - name: 'webhook'
 webhook_configs:
 - url: 'http://{{WEBHOOK_ADAPTER_HOST}}/send'
 send_resolved: true

启动：

1
2
3
4
5
6


docker run -d --restart=always \
 --name=alertmanager \
 -p 9093:9093 \
 -v /home/docker/alertmanager:/etc/alertmanager \
 -v /etc/localtime:/etc/localtime:ro \
 prom/alertmanager:latest

4.3 Grafana（可视化）

Grafana 不是监控体系的"必要组件"，但 99% 的生产环境都会装它。/etc/grafana/grafana.ini 改个匿名访问，UI 就能公开给团队看：

1
2
3
4
5
6


#################################### Anonymous Auth ######################
[auth.anonymous]
enabled = true
org_name = Main Org.
org_role = Viewer
hide_version = true

启动：

1
2
3
4
5
6


mkdir -p /home/docker/grafana/conf
docker run -d --restart=always --name=grafana \
 -e TZ=Asia/Shanghai -e LANG=zh_CN.UTF-8 \
 -p 3000:3000 \
 -v /home/docker/grafana/conf/grafana.ini:/etc/grafana/grafana.ini \
 grafana/grafana:10.0.1

配置数据源：Configuration → Data Sources → Add data source → Prometheus，URL 填 http://{{PROM_HOST}}:9090，保存即可。

推荐仪表盘（到 https://grafana.com/grafana/dashboards 搜索 ID）：

监控对象	推荐 Dashboard ID
Linux 主机	`11074`（Node Exporter Full）
Windows 主机	`10467`
MySQL	`7362`（MySQL Overview）
Docker 容器	`10619`（cAdvisor）

导入流程：Grafana → Dashboards → New → Import → 输入 ID → 选数据源 → 完成。约 30 秒内就能看到主机/容器的 CPU、内存、磁盘、网络等十几张图。

五、应用节点 Exporter 部署

5.1 node-exporter（Linux 主机）

1
2


docker run -d --name node-exporter --restart=always -p 9100:9100 \
 prom/node-exporter:v1.9.1

访问 http://{{HOST}}:9100/metrics 能看到原始指标。node-exporter 默认暴露 1000+ 指标，覆盖 CPU、内存、磁盘、网络、文件系统、内核参数等。

5.2 cAdvisor（容器资源）

cAdvisor 需要访问宿主机文件系统以读取容器信息，所以挂载点比较"重"：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


docker run -d --name cadvisor --restart=always \
 --privileged=true \
 --device=/dev/kmsg \
 -p 8080:8080 \
 -v /:/rootfs:ro \
 -v /var/run:/var/run:ro \
 -v /sys:/sys:ro \
 -v /var/lib/docker/:/var/lib/docker:ro \
 -v /dev/disk/:/dev/disk/:ro \
 gcr.nju.edu.cn/cadvisor/cadvisor:v0.47.2

访问 http://{{HOST}}:8080/containers/ 是个 HTML 索引，Web UI 简单但够用——更深度使用走 Grafana。

5.3 mysqld-exporter（MySQL 指标）

准备 MySQL 客户端配置（不要把明文密码写进 docker run 命令）：

1
2
3
4
5
6
7
8


mkdir -p /home/docker/mysqld-exporter
cat << "EOF" > /home/docker/mysqld-exporter/.my.cnf
[client]
host={{MYSQL_HOST}}
port={{MYSQL_PORT}}
user={{MYSQL_USER}}
password={{REDACTED}}
EOF

启动：

1
2
3
4
5


docker run -d --restart=always \
 --name mysqld-exporter \
 -p 9104:9104 \
 -v /home/docker/mysqld-exporter/.my.cnf:/.my.cnf \
 prom/mysqld-exporter

安全建议：为 exporter 单独建一个只读账号，权限仅 SELECT、PROCESS、REPLICATION CLIENT，避免使用 root 或业务账号。

关键 MySQL 指标解读

监控不是"装上 exporter 就完事"，要看得懂指标才能发现真问题。MySQL 常见的指标分四类：

1. 可用性

指标	含义
`mysql_up`	MySQL 实例是否停机（1=正常，0=挂）
`mysql_global_status_uptime`	数据库运行时长（秒），可配置"运行少于半小时"告警，揪出被频繁重启的实例

2. 连接

指标	含义
`mysql_global_status_threads_connected`	当前已连接线程数
`mysql_global_status_threads_running`	当前运行中线程数（正在执行 SQL）
`mysql_global_status_max_used_connections`	历史最大连接记录
`mysql_global_variables_max_connections`	配置最大连接数（超过则拒绝新连接）
`mysql_global_status_aborted_connects`	异常中断的连接（尝试连接阶段失败）
`mysql_global_status_aborted_clients`	异常中断的连接（超时/被动断）

3. 查询

指标	含义
`mysql_global_status_queries`	当前 QPS（每 15s 增量）
`mysql_global_status_slow_queries`	慢查询累计数（配合 `rate()` 看增量）

4. 流量与文件

指标	含义
`mysql_global_status_bytes_received`	入站流量
`mysql_global_status_bytes_sent`	出站流量
`mysql_global_status_open_files`	当前打开的文件数
`mysql_global_variables_open_files_limit`	允许打开的文件上限

关键 PromQL 示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# MySQL 实例是否在线
mysql_up == 0

# 当前 QPS
rate(mysql_global_status_queries[1m])

# 慢查询增长速率
rate(mysql_global_status_slow_queries[5m])

# 连接数使用率
mysql_global_status_threads_connected / mysql_global_variables_max_connections

六、配置热加载 SOP

修改 prometheus.yml 后的标准流程：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 1. 编辑配置
vim /home/docker/prometheus/prometheus.yml

# 2. 语法检查（promtool 在镜像内）
docker exec prometheus promtool check config /etc/prometheus/prometheus.yml

# 3. 热加载
curl -X POST http://{{PROM_HOST}}:9090/-/reload

# 4. 验证（UI → Status → Targets）
# 所有 targets 状态应为 UP，新加的 job 已出现

不要直接 docker restart prometheus：重启会触发告警状态重置，正在持续中的告警会"消失后再生"，造成误报。热加载是首选。

七、踩坑清单

prometheus.yml 中文注释——YAML 解析失败，Prometheus 启动后立即退出，且日志里只看到"no such file"类错误，很难定位
cAdvisor 镜像拉取失败——gcr.io 国内访问困难，统一改用 gcr.nju.edu.cn/cadvisor/cadvisor 或其他国内镜像
mysqld-exporter 连接失败——MySQL 默认监听 127.0.0.1，远程 exporter 访问会失败；要么改 bind-address=0.0.0.0，要么用 host 网络模式
Grafana 改完 grafana.ini 不生效——容器内只读，必须先 docker cp 出配置、修改后挂载进去
Prometheus 内存爆炸——scrape_interval 设太短（5s 以下）、target 太多（> 1000）会让内存快速膨胀；按需调整而非全局最小化
告警风暴——一个 root cause 触发几十条 alert。配置 group_by: ['alertname'] + group_wait: 30s 做去重

八、2024+ 视角补充

本文写于 2025-03，2025-2026 期间 Prometheus 关键演进：

Prometheus 3.x（2024-11 GA）：WAL 压缩、UTF-8 标签、远程写入 v2（性能 5x 提升）、原生 OpenTelemetry 兼容——3.0 是 Prometheus 自 2.0 以来最大一次重构
Prometheus Agent 模式（3.x GA）：纯抓取不存储，远程写入到 Thanos / Mimir / Cortex——Kubernetes DaemonSet 部署首选
VictoriaMetrics 1.99+ LTS / 2.0：与 Prometheus 兼容，存储压缩 10x、查询快 5-10x——大规模监控默认推荐
Grafana Mimir 2.x：Cortex 演进，水平扩展 + 多租户——50+ 集群首选
OpenTelemetry Collector 0.100+：统一指标 / 日志 / 追踪采集——Prometheus exporter 与 OTel 并存，但 OTel 是未来
kube-prometheus-stack 0.78+：Helm Chart 整合 Prometheus / AlertManager / Grafana / node-exporter，K8s 监控事实标准
告警疲劳应对：2024+ 流行 Mimir 告警去重 + AI 降噪（如 Grafana Sift、Keep）

实战建议（2025-2026 视角）：

单机 / 小规模（< 10 节点）→ Prometheus 3.x 仍 OK
中等规模（10-100 节点）→ VictoriaMetrics 性价比高
大规模 / 多租户（> 100 节点）→ Grafana Mimir / Cortex
K8s → kube-prometheus-stack Helm Chart 一键搞定
新项目：OpenTelemetry Collector 替代纯 Prometheus exporter——避免后续迁移

九、参考资料

Prometheus 官方文档：https://prometheus.io/docs/
Prometheus 3.0 发布说明：https://prometheus.io/blog/2024/11/14/prometheus-3-0/
Grafana Dashboard 仓库：https://grafana.com/grafana/dashboards
cAdvisor GitHub：https://github.com/google/cadvisor
mysqld-exporter GitHub：https://github.com/prometheus/mysqld_exporter
alertmanager 配置：https://prometheus.io/docs/alerting/latest/configuration/
VictoriaMetrics：victoriametrics.com
Grafana Mimir：grafana.com/oss/mimir/
OpenTelemetry：opentelemetry.io

下一步

想做"日志"那一层？→ 看 Loki + Promtail 日志架构一文
想做"链路追踪"？→ 接入 Tempo 或 Jaeger，让 Prometheus + Grafana 体系扩展到 trace
想"少装点东西"？→ HertzBeat 轻量监控告警把监控 + 告警 + 可视化打包到一容器里

HertzBeat 轻量监控告警：国人开源的一体化监控平台

Fri, 15 Mar 2024 00:00:00 +0800

Prometheus + Grafana + alertmanager + node-exporter 一套拉完，少说 5 个容器、3 份配置、1 个 PromQL 学习成本。如果只是想"监控几十台机器 + 微信告警"，杀鸡用了牛刀。Dromara HertzBeat（原 TanCloud）走另一条路——一个容器，监控 + 告警 + 可视化全打包，无 Agent 协议直采（HTTP / SNMP / JDBC / SSH），连 exporter 都不用装。这篇文章讲清楚容器化部署、初始账号、监控模板、配置持久化。

阅读对象：中小团队想"快速搭一套能用"的监控体系、或者觉得 Prometheus 体系太重的同学
覆盖范围：HertzBeat 1.x 容器化部署、初始账号、时区/中文环境、监控模板（Linux/MySQL/Redis/K8s/Windows/SNMP）、告警通知（钉钉/企微/飞书）

一、为什么是 HertzBeat

传统监控方案的痛点：

Prometheus 体系：要装 N 个 exporter、PromQL 学习成本、告警要写规则、调仪表盘要懂 PromQL
Zabbix：重型、关系数据库后端、UI 古老、容器适配差
夜莺（Nightingale）：国产不错但要分 Categraf + n9e + Transfer 多个组件
Datadog / New Relic：SaaS、按量计费、数据出境问题

HertzBeat 的设计哲学是"协议直采，零 Agent"：

HTTP 协议：网站、API、Spring Boot Actuator、K8s API
SNMP：路由器、交换机、打印机
JDBC：MySQL、PostgreSQL、Oracle、达梦、人大金仓
SSH：执行命令采集（CPU/内存/磁盘）
JMX：JVM 应用
Modbus / OPC-UA：工业协议

一个 Jar 包搞定所有采集、可视化、告警、用户权限。

When to use：中小规模（< 200 监控对象）、要"快速上手"、团队不愿意学 PromQL、想用国产开源规避合规问题。规模再大（1000+ 节点、PB 级时序数据）还是建议回 Prometheus + VictoriaMetrics 体系。

二、容器化部署

2.1 host 网络模式（最简）

1
2
3
4
5
6
7


docker run -d --name hertzbeat \
 --restart=always \
 --net=host \
 -e LANG=zh_CN.UTF-8 \
 -e TZ=Asia/Shanghai \
 -v /home/docker/hertzbeat/data:/opt/hertzbeat/data \
 tancloud/hertzbeat

为什么用 host 网络：HertzBeat 默认监听 1157 端口（Web）、反向连接 agent 时端口动态分配。host 模式省去端口映射的麻烦，也避免一些 SNMP/JMX 协议在 NAT 下的奇怪问题。

2.2 端口映射模式

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


docker run -d -p 1157:1157 \
 -e LANG=zh_CN.UTF-8 \
 -e TZ=Asia/Shanghai \
 -v /opt/data:/opt/hertzbeat/data \
 -v /opt/logs:/opt/hertzbeat/logs \
 -v /opt/application.yml:/opt/hertzbeat/config/application.yml \
 -v /opt/sureness.yml:/opt/hertzbeat/config/sureness.yml \
 --restart=always \
 --name hertzbeat \
 tancloud/hertzbeat

挂载配置：生产环境必须把 application.yml、sureness.yml 挂出来，否则容器一升级配置就丢。HertzBeat 升级会清空容器内 /opt/hertzbeat/data 之外的目录。

2.3 初始账号

访问 http://{{HOST}}:1157/passport/login：

默认账号：admin
默认密码：hertzbeat

生产环境：首次登录立即改密码，或在 sureness.yml 里直接配置账号体系（HertzBeat 支持 RBAC 和 LDAP）。

三、添加监控对象

HertzBeat 把"采集什么"封装成"监控模板"——选模板、填 IP/端口/凭据、保存。

3.1 Linux 主机监控（SSH 协议）

监控 → 新建监控 → 选择模板：Linux：

主机：填目标 IP
端口：22
用户名/密码：SSH 凭据
监控周期：60s（默认）

保存后 HertzBeat 通过 SSH 上去 cat /proc/stat、free -m、df -h 等命令采集指标。

3.2 MySQL 监控（JDBC 协议）

监控 → 新建监控 → 模板：Mysql：

主机、端口、数据库、用户名、密码
监控指标：连接数、QPS、慢查询、InnoDB 缓冲池等

3.3 Redis 监控

监控 → 新建监控 → 模板：Redis：

支持有密码和无密码两种连接方式
监控内存使用、连接数、命中率、Key 数量

3.4 Kubernetes 监控

监控 → 新建监控 → 模板：Kubernetes：

填 K8s API Server 地址 + ServiceAccount Token
自动发现 Pod、Deployment、Node 资源

3.5 网站监控（HTTP 协议）

监控 → 新建监控 → 模板：HTTP_API 或 网站监测：

填 URL
选择 HTTP 方法、Header、断言（状态码、响应体关键字）
间隔时间和超时

3.6 SNMP 监控

监控 → 新建监控 → 模板：SNMP：

填目标 IP、SNMP community（默认 public）
OID 模板自动发现接口、流量

HertzBeat v1.6+ 模板生态：官方维护 100+ 模板（Linux/Windows/MySQL/PostgreSQL/Redis/MongoDB/Elasticsearch/Kafka/ZK/Nginx/Apache/Docker/交换机/路由器/…），基本覆盖了常见监控对象。社区也持续贡献新模板。

四、告警通知

HertzBeat 支持多种通知渠道（告警 → 通知媒介）：

渠道	适用
钉钉机器人	国内团队首选
企业微信机器人	国内团队
飞书机器人	字节系团队
Slack	海外
邮件	通用
Webhook	自定义系统对接
Telegram / Discord	海外

钉钉告警示例

告警 → 通知媒介 → 新增 → 钉钉机器人：

名称：DingTalk-Alert
Webhook URL：https://oapi.dingtalk.com/robot/send?access_token={{TOKEN}}
关键字：自定义

告警 → 告警定义 → 新增规则：

选择监控对象
指标：cpu_usage
表达式：cpu_usage > 80
持续时间：5 分钟
通知媒介：DingTalk-Alert

告警收敛：HertzBeat 支持"标签路由 + 抑制规则"，避免同一时刻同一原因触发几十条告警。

五、可视化

HertzBeat 内部集成了图表（基于 ECharts），可以：

单个监控对象查看历史曲线（CPU、内存、磁盘、QPS 等）
多个监控对象叠到同一张图对比
创建 Dashboard 把常用图钉到首页

Grafana 不是 HertzBeat 的依赖。HertzBeat 自己就有完整的可视化能力。如果团队已经在用 Grafana + Prometheus，HertzBeat 也可以通过 /api/metrics 端点把数据暴露出去给 Prometheus 抓取（“反向对接”）。

六、踩坑清单

SSH 监控拿不到数据——目标机器没装 bc 命令（cat /proc/loadavg 的格式化用到），或 ~/.bashrc 里有 prompt 输出
MySQL 监控 “Access denied”——MySQL 8 默认 caching_sha2_password 认证插件，HertzBeat 旧版本只支持 mysql_native_password，要么改用户认证插件，要么升级 HertzBeat
SNMP 监控返回 timeout——目标设备防火墙/ACL 拦截了 UDP 161，或者 community 不对
数据目录丢失——升级前没挂载 /opt/hertzbeat/data，容器销毁后所有监控配置清零
告警收不到——先在 告警 → 告警中心 看历史告警有没有触发，再检查通知媒介的 webhook 是否能 curl 通
中文乱码——LANG=zh_CN.UTF-8 没设，或者容器内字体不全，加 -v /usr/share/fonts:/usr/share/fonts:ro

七、2024+ 视角补充

本文写于 2024-03，2025-2026 期间 HertzBeat 关键演进：

HertzBeat 1.7+ / 1.8+：AI 异常检测（内置时序异常识别）、智能告警降噪（关联分析）、自研存储引擎 v2——单机监控 1000+ 节点
Cloud Native 化：1.7+ 推出 HertzBeat Operator（K8s Operator 模式），CRD 管理监控对象
告警通知生态完善：1.8+ 内置 PagerDuty / Opsgenie / Slack / 钉钉 / 企微 / 飞书——oncall 集成开箱即用
多语言 / 多协议：1.8+ 模板数 200+（新增 Modbus / OPC-UA / IEC104 工业协议——工控监控更专业）
多租户 / 团队权限：1.7+ RBAC 增强，从"全局管理员"到"组织 / 项目 / 视图"三级权限
时序数据库后端可选：1.8+ 支持 VictoriaMetrics / InfluxDB / TDengine 作为存储后端，不再绑定 H2 / 内置 TSDB

实战建议（2025-2026 视角）：

中小规模 / 国产化 → HertzBeat 1.8+ 仍是首选（vs Prometheus 体系仍更轻量）
大规模（1000+ 节点） → 建议 HertzBeat + VictoriaMetrics 组合
工控 / IoT 场景 → HertzBeat 1.8+ 工业协议完善，vs 传统 Zabbix 优势明显
K8s 集群 → 仍推荐 kube-prometheus-stack（生态成熟度 HertzBeat 暂不如）

八、参考资料

HertzBeat 官网：https://hertzbeat.com
文档中心：https://hertzbeat.com/docs/
GitHub 仓库：https://github.com/dromara/hertzbeat
模板中心：https://hertzbeat.com/docs/template

下一步

想做"日志监控"？→ Loki + Promtail 日志架构一文
想要传统三件套？→ Prometheus 监控告警体系一文
想给团队搭可视化大屏？→ Grafana 可视化面板实战一文

Grafana 可视化面板实战：从部署到匿名访问、中文环境与 InfluxDB 数据源

Mon, 25 Sep 2023 00:00:00 +0800

监控数据再多，没人看就是"装个寂寞"。Grafana 把时序数据（Prometheus、InfluxDB、Elasticsearch、Loki…）变成"能拖时间范围、能叠多源、能做告警"的可视化面板，几乎是云原生时代仪表盘的事实标准。这篇文章把 Grafana 容器化部署、初始密码、中文环境、匿名访问、配置持久化这些"装上就完事但装的时候总忘"的事整理成一篇。

阅读对象：刚把 Prometheus 装上、想接 Grafana 看图的开发者；或 Grafana 已经跑起来但中文乱码/匿名访问开不了的运维同学
覆盖范围：Grafana 10 容器化部署、初始密码、InluxDB 数据源、匿名访问（grafana.ini 持久化）、时区与中文环境、注意事项

一、为什么是 Grafana

Grafana 不是"唯一"的仪表盘，但它的优势是面板能复用到极致：

多数据源：Prometheus、InfluxDB、Elasticsearch、MySQL、PostgreSQL、Loki、Tempo… 同一个 Dashboard 拉多个源
导入社区仪表盘：到 https://grafana.com/grafana/dashboards 搜 ID，30 秒装好一套完整图
告警与通知：面板里就能定义 alert rule，发邮件/Webhook/钉钉
多租户：Organization / Team / Folder 权限隔离
插件丰富：官方/社区插件扩展数据源、图表类型、面板组件

When to use：监控要"展示给人看"时，Grafana 几乎必装。如果你的数据是商业 BI 类（要做月度报表、维度下钻），Grafana 就不是首选了——Superset / Metabase 更合适。

二、容器化部署

2.1 最简单一行

1
2


docker pull grafana/grafana:10.0.1
docker run -d --restart=always --name=grafana -p 3000:3000 grafana/grafana

访问 http://{{HOST}}:3000：

初始账号：admin
初始密码：admin

第一次登录会强制要求改密码（生产环境必须改）。

2.2 时区与中文环境

Grafana 默认时区是 UTC，中文界面也有可能因为字体不全出现"豆腐块"。通过环境变量解决：

1
2
3
4
5


docker run -d --restart=always --name=grafana \
 -e TZ=Asia/Shanghai \
 -e LANG=zh_CN.UTF-8 \
 -p 3000:3000 \
 grafana/grafana

TZ 优先级：Grafana 启动时会把 TZ 写到容器内 /etc/localtime，但部分版本仍要靠挂载宿主机时区文件：
1
-v /etc/localtime:/etc/localtime:ro
保险起见两个都加。

2.3 host 网络模式

如果 Grafana 和后端服务在同一台机器，用 --net=host 可以避免端口映射带来的 trace 调用异常：

1
2
3


docker run -d --restart=always --name=grafana --net=host \
 -e TZ=Asia/Shanghai -e LANG=zh_CN.UTF-8 \
 grafana/grafana

三、添加数据源

Grafana 的核心是"数据源 + 仪表盘"。进入 Configuration → Data Sources → Add data source，能看到几十种数据源选项。

3.1 Prometheus

Type: Prometheus
URL: http://{{PROM_HOST}}:9090
其它默认即可
点击 Save & test，绿色 Data source is working 出现即成功

3.2 InfluxDB（时序数据库）

InfluxDB v1/v2 的接入参数略有不同：

Type: InfluxDB
URL: http://{{INFLUXDB_HOST}}:8086
Database: 填库名
User / Password: 填凭据
HTTP Header: 如 Authorization: Token {{TOKEN}}（v2 必需）

测试连接成功后，在 Explore 面板里写 Flux 或 InfluxQL 即可查数据。

3.3 Loki（日志）

Type: Loki
URL: http://{{LOKI_HOST}}:3100

详细看 Loki + Promtail 日志架构一文。

3.4 人员定位面板（业务 Demo）

早期有人拿 Grafana 做过 UWB/蓝牙定位的"实时位置面板"——把人员坐标入库到 InfluxDB，Grafana 用 geomap / table / stat 面板做实时展示。这种"业务可视化"用法比传统 BI 轻量很多，配置简单、刷新及时。

四、匿名访问

生产环境往往需要"未登录用户也能看图"——大屏监控、嵌入式展示、给非技术人员查指标。Grafana 通过 grafana.ini 里的 [auth.anonymous] 段开启。

4.1 直接改容器内配置

1
2


docker exec -it grafana /bin/bash
vi /etc/grafana/grafana.ini

找到 [auth.anonymous] 段，修改：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


[auth.anonymous]
# enable anonymous access
enabled = true

# specify organization name that should be used for unauthenticated users
org_name = Main Org.

# specify role for unauthenticated users
org_role = Viewer

# mask the Grafana version number for unauthenticated users
hide_version = true

坑：发现改不了——容器内 /etc/grafana/grafana.ini 在某些镜像版本是只读，必须停掉容器后挂载出来改（见 4.2）。

4.2 配置持久化（推荐）

把 grafana.ini 复制出来，挂载进容器：

1
2
3


mkdir -p /home/docker/grafana/conf
docker cp grafana:/etc/grafana/grafana.ini /home/docker/grafana/conf
vim /home/docker/grafana/conf/grafana.ini

启动时挂载：

1
2
3
4
5


docker run -d --restart=always --name=grafana \
 -e TZ=Asia/Shanghai -e LANG=zh_CN.UTF-8 \
 -p 3000:3000 \
 -v /home/docker/grafana/conf/grafana.ini:/etc/grafana/grafana.ini \
 grafana/grafana

或 docker-compose：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


grafana:
 container_name: grafana
 image: grafana/grafana:latest
 restart: always
 environment:
 - TZ=Asia/Shanghai
 - LANG=zh_CN.UTF-8
 ports:
 - 3000:3000
 volumes:
 - '/home/docker/grafana/conf/grafana.ini:/etc/grafana/grafana.ini'

改完配置要重启：docker restart grafana 让新配置生效。

五、推荐仪表盘（Dashboard ID）

到 https://grafana.com/grafana/dashboards 搜 ID 即可导入：

监控对象	推荐 Dashboard ID	用途
Linux 主机	`11074`	Node Exporter Full（CPU/内存/磁盘/网络/内核）
Windows 主机	`10467`	Windows 主机全量指标
MySQL	`7362`	MySQL Overview（连接/QPS/慢查询/缓冲池）
Docker 容器	`10619`	cAdvisor（容器 CPU/内存/网络/IO）
Redis	`11835`	Redis 监控
Nginx	`9614`	Nginx 日志/请求/状态码分析
JVM	`4701`	Java 应用堆/线程/GC

导入流程：Grafana → + → Import → 输入 Dashboard ID → 选数据源 → 完成。约 30 秒就能看到十几张图。

六、踩坑清单

改 grafana.ini 不生效——容器内文件只读，参考 4.2 挂载出来
忘记初始密码——容器没挂载数据库时，数据存在容器内 /var/lib/grafana。docker volume rm 重置
中文显示豆腐块——字体不全，加 -e LANG=zh_CN.UTF-8 + 主机字体 fonts-noto-cjk
时间不对——时区没设对，Grafana 默认 UTC，业务日志要 Asia/Shanghai
导入仪表盘数据为空——Dashboard 自带数据源变量 DS_PROMETHEUS，导入时要选实际的数据源
大屏刷新卡顿——Dashboard 太多 Panel、Datasource 查询慢、Chrome 内存爆。优化方向：减少 Panel 数量、降低刷新频率、用 time range from 限制数据范围

七、2024+ 视角补充

本文写于 2023-09，2024-2026 期间 Grafana 关键演进：

Grafana 11.x（2024）+ Grafana 12.x（2025）：Drilldown / Explore 全面重构、Scene 框架（App SDK）让自定义面板开发更轻量
Grafana Loki 3.x（2024-2026）配合：对象存储全面支持 S3 兼容、GCS、Azure Blob，日志查询性能 10x 提升
Grafana Mimir / Pyroscope / Beyla：Metrics / Continuous Profiling / eBPF Auto-instrumentation 一站式可观测
Grafana 11+ IRM（Incident Response Management）：内置 oncall 值班 / 事件管理 / Postmortem 模板，逐步替代 PagerDuty / Opsgenie 部分场景
AI 助手 Grafana LLM（2024-Q3 试验）：用自然语言生成 PromQL，2025 起仍是早期功能
Grafana Faro（RUM）：Web 端真实用户监控 SDK，前端可观测性补齐

实战建议（2025-2026 视角）：

Grafana 11.x / 12.x + Loki 3.x + Prometheus 3.x + Mimir 是云原生可观测的"标准四件套"
K8s 场景优先 Grafana Helm Chart 一键部署
国产可观测（夜莺 / FlashDuty）2024+ 与 Grafana 体系深度集成，可作为 oncall 补充

八、参考资料

Grafana 官方文档：https://grafana.com/docs/grafana/latest/
社区仪表盘：https://grafana.com/grafana/dashboards
配置文件参考：https://grafana.com/docs/grafana/latest/setup-grafana/configure-grafana/

下一步

监控那层用 Prometheus？→ 看 Prometheus 监控告警体系一文
日志也想接 Grafana？→ Loki + Promtail 日志架构一文
不想自己拼装？→ HertzBeat 轻量监控告警把监控+告警+可视化打包到一容器

Linux 监控与系统性能工具：top/glances/lsof/systemctl/dstat 性能观测

Tue, 15 Sep 2020 00:00:00 +0800

一、为什么是 2020 年这一份

2020 年这个时间点，Linux 系统监控进入"工具集成化"阶段：

top 3.x 仍是终端监控的入门首选
glances（2014 发布，2.x 时代）作为"一屏式综合监控"被广泛接受
dstat 替代 vmstat 成为综合 I/O / CPU / 网络监控的事实标准
systemd resource control 全面成熟（CPUQuota / MemoryLimit / IOWeight）
lsof 仍是排查"端口被谁占用"的首选
iotop 与 pidstat 形成"按进程看 I/O"的组合

这一篇覆盖 top 字段精读、glances 一屏监控、lsof 端口排查、systemctl 资源限制、五把刀（dstat/pidstat/iotop/vmstat/top）、mount 修复、时区配置——日常性能观测的"七种武器"。

阅读建议：本文是"工具集"性质——日常每个工具都要会用，遇到具体场景再回头查。

二、top 字段精读

top 是 1991 年起的"上古"工具，至今仍是 Linux 性能观测的入门首选。

2.1 启动参数

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


top --help

# -d 两次刷新间隔（秒）
# -p 只监控指定 PID
# -q 无延迟刷新（高优先级）
# -S 累计模式
# -s 安全模式
# -i 不显示闲置/僵死进程
# -c 显示完整命令行（不只命令名）

top -c -bw 512 # 显示完整命令行，输出宽度 512

2.2 字段含义

第一行：当前时间、运行时间、当前用户、CPU 平均负载（1/5/15 分钟）——“1 代表一个核心满了”

第二行：总/运行/休眠/停止/僵尸进程数

第三行：

us —— 用户空间占用 CPU%
sy —— 内核空间占用 CPU%
ni —— 用户改过优先级的进程占用
id —— 空闲
wa —— 等待 I/O
hi —— hardware IRQ
si —— software IRQ
st —— steal time（仅与虚拟机相关，被偷走的时间）

第四行：物理内存总量、空闲、已用、内核缓存

第五行：虚拟内存总量、空闲、已用、下一波分配量

进程字段：

字段	含义
`PID`	进程 ID
`USER`	进程用户名
`PR`	动态优先级（内核视角）
`NI`	静态优先级（用户视角，nice 值）
`VIRT`	虚拟内存
`RES`	物理内存
`SHR`	共享内存
`S`	状态：D 不可中断 / I idle / R 运行 / S 睡眠 / T 停止 / Z 僵尸
`%CPU` / `%MEM`	CPU / 内存占用
`TIME+`	累计 CPU 时间
`COMMAND`	命令

2.3 Java VIRT 异常大问题

Java 8+ 用 Metaspace 取代 PermGen，元空间放在 OS 本地内存。每个线程分配一个 arena（64MB），线程一多 VIRT 就巨大。这不是真用了那么多内存——用 pmap 查真实占用。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# 按内存块大小排序
pmap -x <pid> | sort -n -k3

# 输出内存块详细信息
cat /proc/<pid>/smaps

# 通过 gdb dump 指定内存块
gdb attach <pid>
dump memory /tmp/0x7fb9b0000000-0x7fb9b3ffe000.dump 0x7fb9b0000000 0x7fb9b3ffe000

# 提取长度超过 10 字符的字符串
strings -10 /tmp/0x7fb9b0000000-0x7fb9b3ffe000.dump

2.4 常用快捷键

键	功能
`shift+m`	按内存排序
`shift+P`	按 CPU 排序
`shift+t`	按时间排序
`shift+n`	按 PID 排序
`m`	内存显示模式
`E`	内存总览单位
`e`	进程内存单位
`c`	显示完整命令行
`i`	不显示闲置
`l`	启动时间和平均负载

2.5 用户下的所有进程

1
2
3
4
5


# 查某用户进程
top -u username

# 取 top 一屏输出供管道调用
top -bn 1 -i -c | awk '{ if (NR > 6) print }' | awk '{print $1,$9}'

三、glances：一屏式综合监控

glances（2014-12 发布 2.0）被称为 htop 的"加强版"，提供一屏式综合监控（CPU / 内存 / 磁盘 / 网络 / 进程全维度）。

3.1 安装

1
2
3
4
5


yum -y install glances # CentOS
apt install -y glances # Debian/Ubuntu

# 配套：硬件温度监控
yum -y install lm_sensors

3.2 启动

1

glances

与 htop 的差异：htop 主要聚焦进程列表；glances 把 CPU / 内存 / 磁盘 / 网络 / 进程都堆在一屏里，类似 Windows 任务管理器的"详细信息"视图。

四、lsof：端口与文件排查

lsof（list open files）是"端口被谁占用"排查的首选。

4.1 安装

1
2


yum -y install lsof # CentOS
apt install -y lsof # Debian/Ubuntu

4.2 常用命令

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


# 查 8080 端口被谁占用
lsof -i:8080

# 查谁打开了 abc.txt
lsof abc.txt

# 查 abc 进程打开的文件
lsof -c abc

# 查 PID 1234 打开的文件
lsof -c -p 1234

# 查 gid 组打开的文件
lsof -g gid

# 查 /usr/local/ 下被进程打开的文件
# +d 不递归，+D 递归
lsof +d /usr/local/
lsof +D /usr/local/

# 查 fd 为 4 的进程
lsof -d 4

# 查所有打开的端口和 UNIX domain 文件
lsof -i -U

五、systemctl 资源限制

systemd 的 resource control（cgroup 集成）能精细控制服务资源。

5.1 查看服务列表

1
2
3
4
5


# 当前已激活的服务
systemctl list-units

# 所有 unit 文件（激活 + 未激活）
systemctl list-unit-files

5.2 修改 service 后重载

1
2
3
4
5


# 重载所有 unit 文件
systemctl daemon-reload

# 重置失败状态
systemctl reset-failed 服务名

5.3 给服务加资源限制

1

systemctl edit sshd

1
2
3
4
5


[Service]
CPUQuota=20%
MemoryLimit=256M
Nice=-10
IOWeight=100

1
2


sudo systemctl daemon-reload
sudo systemctl restart sshd

字段	含义
`CPUQuota=20%`	限制最多用 20% 单核 CPU
`MemoryLimit=256M`	限制最大 256M 内存
`Nice=-10`	优先级（-20~19，越小越高）
`IOWeight=100`	IO 权重（1~10000）

5.4 区分 Ubuntu Server 与桌面

1
2


# display-manager 服务存在 = 桌面版
systemctl status display-manager

六、性能观测"五把刀"

6.1 五把刀概览

工具	用途
`top`	监控整体服务器：CPU / 内存 / 磁盘 / 网络综合
`dstat -d`	查看磁盘每秒读写量（单位 K）
`dstat -r`	查看磁盘随机的读/写 IOPS
`dstat -n`	查看网卡每秒接收/发送量（单位 K）
`pidstat`	统计各进程磁盘 I/O（也可监控 CPU 和内存）
`iotop`	类似 top，但只看 I/O 相关的进程
`vmstat`	监控 I/O 活跃的进程、内存、CPU

6.2 实战组合

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


# 整体情况
top -c

# 磁盘读写
dstat -d

# 随机 IOPS
dstat -r

# 网络流量
dstat -n

# 各进程磁盘 I/O
pidstat -d 1

# I/O 排行
iotop

# 虚拟内存/IO 活跃
vmstat 1

七、磁盘挂载故障

7.1 重新挂载

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 1. 卸载（如果有进程占用，先 fuser -m -k）
mount /dev/sdb /home

# 2. 查 UUID
blkid

# 3. 写 fstab
echo UUID=3cef6fe2-3899-463a-a0cb-2477765fb446 /media/dell/data ext4 nodev,nosuid 0 2 >> /etc/fstab

# 4. 重启
reboot

7.2 fstab 配错 SSH 连不上

如果 fstab 写错导致机器起不来，SSH 连不上。两种处理：

云控制台 VNC 登录 —— 直接进系统改 fstab
Live CD 启动 —— 挂载原系统盘，编辑 /etc/fstab

预防：写 fstab 之前先 mount -a 测试一下，mount -a 会按 fstab 把所有文件系统都挂一遍。

八、时区配置

1
2
3
4
5
6
7
8
9


# 查时区
timedatectl
date

# 改时区
timedatectl set-timezone Asia/Shanghai

# 老方法：直接覆盖 localtime
cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime

为什么用 timedatectl：systemd 时代 timedatectl 会自动同步 RTC，且与 NTP 服务联动。直接覆盖 /etc/localtime 简单粗暴但可能让 systemd 状态错乱。

九、systemctl 启动 Java 微服务

写一个 service 文件让 Java 程序由 systemd 管理：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


# 1. 写启动脚本
vim /home/project/safety/sh/gateway.sh
vim /home/project/safety/sh/bash.sh
vim /home/project/safety/sh/chemistry.sh

# 2. 写 service 文件
vim /etc/systemd/system/gateway.service
vim /etc/systemd/system/base.service
vim /etc/systemd/system/chemistry.service

# 3. 重载 + 启动
systemctl daemon-reload
systemctl start gateway
systemctl start base
systemctl start chemistry

# 4. 停止
systemctl stop gateway
systemctl stop base
systemctl stop chemistry

# 5. 失败重置
systemctl reset-failed gateway

# 6. 卸载
rm -rf /etc/systemd/system/gateway.service
rm -rf /etc/systemd/system/base.service
rm -rf /etc/systemd/system/chemistry.service

service 文件模板：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


[Unit]
Description=Gateway Service
After=network.target

[Service]
Type=simple
User=root
ExecStart=/home/project/safety/sh/gateway.sh
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

十、卸载旧版 Java

1
2
3
4


# CentOS
rpm -qa | grep java | xargs rpm -e --nodeps
rpm -qa | grep jdk | xargs rpm -e --nodeps
rpm -qa | grep gcj | xargs rpm -e --nodeps

Ubuntu/Debian：apt remove --purge openjdk-* + apt autoremove。

十一、前置知识 / 下一步

想看 iotop / dstat / vmstat 详细用法 → man iotop / man dstat / man vmstat
想看 Prometheus + Grafana 监控栈 → 翻本系列《Linux 监控告警：Prometheus 全家桶》（系列其他文章）
想看 cgroup 原理 → 翻独立文章
想看 systemd 高级用法（target、socket 激活）→ 翻独立文章

十二、参考资源

man top / man glances / man lsof / man dstat / man pidstat / man iotop / man vmstat
systemd.resource-control 文档：https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html
Linux Performance Observability（Brendan Gregg）：http://www.brendangregg.com/linuxperf.html
BCC / bpftrace 工具集：https://github.com/iovisor/bcc

2024 视角：从"工具集"到"观测平台"

2020 年这套"五把刀 + glances + lsof"在 2024 年仍是单机排查的速查。但 2024 主流是 eBPF + 观测平台：

一、eBPF 已经成为 Linux 监控的"基础设施"

2020 → 2024 这 4 年里，eBPF 从"前沿技术"变成"事实标准"：

Cilium（CNI）+ Hubble（eBPF 网络可观测性）已成 K8s 网络主流
Pixie（New Relic 开源）直接用 eBPF 抓应用 trace
bpftrace（2020 文章已经提到）从 0.9 升到 0.16+，单行命令就能看内核状态：

1
2
3
4
5


# 看哪些进程在 5 秒内读了 /etc/passwd
bpftrace -e 'tracepoint:syscalls:sys_enter_openat /arg2->filename == "/etc/passwd"/ { printf("%s [%d]\n", comm, pid); }'

# 跟踪 TCP 重传统计
bpftrace -e 'kprobe:tcp_retransmit_skb { @retrans[comm] = count(); }'

二、`bpftool` + `bcc` 工具集更全

BCC 工具集（2020 提过）已经 100+ 工具，2024 必装：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


apt install bpfcc-tools linux-headers-$(uname -r) linux-tools-$(uname -r)

# 看 CPU 调度延迟
/usr/share/bcc/tools/runqlat

# 看 4 层级网络延迟
/usr/share/bcc/tools/netqtop eth0

# 看进程页错误
/usr/share/bcc/tools/sofdsnoop

替代了大部分 2020 那篇提到的"五把刀"——runqlat 比 pidstat 更细，tcpconnect 比 ss | grep 更实时。

三、systemd 资源控制的"v2 时代"

systemd 252+（2022-10）在资源控制上做了大量增强：

MemoryHigh（软上限，超过触发回收，不杀进程）
MemoryMax（硬上限，OOM 杀手）
IOReadBandwidthMax / IOWriteBandwidthMax（IO 带宽）
CPUWeight（cgroup v2 的 CPU 权重，比 quota 灵活）
IPAccounting + IPAddressAllow / IPAddressDeny（网络白名单）

1
2
3
4
5
6
7


[Service]
MemoryHigh=1G
MemoryMax=2G
CPUWeight=200
IOReadBandwidthMax=/var/lib/mysql 200M
IPAddressAllow=10.0.0.0/8
IPAddressDeny=any

四、`top` 的 2024 替代品

htop 3.x（2022 起的活跃版）：彩色 + 鼠标 + 树状折叠。
btop（2021 推出，2024 仍是 C++ 写的最"美"的终端监控）：CPU/内存/磁盘/网络/温度全屏 sparkline。
gtop（Node.js 写的同类）。
atop（老牌但 2024 仍是"事后分析"王者）：日志记录 + 回放。

1
2
3
4
5


# atop 录到日志，事后看
atop -w /var/log/atop.log 5

# 回放
atop -r /var/log/atop.log

五、Prometheus 仍是 2024 事实标准

2020 那篇提到 Prometheus + Grafana 监控栈是"系列其他文章"。到 2024 年：

Prometheus 2.50+（2024）支持远程写入（Remote Write 2.0）+ Agent Mode（无状态 agent）。
OpenTelemetry（OTel） 已经是 Metrics / Traces / Logs 统一标准，Prometheus 通过 OTLP 接收 trace。
VictoriaMetrics / Thanos / Mimir 是 Prometheus 长期存储的三大选择。
Grafana 10+（2024）原生支持 drill-down link / Explore / Alerting 集成。

六、生产环境监控的"完整架构"

1
2
3
4
5
6
7


[主机 / 容器] → node_exporter / otel-collector
 ↓ remote write
 [Prometheus / VictoriaMetrics]
 ↓ PromQL
 [Grafana 仪表盘] + [Alertmanager 告警]
 ↓
 [钉钉 / 企微 / 飞书 / PagerDuty]

单机时代用 top + glances + iotop 是"万金油"；2024 的微服务 / K8s 时代已经必须走这套观测平台。

Java 微服务治理：Sentinel 限流降级 + Spring Boot Admin 监控

Mon, 15 Jun 2020 00:00:00 +0800

微服务架构跑起来后，稳定性保障是头等大事——限流、熔断、降级、监控告警缺一不可。本篇把 Alibaba Sentinel 限流和 Spring Boot Admin 监控两套核心组件的 Docker 化部署整理清楚。

阅读对象：Java 后端 / 微服务架构师 覆盖范围：Sentinel Dashboard 部署 + Spring Boot Admin 部署 + 微服务接入 + 限流规则配置 + 告警通知 + Loki 日志集成

一、微服务治理全景

1
2
3
4
5
6
7
8
9


微服务治理体系
 ├─ 服务注册发现：Nacos / Consul / Eureka
 ├─ 配置中心：Nacos / Apollo
 ├─ API 网关：Spring Cloud Gateway / Zuul
 ├─ 服务调用：OpenFeign / Dubbo
 ├─ 服务熔断：Sentinel / Hystrix（已停维）
 ├─ 链路追踪：Sleuth + Zipkin / SkyWalking
 ├─ 监控告警：Spring Boot Admin / Prometheus + Grafana
 └─ 日志聚合：ELK / Loki

本篇聚焦：Sentinel（限流熔断）+ Spring Boot Admin（监控）。

When to use Sentinel：

微服务架构，需要防雪崩

双 11、618 大促流量控制

第三方接口调用熔断

秒杀、抢购等高并发场景

When to use Spring Boot Admin：

Spring Boot 微服务集群监控

JVM 指标 / 线程 / 内存 / 日志统一查看

实时健康检查 + 告警

二、Alibaba Sentinel

2.1 简介

Sentinel 是阿里开源的流量控制 / 熔断降级组件，2018 年开源：

维度	Sentinel	Hystrix（已停维）	Resilience4j
流量控制	✅ 多种策略	简单	简单
熔断降级	✅	✅	✅
系统自适应保护	✅（Load / CPU / RT）	❌	❌
控制台	✅ 可视化	简单	无
规则持久化	✅ Nacos / Apollo / 文件	配置中心	代码
社区活跃度	高	已停维	中

2.2 Sentinel Dashboard 部署

下载：v1.8.6

1
2
3
4
5
6
7
8
9


# 1. docker 启动
docker run -d --name sentinel --restart=always \
 -p 18080:8080 \
 -v /home/project/safety/sentinel/jar:/jar \
 lwd/jdk:8u371 \
 java -Dserver.port=8080 \
 -Dcsp.sentinel.dashboard.server=localhost:8080 \
 -Dproject.name=sentinel-dashboard \
 -jar /jar/sentinel-dashboard-1.8.6.jar

docker-compose 完整版：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


version: "3"
x-logging: &loki-logging
 driver: loki
 options:
 loki-url: "http://internal.example.com:3100/loki/api/v1/push"
 max-size: "50m"
 max-file: "10"
 loki-pipeline-stages: |
 - multiline:
 firstline: '^\[\d{2}:\d{2}:\d{2} \w{4}\]'
services:
 sentinel:
 image: lwd/jdk:8u371
 container_name: sentinel
 restart: always
 logging: *loki-logging
 network_mode: host
 volumes:
 - "/home/project/safety/sentinel/jar:/jar"
 command: java -Dserver.port=8080 \
 -Dcsp.sentinel.dashboard.server=localhost:8080 \
 -Dproject.name=sentinel-dashboard \
 -jar /jar/sentinel-dashboard-1.8.6.jar

2.3 访问 Dashboard

1
2


http://<IP>:18080
默认账号：sentinel / sentinel

2.4 微服务接入 Sentinel

添加依赖：

1
2
3
4


<dependency>
 <groupId>com.alibaba.cloud</groupId>
 <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

配置：

1
2
3
4
5
6
7
8
9


spring:
 application:
 name: my-service
 cloud:
 sentinel:
 transport:
 dashboard: localhost:18080  # Sentinel Dashboard 地址
 port: 8719 # 与 Dashboard 通信端口
 eager: true # 启动时立刻注册

限流示例：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


@RestController
public class OrderController {

 @GetMapping("/order/create")
 @SentinelResource(value = "createOrder", blockHandler = "handleBlock")
 public String createOrder() {
 return "success";
 }

 // 限流后的回调
 public String handleBlock(BlockException e) {
 return "系统繁忙，请稍后重试";
 }
}

2.5 限流规则配置

Dashboard → 簇点链路 → 找到 createOrder → 流控：

1
2
3
4


阈值类型：QPS
单机阈值：100
流控模式：直接
流控效果：快速失败

效果：每秒超过 100 个请求 → 触发限流 → 调用 handleBlock。

2.6 熔断降级

Dashboard → 熔断规则：

1
2
3
4
5


资源名：createOrder
熔断策略：慢调用比例
最大 RT：500ms
熔断时长：10s
最小请求数：5

效果：5 个请求中慢调用（>500ms）占比超阈值 → 熔断 10s。

2.7 规则持久化（生产必做）

默认规则存内存，重启就丢。生产用 Nacos 持久化：

1
2
3
4


<dependency>
 <groupId>com.alibaba.csp</groupId>
 <artifactId>sentinel-datasource-nacos</artifactId>
</dependency>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


spring:
 cloud:
 sentinel:
 datasource:
 ds1:
 nacos:
 server-addr: nacos.internal.example.com:8848
 dataId: sentinel-flow-rules
 groupId: DEFAULT_GROUP
 rule-type: flow

三、Spring Boot Admin

3.1 简介

Spring Boot Admin 是 Spring Boot 应用的统一监控中心：

应用健康检查（UP / DOWN / OFFLINE / UNKNOWN）
JVM 指标（内存、线程、GC、堆栈）
HTTP 请求追踪
日志查看（实时拉取）
配置信息（Spring Environment）
告警通知（邮件 / Slack / PagerDuty / 钉钉 / 飞书）

3.2 创建 Admin Server

pom.xml：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


<dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
 <groupId>de.codecentric</groupId>
 <artifactId>spring-boot-admin-starter-server</artifactId>
 <version>2.5.6</version>
</dependency>
<dependency>
 <groupId>org.projectlombok</groupId>
 <artifactId>lombok</artifactId>
 <optional>true</optional>
</dependency>

Application.java：

1
2
3
4
5
6
7


@SpringBootApplication
@EnableAdminServer
public class SpringbootAdminApplication {
 public static void main(String[] args) {
 SpringApplication.run(SpringbootAdminApplication.class, args);
 }
}

application.yml：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


server:
 port: 4396
spring:
 application:
 name: springbootadmin
 boot:
 admin:
 notify:
 slack:
 enabled: true
 webhook-url: https://hooks.slack.com/services/{{SLACK_TOKEN}}
 mail:
 enabled: true
 from: noreply@example.com

3.3 部署

1
2
3
4
5


docker run -d --name springbootadmin --restart=always \
 -p 14396:4396 \
 -v /home/docker/springboot-admin/jar:/jar \
 lwd/jdk:8u371 \
 java -jar /jar/SpringbootAdmin-0.0.1-SNAPSHOT.jar

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# docker-compose
version: "3"
x-logging: &loki-logging
 driver: loki
 options:
 loki-url: "http://internal.example.com:3100/loki/api/v1/push"
services:
 admin:
 image: lwd/jdk:8u371
 container_name: admin
 restart: always
 logging: *loki-logging
 network_mode: host
 volumes:
 - "/home/project/safety/admin/jar:/jar"
 command: java -jar /jar/SpringbootAdmin-0.0.1-SNAPSHOT.jar

访问：

1

http://<IP>:14396

3.4 微服务注册到 Admin

添加依赖：

1
2
3
4
5


<dependency>
 <groupId>de.codecentric</groupId>
 <artifactId>spring-boot-admin-starter-client</artifactId>
 <version>2.5.6</version>
</dependency>

配置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


spring:
 boot:
 admin:
 client:
 url: http://admin.internal.example.com:14396
 instance:
 name: my-service
 prefer-ip: true
management:
 endpoints:
 web:
 exposure:
 include: "*"
 endpoint:
 health:
 show-details: always

重启微服务 → 30 秒后 Admin 后台就能看到这个应用。

3.5 Admin 后台功能

Applications → 点击应用：

Details：基本信息
Metrics：JVM / 内存 / 线程
Environment：配置
Logging：实时日志（Level 实时调整）
JVM：堆栈、线程、GC
Mappings：REST API 列表
Trace：最近 HTTP 请求
Threads：线程详情（可以 dump 堆栈）
Heapdump：下载堆转储

3.6 告警通知

邮件告警（最常用）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


spring:
 mail:
 host: smtp.example.com
 port: 465
 username: noreply@example.com
 password: {{SMTP_PASS}}
 boot:
 admin:
 notify:
 mail:
 enabled: true
 to:
 - ops-team@example.com
 from: noreply@example.com

Slack 告警：

1
2
3
4
5
6
7
8


spring:
 boot:
 admin:
 notify:
 slack:
 enabled: true
 webhook-url: https://hooks.slack.com/services/{{TOKEN}}
 channel: '#alerts'

钉钉告警（自定义 NotificationListener）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


@Component
public class DingTalkNotifier implements Notifier {
 @Override
 public void notify(InstanceEvent event) {
 if (event instanceof InstanceStatusChangedEvent) {
 // 调钉钉 Webhook
 sendToDingTalk(((InstanceStatusChangedEvent) event).getInstance().getRegistration().getName());
 }
 }
}

四、限流 vs 监控告警的配合

场景	Sentinel	Spring Boot Admin
应用崩溃	熔断防止雪崩	告警 + JVM 监控
接口慢	慢调用比例熔断	Thread dump 分析
流量激增	QPS 限流	QPS / TPS 指标
内存爆	（不管）	JVM 内存告警
依赖服务挂	熔断下游	Health Check 告警

生产推荐两者都上——Sentinel 做"主动防御"，Admin 做"被动感知"。

五、典型坑位

5.1 Sentinel Dashboard 看不到应用

修复：

1
2
3
4
5
6


spring:
 cloud:
 sentinel:
 transport:
 dashboard: localhost:18080  # 用 IP，不用 localhost
 eager: true # 启动时主动注册

触发初始化：访问任意接口（Sentinel 是懒加载，没人调用就不知道有这个接口）。

5.2 限流规则不生效

修复：

1
2
3
4
5


// 1. 必须加 @SentinelResource
@SentinelResource(value = "createOrder", blockHandler = "handleBlock")

// 2. 或者用 URL 流控（不推荐）
// Dashboard → 流控规则 → 资源名填 /order/create

5.3 Admin 显示应用 OFFLINE

修复：

1
2
3
4
5
6


spring:
 boot:
 admin:
 client:
 instance:
 prefer-ip: true

应用注册到 Admin 时用 IP，不是 hostname。

5.4 Admin 看不到日志

修复：

1
2
3
4
5


logging:
 file:
 name: /app/logs/myapp.log
 pattern:
 file: "%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n"

日志文件路径必须固定，Admin 才能拉取。

六、生产级架构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


 ┌─────────────────┐
 │ Spring Cloud │
 │ Gateway │
 └────────┬────────┘
 │
 ┌──────────────────────┼──────────────────────┐
 │ │ │
 ┌──────▼──────┐ ┌───────▼──────┐ ┌───────▼──────┐
 │ service-a │ │ service-b │ │ service-c │
 └──────┬──────┘ └───────┬──────┘ └───────┬──────┘
 │ │ │
 │ 注册信息 + 健康检查 + JVM 指标 │
 └──────────────────────┼──────────────────────┘
 │
 ┌──────────▼──────────┐
 │ Spring Boot Admin │
 │ Dashboard │
 └─────────────────────┘
 │
 ┌──────────▼──────────┐
 │ Sentinel │
 │ Dashboard │
 └─────────────────────┘

所有微服务都做 3 件事：

注册到 Nacos
监控到 Spring Boot Admin
限流配置到 Sentinel

七、Spring Boot Admin 高级用法

7.1 日志级别动态调整

Admin 后台 → Logs → 选择 logger → 改 level（如 INFO → DEBUG）。

实时生效，不需要重启应用。

7.2 线程 Dump

Admin 后台 → Threads → Download → 拿 .tdump 文件分析。

典型场景：应用 hang 住时直接 dump 线程看是哪里卡了。

7.3 Heap Dump

Admin 后台 → Heapdump → 下载 .hprof → 用 VisualVM / MAT 分析内存泄漏。

7.4 集成 Spring Security

Admin 后台默认无认证——生产必加：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


@Configuration
public class SecurityConfig {
 @Bean
 public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
 http
 .authorizeHttpRequests(authz -> authz
 .requestMatchers("/login", "/css/**", "/js/**").permitAll()
 .anyRequest().authenticated()
 )
 .formLogin(Customizer.withDefaults());
 return http.build();
 }
}

八、最佳实践清单

Sentinel + Spring Boot Admin 一起上——防御 + 监控双保险
Sentinel 规则持久化到 Nacos——重启不丢
Admin 后台加 Spring Security——避免被公网访问
限流阈值用真实压测数据——不要拍脑袋
熔断时长 10s 起——给下游恢复时间
告警分级——P0（立即响应）/ P1（小时级）/ P2（日级）
告警去重——同一问题 5 分钟内只发一次
告警值班——on-call 机制，避免"狼来了"
JVM 指标进 Prometheus——长期趋势分析
链路追踪进 SkyWalking——慢调用根因分析

2024+ 视角补充

本文写于 2020-06，2024-2026 期间 Java 微服务治理关键演进：

Sentinel 1.8.6+ → 1.8.8+（2024-2025）：Spring Boot 3.x 兼容；JDK 17+ 强制；OpenTelemetry 集成——指标 / Trace 全打通
Sentinel 2.0 路线图（2025-Q3）：AI 限流（基于 LLM 流量预测）；自适应并发（自动调整阈值）
Spring Boot Admin 3.x（2024-2025）：Spring Boot 3.x 兼容；Micrometer Tracing 集成；WebFlux 异步应用监控
微服务治理生态（2024-2026）：
- Spring Cloud Alibaba 2023.0+：Nacos 2.x + Sentinel 1.8+ + Seata 1.8+ + RocketMQ 5.x 一站式
- Spring Cloud 2024+：逐步被 Spring Cloud OpenFeign + 独立组件取代——“Spring Cloud 套件"模式弱化
- Service Mesh（Istio 1.20+ / Linkerd 2.15+）：限流 / 熔断下沉到 Sidecar，Java 业务代码不写限流逻辑——2024+ 趋势
- 可观测三件套：Micrometer + Prometheus + Grafana + Tempo（Trace）——Sentinel 与 OpenTelemetry 融合
Spring Cloud Gateway 4.x（2024）：Reactor 2024+；Spring Cloud LoadBalancer（替代 Ribbon）
云原生时代：Spring Boot 3.4+ + K8s 1.30+ + Istio 1.20+ 是 2025+ Java 微服务黄金组合

实战建议（2025-2026 视角）：

传统 Spring Cloud 套件 → Spring Cloud Alibaba 2023.0.x 仍是 2024+ 稳态
K8s 上 → Service Mesh 优先（限流 / 熔断下沉 Sidecar）
AI 监控 → Micrometer + OpenTelemetry + LLM 异常检测（2025+ 实验性）
存量项目 → 升 Spring Boot 3.4+ + JDK 21 是 2025+ 主路线

下一步

想看 JDK 自建镜像实战（Alpine / Debian / Ubuntu）→ JDK 自建镜像实战
想看 Java 应用 Docker 化（Tomcat / Spring Boot 打包）→ Java 应用 Docker 化
想看 XXL-Job 分布式调度（任务调度平台）→ XXL-Job 分布式调度
想看 Nginx 自建镜像实战（反代安全加固）→ Nginx 自建镜像实战

bat 脚本监控与排查：wmic + taskkill 进程管理实战

Sat, 15 Mar 2014 00:00:00 +0800

一、为什么 2024 年还在写 bat 脚本

2014 年的 Windows 自动化基本是 bat + VBScript 双雄；2018 年之后 PowerShell Core 跨平台，bat 看起来"该退休"了。但实际场景里：

老旧 Windows Server 2008 R2 / 2012 R2 默认没装 PowerShell 5，bat 仍是首选
计划任务里挂的"老脚本"没人敢动，出问题了又得维护
NSSM 注册服务的某些参数只能传 bat 路径
第三方工具的安装脚本（很多 CAD / 工控软件）就是 bat，你绕不开

所以"bat 找 PID + 杀进程"是必须会的硬功夫。本文以两个高频需求切入：

找到后台跑的 bat 进程（常见：监控 / 重启脚本卡死）
结束指定进程（常见：清残留）

二、找后台运行的 bat 进程

2.1 用 wmic 找 bat 进程

1

wmic process get commandline,processid | findstr 监控重启.bat | findstr /v findstr

逐步拆解：

wmic process get commandline,processid —— 列出所有进程的"完整命令行"和"PID"
findstr 监控重启.bat —— 过滤出命令行里含"监控重启.bat"的行
findstr /v findstr —— 排除掉 “findstr 自身” 那一行（否则你会看到 findstr 自己的命令行）

输出形如：

1

cmd.exe /c "D:\scripts\监控重启.bat" 4620

第二列的 4620 就是 bat 对应的 PID（其实是 cmd.exe 的 PID，因为 bat 是 cmd 解释执行的）。

2.2 用 PowerShell 等价（推荐）

1
2
3


Get-CimInstance Win32_Process |
 Where-Object { $_.CommandLine -like '*监控重启.bat*' } |
 Select-Object ProcessId, Name, CommandLine

PowerShell 的优势：

对象化输出，可以直接 | Stop-Process 一气呵成
不像 wmic 那样返回字符串，不依赖解析列宽
Unicode 中文文件名不会乱码

wmic 在 Win 10 21H1 起开始被标记为 deprecated（最终会从 Windows 中移除），强烈建议新写的脚本用 PowerShell CIM。

2.3 用 Get-Process 按名字找（不推荐）

1

Get-Process cmd | Where-Object { $_.MainWindowTitle -like '*监控*' }

缺点：cmd.exe 的所有实例都返回（10 个 cmd 窗口就有 10 条），需要再过滤窗口标题，对纯后台运行的 bat 不适用。

三、结束进程

3.1 taskkill（cmd 原生）

1

taskkill /f /pid 4620

参数说明：

/f —— 强制结束（不弹确认）
/pid —— 按 PID
/im —— 按镜像名（taskkill /f /im cmd.exe 会杀掉所有 cmd 窗口，慎用）

3.2 杀进程并确认

1
2
3
4
5
6


taskkill /f /pid 4620
if %errorlevel% == 0 (
 echo 杀进程成功
) else (
 echo 杀进程失败，可能权限不够
)

3.3 PowerShell 一行杀

1
2
3


Get-CimInstance Win32_Process |
 Where-Object { $_.CommandLine -like '*监控重启.bat*' } |
 ForEach-Object { Stop-Process -Id $_.ProcessId -Force }

或者用更直观的 Get-Process：

1
2
3


Get-Process -Name cmd -ErrorAction SilentlyContinue |
 Where-Object { $_.Path -eq 'C:\Windows\System32\cmd.exe' } |
 Stop-Process -Force

四、实战：监控重启脚本

4.1 需求

写一个 bat 监控某个进程（如 myapp.exe），如果挂了自动重启。

4.2 朴素版（轮询）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


@echo off
set INTERVAL=30
:loop
tasklist | findstr /i "myapp.exe" >nul
if %errorlevel% == 0 (
 echo %date% %time% myapp.exe 正常运行
) else (
 echo %date% %time% myapp.exe 已挂，重启中...
 start "" "C:\apps\myapp.exe"
)
timeout /t %INTERVAL% /nobreak >nul
goto loop

关键点：

tasklist | findstr /i —— 查进程是否存在
if %errorlevel% == 0 —— 找到就是 0
start "" —— 空标题必须，否则会报错
timeout /t N /nobreak —— 等 N 秒，不响应 Ctrl+C（比 ping -n 更精确）

4.3 改进版（按需触发）

如果只想要"挂了再启动，不轮询"，可以用 WaitForSingleObject 思路，但 bat 实现不了，这种场景请用 nssm 注册成 Windows 服务（详见 0.4 批次的 2022-12-15《Windows 系统管理员实战》）。

4.4 用 PowerShell 写监控脚本

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


$target = 'myapp'
$interval = 30
$exe = 'C:\apps\myapp.exe'

while ($true) {
 if (-not (Get-Process -Name $target -ErrorAction SilentlyContinue)) {
 Write-Host "$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss') $target 已挂，重启"
 Start-Process -FilePath $exe
 } else {
 Write-Host "$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss') $target 正常"
 }
 Start-Sleep -Seconds $interval
}

PowerShell 优势：

Get-Process 比 tasklist | findstr 更可靠（处理特殊字符不挂）
Start-Sleep 比 timeout 更可编程
异常可以用 try/catch 包裹

五、批处理编码与中文乱码

5.1 bat 文件默认编码

bat 在 中文 Windows 下默认是 GBK 编码。如果你用 UTF-8 编码的 bat 直接运行，中文会乱码。

两种处理方式：

保存为 GBK / ANSI 编码（最稳）—— 用 VS Code 右下角"UTF-8"点开选"Save with Encoding"→“GBK"或"Chinese Simplified (GB2312)”
保存为 UTF-8 BOM 编码 —— Windows 10 1809+ 能识别 BOM 自动用 UTF-8 解释
在 bat 顶部加 chcp 65001 >nul —— 切换控制台代码页到 UTF-8，但这不会改变 bat 源文件的解释编码，对 bat 里的中文 echo 没有帮助，仅对 bat 调用的外部命令的输出有影响

5.2 输出 UTF-8 到文件

1
2


chcp 65001 >nul
echo 你好，世界 > output.txt

注意：> 重定向输出的 output.txt 会带 UTF-8 BOM（如果 cmd 默认按 ANSI 解释 echo 命令后再输出）。最稳的办法是用 PowerShell：

1

"你好，世界" | Out-File -FilePath output.txt -Encoding UTF8

5.3 bat 里包含中文路径

1
2


cd /d "D:\我的文档\脚本"
call 启动.bat

中文路径用双引号包起来就不会出错。/d 开关让你不用先 D: 切盘符。

六、批处理常见错误与排查

6.1 错误级别（`%errorlevel%`）

每条命令执行后，cmd 设置一个 errorlevel：

0 —— 成功
非 0 —— 失败（具体值看命令）

1
2
3
4
5
6


@echo off
xcopy C:\source D:\dest /E /I
if %errorlevel% neq 0 (
 echo 拷贝失败，错误码 %errorlevel%
 exit /b %errorlevel%
)

6.2 延迟扩展（`setlocal enabledelayedexpansion`）

bat 里的 if 块、for 块默认不实时展开变量。典型坑：

1
2
3
4
5
6


@echo off
set COUNT=0
for /l %%i in (1,1,5) do (
 set /a COUNT+=1
 echo 当前 COUNT=%COUNT%
)

输出：

1
2
3
4
5


当前 COUNT=0
当前 COUNT=0
当前 COUNT=0
当前 COUNT=0
当前 COUNT=0

因为 %COUNT% 在 for 块开始时就被展开为 0，后续 set /a 修改的 COUNT 没被重新读取。

正确写法：

1
2
3
4
5
6
7


@echo off
setlocal enabledelayedexpansion
set COUNT=0
for /l %%i in (1,1,5) do (
 set /a COUNT+=1
 echo 当前 COUNT=!COUNT!
)

关键点：

顶部加 setlocal enabledelayedexpansion
块内用 !VAR! 而非 %VAR% 来读取最新值

6.3 路径里的空格

1
2


cd "C:\Program Files\MyApp"
cd %PROGRAMFILES%\MyApp

用双引号包路径最稳。第二种用环境变量展开也 OK，但路径里有 & 之类特殊字符必须用引号。

七、批处理的替代方案

场景	替代方案
简单文件操作 / 启停服务	bat 仍是最简方案
跨平台脚本	PowerShell Core / pwsh
复杂文本处理	PowerShell / Python
长任务调度	Windows 任务计划程序 + bat/ps1
常驻服务	nssm 注册成服务（详见 2022-12-15 那篇）
配置中心	Ansible（WinRM 协议）

八、常见 5 个坑

wmic 在新 Windows 上 deprecated——新写脚本用 Get-CimInstance。
中文乱码——bat 源文件保存为 GBK / ANSI 编码最稳。
for 块内 %VAR% 不刷新——用 setlocal enabledelayedexpansion + !VAR!。
taskkill /f /im cmd.exe 把所有 cmd 窗口都杀了——按 PID 杀更精准。
bat 里的"后台进程"实际是 cmd.exe——wmic 找到的 PID 是 cmd 解释器的，杀它才能停 bat。

九、总结

找后台 bat 进程：wmic process get commandline,processid | findstr xxx.bat（老方案）；Get-CimInstance（推荐）
杀进程：taskkill /f /pid PID（cmd）；Stop-Process（PowerShell）
监控 + 自动重启：tasklist | findstr 轮询（朴素）；nssm 注册服务（推荐）
中文乱码：bat 源文件保存为 GBK / ANSI最稳
延迟变量：setlocal enabledelayedexpansion + !VAR!
新写脚本优先用 PowerShell（pwsh 跨平台），bat 留给"老系统 / 老脚本维护"