Python 程序运行指标的采集思路

用 psutil 实时获取 python 进程 CPU 和内存使用率最稳妥，需基于当前 pid 创建 Process 实例；cpu_percent 需两次调用（间隔 0.1–0.5 秒），memory_info().rss 除以 1024² 得 MB；多进程须单独采集；应通过守护线程+队列缓存指标，避免阻塞主逻辑；prometheus 导出推荐用 prometheus_client，定义带 pid/name 维度的 Gauge；禁用 time.time() 测耗时，优先选 process_time 或 perf_counter；异步场景下仍有效，但需注意上下文损耗；聚焦 CPU、RSS、线程数、GC 四项核心指标。

Python 进程 CPU 和内存使用率怎么实时获取

直接用 psutil 是最稳的选择，它跨平台、开销低、API 清晰。别自己去读 /proc/pid/stat 或调用 os.popen('top')，既难维护又容易出兼容问题。

关键点：必须基于当前进程的 pid 构造 psutil.Process() 实例，否则拿到的是系统全局值。

• process.cpu_percent(interval=0.1)：首次调用会返回 0，需至少调用两次（间隔 >0）才有效；interval 太小（如 0.01）会导致精度失真，推荐 0.1–0.5 秒
• process.memory_info().rss 返回字节数，除以 1024**2 转 MB；注意 vms（虚拟内存）在容器中常失真，优先看 rss
• 如果程序是多进程，每个子进程需单独采集，父进程调用 psutil.Process(child_pid)，不能复用主进程对象

如何避免指标采集拖慢主业务逻辑

指标采集本身有 I/O 和计算开销，尤其 cpu_percent() 依赖两次采样间隔，阻塞式调用会卡住主线程。

• 用独立线程周期性采集，通过 Threading.Thread(daemon=True) 启动，避免阻碍主程序退出
• 用 queue.Queue 缓存最新一次采集结果，业务代码只做非阻塞读取，不参与采集过程
• 不要在 http 请求处理函数或数据库事务里实时调用 psutil —— 这类路径延迟敏感，应读缓存值
• 容器环境（如 docker）中，psutil.sensors_temperatures() 等硬件接口不可用，提前判断 hasattr(psutil, 'sensors_temperatures') 再调用

指标数据怎么结构化导出供监控系统消费

Prometheus 是最常见目标，但 Python 原生不支持暴露指标端点，得靠 prometheus_client 库补足。

立即学习“Python免费学习笔记（深入）”；

• 定义指标前先想清楚维度：比如 python_process_cpu_percent{pid="1234", name="worker"} 比单纯 python_cpu_percent 更有用
• 用 Gauge 类型存瞬时值（CPU、RSS），用 Counter 记累计量（如请求总数、异常次数）
• 避免高频 .set()：每秒更新一次即可，Prometheus 抓取频率通常为 15s，更密反而浪费
• 若不用 Prometheus，输出 jsON 到标准输出也行，但字段名统一用小写+下划线（如 mem_rss_bytes），方便 Logstash 或 Fluentd 解析

为什么 time.time() 不适合做耗时指标的基准

它只反映 wall-clock 时间，无法区分 CPU 占用、I/O 等待、GIL 阻塞等真实瓶颈，导致指标误导性很强。

• 用 time.process_time() 测纯 CPU 执行时间（不含 sleep、I/O 等等待）
• 用 time.perf_counter() 测端到端耗时（含等待），但要注意：它在系统休眠后可能跳变，不适合长期运行服务的“总运行时”统计
• 真正要定位性能热点，得结合 cProfile 或 py-spy，而不是靠外围采集的平均值
• 异步场景（asyncio）下，process_time 仍有效，但要注意事件循环切换带来的上下文损耗，单次 await 的耗时意义有限

采集不是越全越好，重点盯住 CPU、RSS、线程数、GC 次数这四个硬指标；其余像磁盘 I/O、网络连接数，只在对应模块启用时才打开采集开关——否则只是给监控系统喂噪音。