服务监控核心是及时发现异常、定位问题、评估影响，需聚焦反映健康状态和指导排障的指标，覆盖可用性、性能、资源消耗、业务逻辑四维度，并关注python隐性风险及轻量落地实践。
服务监控的核心目标是及时发现异常、定位问题、评估影响
不是所有指标都要采集，重点看是否能反映服务健康状态、是否能指导故障排查。比如CPU使用率本身不直接说明服务是否出问题，但结合请求错误率和响应延迟，就能判断是不是过载或代码有缺陷。
关键监控指标要覆盖四个维度
可用性：HTTP状态码分布（尤其是5xx、4xx比例）、端口连通性、进程存活状态。
性能：平均响应时间（P90/P95更实用）、请求吞吐量（QPS）、慢请求占比（如>1s的请求比例）。
资源消耗：内存占用（注意RSS而非VSS）、线程/协程数、文件描述符使用量、GC频率与耗时（对Python尤其重要）。
业务逻辑：核心接口调用成功数、订单创建失败原因分类、缓存命中率、数据库连接池等待时长。
Python服务中要特别关注的“隐性风险点”
• GIL争用导致的伪高CPU：多线程Python服务CPU高但QPS低，可能是锁竞争或频繁切换，需配合线程栈采样分析。
• 内存泄漏常见诱因：全局字典未清理、循环引用（尤其带__del__的对象）、日志对象长期持有上下文。
• 异步任务积压：使用asyncio或Celery时，检查任务队列长度、worker空闲率、重试次数突增。
• 第三方库副作用：requests未关闭session、redis连接未复用、SQLAlchemy session未及时close——这些不会立刻报错，但会缓慢拖垮服务。
落地建议：轻量起步，逐步增强
• 用Prometheus + client_python暴露基础指标（HTTP中间件自动打点+自定义业务计数器）。
• 配合Grafana做可视化，首页只放5个以内最关键的看板（如错误率、P95延迟、内存趋势、QPS、任务积压数）。
• 设置分级告警：严重级（5xx > 5%持续2分钟）、警告级（P95 > 2s持续5分钟）、观察级（内存使用率 > 80%）。
• 日志中结构化记录关键字段（trace_id、status、duration、error_type），便于和指标交叉下钻分析。
