借助 NVIDIA NIM 推理微服务和 ITMonitron 实现实时 IT 事故检测和情报

在当今快节奏的 IT 环境中，并非所有事件都始于明显的警报。这些问题可能始于细微的分散信号、错过的警报、悄无声息的 SLO 漏洞，或逐渐影响用户的降级服务。

ITMonitron 由 NVIDIA IT 团队设计，是一款有助于理解这些模糊信号的内部工具。通过将实时遥测与 NVIDIA NIM 推理微服务和 AI 驱动的摘要相结合，ITMonitron 可将分散的监控转化为统一、可操作的智能，从而缩短检测时间并加快决策速度。

愿景：从分散的信号到统一的智能

从应用程序到基础设施监控，再到关联工具，再到SaaS平台，再到企业安全监控，大量的监控工具充斥着企业。每个工具都会生成自己的数据，而这些数据通常是孤立的。

结果如何？缓慢的事件检测、肿的Mean Time to Detect、Mean Time to Resolve (MTTR) 以及大量的手动分诊。

借助 ITMonitron，我们的目标是充当连接所有部件的结缔组织，提供系统运行状况的统一视图，从而解决碎片化问题。

通过实时聚合、关联和归一化数据，ITMonitron 为 SRE、事件经理和高管提供 360°全方位的系统运行状况视图，帮助他们更快地检测事件并更高效地做出响应。该组合可提供切实可行的见解，而不仅仅是原始警报。

幕后：设计脉冲

ITMonitron 是一个基于 Go 的模块化平台，专为高效的数据提取、归一化和摘要而设计。该架构旨在与应用、基础设施、SaaS 和云服务提供商的各种可观察性和事件管理工具集成，使 SRE 团队能够有效地监控和管理系统。

该平台的关键组件包括：

• API 网关层：用于跨多个监控源访问数据的统一入口点。它可以简化 API 复杂性，确保一致性，并优化缓存和性能。
• 源连接器：用于遥测提取的专用连接器套件。这些连接器可处理重试和数据格式可变性，确保弹性数据管道。
• 抽象和编排层：将遥测数据归一化、关联并丰富到一致的模式中。它还将缓存经常访问的值，通过重复数据删除和优先处理信号来减少噪音，并提供高效的数据处理流程。
• LLM 驱动的事件摘要：此层由 NVIDIA NIM 提供支持，可生成高背景、简洁的事件报告，为技术团队和高管降低噪音并提高清晰度。
• 自定义控制面板：Grafana 集成可为 SRE 和高管提供量身定制的实时可视化效果，从而促进快速决策和高效事件响应。
• 可扩展架构：ITMonitron 基于基于 REST 的通信的模块化微服务框架构建，可确保可扩展性以及与新系统的轻松集成。

深入了解 ITMonitron：可扩展的 AI 引擎示例

与 NVIDIA NIM 的实时 LLM 集成

此层由 NVIDIA NIM 提供支持，可生成高背景、简洁的事件报告，为技术团队和高管降低噪音并提高清晰度。默认情况下，我们使用 llama-3.1-nemotron-70b-instruct 模型来平衡生产工作负载的准确性和性能。

为适应各种用例并提供灵活性，ITMonitron 通过 NIM 接口支持多个顶级模型。用户可以从精心策划的集合中动态选择，包括：

• llama-3.1-405b-instruct
  llama-3.3-nemotron-super-49b-v1
• llama-3.1-70b-instruct
• llama-3.1-Nemotron-Ultra-253b-v1

这种与模型无关的设计使我们能够对摘要质量进行基准测试，适应不断变化的模型性能，并确保事件叙事在各种环境中保持清晰、准确和可行。

示例摘要 (由 NVIDIA NIM 生成)：
“由于 DNS 延迟，Service X 的性能降低。站点 A 和站点 B 之间触发的警报。用户可能会在西海岸受到影响。正在调查的根本原因。”相关持续变化：

• 站点 A Internet circuit 迁移和升级 (CHG001) 可能与站点 A 中的 Pan-FW 问题有关，尽管没有明确确认直接相关。
• 错误的二级防火墙替换 (CHG002) 可能会关联到与防火墙相关的警报。

这些简洁、可操作的摘要使利益相关者能够做出决策，而无需涉猎冗长的警报流或碎片化的dashboard。

智能停机验证服务

基于 ITMonitron 平台，我们最近开发了一项 Outage Validation 服务，解决了一个看似困难的问题：

这个用户报告的问题是更广泛的中断的一部分吗？

AI 功能可以解决根据实时基础设施信号验证用户报告的问题的问题。

