利用可观测性API和生成式AI自动化IT事件报告

最近，我参与了一个项目，通过集成监控解决方案和生成式AI来自动化IT事件报告的生成。本文分享我在这一持续进行中的实践中的观察，重点介绍如何利用AI服务来解释由可观测性解决方案（本例中为eG Enterprise Suite）生成的警报。

我们使用了Gemma AI模型（通过Ollama在本地运行，适用于本地部署用户）和Llama-3.1 AI模型（通过OpenAI，适用于有互联网连接的用户）。这一实践的成果是加快了对系统问题的理解和潜在修复步骤的提供，自动化了Level 1工程师创建事件报告的过程。

先决条件

• eG Innovations SaaS服务的有效订阅或eG Innovations Manager的安装。需要eG Manager的主机名或IP地址、端口、用户名以及API密钥或密码。
• 对于本地AI模型：
  • Windows服务器，最好配备GPU卡（本指南以Microsoft Windows为重点，但Ollama也支持macOS和Linux），或
  • 用于初始Ollama和Gemma 2设置的互联网连接。
• 对于SaaS AI模型，有效的OpenAI API密钥。

I. 为本地环境设置Ollama

1. 下载并安装Ollama：

   • 访问Ollama网站。
   • 点击“Download”按钮，选择Windows版本。
   • 按照屏幕指示安装应用程序。

2. 验证Ollama服务器状态：

   • 安装后，Ollama应自动启动。可以通过检查任务栏来验证，应出现Ollama图标（如下所示的白色图标）。

3. 在浏览器中确认Ollama运行：

   • 打开Web浏览器（如Chrome、Firefox、Edge）并导航到http://localhost:11434/。
   • 应看到以下响应：Ollama is running。

4. 配置命令行访问Ollama：

   • 打开提升的命令提示符（以管理员身份运行）。
   • 在系统的PATH环境变量中设置Ollama安装文件夹，以便从任何目录运行Ollama命令。

     1	set PATH=%PATH%;C:\Users\<your_username>\AppData\Local\Programs\Ollama

   • 重要：将<your_username>替换为实际的Windows用户名。

5. （可选）使PATH永久化：要通过系统属性使PATH更改永久化：

   • 打开控制面板 > 系统和安全 > 系统 > 高级系统设置 > 环境变量。
   • 在用户变量下，找到Path变量，选择它并点击编辑。
   • 将Ollama目录（C:\Users<your_username>\AppData\Local\Programs\Ollama）添加到列表中。
   • 重启命令提示符或终端以使更改生效。

II. 下载Gemma 2模型

• 打开提升的命令提示符：确保打开具有管理员权限的命令提示符。
• 拉取（下载）Gemma 2模型：执行以下命令从Ollama库下载Gemma 2模型：

  1	Ollama run gemma2

  Ollama将开始下载必要组件。此过程可能需要一段时间，具体取决于互联网连接速度，因为下载大小约为5.4 GB。 应在命令提示符中看到进度指示器：

  1 2 3 4 5 6 7 8 9 10

  ollama run gemma2 pulling manifest pulling ff1d1fc78170... 100% ▕████████████████████████████████████████████████████████▏ 5.4 GB pulling 109037bec39c... 100% ▕████████████████████████████████████████████████████████▏ 136 B pulling 097a36493f71... 100% ▕████████████████████████████████████████████████████████▏ 8.4 KB pulling 2490e7468436... 100% ▕████████████████████████████████████████████████████████▏ 65 B pulling 10aa81da732e... 100% ▕████████████████████████████████████████████████████████▏ 487 B verifying sha256 digest writing manifest success

  成功消息表示模型已正确下载和安装。

III. 与eG Innovations（或任何其他可观测性解决方案）集成

