<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>可观测性 on 魔都水滴</title>
		<link>https://blog.margrop.net/tag/%E5%8F%AF%E8%A7%82%E6%B5%8B%E6%80%A7/</link>
		<description>Recent content in 可观测性 on 魔都水滴</description>
		<generator>Hugo</generator>
		<language>zh-CN</language>
		
		
		
		
			<lastBuildDate>Sat, 11 Jul 2026 08:30:00 +0800</lastBuildDate>
		
			<atom:link href="https://blog.margrop.net/tag/%E5%8F%AF%E8%A7%82%E6%B5%8B%E6%80%A7/index.xml" rel="self" type="application/rss+xml" />
			<item>
				<title>别再让 AI 猜故障了：MySQL &#43; Prometheus &#43; Loki &#43; Grafana 四件套接入 Agent 全自动实战</title>
				<link>https://blog.margrop.net/post/mysql-prometheus-loki-grafana-ai-agent-hands-on/</link>
				<pubDate>Sat, 11 Jul 2026 08:30:00 +0800</pubDate>
				<guid>https://blog.margrop.net/post/mysql-prometheus-loki-grafana-ai-agent-hands-on/</guid>
				<description>&lt;p&gt;&lt;img src=&#34;https://blog.margrop.net/post-images/mysql-prometheus-loki-grafana-ai-agent/00-cover-ai-generated.png&#34; alt=&#34;MySQL、Prometheus、Loki、Grafana 汇入 AI Agent 的原创题图&#34;&gt;&lt;/p&gt;&#xA;&lt;p&gt;很多团队已经把 MySQL、Prometheus、Loki 和 Grafana 装起来了，但线上报警之后，值班人员仍然要在四个窗口之间来回切换：先看仪表盘，再写 PromQL，然后去日志里搜索 trace_id，最后登录数据库核对业务记录。&lt;/p&gt;&#xA;&lt;p&gt;这就像医院明明有体温计、病历、化验单和监护大屏，医生却仍要自己跑四个房间抄数据。AI Agent 真正有价值的地方，不是替医生“猜病”，而是拿着受限制的工具，自动把四处证据取回来，再把“现象、证据、根因和建议”分开说明。&lt;/p&gt;&#xA;&lt;p&gt;本文不是概念拼贴。我实际启动了一套隔离环境，使用 MySQL 8.4、Prometheus 3.13、mysqld_exporter 0.19、Loki 3.7 和 Grafana 13.1，注入了一次带统一 &lt;code&gt;trace_id&lt;/code&gt; 的慢查询故障，然后通过自建只读 MCP Bridge 完成协议初始化、工具发现、PromQL 查询、LogQL 查询、MySQL 只读查询和 Grafana 数据源审计。&lt;/p&gt;&#xA;&lt;h2 id=&#34;先说结论四件套接入-agent不等于把四套管理员密码交给-ai&#34;&gt;先说结论：四件套接入 Agent，不等于把四套管理员密码交给 AI&lt;/h2&gt;&#xA;&lt;p&gt;正确的架构应该满足下面几条：&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;MySQL 仍然保存业务事实，Agent 只能使用专门的只读账号；&lt;/li&gt;&#xA;&lt;li&gt;Prometheus 负责保存数字随时间的变化，例如连接数、QPS 和缓存命中率；&lt;/li&gt;&#xA;&lt;li&gt;Loki 保存“发生了什么”的日志，并通过标签、时间和 &lt;code&gt;trace_id&lt;/code&gt; 关联事件；&lt;/li&gt;&#xA;&lt;li&gt;Grafana 继续承担人工观察、仪表盘、数据源管理和结果复核；&lt;/li&gt;&#xA;&lt;li&gt;MCP Bridge 把查询包装成边界明确的工具，而不是开放任意 Shell；&lt;/li&gt;&#xA;&lt;li&gt;Agent 先调用工具取证，再总结答案，不能把语言模型的推测冒充事实。&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;换句话说，Agent 拿到的应该是一串“只能打开指定抽屉的钥匙”，而不是整栋楼的万能钥匙。&lt;/p&gt;&#xA;&lt;p&gt;&lt;img src=&#34;https://blog.margrop.net/post-images/mysql-prometheus-loki-grafana-ai-agent/01-four-piece-architecture.png&#34; alt=&#34;四件套职责与 AI Agent 的关系&#34;&gt;&lt;/p&gt;&#xA;&lt;h2 id=&#34;四件套分别是什么用小学生也能懂的方式解释&#34;&gt;四件套分别是什么？用小学生也能懂的方式解释&lt;/h2&gt;&#xA;&lt;h3 id=&#34;mysql学校老师手里的成绩册&#34;&gt;MySQL：学校老师手里的成绩册&lt;/h3&gt;&#xA;&lt;p&gt;MySQL 保存订单、用户、库存、付款状态等业务事实。你问“这个订单到底有没有支付”，最终应该以数据库记录为准。&lt;/p&gt;&#xA;&lt;p&gt;它像成绩册：里面写着谁参加了考试、得了多少分。成绩册擅长回答具体事实，却不适合每隔五秒画一次“全校平均分变化曲线”。&lt;/p&gt;&#xA;&lt;h3 id=&#34;prometheus每隔几秒自动测一次体温&#34;&gt;Prometheus：每隔几秒自动测一次体温&lt;/h3&gt;&#xA;&lt;p&gt;Prometheus 会定时抓取指标，并保存时间序列。借助 &lt;code&gt;mysqld_exporter&lt;/code&gt;，MySQL 的连接数、查询数、线程状态等数据会被翻译成 Prometheus 能理解的格式。&lt;/p&gt;</description>
			</item>
			<item>
				<title>别再人工翻日志了：ELK 三件套接入 AI Agent，从部署到自动排障的手把手教程</title>
				<link>https://blog.margrop.net/post/elk-ai-agent-hands-on/</link>
				<pubDate>Sat, 11 Jul 2026 03:30:00 +0800</pubDate>
				<guid>https://blog.margrop.net/post/elk-ai-agent-hands-on/</guid>
				<description>&lt;p&gt;&lt;img src=&#34;https://blog.margrop.net/post-images/elk-ai-agent-hands-on/00-cover-ai-generated.png&#34; alt=&#34;ELK 三件套接入 AI Agent 题图&#34;&gt;&lt;/p&gt;&#xA;&lt;p&gt;过去，线上报警后的标准动作通常是：打开 Kibana、选择时间范围、输入查询语句、翻几十页日志、复制错误堆栈，再把零散证据拼成结论。系统一多，这件事很像在一座没有导购员的巨大仓库里找一颗螺丝。&lt;/p&gt;&#xA;&lt;p&gt;现在可以换一种方式：让 ELK 继续负责可靠地收集、整理和搜索日志，再给它加一座 MCP “翻译桥”，让 AI Agent 用工具读取证据。于是你可以直接问：&lt;/p&gt;&#xA;&lt;blockquote&gt;&#xA;&lt;p&gt;最近 15 分钟哪个服务的 5xx 最多？请列出证据、关联 trace_id，并给出下一步排查建议。&lt;/p&gt;&#xA;&lt;/blockquote&gt;&#xA;&lt;p&gt;Agent 不再只靠语言模型“猜”，而是先调用 Elasticsearch 查询，再根据返回的数据组织答案。本文不是概念拼贴。我实际启动了 Elasticsearch、Logstash、Kibana 和 Elasticsearch MCP Server，导入一组脱敏故障日志，完成 MCP 协议握手与查询，并记录了中途踩到的权限问题。&lt;/p&gt;&#xA;&lt;h2 id=&#34;先说结论真正有价值的不是让-ai-看日志而是让它有边界地查日志&#34;&gt;先说结论：真正有价值的不是“让 AI 看日志”，而是让它有边界地查日志&lt;/h2&gt;&#xA;&lt;p&gt;接入后的合理架构是：&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;Logstash 负责接收、解析、清洗和补充字段；&lt;/li&gt;&#xA;&lt;li&gt;Elasticsearch 负责索引、搜索、聚合与保存；&lt;/li&gt;&#xA;&lt;li&gt;Kibana 负责人工可视化、验证和审计；&lt;/li&gt;&#xA;&lt;li&gt;MCP Server 把查询能力包装成 Agent 能理解的工具；&lt;/li&gt;&#xA;&lt;li&gt;AI Agent 负责拆解问题、调用工具、总结证据，但默认不拥有删除和写入权限。&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;这与“把所有日志复制给聊天机器人”完全不同。后者既容易泄密，也会受上下文长度限制；前者让数据留在自己的 ELK 中，Agent 只取当前问题需要的少量结果。&lt;/p&gt;&#xA;&lt;p&gt;&lt;img src=&#34;https://blog.margrop.net/post-images/elk-ai-agent-hands-on/01-elk-library-analogy.png&#34; alt=&#34;ELK 像一座会说话的图书馆&#34;&gt;&lt;/p&gt;&#xA;&lt;p&gt;如果给小学生解释，可以把它想成一座图书馆：Logstash 是收书和贴标签的工作人员，Elasticsearch 是记住每本书放在哪里的图书管理员，Kibana 是墙上的查询大屏，MCP 是翻译员，AI Agent 是会帮你办事的值班同学。你问“哪一类事故最多”，值班同学不会凭印象回答，而是让翻译员去问图书管理员，然后把查到的书名和页码一起交给你。&lt;/p&gt;&#xA;&lt;h2 id=&#34;elk-三件套到底是什么&#34;&gt;ELK 三件套到底是什么&lt;/h2&gt;&#xA;&lt;h3 id=&#34;elasticsearch不是数据库替代品而是搜索与分析引擎&#34;&gt;Elasticsearch：不是数据库替代品，而是搜索与分析引擎&lt;/h3&gt;&#xA;&lt;p&gt;Elasticsearch 将文档建立倒排索引，擅长全文检索、时间范围过滤、多条件查询和聚合统计。日志场景中，一条日志通常是一份 JSON 文档，包含时间、服务、级别、消息、状态码、耗时、链路标识等字段。&lt;/p&gt;</description>
			</item>
	</channel>
</rss>
