性能指标需与业务节奏对齐：支付接口均值80ms若超时阈值100ms且失败集中于最后20ms则属危险，应分段打点统计p50/p90/p99及超时占比，并映射为分级标签（如“A级响应”≤300ms）而非裸露数值。
怎么把 time.perf_counter() 的数字变成业务能看懂的判断
性能指标不是越小越好，而是要和业务节奏对齐。比如支付接口平均耗时 80ms，听起来快，但如果用户等待超时设的是 100ms、失败率又集中在最后 20ms 区间，那这 80ms 就是危险信号。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 别只记均值——用
time.perf_counter()分段打点，至少捕获 p50/p90/p99 和超时（如 >100ms）占比 - 把耗时映射到业务状态：比如
db_query_time > 50ms触发降级日志，render_time > 200ms自动切简化模板 - 避免直接暴露原始数值给产品/运营，改用分级标签：
"A级响应"（"B级预警"（100–300ms）、"C级阻塞"（>300ms）
为什么 psutil.cpu_percent() 在容器里经常不准
容器共享宿主机 CPU 资源，但 psutil.cpu_percent() 默认按“自上次调用以来”的增量计算，而容器可能被限频、被抢占，导致采样窗口内实际调度时间极短，结果要么是 0，要么是虚高。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 必须传
interval=1.0（不能为 0），且首次调用会返回 0.0，需忽略——第二次起才有效 - 在 Kubernetes 中优先用 cgroup 接口：
/sys/fs/cgroup/cpuacct/cpuacct.usage+/sys/fs/cgroup/cpu/cpu.cfs_quota_us算出真实使用率 - 如果只能用
psutil，建议连续采样 3 次取中位数，避开瞬时抖动
logging.info() 打日志为什么拖慢了接口 300ms
默认的 FileHandler 是同步阻塞写入，尤其当日志格式含 %(asctime)s 或用了 RotatingFileHandler，每次写都触发磁盘 I/O 和锁竞争。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 生产环境禁用
StreamHandler和FileHandler直连，改用QueueHandler+ 后台线程消费 - 把非关键日志（如调试级）关掉，或用
if logger.isEnabledFor(logging.DEBUG)提前拦截 - 避免在日志里拼接大对象：
logging.info("user=%s", user_obj)比logging.info(f"user={user_obj}")安全得多——后者不管是否输出都会执行字符串格式化
监控告警阈值设成 95% CPU 利用率，为什么总在半夜误报
95% 是个静态数字，但业务流量有峰谷。半夜流量只有白天 5%，此时 CPU 占用 95% 很可能是单个异常进程卡死，而不是整体过载；反过来，大促期间白天 85% 可能已逼近瓶颈。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 阈值必须带上下文：用
cpu_utilization_5m_avg替代cpu_usage_percent，再结合http_requests_total_5m_rate做比值归一化 - 对周期性服务（如定时任务），加静默规则：检测到
crond进程活跃时，临时放宽 CPU 告警窗口 - 真正该盯的是“不可用时间”，不是利用率——比如
process_cpu_seconds_total突增但up == 0，说明进程已崩溃，比任何百分比都关键
业务化解读最难的不是算数，是得知道哪一毫秒的延迟会让人取消订单、哪 0.5% 的错误率会让客服电话爆掉——这些没法从指标文档里抄，得蹲在日志和用户反馈里认出来。
