第24章：可观测性实战——日志、指标与追踪

1. 项目背景业务场景某公司的AI平台已经运行了三个月，接入了客服、研发、运维三个部门。但CTO在一次故障复盘会上发现一个令人尴尬的事实——每次出问题都是用户报的，从来没有系统主动告警。上周五的故障最典型：下午2:30开始，AI响应延迟缓慢上升，从2秒爬到15秒——但因为没人监控，直到3:00客服主管在群里喊"AI是不是坏了？"技术团队才开始排查。最终发现是某个测试脚本在后台反复调用大模型做长文档摘要，占满了GPU。如果能提前监控到tokens/s下降和P95延迟飙升，这个故障3分钟内就能解决。更让人头疼的是，"AI今天表现不好"这句话没法定位——到底是模型加载慢？排队等太久？Prompt太长？还是模型输出太慢？在没有分阶段监控数据的情况下，排查全靠猜。痛点无指标体系：不知道QPS、延迟P95、tokens/s、错误率的当前值和趋势。无结构化日志：日志是print()打出来的，没有request_id，无法关联一次请求的全链路。流式追踪困难：流式响应不像普通HTTP请求有明确的开始和结束，追踪跨度大。告警全凭人工：模型故障、GPU过载、磁盘不足——都应该自动告警，而不是等人发现。一句话总结：没有可观测性的AI服务，就像没有