监控 on 技术博客

AI Observability Agent：大模型时代的监控利器

Sat, 11 Apr 2026 11:00:00 +0800

用 Rust 构建的高性能 AI 可观测性平台，让 AI 成本、性能、质量一目了然

项目简介

Prometheus Agent 是什么？

Prometheus Agent（又名 AI Observability Agent）是一个使用 Rust 实现的高性能监控数据采集与上报代理。它不仅继承了传统监控代理的所有能力，还专门针对 AI/LLM 时代的需求进行了深度优化。

┌─────────────────────────────────────────────────────────────────┐
│                    AI Observability Agent                        │
├─────────────────────────────────────────────────────────────────┤
│  传统监控能力              │           AI 专属能力              │
│  ─────────────             │           ─────────────            │
│  • 系统指标采集            │           • OTLP 协议接收          │
│  • 服务指标抓取            │           • AI 专用采集器          │
│  • Remote Write 上报       │           • 成本追踪引擎          │
│  • 多端点故障转移          │           • 质量监控系统          │
└─────────────────────────────────────────────────────────────────┘

为什么需要 AI Observability Agent？

在大模型时代，企业和开发者面临着全新的监控挑战：

AI 采集器：Claude Code、OpenAI、LiteLLM 监控

Sat, 11 Apr 2026 11:00:00 +0800

深入了解 AI Observability Agent 的 AI 专用采集能力

AI 监控的挑战

在大模型时代，企业和开发者面临着独特的监控挑战：

挑战	传统监控的局限	AI 采集器的解决
多源数据	各 AI 工具指标格式不统一	统一采集接口
成本透明	无法追踪 AI API 调用成本	实时成本计算
Token 监控	不支持 Token 维度分析	细粒度 Token 统计
质量评估	缺少 AI 服务质量指标	响应时间、错误率监控
平台差异	不同 AI 平台接口不同	统一抽象层

内置 AI 采集器

AI Observability Agent 提供了多种 AI 专用采集器，覆盖主流 AI 平台：

1. OpenAI Usage API 采集器

功能：从 OpenAI Usage API 采集使用数据

配置示例：

ai_collectors:
  enabled: true
  
  openai:
    - name: openai_usage
      enabled: true
      api_key: ${OPENAI_API_KEY}      # OpenAI API Key
      org_id: ${OPENAI_ORG_ID}        # 组织 ID（可选）
      scrape_interval_secs: 3600      # 采集间隔（默认 1 小时）
      labels:
        source: openai
        environment: production

采集的指标：

Grafana 可视化：开箱即用的监控面板

Sat, 11 Apr 2026 11:00:00 +0800

深入了解 AI Observability Agent 的 Grafana Dashboard，实现 AI 监控数据的可视化

预置 Dashboard 介绍

AI Observability Agent 提供了预置的 Grafana Dashboard，开箱即用，无需手动配置。

1. AI Observability Dashboard

文件：dashboards/ai-observability.json

功能：全面监控 AI 服务的成本、Token 使用、请求延迟等指标。

包含面板：

每日成本统计：显示每日 AI API 成本
最近一小时请求数：显示最近一小时的请求量
按模型的每小时成本趋势：展示各模型的成本变化
按模型的 Token 使用趋势：展示输入/输出 Token 使用情况
请求延迟分布：P95/P99 延迟统计
成本分布饼图：按模型/提供商的成本分布
按提供商的请求分布：各 AI 提供商的请求占比

2. Claude Code Dashboard

文件：dashboards/claude-code-dashboard.json

功能：专门监控 Claude Code 的开发效率和使用情况。

包含面板：

24小时会话数：显示最近 24 小时的会话数量
Claude Code 成本：显示 Claude Code 的使用成本
Token 使用量：输入/输出 Token 的使用趋势
按模型的成本趋势：各模型的成本变化
生成的代码行数：Claude Code 生成的代码量
PR 统计：Pull Request 数量统计

导入方法

方法一：通过 UI 导入

