你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
小窍门
- 使用假设驱动的调查，而不是随机日志搜索。
- 提供完整的证据链，显示 为什么 这是原因。
- 回顾过去类似的事件及其修复。
问题：日志搜索不等同于调查
大多数调试都以“显示错误”开始。查询日志、滚动结果、复制时间戳、切换工具并运行另一个查询。 您没有进行调查。 你正在手动关联数据并将推理保存在脑海中。
问题不在于找到日志。 它知道要问什么问题、要检查什么工具，以及如何关联日志、指标、部署和过往事件中的线索。 这些心智模型存在于你的高级工程师的脑海中，而他们不可能参加每一次会议。 新团队成员需要花费数小时解决的问题，资深员工几分钟就能搞定，因为相关推理过程没有任何文档记录。
Azure SRE 代理如何解决此问题
您的代理会像专家级的 SRE 一样进行调查。 它不仅仅是用来搜索日志的。 它形成关于出问题的原因的假设，并系统地使用证据验证每一个。
- 收集上下文：查询 Application Insights、Azure Monitor、部署历史记录、活动日志和资源属性。
- 形式假设：基于证据模式生成理论。
- 验证每一个：系统地测试假设，排除虚假线索。
- 解释结论：显示支持证据和引文的完整推理线索。
这种方法有何不同
与日志搜索不同，您的代理会分析问题。 “向我显示错误”会为你提供可供解读的数据。 您的代理通过形成理论、测试这些理论并解释结论来为您解释数据。
与静态仪表板不同，代理适应特定事件。 它不仅向你展示指标。 它决定哪些指标很重要，将它们与其他证据相关联，并告诉你原因。
与脚本不同，代理处理新情况。 脚本每次都运行相同的步骤。 您的代理分析这次的不同之处，并相应地调整其调查。
前后
| 类别 | 之前 | 之后 |
|---|---|---|
| 调查方法 | 搜索日志并期望能找到一些东西 | 代理程序构建并测试假设 |
| 已打开的工具 | 4 个或更多门户，手动关联 | 0 （代理查询所有源） |
| Reasoning | “我认为这是数据库...” | 数据库 DTU 达到 98%，已验证 |
| 证据线索 | 在你的脑海里 | 包含说明的完整流程 |
| 下一次 | 从头开始 | 记忆回忆类似事件 |
示例：数据库超时调查
症状：“/api/orders 终结点上出现 500 个错误”
HYPOTHESIS 1: Recent deployment broke something
├─ Checked: Last deployment was 3 days ago
├─ Evidence: Error rate stable until 30 minutes ago
└─ Result: INVALIDATED
HYPOTHESIS 2: Database overloaded
├─ Checked: Azure SQL metrics (CPU, DTU, connections)
├─ Evidence: DTU at 98%, query duration 4x normal
├─ Traced: SELECT * FROM orders WHERE... taking 8.2s
└─ Result: VALIDATED
ROOT CAUSE: Orders table missing index on customer_id column.
Query plan shows full table scan on 2.1M rows.
RECOMMENDED ACTION: Add index on orders.customer_id
Similar fix applied in INC-2341 (3 weeks ago)
开始
根本原因分析可自动与 Azure 的内置工具配合使用。 若要启用更深入的分析，请考虑以下增强功能。
| 增强功能 | 它所带来的意义 | Setup |
|---|---|---|
| 源代码管理 | 错误与代码的关联，语义代码搜索 | 连接源代码 |
| 知识库 | 假设生成的上下文 | 上传知识 |
| 自定义遥测 | Kusto 中的业务指标 | 设置 Kusto 连接器 |