Expedia Group 推出了 Service Telemetry Analyzer（STAR），这是一个内部 AI 辅助可观测性平台，帮助工程师通过分析服务遥测数据并生成结构化根因评估，来调查生产环境中的故障事件。该系统通过预定义的诊断工作流，将运营指标与大语言模型（LLM）结合起来，从而减少工程师识别服务性能下降根源所需的时间，同时确保人类仍然负责验证和决策。
该平台并没有采用自主 AI Agent，而是遵循一种确定性的工作流：先收集遥测数据，再使用领域专属提示词进行分析，将分析结果汇总为中间发现，最终生成包含潜在根因和建议后续步骤的报告。
在描述项目目标时，团队写道：
我们的目标是通过这项服务，将了解问题所需时间（TTK）和恢复时间（TTR）降至最低。
STAR 架构
该平台以 FastAPI 应用的形式实现，集成了 Datadog 用于获取服务指标，同时接入内部生成式 AI 网关，用于管理身份认证以及对 LLM 服务商的访问。该工作流采用提示词链（prompt chaining），允许在生成汇总诊断结果之前执行多个专门化分析。Expedia 表示，当前实现并未使用函数调用（function calling）、检索增强生成（RAG）、记忆能力（memory）或自主工具调用等能力，而是依靠预定义工作流来生成一致的分析结果。
STAR 主要关注从基于 Kubernetes 的服务和 JVM 应用中收集的标准化基础设施遥测数据。该系统分析的指标包括请求吞吐量、延迟、HTTP、gRPC 和 GraphQL 错误率、CPU 和内存使用情况、容器重启事件、Kubernetes 就绪探针和存活探针失败情况、Java 堆内存使用率，以及垃圾回收活动。Expedia 解释称，基础设施指标能够为使用不同编程语言和框架开发的服务提供统一视角。
随着平台不断演进，Expedia 用基于 Celery 的异步架构替换了 FastAPI 后台任务，并使用 Redis 同时作为消息代理和结果存储后端。工程团队表示，大部分处理过程都属于 I/O 密集型操作，涉及遥测数据获取和 LLM 请求。异步执行模型让 STAR 能够并发处理多个分析任务，同时适应 Datadog 以及公司内部 AI 网关施加的速率限制。
该公司表示，STAR 已被用于支持生产事故调查、事故复盘分析、Kubernetes 故障排查以及 JVM 内存诊断。工程师会在采取行动前审查系统生成的分析结果，使该平台成为辅助工具，而不是一个自主运行的运维系统。
博客还介绍了该平台未来的扩展工作。计划中的增强功能包括引入服务依赖信息、更多运营元数据、基于 Model Context Protocol（MCP）的工具集成，以及对话式交互界面。Expedia 还在评估将 STAR 应用于混沌工程实践，帮助分析受控故障实验的结果。目前，提示词管理、追踪和评估能力通过 Langfuse 提供支持，而系统性能则通过领域专家评审和用户反馈进行评估。
原文链接：
https://www.infoq.com/news/2026/07/expedia-ai-observability-star/
