pidstat可精准监控微服务各组件进程的cpu、内存、i/o及上下文切换行为，需结合ps或systemctl获取pid，按服务角色差异化采集指标：网关关注%usr+%system与ncswch/s，java服务关联majflt/s与gc日志，go服务侧重-u和-d，消息消费者紧盯kb_wr/s与lag关系。
在微服务架构中，各组件（如 API 网关、注册中心、配置中心、业务服务、消息消费者等）通常以独立进程运行，常驻后台且资源消耗动态变化。pidstat 不直接识别“微服务”概念，但能精准监控每个服务进程的 CPU、内存、I/O 和上下文切换行为——这正是定位负载瓶颈的关键。
确认并定位目标微服务进程
微服务多由 Java、Go、Node.js 等启动，需先获取其 PID 或命令名：
- 用 ps -ef | grep 模糊匹配服务关键词，例如：
ps -ef | grep "nacos-server"或ps -ef | grep "spring-boot" - 若服务通过 systemd 管理，可用
systemctl show -p MainPID <service-name></service-name>获取 PID - 推荐结合 -C 选项按命令名筛选，避免 PID 变更导致监控中断，例如：
pidstat -C "java" -u 2可捕获所有 Java 进程的 CPU 使用
分维度采集关键负载指标
单一视图无法反映真实压力，应组合使用不同选项，间隔采样（如每 3 秒一次，持续 10 次）：
-
CPU 竞争：执行
pidstat -u -p <pid> 3 10</pid>，重点关注 %usr（业务逻辑耗时）和 %system（内核调用开销），若 %system 显著偏高，可能涉及频繁系统调用（如日志刷盘、网络 epoll） -
内存压力：执行
pidstat -r -p <pid> 3 10</pid>，观察 majflt/s（主缺页次数）。持续 > 0 表示频繁从磁盘加载页，常见于堆内存不足触发 GC 后反复加载类或缓存数据 -
I/O 阻塞：执行
pidstat -d -p <pid> 3 10</pid>，检查 kB_rd/s 和 kB_wr/s 是否突增。例如配置中心大量拉取配置时，可能伴随高读；消息消费者批量写 DB 则体现为高写 -
线程震荡：执行
pidstat -w -t -p <pid> 3 10</pid>，对比 cswch/s（自愿切换）与 ncswch/s（非自愿切换）。ncswch/s 持续高于 cswch/s，往往说明线程被抢占严重，CPU 资源紧张或存在锁竞争
按服务角色做差异化监控策略
不同微服务组件负载特征不同，应调整关注重点：
- 网关类（如 Spring Cloud Gateway、Kong）：高并发下重点关注 %usr + %system 总和是否接近 100%，以及 ncswch/s 是否随 QPS 上升陡增，可判断线程模型（Reactor vs Thread-per-Request）是否适配
-
Java 业务服务：必须搭配
-r监控 majflt/s，并关联 JVM 的 GC 日志。若 majflt/s 波动与 Full GC 时间吻合，基本可判定为堆外内存泄漏或 DirectByteBuffer 使用不当 -
Go 微服务（如 etcd、consul）：Go runtime 自管理 M:N 线程，
pidstat -t显示的“线程数”常远高于实际 goroutine 数，此时更应依赖-u和-d，观察是否因协程调度器阻塞导致 CPU 利用率异常偏低而延迟升高 -
消息消费者（如 Kafka consumer）：典型 I/O 密集型，
pidstat -d中 kB_wr/s 应与消费速率正相关；若 kB_wr/s 极低但 lag 持续增长，需检查是否卡在反序列化或数据库事务中
整合输出便于比对分析
多个服务需横向对比时，避免人工翻页：
- 用
-h输出单行格式，方便导入 Excel 或脚本解析：pidstat -u -r -d -C "java" 5 -h > microsvc-stats.csv - 加
-l显示完整命令行参数，区分同一 JVM 启动的不同服务实例：pidstat -C "java" -l 2 - 对长期运行的服务，可配合 cron 每 5 分钟记录一次摘要：
*/5 * * * * pidstat -u -r -p $(pgrep -f "auth-service") 1 1 >> /var/log/auth-load.log
