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

引言

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

该项目使用了两种AI模型：针对本地用户的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

下载并安装Ollama：
- 访问Ollama网站。
- 点击“Download”按钮，选择Windows版本。
- 按照屏幕指示安装应用程序。
验证Ollama服务器状态：
- 安装后，Ollama应自动启动。可通过检查任务栏确认，应出现Ollama图标（白色图标）。
在浏览器中确认Ollama运行：
- 打开浏览器（如Chrome、Firefox、Edge）并导航至http://localhost:11434/。
- 应看到响应：Ollama is running。
配置命令行访问Ollama：
- 打开提升的命令提示符（以管理员身份运行）。
- 在系统的PATH环境变量中设置Ollama安装文件夹，以便从任何目录运行Ollama命令：
  1
  
  set PATH=%PATH%;C:\Users\<your_username>\AppData\Local\Programs\Ollama
- 重要：将<your_username>替换为实际的Windows用户名。
（可选）使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。
命令提示符中应显示进度指示器，成功消息表示模型已正确下载和安装。

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模型间歇性尝试建立互联网连接，触发了我的杀毒软件网络安全功能警报。
本地Ollama应用程序提供AI响应生成，即使在阻止互联网连接的情况下也能可靠工作。具体来说，它在生产环境中使用Ollama与gemma:7b，运行在无互联网访问的Ubuntu服务器上。
对于偏好AI SaaS服务的用户，我通过Perplexity的API网关实现了对llama-3.1-sonar-small-128k-online模型的访问。应用程序架构包括一个AIService接口，带有generateResponse()方法，由OllamaService和OpenAiService实现。首选AI服务通过application.properties中的ai.provider=openai参数选择。
以下流程图可帮助可视化此过程。
为增强数据安全性和控制，我们进行了数据传输的详细分析。目标是简化配置，确定哪些数据发送、哪些数据掩码。实施的技术包括用代理值替换原始值，并提供选择性包含或排除数据传输的选项。这允许在数据处理中具有更大的灵活性和安全性。

VI. 准备有效提示

在可观测性领域，仅解释警报是不够的。关联至关重要。如处理提示与Ollama（第IV节）所示，展示了生成式AI幻觉的局限性，简单的警报解释是无效的。
为生成有意义的事件报告，我们必须提供相关数据以增强提示。大多数监控解决方案通过API或CLI暴露其数据。我建议使用四个API调用来准备此需求的提示：
1. 检索目标环境中引发的警报历史：提供所有警报记录及其参数。
2. 检索测量的历史数据：提供引发警报的测量趋势。
3. 检索测量的详细诊断：提供额外数据以证明警报合理性。例如，当CPU利用率增加时，这会揭示哪些进程消耗了CPU周期。
4. 检索组件的实时测量：提供为问题服务器、应用程序或网络设备收集的所有其他指标。这是关联中的关键参数。例如，如果数据库服务器难以应对，我们需要众多指标点——如等待类型、等待时间、错误日志、用户进程、客户端进程和顶级查询——以确定根本原因。产品已为此提供KPI分析报告。即使没有生成式AI，电子邮件也包含警报解释。但此实践的目的是将生成式AI能力与相同数据集成并自动化。
考虑到这一点，让我们检查使用包含这四个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利用率的主要贡献者。

建议

立即行动：

识别并终止主导进程：
- ollama进程被识别为高CPU利用率的主要原因。应立即行动识别并终止此进程，如果它对系统操作不关键。
检查资源密集型程序：
- 审查系统上运行的其他进程，确定是否有任何其他应用程序消耗显著CPU资源。
监控系统日志：
- 检查系统日志，查看是否有与ollama进程或其他资源密集型应用程序相关的错误消息。 长期解决方案：
实施CPU监控：
- 确保连续CPU监控到位，以及时检测此类峰值。
资源优化：
- 优化资源分配，防止未来高CPU利用率发生。
定期维护：
- 定期审查系统性能并优化资源使用，避免未来警报。

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资源。 建议：

立即行动： 识别并终止ollama进程。
检查资源密集型程序： 审查其他进程的显著CPU使用。
监控系统日志： 检查与资源密集型应用程序相关的错误消息。 eG Enterprise Suite模块建议：
系统详情测试： 全面系统健康监控。
进程详情测试： 详细进程信息包括CPU使用。
内存详情测试： 关联内存和CPU使用以优化。

通过Ollama与Gemma模型的响应

趋势分析： 过去一小时，CPU利用率稳步增加，约30分钟前略有下降。此期间的平均CPU利用率约为72.115%，而最大达到85.421%。似乎没有一致趋势；相反，出现多个短暂CPU利用率峰值，可能表明间歇性系统过载或资源密集型进程并发运行。 根本原因识别： 基于详细诊断数据，我识别以下导致高CPUutilization的因素：

系统进程： 几个系统进程持续消耗高CPU资源，ollama.service。这些可能导致不必要开销。
资源密集型程序： 一个或多个资源密集型程序并发运行，可能贡献增加的CPU负载。这些可能是应用程序、服务或脚本，未针对性能优化。 建议： 减轻此CPU利用率