打开 Grafana UI：访问 Grafana 网页界面（默认 http://localhost:3000）
导航到 Dashboards：点击左侧菜单的 “Dashboards”
点击 Import：在 Dashboards 页面点击 “Import” 按钮
上传 JSON 文件：点击 “Upload JSON file”，选择对应的 Dashboard JSON 文件
选择数据源：在 “Prometheus” 下拉菜单中选择你的 Prometheus 数据源
点击 Import：完成导入

方法二：通过 API 导入

步骤：

OTLP 协议支持：OpenTelemetry 原生集成

Sat, 11 Apr 2026 11:00:00 +0800

深入了解 AI Observability Agent 的 OpenTelemetry 集成能力

OpenTelemetry 简介

什么是 OpenTelemetry？

OpenTelemetry（简称 OTel）是一个开源的可观测性框架，提供了统一的标准和工具集，用于生成、收集和导出遥测数据（指标、日志、追踪）。

核心价值：

标准化：统一的遥测数据格式和采集标准
可扩展：丰富的插件生态系统
厂商中立：支持多种后端存储
跨语言：支持多种编程语言

OpenTelemetry Protocol (OTLP)

OTLP 是 OpenTelemetry 的标准数据传输协议，定义了遥测数据如何在不同组件之间传输。

协议版本：v1.0+ 传输方式：

gRPC：高性能二进制协议，默认端口 4317
HTTP/JSON：基于 HTTP 的文本协议，默认端口 4318

OTLP 协议详解

1. gRPC 接收器

AI Observability Agent 通过 gRPC 协议接收 OTLP 指标：

配置：

otlp:
  enabled: true
  grpc_endpoint: 0.0.0.0:4317  # gRPC 监听地址

技术实现：

使用 tonic crate 实现 gRPC 服务
实现 collector.metrics.v1.MetricsService/Export 方法
异步处理请求，支持高并发

性能特性：

二进制协议，传输效率高
支持流式传输
适合高吞吐量场景
支持 TLS 加密

2. HTTP 接收器

Agent 同时支持 HTTP 协议接收 OTLP 指标：

Remote Write：高效数据推送

Sat, 11 Apr 2026 11:00:00 +0800

深入了解 AI Observability Agent 的 Remote Write 功能，实现高效可靠的数据推送

Prometheus Remote Write 协议

协议概述

Prometheus Remote Write 是 Prometheus 生态系统中的一种数据传输协议，用于将监控数据从采集器推送到存储后端。

核心特点：

基于 HTTP：使用 HTTP POST 请求
Protobuf 编码：高效的二进制编码
Snappy 压缩：减小传输体积
批量发送：提高传输效率

协议版本

版本：0.1.0
Content-Type：application/x-protobuf
Content-Encoding：snappy
X-Prometheus-Remote-Write-Version：0.1.0

兼容的存储后端

存储后端	兼容性	特点
Prometheus	✅ 完全兼容	原生支持
VictoriaMetrics	✅ 完全兼容	高性能时序数据库
Cortex	✅ 完全兼容	可扩展的 Prometheus 水平扩展方案
Mimir	✅ 完全兼容	Grafana 开源的 Prometheus 兼容存储
Thanos	✅ 完全兼容	高可用 Prometheus 方案
InfluxDB	✅ 兼容（需适配器）	时间序列数据库

数据编码流程

1. 数据准备

Sample 收集：从采集器和抓取器收集 Sample 数据
数据聚合：按 metric_name + labels 分组
标签处理：添加 __name__ 标签，排序标签

2. Protobuf 编码

使用 prost 库进行 Protobuf 编码：

快速开始：5分钟部署指南

Sat, 11 Apr 2026 11:00:00 +0800

快速部署和使用 AI Observability Agent 的完整指南

环境准备

系统要求

平台	最低配置	推荐配置
Linux	1 CPU, 512MB RAM	2 CPU, 1GB RAM
macOS	1 CPU, 512MB RAM	2 CPU, 1GB RAM
Windows	1 CPU, 1GB RAM	2 CPU, 2GB RAM

