收益：
- 能够理解可观察性的三大支柱（指标、日志、跟踪）和四个黄金信号，并让人工智能生成 PromQL 查询、警报规则和仪表板
- 能够通过保持警报以行动为导向、处于适当的紧急程度并根据您自己系统的历史数据测试阈值来防止警报疲劳
- 在将日志提供给人工智能之前，能够通过屏蔽敏感区域来防止隐私和秘密泄露
虽然系统可能看起来在工作，但它的内部可能正在死亡：内存慢慢填满，响应时间增加，错误率攀升。注意到这一点的唯一方法是不断监控系统。一个更高级的概念是可观察性：通过观察系统外部迹象来了解系统内部正在发生的事情的能力。可观察性有三个支柱，DevOps 专业人员使用这三个支柱：
- 指标：随着时间的推移测量的数值 - CPU 使用率、请求数、响应时间、错误率。 “多少？”回答了问题。
- 日志：系统产生的文本事件记录——“用户登录”、“数据库连接丢失”。 “究竟发生了什么？”回答了问题。
- 跟踪：请求在系统内从一个服务传递到另一个服务时所遵循的路径以及每个步骤的持续时间。 “哪里慢了？”回答了问题。
最常见的工具：用于指标的 Prometheus、用于可视化的 Grafana、用于日志的 Loki/ELK、用于跟踪的 Jaeger/OpenTelemetry。 AI非常擅长为这些工具编写查询语言（尤其是Prometheus的PromQL）、警报规则和仪表板配置。这也是人工智能最强大的地方：总结大量日志和指标并标记异常。
让我们用一句话来澄清监控和可观察性之间的区别：监控是问你已经知道的问题（“CPU 是否超过 90%？”）；可观察性是能够提出您不知道的问题（“为什么这种奇怪的缓慢现象只在特定时间发生在特定客户身上？”）。现代系统非常复杂，您无法预测所有故障模式；因此，收集丰富的指标、日志和跟踪，然后深入查询它们的能力（即可观察性）变得至关重要。这就是人工智能在回答“以前未知的问题”时发挥作用的地方：它快速扫描您拥有的原始数据，提出模式和异常情况，然后您通过验证这些线索找到根本原因。
一步一步：监控什么以及如何监控？
- 选择正确的指标。业界以“四个黄金信号”为基础：延迟、流量、错误、饱和度——资源的满度。这些总结了大多数服务的健康状况。
- 收集指标。让应用程序提供 Prometheus 可以读取的端点。
- 设置仪表板。在 Grafana 中可视化这些指标。
- 编写报警规则。当超过阈值时谁会收到警告以及如何收到警告？
- 集中日志。使所有服务日志都可在一处进行搜索。
- 减少噪音。过多的警报会造成“警觉疲劳”；重要警报消失。
提示：一个好的警报满足两个条件：可操作且具有适当的紧迫性。凌晨 3 点叫醒某人的闹钟必定确实需要夜间干预。不要因为不需要采取任何操作的事情而叫醒任何人，例如“CPU 70%”；将其显示在板上。
报警规则怎么写？
警报由三个部分组成：条件（哪个指标超过哪个阈值以及持续多长时间）、持续时间（“持续 5 分钟”以避免触发瞬时波动）和重要性/操作（对谁、通过哪个渠道）。人工智能巧妙地在正确的背景下建立了这三者。例如，将“如果错误率在 5 分钟内超过 5%，则发出严重警报”之类的规则转换为 PromQL 对于 AI 来说是一个瞬间完成的任务，但您可以决定阈值是否适合您的系统。
注意：AI 建议的警报阈值是一般假设。您的系统的正常负载、耐受性和工作影响是不同的。在直接将阈值放入产品之前，您会查看历史数据并询问“过去触发了多少次该阈值，其中有多少是真正的问题？”回答问题。
日志隐私：严重警告
日志是最常被忽视的泄漏源。日志行可能会意外包含密码、信用卡号或个人数据（根据 KVKK/GDPR）。将日志粘贴到 AI 中进行分析时：
- 遮盖敏感区域。将令牌、密码、电子邮件、ID 号等值替换为 <REDACTED>。
- 举个例子吧，不是全部。不需要一百万行，几百个代表性行通常就足够了。
- 选择机构认可的车辆。特别是对于生产日志，请使用其数据不用于训练的工具。
四个黄金信号和警报表
信号
测量由
警报阈值示例
紧迫性
延迟
响应时间
p95 > 800 毫秒，5 分钟
高
交通
请求/秒
突然增加/减少300%
中等
错误
请求失败率
> 5%，5 分钟
批评的
饱和度
资源占用
磁盘 > 85%
高
三个迷你箱子
案例 1 — 在 30 秒内汇总 400 行日志。服务速度变慢了。工程师将屏蔽后的 400 行日志交给 AI，并说：“总结重复出现的错误模式和时间强度。” AI 表明，特定的外部 API 调用每 30 秒就会超时。 30秒内找到根本原因；手动扫描日志需要半个小时。
案例 2 — 警报疲劳已解决。一个团队每天收到 200 个警报，但却忽略了所有警报，直到真正的停电警报也被忽略。把所有的警报规则交给AI，并询问“哪些是不可操作的，哪些是可以组合的？”他们问道。警报数量减少至每天 12 起；现在，每个警报都得到认真对待。
案例 3 — 尽早发现错误的阈值。 YZ 建议磁盘“Warn when 95% full”。工程师查看了历史数据：一旦磁盘达到95%，就几乎没有时间进行干预了。它将阈值降低至 80%，并添加了基于“增长率”的第二个警报。验证避免了实际的午夜停电。
四个可复制模板
1）日志汇总（屏蔽）：
分析下面的日志示例（我用<REDACTED>屏蔽了敏感值）。请告诉我：(1) 重复出现的错误模式，(2) 随着时间的推移的集中度，(3) 最可能的根本原因，以及 (4) 我将查看以验证的 3 个指标。日志：[行]
2）报警规则生成：
为Prometheus/Alertmanager编写一条报警规则：如果[THRESHOLD]超过[METRIC][DURATION]，则生成[SEVERITY]报警。该规则应以操作为导向，并包含注释和运行手册链接字段。解释 PromQL 并写出为什么这个阈值是合理的。
3) 编写/声明 PromQL 查询：
编写一个 PromQL 查询来测量：[EX. 5xx 最近 5 分钟的错误率百分比]。逐步解释该查询。然后告诉我这个值的健康范围应该是多少。
4）仪表板设计：
为 [服务] 设计一个 Grafana 仪表板：我应该使用哪些面板来显示四个黄金信号（延迟、流量、错误、饱和度）？为每个面板建议指标、可视化类型和合理阈值。目的：10秒查看守卫的健康状况。
弱提示/强提示
弱者：“日志里有什么？” （后面是 5000 行原始日志，其中有令牌）
结果：你泄露了秘密，人工智能给出了一个没有针对性的、肤浅的总结。
强：“在下面的 300 行屏蔽日志示例中查找重复出现的错误模式和时间强度；告诉我最可能的根本原因以及我将查看以验证的指标。我将标记设为<已编辑>。”
区别：第二个提示给出了一个屏蔽的、重点突出的例子，要求有清晰的分析输出；它既安全又有用。
常见错误
- 将日志粘贴到 AI 中而不进行屏蔽。最常见的秘密/个人数据泄露。
- 为所有事情设置警报。警报疲劳掩盖了真正的警报。
- 不可操作的警报。这是一种无人能做的警告噪音。
- 毫无疑问地接受AI的门槛。应根据系统的历史记录设置阈值。
- 只是看指标。如果没有日志和跟踪，大多数时候无法找到根本原因。
- 没有设置闹钟时间（for）。瞬时波动会产生误报。
总之
可观测性；它是通过指标、日志和跟踪从外部了解系统内部的能力。四个黄金信号（延迟、流量、错误、饱和度）总结了大多数服务的健康状况。 AI 在编写 PromQL 查询、警报规则和仪表板以及汇总大块日志和查找异常方面非常强大。但您有责任根据自己系统的历史记录验证警报阈值，保持警报以操作为导向，并且切勿在未屏蔽日志的情况下共享日志。
应用任务
对于服务（或示例服务）： (1) 使用“报警规则生成”模板针对错误率生成报警规则，并将建议阈值设置为“过去触发了多少次？”用问题来测试一下； (2) 屏蔽您拥有的日志样本，并使用“日志摘要”模板对其进行分析； (3) 记下您将查看哪个指标来确认最可能的根本原因。
清单
- [ ] 我根据四个黄金信号选择了要跟踪的指标。
- [ ] 我在敏感区域屏蔽了所有给AI的日志。
- [ ] 我确认每个警报都是以行动为导向的并且具有正确的紧迫性。
- [ ] 我根据系统的历史数据测试了警报阈值。
- [ ] 我通过向警报添加持续时间来过滤瞬时波动。
- [ ] 我一起使用了指标+日志+跟踪来寻找根本原因。