问题意识

在运营集群时经常会发生错误，每次都需要检查和分析日志来寻找错误的原因，甚至有时无法检测到错误。此外，个人在运营集群的同时又要进行开发，时间效率下降的现象非常明显。

Meerkat项目是为解决此问题而启动的。我们认为，如果有一个可以智能分析和完美整理日志的AI代理，不需要手动查找，就能减少集群运营成本。

核心设计1：基于RAG的日志向量存储

Meerkat由Analyzer和Vectors两个服务组成。

Analyzer负责汇集数据以分析错误原因，Vectors则通过OpenTelemetry传输的日志存储为有意义的数据。

Vectors不仅仅是简单地存储日志。通过模板提取来去除OpenTelemetry中输入的日志的冗余，在通过嵌入模型进行向量化后，将其存储在像Milvus这样的向量数据库中。避免一个服务中出现重复的错误日志，并通过使用向量化数据显著提高检索效率。

graph LR
    subgraph "数据流"
        App[应用] -- OTLP 日志 --> Vectors
        Vectors -- 嵌入存储 --> Milvus[(Milvus)]
        Analyzer -- 语义搜索 --> Vectors
    end

核心设计2：基于工具的Metrics/Logs分析

Analyzer采用了类似OpenCode/Claude等代码代理工具的概念来自动分析错误原因。通过与Vectors、Prometheus等外部依赖通信，制作接口以便在循环中动态调查原因。

sequenceDiagram
    participant User as 用户
    participant Analyzer as Analyzer
    participant LLM as LLM
    participant Tools as 工具

    User->>Analyzer: 分析请求
    Analyzer->>LLM: 上下文+可用工具列表

    loop 代理循环
        LLM-->>Analyzer: 调用工具或提供最终答案

        alt 调用工具
            Analyzer->>Tools: Prometheus/Loki/Vectors 查询
            Tools-->>Analyzer: 结果
        else 最终答案
            Analyzer-->>User: 分析完成
        end
    end

运营环境的考虑

由于系统特性，Analyzer可能会在短期内因每个应用程序发送的错误和重复错误而收到大量请求。因此，当以单台服务器的同步请求来处理时，可能会出现吞吐量下降、超时等问题。

我们希望通过使用工作池来解决这个问题。通过并行处理提高处理效率，并防止所有并行任务等待LLM响应这一致命问题。从可扩展性来看，即使扩展多个Analyzer，工作池也能在服务前端调节处理，达到自然扩展的效果。

改进的余地

在制作Meerkat的同时，我们努力保持日志监控服务的特点，同时实现与外部基础设施服务的松散耦合。尽管如此，由于OpenTelemetry、Prometheus、Loki、ELK等各自有不同的责任、协议及请求/响应模式，使得在多种环境中应用困难。因此，未来需对各种规格进行更新，致力于实现适用于多种基础设施服务和环境的目标。

此外，在日志或指标搜索中，所需的语法有时各不相同或相对复杂。我们认为，为代理创建更清晰的结构化工具系统，让代理易于理解是非常重要的。

结束语

这是一个在考虑诸多外部服务时进行的项目，目前项目的形态尚不稳定。然而，创立和运用Meerkat服务的过程中，我们显著提高了基础设施运营效率。通过解决直接分析日志和对原因的识别过程，也验证了基于AI代理的基础设施运营系统的潜力。