• 使用API收集eG警报：我使用Spring Boot与Spring AI库连接eG Innovations Manager API并检索警报。

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

  private List<Alarm> getAlarmsFromEGManager() { String egManagerUrl = "https://<eg-manager-hostname>:443/api/eg/analytics/getAlerts"; HttpHeaders headers = new HttpHeaders(); headers.setContentType(MediaType.APPLICATION_JSON); headers.set("managerurl", "https://<eg-manager-hostname>:443"); headers.set("user", "<user name>"); headers.set("pwd", Base64.getEncoder().encodeToString("<api key>".getBytes())); String requestBody = "{\"filterBy\":\"zone\",\"filterValues\":\"ALL\"}"; HttpEntity<String> entity = new HttpEntity<>(requestBody, headers); RestTemplate restTemplate = new RestTemplate(); ResponseEntity<String> response = restTemplate.exchange(egManagerUrl, HttpMethod.POST, entity, String.class); return parseAlarmsFromResponse(response.getBody()); }

  参考之前的代码片段，确保使用/api/eg/analytics/getAlerts端点，包括请求体中的filterBy和filterValues。响应的解析和实体对象集合的准备工作也已完成，此处未显示，因为它不重要。

• 迭代警报并构建提示：对于从eG Manager API检索的每个警报，构建一个将发送到AI模型的提示。

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

  @Override public void run(String... args) throws Exception { while (true) { List<Alarm> alarmsFromEGManager = getAlarmsFromEGManager(); for (Alarm alarm:alarmsFromEGManager) { StringBuilder sb = new StringBuilder(); sb.append("This is an alarm from eG Innovations. "); sb.append("Component name:"+alarm.getComponentName()); sb.append("\n"); sb.append("Component type:"+alarm.getComponentType()); sb.append("\n"); sb.append("Description:"+alarm.getDescription()); sb.append("\n"); sb.append("Layer:"+alarm.getLayer()); sb.append("\n"); sb.append("Measure:"+alarm.getMeasure()); sb.append("\n"); sb.append("Priority:"+alarm.getPriority()); sb.append("\n"); sb.append("Business Service affected by this alert:"+alarm.getService()); sb.append("\n"); sb.append("Alarm start time:"+alarm.getStartTime()); sb.append("\n"); sb.append("Test or Probe name:"+alarm.getTest()); sb.append("\n"); sb.append("Interpret this alert for me in simple terms. Provide me potential causes. Provide remediation if any."); String promptString = sb.toString(); processPrompt(promptString); } } }

IV. 使用Ollama处理提示

上一步准备的提示在此处传递。它在四个步骤中处理：

1. 创建一个CountDownLatch来管理异步操作完成。
2. 使用流式API将提示发送到AI模型（gemma2）。
3. 订阅响应流：
   • 实时打印每个响应部分。
   • 通过打印错误并释放latch来处理错误。
   • 通过打印消息并释放latch来信号完成。
4. 等待latch释放（操作完成）或300秒超时。

本质上，它异步处理AI提示，实时打印响应，并确保操作完成（或超时）后再继续。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

private void processPrompt(String promptString) throws InterruptedException {
    CountDownLatch latch = new CountDownLatch(1);
    
    Flux<ChatResponse> responseFlux = chatModel.stream(new Prompt(
            promptString,
            OllamaOptions.create()
                .withModel("gemma2")
                .withTemperature(0.4D)
        ));
    // Block and collect all responses
    
    responseFlux.subscribe(
            chatResponse -> System.out.print(chatResponse.getResult().getOutput().getContent()),
            error -> {
                System.err.println("An error occurred: " + error.getMessage());
                latch.countDown();
            },
            () -> {
                System.out.println("\nGeneration complete.");
                latch.countDown();
            }
        );
    
    // Wait for the operation to complete
    latch.await(300, TimeUnit.SECONDS);
    System.out.println("3");
}

可行性检查期间创建的一个简单提示如下。这是一个无效的提示。后续部分将解释我后来如何改进它。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

