使用 AI 进行故障排除：OpenAI vs DeepSeek
I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (excluding the source line you’ve already provided) here? Once I have the text, I’ll translate it into Simplified Chinese while preserving the original formatting, markdown, and any code blocks or URLs.
AI‑驱动的根因分析
AI 现在已成为从写作到编码的万用工具。现代的大语言模型（LLM）如此强大，只要提供合适的提示并进行少量调整，它们几乎可以轻松完成各种任务。
在 Coroot（一个简化可观测性的开源项目）中，我们开发了 AI（LLM + 机器学习）来进行根因分析。找到准确的根因很困难，因为可能的场景很多。我们的许多用户并非数据库、网络性能或特定运行时的专家，所以我们需要提供清晰的解释——最好还能给出如何修复问题的指导。
在下面的博客中，我决定测试不同 LLM 对一次混沌实验的诊断能力。由于懒惰常常推动进步，我没有把遥测数据转换成提示，而是直接上传了一张截图作为 LLM 的输入。
结果让我大吃一惊。
OpenAI GPT‑4o
提示（未提供其他上下文）：
回答
从提供的 PostgreSQL 监控仪表盘来看，似乎是一个 ALTER TABLE 语句导致了性能问题，具体表现为：
- 查询延迟增加 – 平均查询延迟出现尖峰，尤其是在
pg‑cluster‑2上。 ALTER TABLE引起的 I/O 负载 – “ALTER TABLE” 语句（alter table articles alter column body set not null）消耗了大量 I/O（见 Queries by I/O time 图表）。- 连接和查询被锁
- Postgres connections 图表显示锁定的连接数量急剧上升。
- Locked queries 图表确认查询因
ALTER TABLE操作被阻塞。 - Blocking queries 图表表明
ALTER TABLE查询持有锁并阻塞了多个其他查询。
- 复制延迟 – 出现尖峰，可能是由
ALTER TABLE产生的大量写入积压导致的。
为什么会出现这种情况？
ALTER TABLE … SET NOT NULL 是一次全表操作，需要对整张表进行扫描，以验证没有现有行违反新约束。它会锁定整张表，阻止读写操作直至完成。在读写频繁的高负载环境中，这尤其成问题。
如何修复（立即行动）
-- 如果 ALTER TABLE 导致宕机，先取消它
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE query LIKE '%ALTER TABLE articles alter column body set not null%';取消后，检查是否还有残留锁：
SELECT *
FROM pg_stat_activity
WHERE wait_event IS NOT NULL;长期解决方案
由于 ALTER TABLE 开销大，建议采用以下最佳实践：
-
转为在线友好的方式
-- 1️⃣ 添加非验证的检查约束（非阻塞） ALTER TABLE articles ADD CONSTRAINT articles_body_not_null CHECK (body IS NOT NULL) NOT VALID; -- 2️⃣ 回填缺失的值（如果有） -- 3️⃣ 验证约束（仍然非阻塞） ALTER TABLE articles VALIDATE CONSTRAINT articles_body_not_null; -- 4️⃣ 若不存在违规记录，设置列为 NOT NULL ALTER TABLE articles ALTER COLUMN body SET NOT NULL; -
使用
pg_repack实现零停机迁移pg_repack -t articles --dbname=mydatabase -
在低流量时段进行模式变更 – 为生产环境安排维护窗口。
-
对大表进行分区 – 将操作限制在更小的分区上，以降低影响。
Source: …
uce impact.
结论
ALTER TABLE 操作正在锁定 articles 表，导致查询延迟显著并产生复制滞后。推荐的做法是：
- 如果导致停机，请取消该操作。
- 使用在线安全的替代方案（检查约束 + 验证）。
- 谨慎安排模式更改，并考虑使用
pg_repack等工具以将影响降至最低。
DeepSeek‑R1
Prompt: (same screenshot)
答案
数据表明 pg‑cluster‑2 存在显著的性能问题，主要原因是对 articles 表的长时间运行的 ALTER TABLE 命令。该操作：
- 对
articles表持有排他锁。 - 阻塞其他关键查询（
SELECT、INSERT）。 - 导致查询延迟高（10‑15 秒），活跃/锁定连接激增，吞吐量下降，以及其他集群出现轻微复制滞后。
立即修复
-- Find the PID of the ALTER TABLE query
SELECT pid, query
FROM pg_stat_activity
WHERE query ILIKE '%ALTER TABLE articles alter column body set not%';
-- Terminate it (if safe)
SELECT pg_terminate_backend(pid);终止后，验证锁是否已清除：
SELECT *
FROM pg_stat_activity
WHERE wait_event IS NOT NULL;长期建议
- 遵循 GPT‑4o 中描述的相同在线友好方法。
- 使用
pg_repack或类似工具实现零停机时间的模式更改。 - 在维护窗口期间安排大量 DDL 操作。
- 考虑对非常大且频繁更改的表进行分区。
最终思考
两个模型都从单张截图中提供了令人印象深刻的准确分析。LLM 能够“理解”我们的领域并生成深入、可操作的摘要，这一点令人兴奋。然而，仅依赖单一供应商并不是稳健的解决方案。
DeepSeek 的 R1 模型被证明是 OpenAI 产品的有力替代方案，使我们确信多供应商策略能够提供可靠、与供应商无关的 AI 驱动可观测性。
DeepSeek‑R1 提供的答案与 OpenAI 的相当接近。我认为它足够准确，可作为 OpenAI 模型的可行替代方案。
此外，我在实验室测试了其他开源模型，但只能运行最多 70 0 亿参数的 LLM。在这个范围内，我没有找到任何能接近 OpenAI 或更大 DeepSeek 模型的方案，满足我们的需求。
阻塞 ALTER TABLE 问题
-- Find the blocking query
SELECT pid, query
FROM pg_stat_activity
WHERE query LIKE '%alter column body%';
-- Terminate it
SELECT pg_terminate_backend(pid);注意： 确保此操作不会导致数据损坏（例如，ALTER 是迁移的一部分时）。
重新安排 DDL 操作
在低流量期间运行模式更改，或使用在线 DDL 工具，例如：
pg_repack– 在不使用排他锁的情况下重建表。CREATE INDEX CONCURRENTLY– 在不阻塞写入的情况下执行索引相关更改。
优化 ALTER TABLE
如果列被设置为 NOT NULL，请确保它已经不包含 NULL 值。预先运行如下清理：
UPDATE articles
SET body = ''
WHERE body IS NULL; -- Example cleanup长期改进
使用锁超时
SET LOCAL lock_timeout = '5s';
ALTER TABLE ...;监控和调优查询
- 优化查询
SELECT id FROM articles WHERE created ...
AIOps 终于来了？
是的，但前提是你拥有足够描述系统行为的数据。
仅凭 CPU、内存和磁盘使用情况是无法实现的。此情形下 AI 的真正魔力在于它能够理解全局、运用领域知识并提出问题的解决方案。
Coroot 的 AI 驱动根因分析
Coroot 将 eBPF 与 机器学习 相结合，以捕获仅 LLM 无法捕获的上下文。作为我们致力于让可观测性更简单、对所有人都可访问的一部分，您可以进行设置
免费使用我们的开源版本。
我们希望它能帮助您节省数小时的遥测数据挖掘时间，并让您的团队更容易进行根因分析。