用 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的耗时意义有限