This is an alarm from eG Innovations.
Component name: reverse_proxy_srv1:443
Component type: Apache Web
Description: The web page 'HomePage' running in reverse_proxy_srv1:443 is unavailable
Layer: Web Server
Measure: Web availability
Priority: critical
Business Service affected by this alert: -
Alarm start time: Feb 15, 2025 14:06
Test or Probe name: HTTP
Interpret this alert for me in simple terms. Provide me with potential causes. Provide remediation steps if any.

以下是一个示例响应：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

##  eG Innovations Alarm: Your Website is Down!

This alarm means that the webpage "HomePage" on your web server (called "reverse_proxy_srv1") running on port 443 (usually used for secure websites) is currently unavailable.  

**Think of it like this:** Imagine your website is a shop, and "HomePage" is the front door. This alarm is saying the front door is locked, and customers can't get in!

**Possible Causes:**

* **Server Crash:** The web server itself might have crashed or frozen.

* **Software Glitch:** A bug in the website software (Apache Web) or a related program could be causing the problem.
* **Configuration Error:**  Something might be wrong with how the web server is set up, preventing it from serving the "HomePage" correctly.

**What to Do:**

1. **Check your Server Status:** Log into your web server and see if it's running. Look for any error messages.
2. **Test your Network Connection:** Make sure you have a stable internet connection. Try accessing other websites to rule out a broader network problem.
3. **Restart the Web Server:**  Sometimes a simple restart can fix things. 

5. **Contact Support:** If you're unable to resolve the problem yourself, contact your hosting provider or IT support for assistance.


Remember:  The sooner you address this alarm, the faster you can get your website back online

提示仍然可以通过来自其他API网关的额外输入进行自定义，以提高响应的准确性。

V. 满足本地和基于互联网用户的需求

虽然性能数据通常被认为敏感性较低，但它包含敏感信息，如服务器主机名、IP地址、进程位置和用户名。

对于Ollama服务的本地部署，本地生成报告是一种安全高效的方法。这种方法无需将敏感数据传输到外部，并允许在没有互联网连接的情况下生成AI模型响应。

然而，我们观察到AI模型间歇性地尝试建立互联网连接，触发了我的防病毒Web安全功能的警报。

本地Ollama应用程序提供AI响应生成，即使在阻止互联网连接的情况下也能可靠工作。具体来说，它在生产环境中使用Ollama与gemma:7b，运行在没有互联网访问的Ubuntu服务器上。

对于偏好AI SaaS服务的用户，我通过Perplexity的API网关实现了对llama-3.1-sonar-small-128k-online模型的访问。应用程序的架构包括一个AIService接口，带有generateResponse()方法，由OllamaService和OpenAiService实现。使用ai.provider=openai参数在application.properties中选择首选的AI服务。

以下流程图可能有助于可视化这一过程。

为了增强数据安全性和控制，我们进行了数据传输的详细分析。目标是简化配置，确定哪些数据发送，哪些数据被屏蔽。实施的技术包括用代理值替换原始值，并提供选择性包含或排除数据传输的选项。这允许在数据处理中具有更大的灵活性和安全性。

VI. 准备有效的提示

在可观测性领域，仅解释警报是不够的。关联是必不可少的。如“使用Ollama处理提示”（第IV节）所示，它展示了GenAI幻觉的局限性，简单的警报解释是无效的。

为了生成有意义的事件报告，我们必须提供相关数据来增强我们的提示。大多数监控解决方案通过API或CLI暴露其数据。我建议使用四个API调用来满足这一需求的提示准备：

1. 检索目标环境中引发的警报历史：提供所有警报记录及其参数。
2. 检索测量的历史数据：提供引发警报的测量趋势。
3. 检索测量的详细诊断：提供额外数据来证明警报的合理性。例如，当CPU利用率增加时，这揭示了哪些进程消耗了CPU周期。
4. 检索组件的实时测量：提供为有问题的服务器、应用程序或网络设备收集的所有其他指标。这是关联中的关键参数。例如，如果数据库服务器难以应对，我们需要大量指标点——如等待类型、等待时间、错误日志、用户进程、客户端进程和顶级查询——来确定根本原因。产品已经为此提供了KPI分析报告。即使没有GenAI，电子邮件也包含警报解释。但本练习的目的是将GenAI功能与相同数据集成并自动化它。

