CentOS 上建议采用“应用内指标 + 系统资源监控 + 持续监视器”的组合方案，覆盖接口性能、主机负载与长期可用性。
监控方案总览
| 维度 |
工具或方式 |
关键指标 |
典型用途 |
| 应用内性能 |
Postman Monitor、Collection Runner |
响应时间、成功率、断言结果、P95/P99 |
回归验证、定时健康检查、趋势对比 |
| 系统资源 |
top/htop、nmon、glances、vmstat/iostat |
CPU、内存、磁盘 I/O、网络 |
定位瓶颈、容量评估、异常归因 |
| 运行与日志 |
ps、journalctl、Postman 日志目录 |
进程存活、错误日志、控制台输出 |
故障排查、审计与告警依据 |
应用内性能监控
- 使用 Postman Monitor 做定时拨测与可用性监控：为集合创建 Monitor，设置运行频率（如每 5 分钟）、选择环境与时区；在报告中查看 Monitor Summary / Request Split 视图，获取响应时间统计、成功率与测试结果，便于观察 P95/P99 等延迟趋势与错误率变化。该方式适合长期 SLA 观测与回归。
- 使用 Collection Runner / Newman 做批量与并发执行：在 Runner 中配置集合、迭代次数与并发数，执行后在结果面板查看每个请求的响应时间与成功率；若需更高并发或更复杂场景，可结合 CI/CD 自动化运行。注意 Postman 更适合简单性能测试，复杂压测建议使用 JMeter/LoadRunner 等专业工具。
系统资源监控
- 实时与交互式监控：使用 top/htop 观察 Postman 进程的 CPU% / MEM%，快速定位高占用进程；nmon 获取 CPU、内存、磁盘 I/O 等综合视图；glances 提供跨平台监控与可选 Web 界面，便于集中查看。
- 采样与趋势分析：使用 vmstat 1（或 iostat -x 1）记录 CPU 空闲、I/O 等待、上下文切换 等，配合日志长期保存，用于容量规划与性能回溯。
- 容器化场景：若通过 Docker 运行 Postman，使用 docker stats 实时查看容器 CPU、内存、网络 I/O 等指标，便于与宿主机指标联动分析。
运行监控与日志
- 进程与状态：使用 ps aux | grep postman 检查进程是否存在；若以服务方式运行，使用 systemctl status postman.service 查看运行状态与最近日志。
- 系统日志：通过 journalctl 检索与 Postman 相关的系统日志（如服务单元日志），辅助定位启动失败、崩溃等问题。
- Postman 日志：检查用户目录 ~/.postman/logs/ 下的日志文件，获取应用运行细节与错误输出，配合 Monitor 的 Console log 与 Test Results 做问题复核。
快速上手与最佳实践
- 5 步落地
- 在 Postman 为关键集合创建 Monitor（如每 5 分钟 一次），在测试脚本中补充 响应时间阈值 与业务断言，建立可观测基线。
- 在 CentOS 上启动 htop/nmon/glances 实时观察资源波动，必要时用 vmstat/iostat 采样记录。
- 使用 Collection Runner 执行小规模并发回归（例如 10–20 并发、3–5 次迭代），验证脚本稳定性与指标采集完整性。
- 将 Runner 集成 Jenkins/GitLab CI，在代码提交或部署后自动运行，产出报告并与历史对比。
- 建立告警基线：Monitor 失败、成功率低于阈值、P95/P99 明显劣化、或系统 CPU/内存/磁盘 I/O 超阈值即触发通知（企业微信/钉钉/邮件）。