本次查询：可观测性
中文解释：可观测性
常见场景：在微服务架构 / AI模型部署 / 云原生应用中 / 可观测性帮助开发者快速定位故障 / 排查性能瓶颈
一句话解释
可观测性是指通过外部输出（如日志、指标、链路数据）推断系统内部运行状态的能力。简单说，就是让黑盒系统变得透明，不必“拆机”就能知道哪里出了问题。
为什么会被关注
随着微服务、容器化和AI大规模部署，系统复杂度指数级增长。传统监控只能回答“系统挂了没”，而可观测性能够回答“为什么挂、哪个环节最慢、数据流在哪断裂”。
尤其在AI模型推理场景中，可观测性帮助追踪数据漂移、模型响应延迟，避免“模型准确率很高但业务落地崩溃”的尴尬。各大云服务商和开源社区都在推动OpenTelemetry等标准，降低接入门槛。
核心逻辑
可观测性依赖“三大支柱”：指标（Metrics）、日志（Logs）和链路追踪（Traces）。指标提供聚合视图（如CPU使用率），日志记录详细事件，链路追踪则串联请求在多个服务间的完整路径。
三者不是孤立使用，而是通过统一关联（如请求ID、时间戳）形成上下文。当出现异常时，可以从高维指标下钻到具体链路，再定位到某条日志，实现快速根因分析。
常见场景
微服务故障定位：用户反馈下单失败，通过链路追踪发现订单服务调用了已超时的支付网关，日志提示连接池耗尽，指标显示该网关Pod的内存暴涨。
AI模型性能监控：实时记录模型推理耗时、输入分布变化。当准确率下降时，可观测性工具比对不同版本模型的响应日志，定位到新版本的数据预处理逻辑有Bug。
容易混淆的点
可观测性≠监控。监控是已知故障的阈值告警，可观测性则是探索未知问题——即使没设告警，也能通过数据发现异常模式。监控是可观测性的子集。
可观测性≠全量日志。盲目采集所有日志只会造成数据噪声，真正有效的是基于“三大支柱”的关联分析，用有限的采样和结构化数据还原完整真相。