软件要求

Rust 1.70+（仅用于从源码构建）
Prometheus 2.33+（用于接收 Remote Write 数据）
Grafana 9.0+（用于可视化，可选）

网络要求

端口	用途	说明
9090	HTTP 服务	Agent 自身的 HTTP 服务
4317	OTLP gRPC	OpenTelemetry gRPC 接收器
4318	OTLP HTTP	OpenTelemetry HTTP 接收器

快速部署

1. 二进制部署

步骤 1：下载二进制文件

成本追踪：AI API 成本计算与预算管理

Sat, 11 Apr 2026 11:00:00 +0800

全面了解 AI Observability Agent 的成本追踪系统，实现 AI 支出的透明化管理

AI 成本监控的重要性

在大模型时代，AI API 调用成本已经成为企业的重要支出项。有效的成本监控可以：

1. 成本透明化

实时了解支出：实时掌握 AI API 调用成本
识别成本异常：及时发现异常的成本增长
优化资源分配：基于成本数据调整资源分配

2. 预算控制

设置预算限制：避免超支风险
阈值告警：预算接近限额时及时提醒
成本预测：基于历史数据预测未来支出

3. 决策支持

模型选择：基于成本效益分析选择合适的模型
使用模式优化：识别并优化高成本使用模式
ROI 分析：评估 AI 投资回报率

内置定价表

AI Observability Agent 内置了主流 AI 模型的定价数据，确保成本计算的准确性。

支持的模型列表

模型	提供商	输入成本 ($/1K tokens)	输出成本 ($/1K tokens)
claude-3-opus	anthropic	0.015	0.075
claude-3-sonnet	anthropic	0.003	0.015
claude-3-haiku	anthropic	0.00025	0.00125
gpt-4o	openai	0.005	0.015
gpt-4-turbo	openai	0.01	0.03
gpt-3.5-turbo	openai	0.0005	0.0015
o1	openai	0.015	0.06
o1-mini	openai	0.003	0.012
llama3-70b	meta	0.001	0.002
gemini-1.5-pro	google	0.0035	0.0105

定价数据来源

官方文档：各 AI 提供商的官方定价页面
API 响应：从 API 响应中获取实际定价
社区维护：定期更新定价数据

自定义定价

支持用户自定义模型定价：

插件系统：灵活扩展采集能力

Sat, 11 Apr 2026 11:00:00 +0800

深入了解 AI Observability Agent 的插件系统，通过插件扩展采集能力

插件架构设计

AI Observability Agent 的插件系统采用灵活的插件架构，允许用户通过插件扩展采集能力：

核心设计

插件接口：统一的插件接口
动态加载：运行时动态加载插件
并发执行：插件并发执行，互不影响
错误隔离：单个插件失败不影响其他插件
生命周期管理：插件的启动、停止、重启

插件类型

插件类型	数据源	适用场景
HTTP 插件	HTTP 端点	从 HTTP 服务获取指标
Exec 插件	命令输出	执行命令获取指标
Script 插件	脚本输出	执行脚本获取指标

插件架构图

┌─────────────────────────────────────────────────────────┐
│                  Plugin System                         │
├─────────────────────────────────────────────────────────┤
│  ┌─────────────────┐  ┌─────────────────┐  ┌───────────┐ │
│  │ HTTP 插件       │  │ Exec 插件       │  │ Script 插件│ │
│  └────────┬────────┘  └────────┬────────┘  └────┬──────┘ │
│           │                    │                 │        │
│           └────────────────────┼─────────────────┘        │
│                                │                         │
│  ┌─────────────────────────────────────────────────────┐ │
│  │                 Plugin Manager                     │ │
│  │  - 插件生命周期管理                                │ │
│  │  - 插件配置管理                                    │ │
│  │  - 插件执行调度                                    │ │
│  └─────────────────────────────────────────────────────┘ │
│                                │                         │
│  ┌─────────────────────────────────────────────────────┐ │
│  │                 Metrics Pipeline                    │ │
│  │  - 指标解析                                        │ │
│  │  - 标签处理                                        │ │
│  │  - 数据推送                                        │ │
│  └─────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘

HTTP 插件

功能

HTTP 插件从 HTTP 端点获取 Prometheus 格式的指标。

本地持久化：网络故障数据保护

Sat, 11 Apr 2026 11:00:00 +0800

深入了解 AI Observability Agent 的本地持久化机制，确保网络故障时数据不丢失

为什么需要本地持久化

在监控系统中，网络故障是常见的问题。当网络中断时，监控数据可能会丢失，导致监控空白期。本地持久化机制可以解决这个问题：

核心价值

数据不丢失：网络故障时数据持久化到磁盘
自动恢复：网络恢复后自动重发数据
容错能力：提高系统可靠性
数据完整性：保证监控数据的连续性

应用场景

网络不稳定环境：网络连接不稳定的场景
远程部署：部署在边缘节点的场景
高可靠性要求：对数据完整性要求高的场景
批量数据处理：需要批量处理数据的场景

持久化机制

工作原理

┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│  数据采集       │────→│  数据缓冲       │────→│  网络发送       │
└─────────────────┘     └─────────────────┘     └────────┬────────┘
                                                      │
                                                      ↓
                                             ┌─────────────────┐
                                             │  本地持久化     │
                                             │  (磁盘存储)     │
                                             └─────────────────┘
                                                      │
                                                      ↓
┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│  远程存储       │←────│  数据恢复       │←────│  网络检测       │
└─────────────────┘     └─────────────────┘     └─────────────────┘

数据写入流程

数据采集：采集器和抓取器收集数据
数据缓冲：数据进入 Batcher 缓冲区
网络发送：尝试发送数据到远程存储
失败处理：发送失败时将数据写入本地存储
文件管理：按时间和大小管理持久化文件

数据恢复流程

网络检测：定期检测网络连接状态
数据读取：网络恢复后读取本地存储的数据
数据重发：将读取的数据重新发送到远程存储
文件清理：成功发送后清理持久化文件
状态更新：更新持久化状态

配置说明

基本配置

remote_write:
  persistence:
    enabled: true                # 是否启用持久化
    data_dir: ./data/persistence # 数据存储目录
    max_file_size_mb: 100       # 单文件最大大小
    retention_hours: 24         # 数据保留时间
    flush_interval_secs: 30      # 刷新间隔
    max_retries: 5              # 最大重试次数

配置项详解

配置项	类型	默认值	说明
`enabled`	bool	false	是否启用本地持久化
`data_dir`	string	./data/persistence	数据存储目录
`max_file_size_mb`	u64	100	单个持久化文件的最大大小（MB）
`retention_hours`	u64	24	数据保留时间（小时）
`flush_interval_secs`	u64	30	数据刷新到磁盘的间隔（秒）
`max_retries`	u32	5	数据恢复时的最大重试次数

存储格式

文件结构

data/persistence/
├── 2024-04-11T10:00:00Z-000001.protobuf
├── 2024-04-11T10:30:00Z-000002.protobuf
├── 2024-04-11T11:00:00Z-000003.protobuf
└── metadata.json

文件命名规则

命名格式：{timestamp}-{sequence}.protobuf
timestamp：文件创建时间（UTC）
sequence：递增序号
文件格式：Protobuf 编码的 WriteRequest

元数据文件

{
  "last_flush": "2024-04-11T10:30:00Z",
  "total_files": 3,
  "total_size_mb": 150.5,
  "last_recovery": "2024-04-11T09:00:00Z"
}

性能影响

磁盘使用

存储容量：根据 max_file_size_mb 和 retention_hours 计算
磁盘 I/O：定期写入和读取操作
文件数量：按时间分割的文件数量

内存使用

缓冲区大小：与 Batcher 容量相关
恢复过程：数据恢复时的内存使用
并发处理：多文件并发处理

恢复速度