目前有两个重要选项：

• 函数调用，其中 LLM 会解析用户的查询，识别要调用的函数或工具 (例如 checkDatadogMetrics、queryIncidentDB 等)，提取正确的参数并编排响应。
• 代理式 AI，其中 LLM 充当自主智能体，可能具有内存，对多个工具和步骤进行推理，通过推理链、工具链等动态决定如何验证中断。

虽然这些方法功能强大，非常适合复杂的工作流程，但我们认为，这两种方法都经过了过度设计，可用于中断验证这一具有明确界限的狭窄任务。

为什么不使用代理式 AI？

代理式系统具有灵活性，但需要进行重大权衡：

1. 由于multi-step reasoning，它们的速度较慢。
2. 它们在生产环境中更难以监控和调试。
3. 它们往往会产生幻觉，尤其是在监控数据模糊或结构化薄弱时。
4. 最重要的是，每次从零开始选择正确工具和参数所产生的认知开销，使得这些工具和参数不适合中断检测等延迟敏感型高精度用例。

为什么不单独调用函数呢？

LLM 选择预定义函数来运行的函数调用更轻量级，但仍然假设：

1. 该模型可以准确地对问题类型 (app vs. 网络 vs. 身份 vs. Wi-Fi 等) 进行分类。
2. 它可以从杂乱的自然语言输入中提取参数并对其进行归一化。
3. 即使问题模糊或跨越多个层，它也知道要调用哪个函数。
4. 在实践中，用户查询过于开放或依赖于上下文。例如：“我在尝试从东京的酒店 Wi-Fi 登录 VPN 时遇到超时”

… 可能涉及网络、身份验证、服务可用性，甚至是本地 ISP 问题。让 LLM 选择正确的诊断工具，而不会出现过拟合或悄无声息的故障，这非常困难，而且通常很脆弱。

我们的理念是：在 LLM 真正大放异彩的地方发挥其作用

与让 LLM 成为决策者和工具编排器不同，我们采用了以下方法：

• 我们通过不断从监控来源中提取和扁平化停机候选数据，对所有相关信号进行预处理。
• 我们会生成环境中显著问题 (包括服务、infra layers、和持续维护) 的实时摘要视图。
• 我们要求 LLM 只执行一项任务：根据现有的中断摘要交叉检查自然语言用户查询，以确定该问题是否可能是更大的已知事件的一部分。

这种方法可显著减少 LLM 的认知负荷。凭借更少的自由度和范围更广的提示，LLM 可以执行集中推理，从而实现更高的准确性、更少的幻觉和更可信的回答。

结构化响应格式

为了使停机验证服务的输出可由机器读取并易于在不同系统中使用，我们要求 LLM 以严格的 JSON 格式返回响应。

{
  "is_outage": true | false,
  "confidence": "NoConfidence" | "LowConfidence" | "HighConfidence",
  "reasoning": "<natural language explanation>"
}

此结构使我们能够：

1. 将服务作为可集成到各种下游系统 (例如 Slack 机器人、事件响应控制面板、售票系统) 的 REST API 公开。
2. 无论使用何种接口，均可确保对验证结果进行一致的programmatic handling。
3. 根据结构化输出 (例如，自动分配工单、在 is_outage：true 的情况下通知应召接线员) 启用自动分类和警报。
4. 随着时间的推移记录和分析响应，以改进模型行为，并系统地追踪False Positives/ False Negatives。

通过避免非结构化自然语言回复，我们确保人类和机器都能从 LLM 的推理中受益，同时保持简洁、确定性的 APIs 以实现自动化。

提示设计：精度受限

我们的停机验证服务的核心是一个精心设计的提示，它引导 LLM 像确定性评估器一样行事，而不是对话助手。

提示将模型定位为专家，将用户报告的问题与实时监控摘要进行匹配。它被明确指示严格根据可用的监控数据做出决策，而不要在可验证的数据之外进行推理或假设。

关键设计原则

严格匹配规则：只有当用户的问题和中断摘要之间存在直接、明确的匹配时，LLM 才允许确认中断。它必须精确匹配服务名称、位置和标识符，才能声明高置信度结果。

明确的置信度值：提示定义了符合 HighConfidence 与 LowConfidence 决策条件的选项。这有助于下游系统和人类以结构化、机器可操作的方式解释模型的确定性。

归一化逻辑：由于用户查询是自由格式的，因此系统会指示模型执行基本归一化 (删除空格、处理大小写不敏感等)处理用户提及服务时的细微变化 (例如，“nv bot”与“nvbot”) 。