考虑到这一点，让我们检查一个使用包含来自这四个API输入的提示生成的事件报告。报告在下一节提供。

一个示例事件报告

今天早上有一个关于Linux服务器CPU利用率的警报。

以下是AI服务准备事件报告的响应：

通过Perplexity API从OpenAI的响应

CPU利用率警报的全面分析

趋势分析

摘要： localhost.localdomain上的CPU利用率在过去一小时内经历了显著飙升。数据显示CPU利用率稳步增加，最终在06:31触发严重警报。

平均和最大CPU利用率：

• 平均CPU利用率： 过去一小时的平均CPU利用率约为10.5%（根据给定数据点计算）。
• 最大CPU利用率： 最大CPU利用率在06:31达到100%，表明严重的CPU争用。

趋势描述： 过去一小时的趋势可以描述如下：

• CPU利用率在05:36从0%开始。
• 逐渐增加到1%并保持到05:46。
• 在06:01有一个轻微飙升到4%。
• CPU利用率然后在06:06急剧增加到13%。
• 多次下降到0%，直到06:31的关键飙升达到100%。

结论： 在关键警报之前，CPU利用率有持续增加的趋势，伴有显著飙升和下降。最终的关键飙升表明严重的CPU争用。

根本原因识别

详细诊断： 详细诊断数据表明以下进程导致高CPU利用率：

• ollama： ollama进程在06:31消耗了100%的CPU。
• top： top进程在06:31额外消耗了25%的CPU。
• kworker/2:2-events： 一个内核工作进程在06:31消耗了1.55%的CPU。

与时间序列数据的关联： 时间序列数据显示，CPU利用率保持稳定，直到06:31急剧增加到100%。这与ollama进程消耗100%的CPU相关，表明它是高CPU利用率的主要贡献者。

建议

立即行动：

1. 识别并终止主导进程：
   • ollama进程被识别为高CPU利用率的主要原因。应立即采取行动识别并终止此进程，如果它对系统操作不关键。
2. 检查资源密集型程序：
   • 审查系统上运行的其他进程，确定是否有任何其他应用程序消耗大量CPU资源。
3. 监控系统日志：
   • 检查系统日志，查看是否有与ollama进程或其他资源密集型应用程序相关的错误消息。

长期解决方案：

1. 实施CPU监控：
   • 确保持续的CPU监控，以便及时检测此类飙升。
2. 资源优化：
   • 优化资源分配，以防止未来发生高CPU利用率。
3. 定期维护：
   • 定期审查系统性能并优化资源使用，以避免未来警报。

eG Enterprise Suite模块建议

监控应用程序模型： 为了有效监控和管理CPU利用率，以下eG Enterprise Suite监控应用程序可能有益：

• 系统详情测试： 此测试提供系统健康的全面详情，包括CPU利用率。
• 进程详情测试： 此测试提供运行进程的详细信息，包括它们的CPU使用情况。
• 内存详情测试： 此测试有助于监控内存利用率，可以与CPU使用情况关联以识别潜在瓶颈。

好处： 这些监控模型将通过以下方式为解决当前CPU利用率问题提供直接价值：

• 识别贡献进程。
• 提供趋势分析的历史数据。
• 提供实时监控能力以检测未来发生。

输出格式

趋势分析：

• CPU利用率趋势： CPU利用率经历了持续增加，导致关键飙升。
• 平均CPU利用率： 10.5%
• 最大CPU利用率： 100%
• 趋势描述： 逐渐增加伴有轻微飙升和下降，最终在06:31关键飙升。

根本原因识别：

• 主要原因： ollama进程消耗了100%的CPU。
• 其他贡献进程： top和kworker/2:2-events进程也消耗了显著的CPU资源。

建议：

1. 立即行动： 识别并终止ollama进程。
2. 检查资源密集型程序： 审查其他进程的显著