项目关键词Elasticsearch 9.3、ES|QL、Kibana Maps、Kibana Alerting、AI Agent Builder、通义千问、Runbook 语义检索、MCP、A2A、多 Agent 运维分析。本文介绍一个 “景枢” 的技术设计与实现。它面向多家大型文旅景区购票平台基于脱敏后的真实 nginx 与 service 日志构建一个 AI 运营值班长当支付接口变慢、错误码突增或疑似黄牛出现时系统可以自动完成告警、数据下钻、根因判断、Runbook 检索和分级处置建议。和普通监控大屏不同景枢的目标不是“展示更多指标”而是把 Elastic 的搜索、聚合、语义检索和 Agent 工具调用能力组合起来让系统能够回答技术团队真正关心的问题哪个接口真的慢哪些只是长连接造成的假慢这次高峰是自然客流、攻击流量还是内部任务service 侧错误码和 nginx 侧慢请求能否关联起来历史处置手册能否被 Agent 自动检索并用于生成建议这些分析能力能否通过 MCP/A2A 暴露给外部 AI 客户端1. 场景与数据基础项目使用的是多景区购票平台的脱敏生产日志演示窗口包含约 176 万条 nginx 与 service 样本。为避免暴露客户与业务方信息本文对景区名称、URL slug、订单号、IP、证件号、token 等信息均做匿名化处理。日志覆盖的业务对象抽象如下匿名景区编号说明park_a头部景区 Apark_b头部景区 Bpark_c头部景区 Cpark_d头部景区 D数据源主要分为两类nginx ingress 日志包含 client_ip、url、status、request_time、upstream_response_time、user_agent、proxy_upstream_name 等字段。service 结构化日志包含 level、error_code、error_message、biz_action、exception_class、stack、order_no 等字段。这个场景的技术难点在于日志本身不是为比赛准备的“干净数据”。它包含真实世界里的大量噪声预检请求、nacos 长轮询、WebSocket 长连接、微信订阅消息失败、内部 xxl-job 调度回调、鉴权失败、重复购票错误等。项目的关键不是把日志灌进 Elasticsearch而是把这些日志清洗成 Agent 可以可靠调用的分析工具。2. 总体架构景枢采用 “日志治理 ES|QL 工具 Agent 编排 Kibana 可视化 MCP/A2A 互操作” 的架构。生产日志 ├─ nginx ingress access log └─ service JSON log | v Elasticsearch Ingest Pipeline ├─ 字段解析park / api_path / error_code / biz_action ├─ 合规脱敏身份证 / token / openid / orderNo / client_ip ├─ GeoIP 丰富client_geo.location / region / city ├─ 噪声标记nacos / websocket / xxl-job / OPTIONS └─ 关联字段order_no_hash / proxy_upstream_name | v Elasticsearch 索引 ├─ nginx_logs ├─ service_logs └─ runbook_kb | v 分析与智能化 ├─ ES|QL Tools ├─ Kibana Dashboard / Maps / Alerting ├─ AI Agent Builder └─ Qwen Connector Embedding | v 对外互操作 ├─ MCP暴露工具给 Claude / Cursor 等客户端 └─ A2A暴露 Agent 给外部 Agent 框架这套架构里Elasticsearch 不是单纯的日志存储而是三类能力的统一底座结构化分析ES|QL 聚合、过滤、分桶、TopN。语义检索Runbook 知识库向量化后供 Agent 检索。Agent 工具运行时Agent Builder 将 ES|QL 查询封装为可调用工具。3. 数据治理从原始日志到可分析索引3.1 景区解析景区 slug 并不总是出现在固定 path 层级。为避免暴露真实路径下面使用匿名路径示例/gateway/park_a/.../gateway/ws/park_a/webSocket?orderId...其中 ws 代表 WebSocket 模块不是景区。因此不能简单取 URL 的固定段作为景区。项目在 pipeline 中使用匿名景区白名单 {park_a, park_b, park_c, park_d} 在整条 path 中匹配避免把模块名误判为景区。3.2 脱敏策略日志中包含真实敏感信息因此入库前必须完成脱敏同时保留分析能力。字段风险处理方式身份证号真实个人身份信息mask 或 hash微信 access_token真实密钥整段抹除openid用户标识hash 或删除orderNo订单号一致性 hash保留 join 能力client_ip公网 IPGeoIP 后降精度不保留原始 IP这里一个重要设计是 orderNo 不直接删除而是做一致性 hash。这样 nginx 侧 URL 中的 orderId/orderNo 与 service 侧日志中的订单号可以在脱敏后继续关联用于购票链路下钻。3.3 噪声标记项目没有简单删除噪声数据而是增加 is_noise、noise_reason 等字段。这样做有两个好处Dashboard 可以同时展示“信号 vs 噪声”的对比。Agent 可以解释为什么某些监控指标不应触发升级。典型噪声包括OPTIONS 预检请求。/nacos/v1/cs 长轮询。/webSocket 出票状态推送长连接。xxl-job 调度器回调与 registry。非核心微信订阅消息推送失败。这一步是项目里非常关键的工程判断。没有噪声建模后面的 Agent 很容易把“长连接假慢”“内部调度高频访问”解释成故障或攻击。4. 索引设计项目核心索引有三个。4.1 nginx_logs用于请求链路、接口耗时、来源地理分布与流量趋势分析。核心字段包括timestamp park api_path method status request_time upstream_response_time proxy_upstream_name ua_device is_slow is_noise noise_reason order_no_hash client_geo.country_name client_geo.region_name client_geo.city_name client_geo.location4.2 service_logs用于业务错误、异常堆栈和业务动作分析。核心字段包括timestamp park level error_code error_message biz_action exception_class stack order_no_hash is_noise4.3 runbook_kb用于处置手册语义检索。核心字段包括symptom root_cause action priority error_code semantic_textsemantic_text 会组合故障现象、根因、错误码和处置动作再通过通义千问 embedding 写入向量字段。这样用户输入“付款一直转圈”这类自然语言也能命中“支付接口高峰变慢”相关 Runbook。5. ES|QL Tool 设计Agent Builder 的关键不是让大模型自由生成查询而是把高价值分析路径封装成稳定工具。项目中把常用 ES|QL 查询注册为 Agent 可调用的 Tool。5.1 慢接口分析 slow_api_topn用于排除长连接噪声后定位真实慢接口。FROM nginx_logs | WHERE is_noise false AND request_time ?min_seconds | STATS slow_count COUNT(*), p50 PERCENTILE(request_time, 50), p90 PERCENTILE(request_time, 90), p99 PERCENTILE(request_time, 99) BY api_path | SORT slow_count DESC | LIMIT 10在演示数据中该工具定位到 /shop/order/payOrder 是真实业务慢接口P99 约 6.8 秒。5.2 景区流量趋势 park_traffic用于判断流量峰值是否集中在某一景区或某一时间段。FROM nginx_logs | WHERE is_noise false | STATS requests COUNT(*) BY park, ts BUCKET(timestamp, 5 minute) | SORT ts5.3 客流来源 visitor_geo用于支撑 Kibana Maps 和 Agent 判断“自然高峰 vs 单点攻击”。FROM nginx_logs | WHERE is_noise false AND client_geo.region_name IS NOT NULL | STATS visits COUNT(*) BY province client_geo.region_name | SORT visits DESC | LIMIT 205.4 业务错误分析 error_breakdown用于从 service 日志中识别真正影响业务的错误。FROM service_logs | WHERE level ERROR AND is_noise false | STATS errors COUNT(*) BY error_code, biz_action | SORT errors DESC5.5 黄牛识别 scalper_detect用于分析 errorCode4027 等重复购票错误。FROM service_logs | WHERE error_code 4027 | STATS attempts COUNT(*) BY order_no_hash | WHERE attempts 2 | SORT attempts DESC实际系统中也可以把证件 hash、设备指纹、手机号 hash、IP geo 和时间窗一起纳入聚合。比赛版本保留了脱敏后的最小可演示链路。6. Kibana 可视化与告警项目构建了一个 Kibana Dashboard作为运营中枢的第一视图。它包括总请求量、慢请求量、Geo 坐标点数量。多景区流量排名。5 分钟粒度流量趋势。慢接口 Top10。来源省份 Top10。业务错误码分布。信号与噪声对比。客流来源地图。其中 Kibana Maps 使用 client_geo.location 字段展示访问来源。演示窗口中有 62,115 个可用坐标点可以直观看出本地客流与跨区域客流同时存在的分散访问特征。告警使用 ES|QL 规则监控 payOrder 的 P99 延迟FROM nginx_logs | WHERE api_path /shop/order/payOrder | STATS p99 PERCENTILE(request_time, 99) | WHERE p99 3这条规则的作用不只是触发告警而是作为 Agent 分析链路的入口告警提供时间窗口与异常对象Agent 再基于工具完成后续诊断。除了实时 Dashboard项目还在 ops-platform 中实现了独立的值班交接报告页对应访问路径为 /report。这不是一份静态模板而是由后端通过 ES|QL 按班次时间窗聚合 nginx_logs、service_logs 和告警数据后动态生成报告会汇总总请求、真实业务请求、慢请求比例、核心接口 P99、真实业务错误、客流坐标点、噪声过滤比例、风控信号和 401 鉴权热点并基于规则化逻辑自动给出“告警 / 关注 / 正常”的健康分级、根因研判、分级处置建议和遗留交接事项。页面采用 A4 文档式布局支持值班主管补充、处置状态编辑、签核确认并可直接通过浏览器打印或导出 PDF从而把 Kibana 监控、Agent 诊断和人工值班流程沉淀为可归档、可复盘的运维闭环。7. Agent Builder 实现项目设计了四类 Agent。7.1 技术诊断 Agent挂载工具slow_api_topnerror_breakdownsearch_runbook职责是从接口耗时、业务错误与历史处置方案三条线定位根因。它的输出不是日志列表而是结构化诊断慢接口/shop/order/payOrder 现象P99 超过 6s 关联错误创建订单 / 未支付订单 / 系统维护类错误 Runbook 命中支付接口高峰变慢 建议扩容支付服务、提高连接池、调整限流、必要时降级非核心能力7.2 业务洞察 Agent挂载工具park_trafficvisitor_geo职责是判断异常是否由自然客流导致。它会看峰值倍率、景区分布、来源地域分布等指标。演示中 06-04 上午 10 点达到约 136,378 请求/小时是低谷时段的约 7 倍并且来源省份分散因此判断为真实高峰。7.3 风控哨兵 Agent挂载工具scalper_detectauth_anomaly职责是识别重复购票、鉴权异常、高频访问等风险。它不会把所有高频访问都判定为黑产而会结合 UA、路径、错误码和业务语义排除内部调度器等噪声。7.4 运营总管 Agent总管 Agent 挂载全部核心工具负责将三类分析结果汇总成值班报告。在 Elastic 9.3 环境中Workflow 能力仍属于预览性质因此项目采用更稳定的 GA 实现让总管 Agent 挂载所有工具由大模型根据系统指令完成自路由和综合推理。概念上仍然是多专家分工但现场演示时以“总管 工具编排”的稳定链路为主。总管输出包含性质判定真实高峰、技术瓶颈、非攻击。根因定位payOrder 支付链路在高峰期 P99 升高。风险信号少量 4027 重复购票。分级处置P0 扩容支付服务P1 调整限流策略P2 高频证件加验证码。8. Runbook 语义检索传统 Runbook 往往以文档形式存在人需要自己搜索。景枢把 Runbook 做成可检索知识库并注册为 Agent Tool。实现流程编写处置知识symptom、root_cause、action、priority、error_code。拼接 semantic_text。调用通义千问 text-embedding-v3 生成向量。写入 runbook_kb。Agent 根据用户问题或诊断结果调用 search_runbook。这样一来技术诊断 Agent 在定位到 payOrder 慢之后可以进一步检索“支付接口高峰变慢”的历史处置方案。它不是只告诉你“哪里慢”而是能把“上次怎么处理”带回来。9. MCP 与 A2A从系统内部能力到外部生态这个项目还验证了 Agent Builder 的互操作能力。9.1 MCP 暴露工具Agent Builder 内置 MCP 端点/api/agent_builder/mcp项目通过该端点把 6 个景区分析工具开放给外部 MCP 客户端。外部客户端可以完成initializetools/listtools/call例如 Claude Desktop 或 Cursor 可以发现 slow_api_topn 并直接调用它拿到 Elasticsearch 中真实数据的分析结果。这里 MCP 暴露的是工具能力。9.2 A2A 暴露 AgentA2A 暴露的是完整 Agent而不是单个工具。项目验证了GET /api/agent_builder/a2a/{agent_id}.json POST /api/agent_builder/a2a/{agent_id}外部 A2A 客户端可以先发现 Agent Card再向技术诊断 Agent 或运营总管 Agent 发送任务。项目中使用官方 A2A SDK 客户端完成了发现与调用验证返回的是千问驱动的真实诊断结果。这部分的意义在于景枢不是一个封闭的 Kibana Demo而是可以把日志分析工具和智能诊断 Agent 作为能力节点接入外部 AI 工作流。10. 一个完整诊断链路以 “06-04 上午 10 点支付为什么慢” 为例系统链路如下Kibana Alerting 触发 payOrder P99 告警。用户向运营总管 Agent 提问。总管调用 park_traffic 与 visitor_geo判断这是自然客流高峰。调用 slow_api_topn排除长连接噪声定位 payOrder 真实慢。调用 error_breakdown查看 service 侧错误码与业务动作。调用 search_runbook命中支付高峰处置方案。调用 scalper_detect识别少量重复购票信号。汇总输出结构化值班报告。最终输出不是“日志摘要”而是可执行判断性质真实高峰导致支付链路瓶颈非攻击。 根因payOrder 在高峰期 P99 约 6.8s。 影响购票支付体验下降伴随少量重复购票风险。 处置 P0扩容支付服务实例检查连接池和下游支付依赖。 P1调整高峰限流阈值与排队策略。 P2对高频证件或账号增加验证码与风控拦截。11. 技术收益与工程经验这个项目带来的最大经验是AI Agent 做运维分析时关键不在于让模型“看更多日志”而在于给它高质量、可控、可解释的工具。几个工程结论比较明确日志治理要前置。没有脱敏、字段标准化和噪声标记Agent 很容易基于错误信号做错误判断。ES|QL Tool 要小而稳定。让模型调用明确工具比让模型临时生成复杂查询更可靠。业务语义要进入索引。is_noise、biz_action、error_code、park、order_no_hash 这些字段决定了 Agent 能不能说出有价值的结论。可视化仍然重要。Kibana Maps 和 Dashboard 可以让人快速建立信任Agent 则负责继续下钻和解释。Runbook 是 Agent 落地的关键。没有处置知识库Agent 最多定位问题有了 RunbookAgent 才能给出可执行建议。MCP/A2A 让能力可复用。工具和 Agent 可以被外部客户端调用这比单一演示页面更接近实际工程集成方式。总结景枢的技术价值在于把 Elastic Stack 的几类能力连接成一条完整链路日志采集治理 - Elasticsearch 索引 - ES|QL 分析工具 - Kibana 告警与地图 - Agent Builder 工具调用 - Runbook 语义检索 - MCP/A2A 对外互操作它验证了一个面向真实业务系统的 AI 运维范式让大模型不直接 “猜日志”而是通过受控工具查询真实数据通过业务字段理解上下文通过 Runbook 生成可执行建议。对于技术团队来说这类系统的重点不是把监控大屏做得更漂亮而是把可观测数据、业务语义和处置经验组织成 Agent 可以调用的工程化能力。景枢正是沿着这条路径把一个景区购票平台从 “被动告警” 推进到了 “智能值班”。参考刘晓国老师编写的以下文档Elastic开发者上手指南如何为阿里云 Elasticsearch 创建推理端点连接器Workflow 并写入数据转自景枢基于 Elastic AI Agent Builder 的多景区购票智能运维中枢技术解析-CSDN博客