网络带宽：网络恢复后的发送速度
数据量：需要恢复的数据量
并发发送：分片并发发送能力

最佳实践

1. 配置最佳实践

存储目录：

架构设计：高性能、可扩展的监控架构

Sat, 11 Apr 2026 11:00:00 +0800

深入了解 AI Observability Agent 的系统架构和设计理念

整体架构图

┌─────────────────────────────────────────────────────────────────────────────┐
│                              AI Observability Agent                          │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│  ┌─────────────────┐  ┌─────────────────┐  ┌─────────────────────┐  ┌───────┐ │
│  │ 系统采集器      │  │ 服务抓取器      │  │ OTLP 接收器        │  │ 插件  │ │
│  │ System Collectors│  │ Service Scrapers│  │ (gRPC/HTTP)        │  │ 系统  │ │
│  └────────┬────────┘  └────────┬────────┘  └────────┬────────────┘  └──┬────┘ │
│           │                    │                     │                   │      │
│           └────────────────────┼─────────────────────┼───────────────────┘      │
│                                │                     │                            │
│  ┌─────────────────────────────────────────────────────────────────────────────┐ │
│  │                          数据处理层                                          │ │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────────┐  ┌────────┐ │ │
│  │  │ 指标转换    │  │ 成本计算    │  │ 质量评估               │  │ 缓存   │ │ │
│  │  │ (OTLP→Prom) │  │ 引擎        │  │ (规则引擎)             │  │ 批处理 │ │ │
│  │  └─────────────┘  └─────────────┘  └─────────────────────────┘  └────────┘ │ │
│  └─────────────────────────────────────────────────────────────────────────────┘ │
│                                │                     │                            │
│  ┌─────────────────────────────────────────────────────────────────────────────┐ │
│  │                          数据上报层                                          │ │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────────┐  ┌────────┐ │ │
│  │  │ Remote      │  │ 重试策略    │  │ 多端点故障转移         │  │ 本地   │ │ │
│  │  │ Write 客户端 │  │ (指数退避)  │  │ (健康检查)             │  │ 持久化 │ │ │
│  │  └─────────────┘  └─────────────┘  └─────────────────────────┘  └────────┘ │ │
│  └─────────────────────────────────────────────────────────────────────────────┘ │
│                                │                     │                            │
└────────────────────────────────┼─────────────────────┼────────────────────────────┘
                                 ↓                     ↓
                          Prometheus/VictoriaMetrics  磁盘存储

核心模块介绍

1. 数据采集层

1.1 系统采集器 (System Collectors)

系统采集器负责采集主机或容器的系统指标：

质量监控：AI 服务质量评估

Sat, 11 Apr 2026 11:00:00 +0800

深入了解 AI Observability Agent 的质量监控系统，确保 AI 服务的稳定性和可靠性

AI 服务质量评估维度

在大模型时代，AI 服务的质量评估需要考虑多个维度：

维度	说明	重要性
响应时间	AI 服务的响应速度	⭐⭐⭐⭐⭐
Token 效率	输入/输出 Token 比率	⭐⭐⭐⭐
错误率	API 调用失败的比例	⭐⭐⭐⭐⭐
吞吐量	单位时间处理的 Token 数	⭐⭐⭐
一致性	相同输入的输出一致性	⭐⭐⭐
准确性	输出结果的准确程度	⭐⭐⭐⭐

AI Observability Agent 的质量监控系统针对这些维度提供了全面的监控能力。

规则引擎

质量监控系统基于规则引擎，支持多种类型的质量规则：

1. 响应时间规则

功能：监控 AI 服务的响应时间

配置示例：

quality_monitoring:
  rules:
    - name: high_latency
      type: response_time
      enabled: true
      threshold: 5000              # 阈值（毫秒）
      max_value: 30000             # 最大允许值
      severity: warning            # 严重程度：info, warning, critical
      weight: 1.0                  # 权重（用于计算总分）

评估逻辑：

计算平均响应时间
与阈值比较
超过阈值触发告警

指标：ai_request_latency_seconds