文章目录ClaudeCode×Elasticsearch服务日志查询的 AI 化落地实践一、思路来源与ClaudeCode本文应用1.1 整体思路来源1.2 ClaudeCode本文核心应用二、ClaudeCode在WSL Ubuntu系统的安装2.1 安装前准备2.2 具体安装步骤三、Elasticsearch的Skills编写3.1 Skills编写整体思路与架构设计3.2 Skills核心内容展示与护栏配置3.2.1 注入纯净的环境上下文3.2.2 强制的“字段映射与粒度约束”3.2.3 “红线”操作规范3.2.4 “红线”操作规范3.3 体验 AI 的“性能最优解”四、日志采集架构与AI联动4.1 整体采集架构思路4.2 Agent Skills编写与采集流程的结合五、结尾五、结尾ClaudeCode×Elasticsearch服务日志查询的 AI 化落地实践一、思路来源与ClaudeCode本文应用1.1 整体思路来源正如我公众号第一篇文章方案的灵感来源于运维场景的实际需求与 AI 技术的快速发展OpenCode、Claude Code、Cursor 本质都是代码开发工具最初并非为运维场景设计在实际开发与运维工作中我们常年面临分布式系统日志管理的核心痛点这也是本次方案思路的核心来源。真正耗时的从来不是“看见日志”而是在海量日志里把有用信息捞出来再把它们拼成结论。而这件事恰恰是开发和运维在日常排障里最痛、最烦、也最容易出错的一环。传统 Elasticsearch 查询依赖 DSLKibana 又离不开 KQL语法门槛高分析链路长遇到复杂问题时排查效率和沟通成本都会迅速上升。所以我在想既然 ClaudeCode 已经具备自然语言理解、命令生成和执行能力那能不能把它真正接进运维场景里让它帮我查 Elasticsearch、读日志、做初步分析答案是可以但前提不是“直接把 ES 地址丢给 AI”。因为一旦没有约束AI 很可能为了查一个 404直接生成全字段扫描、没有时间边界、没有字段约束的低效查询轻则返回一堆无效结果重则把 Elasticsearch 集群拖到高负载。也就是说AI 想在运维里真正可用靠的不是模型自己变聪明而是要有人提前给它立规矩、画边界、喂业务上下文。于是我做了这次实践把 ClaudeCode 和 Elasticsearch 连接起来再通过定制化 Skills把查询规则、字段映射、时间边界、索引范围和操作红线全部提前写清楚。这样一来原本需要手动编写 DSL 的日志查询就可以被转化成自然语言指令而 AI 返回的也不再是“想当然”的答案而是带着护栏的查询命令 基于结果的初步分析。1.2 ClaudeCode本文核心应用本次实践全程围绕nginx访问日志展开演示因此ClaudeCode的应用均贴合该场景重点体现在三个核心维度一是Skills调用与联动通过调用后续编写的Elasticsearch专属Skills建立与ES的稳定连接精准获取存储在ES中的nginx访问日志含请求地址、状态码、访问时间、客户端IP等核心字段二是日志分析演示接收Skills返回的nginx日志数据后可通过自然语言指令让ClaudeCode完成日志筛选、统计与分析比如筛选404/异常请求、统计热门访问接口无需手动编写DSL查询三是辅助实操落地在日志分析过程中若遇到Skills调用异常、日志查询报错等问题可借助ClaudeCode的调试能力定位问题同时可生成日志分析相关的辅助脚本为后续演示与实操提供支撑全程服务于“nginx访问日志演示与分析”这一核心目标也为后文Skills编写逻辑、Flunt-bit日志采集等实操内容做好铺垫。二、ClaudeCode在WSL Ubuntu系统的安装2.1 安装前准备添加网络代理”科学上网“宿主机开启系统代理在WSL启动的ubuntu系统里配置网络代理[rootlocalhost /data]$vim/etc/profileproxy(){exporthttp_proxyhttp://172.19.128.1:7890exporthttps_proxy$http_proxyexportsocks5_proxysocks5://172.19.128.1:7890echoHTTP Proxy on}# noproxynoproxy(){unsethttp_proxyunsethttps_proxyechoHTTP Proxy off}[rootlocalhost /data]$source/etc/profile开启网络代理并藏问谷歌进行测试rootlocalhost:/data# proxyHTTP Proxy on rootlocalhost:/data# curl -I https://www.google.comHTTP/1.1200Connection established验证是否生效在对应终端执行验证命令返回状态码200或出现HTTP/1.1 200/HTTP/2 200即表示代理生效。若验证失败请先分别检查当前终端中的代理变量是否已设置正确再重新测试。细节由于采用的是wsl启动的系统所以配置的网关要是WSL的vEnthernet2.2 具体安装步骤下载安装脚本并执行安装curl-fsSLhttps://claude.ai/install.sh|bash导入环境变量[rootlocalhost /data]$echoexport PATH$HOME/.local/bin:$PATH~/.bashrcsource~/.bashrc[rootlocalhost /data]$ claude--version2.1.63(Claude Code)安装完成后执行以下命令检查 Claude CLI 是否可用claude--version2.1.62(Claude Code)在环境变量当中添加以下变量# 设置 API 密钥exportANTHROPIC_AUTH_TOKENsk-你的kys# 设置 API 基础地址exportANTHROPIC_BASE_URLhttps://xxx.xxx.xx 你的api地址# 禁用非必要流量exportCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC1# 指定模型可选exportANTHROPIC_MODELclaude-opus-4-6也可以直接编写settings.json:{env:{ANTHROPIC_AUTH_TOKEN:api_keys,ANTHROPIC_BASE_URL:https://代理商,ANTHROPIC_DEFAULT_HAIKU_MODEL:claude-opus-4-6-20260205,ANTHROPIC_DEFAULT_OPUS_MODEL:claude-opus-4-6-20260205,ANTHROPIC_DEFAULT_SONNET_MODEL:claude-opus-4-6-20260205,ANTHROPIC_MODEL:claude-opus-4-6-20260205,BASH_DEFAULT_TIMEOUT_MS:300000,BASH_MAX_TIMEOUT_MS:600000,CLAUDE_AUTOCOMPACT_PCT_OVERRIDE:55,CLAUDE_CODE_ATTRIBUTION_HEADER:0,CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC:1,CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS:1,CLAUDE_CODE_MAX_OUTPUT_TOKENS:32000,DISABLE_AUTOUPDATER:1,DISABLE_ERROR_REPORTING:1,DISABLE_TELEMETRY:1,MAX_THINKING_TOKENS:16000,MCP_TIMEOUT:60000,MCP_TOOL_TIMEOUT:120000},hooks:{SessionEnd:[{matcher:,hooks:[{type:command,command:ccclub sync --silent,timeout:30,async:true}]}],Stop:[{matcher:,hooks:[{type:command,command:ccclub sync --silent,timeout:30,async:true}]}]}}网上有众多中转站大家可以任意选择相关中转站完成大模型的接入不过本文不为大家提供以免有打广告的嫌疑嘿嘿。启动claude code 选择主题后即可开始对话:配置完成切换模型至此安装部分完成。三、Elasticsearch的Skills编写让 ClaudeCode 直接操作 Elasticsearch 极易引发性能灾难比如可能会出现如全量扫描造成超长上下文。因此编写专属的 Elasticsearch Skills本质上是给 AI 制定一份 “说明书”。本篇文章的 Skills 内容较多核心思路已完整呈现文末附 SKILL.md 核心骨架与 references 目录示例可直接复用。~/.claude/skills/elasticsearch-skill/ ├── SKILL.md# 主说明书基础规则字段约束└── references/# 深度语法文档按高级域分类├── aggregations.md# 聚合分析语法├── cluster-api.md# 集群诊断API├── document-api.md# 文档CRUD语法├── index-api.md# 索引/映射管理语法├── kibana-api.md# Kibana操作语法├── otel-data.md# OTel链路追踪查询语法├── query-dsl.md# Query DSL语法└── search-api.md# 搜索API语法3.1 Skills编写整体思路与架构设计如果你只给 AI 一个 ES 地址它为了查一个 404 错误往往会使用性能极差的query_string进行全字段跨区扫描由于没有时间边界这一条语句就能拉满整个 ES 集群的 CPU导致业务瘫痪。设计原则为了省 Token 并防止乱来我们将 ES 的能力做成三层渐进式披露架构其核心运行流程如下┌─────────────────────────────────┐ │ 用户问题 │ └────────────┬────────────────────┘ │ ▼ ┌─────────────────────────────────┐ │ 加载 SKILL.md 到上下文 │ (Level 2: 高频基础知识) │ - 环境变量及 Auth 认证方式 │ │ - 核心字段管控表防坑护栏 │ │ - 日常 80% 基础查询示例 │ └────────────┬────────────────────┘ │ ▼ ┌────────────────────────┐ │ 识别问题属于哪个高级域 │ └────────────────────────┘ │ ├─ 搜索/Query DSL? ────→ 加载 references/query-dsl.md search-api.md │ ├─ 聚合分析? ──────────→ 加载 references/aggregations.md aggregations-api.md │ ├─ 索引/映射管理? ──────→ 加载 references/index-api.md mapping-api.md │ ├─ 文档CRUD? ──────────→ 加载 references/document-api.md │ ├─ 集群诊断? ──────────→ 加载 references/cluster-api.md │ ├─ Kibana 操作? ───────→ 加载 references/kibana-api.md │ └─ OTEL 查询? ─────────→ 加载 references/otel-data.md │ ▼ ┌──────────────────────────────────┐ │ 组合 SKILL.md (基础规则) │ │ 匹配到的 references/ (深度语法) │ │ → 构造出精准、安全的 curl 命令 │ └──────────────────────────────────┘流程解析基础打底Level 1/2ClaudeCode调用Skills时默认仅读取主说明书SKILL.md文中强制规定了nginx日志查询的“安全红线”——比如查询必须带时间参数、必须使用正确的字段名如http.response.status_code同时包含ES认证信息和基础查询示例。对于简单查询AI直接在此层面完成响应无需加载深层语法节省Token且提升效率。意图分发Level 3当用户提出复杂查询需求如“统计最近30分钟nginx不同状态码的访问量并用composite聚合分析请求趋势”AI会根据SKILL.md中的指引精准识别需求所属的高级域聚合分析Query DSL仅加载对应的aggregations.md和query-dsl.md避免加载无关的API文档。最终组合出结果AI将SKILL.md中的基础规则与加载的深层语法结合生成可直接在终端执行的curl命令既保证查询精准性贴合nginx日志字段又确保查询安全性同时最大化节省Token。3.2 Skills核心内容展示与护栏配置Skills的核心价值在于“划定安全边界、适配业务场景”结合本次nginx访问日志查询需求我们在Level 2的SKILL.md中植入了与nginx日志高度绑定的护栏配置从环境、字段、操作三个维度强制规范AI的查询行为确保每一次查询都安全、高效。3.2.1 注入纯净的环境上下文为避免ClaudeCode每次查询时重复询问ES账号、密码等信息同时规范认证方式我们在Skills中直接指定环境变量读取规则所有curl查询命令均严格遵循统一格式确保与ES集群连接的安全性和一致性适配nginx日志索引查询场景# 所有 curl 示例必须严格遵循此格式curl-s${ES_URL%/}/nginx-*/_search\-HAuthorization: ApiKey$(printenvES_API_KEY)\-HContent-Type: application/json\...nginx-*索引匹配规则对应后续Fluent-bit采集nginx日志时的索引命名规范确保AI仅操作nginx相关日志索引避免误操作其他业务索引。3.2.2 强制的“字段映射与粒度约束”AI缺乏nginx日志的业务常识无法识别合理的查询字段与查询方式因此我们将Fluent-bit采集落盘后ES中nginx访问日志的真实字段表强制植入Skills明确规定每个字段的查询方式和用途从根源上避免低效查询如用query_string全字段扫描。以下是nginx访问日志专属字段约束表ES 字段名类型查询方式说明timestampdaterange日志时间始终用于时间过滤client.ipkeywordterm客户端 IP精确匹配http.request.methodkeywordtermHTTP 方法GET/POST/PUT等http.request.referrerkeywordtermReferer 头http.response.body.byteslongrange响应体大小字节http.response.status_codekeywordterm/termsHTTP 状态码如200/404/500http.versionkeywordtermHTTP 协议版本1.1/2.0url.originalkeywordterm/wildcard完整请求路径含查询参数user_agent.originalkeywordterm/wildcardUser-Agent 原始字符串messagetextmatch原始日志行全文service.namekeywordterm服务名host.namekeywordterm部署节点主机名log.file.pathkeywordterm/wildcard日志文件路径event.datasetkeywordterm数据集名称如nginx.access当然这是针对于nginx的日志来说要是针对于生产场景下的微服务来说就可以参考下面的内容补充说明上述字段均由Fluent-bit采集nginx日志时按规范解析后写入ES具体采集与解析逻辑在第四部分详细讲解。若为生产环境微服务日志可参考此格式自定义字段映射表核心是“明确字段用途、规范查询方式”。至于这里面的“字段由xxxxxx解析后写入es”这是本文的核心思想会在后面进行详细讲述。3.2.3 “红线”操作规范由于Skills中植入了字段约束、时间边界要求和操作规范AI会瞬间绕过query_string全字段扫描的误区输出带有完美护栏的最优查询命令无需手动干预可直接在终端执行具体如下# ClaudeCode输出的查询命令自动遵循Skills约束curl-s${ES_URL%/}/nginx-*/_search\-HAuthorization: ApiKey$(printenvES_API_KEY)\-HContent-Type: application/json\-d{ query: { bool: { filter: [ { range: { timestamp: { gte: now-10m, lte: now } } }, # 强制时间边界 { term: { http.response.status_code: 500 } }, # 精准匹配状态码符合字段约束 { term: { event.dataset: nginx.access } } # 仅查询nginx访问日志 ] } }, size: 100 # 限制返回条数避免数据过多 }|jq.hits.hits[]._source | {time: .[timestamp], client_ip: .[client.ip], url: .[url.original], status: .[http.response.status_code]}# 输出瘦身对应的ES查询DSL核心过滤条件AI自动生成符合性能最优原则{filter:[{range:{timestamp:{gte:now-10m,lte:now}}},# 时间边界不可少{term:{http.response.status_code:500}}# 精准匹配替代低效的query_string]}3.2.4 “红线”操作规范核心skills片段展示--- name: elasticsearch description:通过 REST APIcurl操作 Elasticsearch 和 Kibana。适用于查询、索引、管理索引、 检查集群健康状态、编写聚合、部署 Dashboard以及排查 Elasticsearch 问题。 支持从环境变量加载连接配置URL、API Key 或用户名/密码。 涵盖搜索Query DSL / ES|QL、CRUD、索引管理、Mapping、聚合、集群健康、 ILM、Kibana APIDashboard、数据视图、Saved Objects、OpenTelemetry 数据模式。 ---# Elasticsearch所有 Elasticsearch 操作均通过 REST API 使用curl完成无需 SDK 或客户端库。## 环境变量配置使用前请先设置连接配置支持两种认证方式 bash# ── 必填 ──────────────────────────────────────────────ES_URLhttps://your-cluster.es.cloud.elastic.co:443# ── 认证方式一API Key推荐适用于 Elastic Cloud──ES_API_KEYyour-base64-api-key# ── 认证方式二用户名/密码适用于自建集群──────────ES_USERelasticES_PASSyour-password# ── Kibana仅使用 Kibana API 时需要─────────────────KIBANA_URLhttps://your-deployment.kb.us-east-1.aws.elastic.cloud优先使用ES_API_KEY若未设置自动回退到ES_USERES_PASS。### 认证请求模板bash# API Key 认证curl-s${ES_URL%/}/endpoint\-HAuthorization: ApiKey$(printenvES_API_KEY)\-HContent-Type: application/json\-djson-body# 用户名/密码认证curl-s${ES_URL%/}/endpoint\-u$(printenvES_USER):$(printenvES_PASS)\-HContent-Type: application/json\-djson-body**重要说明** - 始终用$(printenvES_API_KEY)而非$ES_API_KEY防止变量在curl中展开失败导致401错误 - 始终用${ES_URL%/}去除末尾斜杠防止路径出现双斜杠如//_cluster/health## 快速健康检查bash# 集群健康状态green/yellow/red——Serverless 不可用curl-s${ES_URL%/}/_cluster/health\-HAuthorization: ApiKey$(printenvES_API_KEY)|jq.# 索引概览Serverless 和传统部署均可用curl-s${ES_URL%/}/_cat/indices?vsstore.size:deschindex,health,status,docs.count,store.size\-HAuthorization: ApiKey$(printenvES_API_KEY)**Serverless 注意** 若收到api_not_available_exception错误说明是 Serverless 模式。以下 API 在 Serverless 中**不可用** -_cluster/health、_cluster/settings、_cluster/allocation/explain-_cat/nodes、_cat/shards-_nodes/hot_threads、_nodes/stats- ILM 相关 API_ilm/*...省略1w字... ---## 搜索Query DSLbash# 简单 match 查询curl-s${ES_URL%/}/my-index/_search\-HAuthorization: ApiKey$(printenvES_API_KEY)\-HContent-Type: application/json\-d{ query: { match: { message: error timeout } }, size: 10, sort: [ { timestamp: { order: desc } } ] }|jq.# Bool 组合查询must filter must_notcurl-s${ES_URL%/}/my-index/_search\-HAuthorization: ApiKey$(printenvES_API_KEY)\-HContent-Type: application/json\-d{ query: { bool: { must: [ { match: { message: error } } ], filter: [ { range: { timestamp: { gte: now-1h } } } ], must_not:[ { term: { level: debug } } ] } }, size: 20 }|jq. 完整 Query DSL 参考term、range、wildcard、nested、multi_match 等→[references/query-dsl.md](references/query-dsl.md)完整 Search API 参考ES|QL、EQL、分页、高亮等→[references/search-api.md](references/search-api.md)3.3 体验 AI 的“性能最优解”我们进行测试前提我们已经写在skills里了就是es的配置信息需要写在环境变量里我们写在了settings.json的env字段里{env:{...ES_URL:http://127.0.0.1:9200,ES_USER:elastic,ES_PASS:password},接下来我们让它分析一下今天访问前三的请求路径是什么首先它生成了一条查询命令但是显然它生成的命令是存在一部分小问题并未拿到正确结果接下来重新生成了一条curl-s${ES_URL%/}/nginx-access-*/_search?size0\-u$(printenvES_USER):$(printenvES_PASS)\-HContent-Type: application/json\-d{ query: { range: { timestamp: { gte: now/d, lte: now } } }, aggs: { top_urls: { terms: { field: url.original.keyword, size: 3, order: { _count: desc } } } } }|jq-r.aggregations.top_urls.buckets | to_entries | .[] | 第\(.key 1)名: \(.value.key) - 访问次数: \(.value.doc_count)很显然这次拿到了分析结果并且还帮助我们分析了结果由于不想拿简单的服务进行测试直接用nginx的80端口反向代理了Kibana的端口所以都是访问Kibana的参数再测试一个相对较难的内容我用Kibana创建一个数据视图去匹配一个不存在的索引导致日志会出现404问题我们让AI分析为何会404这个问题。curl-s${ES_URL%/}/nginx-error-*/_search\-u$(printenvES_USER):$(printenvES_PASS)\-HContent-Type: application/json\-d{ query: { bool: { filter: [ { range: { timestamp: { gte: now-5m } } }, { term: { http.response.status_code: 404 } } ] } }, size: 10, sort: [ { timestamp: { order: desc } } ] }|jq-r.hits.hits[]._source | \(.[timestamp]) | IP: \(.[client.ip]) | \(.[http.request.method]) \(.[url.original]) | 状态: \(.[http.response.status_code]) | UA: \(.[user_agent.original] // none)很显然AI分析失败了这也就是说AI有时候是真的不懂业务其实也不能这么说主要是你提供的skills里得真的有和你业务相关状态的内容提示当你Skills里定义的不详细或业务过于复杂但并未让AI明确的时候就会出现类似的问题。不过我想了一下其实也可以定义一个skills进行联网查询让它从广泛数据中进行查询然后获得更加精准的结果当然这也意味着token会在天上飞。不管怎样我们的核心功能还是实现了的。四、日志采集架构与AI联动4.1 整体采集架构思路讲完了AI部分我们来谈一谈数据采集我的数据采集流程是“EFK”EElasticsearchFFluent-bitKKibanaFluent Bit 作为日志采集核心F 环节核心作用是实时采集 Nginx 访问/错误日志经过简单过滤、解析和字段增强后将标准化日志输出至 ElasticsearchE 环节为后续 KibanaK 环节可视化分析提供数据支撑。那么核心就是Fluent它如何能够把日志精准的采集到的呢Fluent Bit通过加载/etc/fluent-bit/目录下的全套模板文件主配置fluent-bit.conf、环境变量fluent-bit.env、解析模板parsers.conf和multiline_parsers.conf、字段增强脚本enrich.lua以tail插件监听Nginx访问及错误日志经过滤标准化、格式解析、字段增强后按指定格式将结构化日志稳定输出至Elasticsearch全程自动化完成**“采集→处理→输出”**无需额外开发仅需微调少量关键参数即可复用。当然市面上日志采集工具有很多比如Filebeta、Logstash但是我还是选择了Fluent Bit一个字轻。它资源占用低、配置简洁无需复杂部署仅凭一套可复用的模板就能完成日志采集全流程远比同类工具更轻便、更高效当然配置上可能稍显复杂但是还在可接受范围之内对比一下就晓得了采集工具资源占用配置复杂度性能易用性适用场景Fluent Bit极低MB 级内存中等高百万日志 / 秒中等容器 / 轻量服务器 / 边缘节点Logstash高GB 级内存低中高复杂日志处理 / 中台级采集Filebeat低低中高简单日志采集无复杂处理4.2 Agent Skills编写与采集流程的结合为什么要说这里是因为我感受到了一些不一样的东西就是前瞻思想。如果我不这样按照严格的模板化采集日志那么前文编写的 Elasticsearch Skills 就会彻底失去价值 AI 基于 Skills 里的字段约束生成的查询命令会因为ES中日志字段命名不统一、格式不规范、关键信息缺失最终要么查不到数据要么返回无效结果所谓 “AI 赋能日志分析” 也就成了空谈。层级采集侧Fluent Bit动作Skills 侧对应设计最终效果字段命名层通过parsers.conf解析日志时将 nginx 原生字段如remote_addr映射为 ES 标准字段如client.ip并严格遵循 ECSElastic Common Schema规范Skills 的 “字段映射与粒度约束表” 直接复用 ECS 标准字段名明确client.ip为keyword类型、仅支持term查询AI 生成的查询命令中字段名与 ES 中存储的字段完全一致避免 “查错字段”格式规范层强制解析timestamp字段为 ISO8601 格式状态码status转为字符串类型url.original保留完整请求路径Skills 中规定timestamp必须用range做时间过滤http.response.status_code对应采集侧status仅支持term/terms查询AI 生成的查询命令能精准命中数据类型避免 “字符串字段用数值查询”“时间字段格式不兼容” 等语法错误索引隔离层Fluent Bit 输出日志时按 “nginx-access-YYYY.MM.DD”“nginx-error-YYYY.MM.DD” 命名索引Skills 中限定查询索引为nginx-*并区分event.dataset: nginx.access/nginx.errorAI 仅操作指定索引避免误查其他业务日志同时可精准区分访问 / 错误日志场景五、结尾受AI的影响现在做方案都会考虑一些后手也就是所谓的AI赋能究竟应该如何把AI融入到运维去实现高效运维提高生产效率已经成为今年共同探索的核心方向了当然现在很多大厂都有相关产品比如某公司的SREAgent刚出来的时候真的很吓人但是吓人归吓人日子还得一天天的过一个人探索未来跟着大厂的思想走何尝不是一种快乐呢这个文章其实也只是探索过程中的一部分结合第一篇文章其实已经落地了现代微服务三大监控中的两个了还缺少一个分布式链路追踪。但是真的缺少么有细心的人其实能在我放的截图里看到了一个OTel的skills了一套基于Elasticsearch、Jaeger、OpenTelemetry实现分布式链路追踪的方案其实早已写完并且完成测试了只不过skills还没有定义的非常详细链路追踪真的是重头戏那个skills必须要完全懂得业务逻辑才能去让AI变得刚高效所以每天提升自己刻不容缓哈哈哈那就写到这里了拜拜我们评论区见。s 中限定查询索引为nginx-*并区分event.dataset: nginx.access/nginx.error| AI 仅操作指定索引避免误查其他业务日志同时可精准区分访问 / 错误日志场景 |五、结尾受AI的影响现在做方案都会考虑一些后手也就是所谓的AI赋能究竟应该如何把AI融入到运维去实现高效运维提高生产效率已经成为今年共同探索的核心方向了当然现在很多大厂都有相关产品比如某公司的SREAgent刚出来的时候真的很吓人但是吓人归吓人日子还得一天天的过一个人探索未来跟着大厂的思想走何尝不是一种快乐呢这个文章其实也只是探索过程中的一部分结合第一篇文章其实已经落地了现代微服务三大监控中的两个了还缺少一个分布式链路追踪。但是真的缺少么有细心的人其实能在我放的截图里看到了一个OTel的skills了一套基于Elasticsearch、Jaeger、OpenTelemetry实现分布式链路追踪的方案其实早已写完并且完成测试了只不过skills还没有定义的非常详细链路追踪真的是重头戏那个skills必须要完全懂得业务逻辑才能去让AI变得刚高效所以每天提升自己刻不容缓哈哈哈那就写到这里了拜拜我们评论区见。