支持的服务列表：每个查询都使用受支持应用程序的动态列表来确定范围，该列表在运行时注入到提示中。这可确保模型仅评估其监控可见性的内容，并在事物超出该范围时优雅地拒绝猜测。

通过 Slack Bot 实现高级易用性：Outage intelligence 在您的指尖

停机验证服务现已在我们基于 Slack 的停机机器人中上线，使用户和呼叫响应人员能够无缝交互。任何人都可以使用：

/outage-validate is Service X down?
/outage-validate having trouble connecting to wifi in Finland

机器人会将查询发送到我们的 REST API，运行基于 LLM 的验证，并立即回复：提交查询的用户或呼叫事件管理器 (如果检测到潜在的中断匹配) 。这种实时反馈回路可提高用户信任度，减少重复工单，并使事件团队能够更快、更智能地做出响应。

结果和后续动态

我们使用拇指向上/ 向下的反应将轻量级反馈回路直接引入停机机器人。在完成每个验证响应后，用户可以投票确定答案是否有用。这种反馈非常宝贵，因为它使我们能够：

• 不断完善提示，以提高清晰度和准确性。
• 在生产环境中试验多个 LLM 和 LRM。
• 衡量现实世界的准确性，而不仅仅是理论评估分数。

在 alpha 版本中，我们已收到 100 多个反馈响应，到目前为止，我们看到 93% 的反馈是积极的。这一早期信号表明，用户期望的结果与模型返回的结果高度一致。我们目前正在使用这些反馈数据：

• 识别弱点 (false negatives/positives)
• 在候选模型之间运行 A/B 评估
• 调整提示策略以保持大规模性能

学习

构建 ITMonitron 既是一项工程挑战，也是一次学习之旅。以下是我们开发过程中的一些关键要点：

1. 警报降噪并非可选。并非所有警报都是平等的，并非每个事件都值得关注。其中一项最重要的学习是，高保真总结始于规范的Telemetry卫生条件。
2. 抽象就是力量，但只有借助护栏才能实现。在不同平台上对数据进行标准化是一项复杂的工作。学习意味着，虽然激进抽象化提高了 ITMonitron 的 API 可用性，但它必须与为高级用例公开特定于源的详细信息的需求保持平衡。
3. 提示工程是真实的。推动决策的执行摘要需要的不仅仅是语言流畅性。它们需要结构化上下文、特定领域的逻辑和有针对性的提示。所有这些都不是“开箱即用”的。我们了解到，Prompt Engineering和情境丰富是生产LLM系统的关键技能。
4. 中断验证需要精确的范围和约束。使用 LLM 成功验证中断需要严格范围的提示和定义明确的匹配规则，以避免产生幻觉和误报。将 LLM 的任务范围缩小到根据精心策划的停机摘要交叉检查用户查询，可显著提高准确性和可靠性。
5. 实时用户反馈回路可提高模型信任度。将用户反馈直接整合到停机验证机器人中，有助于快速识别边缘案例，这对于持续改进和提高用户对 AI 驱动的验证的信心至关重要。

衡量重要事项

为了量化 ITMonitron 的影响，我们不断跟踪以下核心指标：

• 依赖项覆盖：确保跨关键系统 100% 监控可见性
• 平均检测时间 (Mean Time to Detect, MTTD) ：通过智能关联将 MTTD 减少 30%
• 信噪比降低：通过持续调整增强基于监控的检测。

展望未来

展望未来，我们的目标不仅是减少 MTTR，而且要在中断发生之前预测和预防。ITMonitron 体现了我们将智能系统与卓越运营相结合的承诺。即将推出的功能包括：

• 中断验证的置信度评分
• 历史事件融合，以识别重复的模式和先兆

总结

ITMonitron 由 NVIDIA NIM 推理微服务提供支持，可将碎片化的遥测变得清晰明了，提供简洁、可行的见解，并为 SRE、事件管理器和高管提供快速、统一的系统运行状况视图。此外，借助其智能停机验证服务，ITMonitron 可帮助快速确认用户报告的问题是否属于更广泛的事件，从而减少噪音并实现更快、更准确的响应。如果您面临警报疲劳、数据孤岛或延长的 MTTR，这些方法可能会提供一条前进的道路。

致谢

我们要对 IT 领导团队的持续支持表示最衷心的感谢。特别感谢 Nina Mushiana 的远见卓识和付出，她致力于确保 ITMonitron 的指示器和可视化效果不仅清晰直观，而且还能为用户提供清晰、可行的视图。如果没有他们的支持，这项计划就不会充分发挥潜力。