AI Observability

用 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 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 采集的指标： ...

深入了解 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 导入 步骤： ...

深入了解 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 指标： ...

深入了解 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 编码： ...

快速部署和使用 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 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 响应中获取实际定价 社区维护：定期更新定价数据 自定义定价 支持用户自定义模型定价： ...

深入了解 AI Observability Agent 的插件系统，通过插件扩展采集能力 插件架构设计 AI Observability Agent 的插件系统采用灵活的插件架构，允许用户通过插件扩展采集能力： 核心设计 插件接口：统一的插件接口 动态加载：运行时动态加载插件 并发执行：插件并发执行，互不影响 错误隔离：单个插件失败不影响其他插件 生命周期管理：插件的启动、停止、重启 插件类型 插件类型 数据源 适用场景 HTTP 插件 HTTP 端点 从 HTTP 服务获取指标 Exec 插件 命令输出 执行命令获取指标 Script 插件 脚本输出 执行脚本获取指标 插件架构图 ┌─────────────────────────────────────────────────────────┐ │ Plugin System │ ├─────────────────────────────────────────────────────────┤ │ ┌─────────────────┐ ┌─────────────────┐ ┌───────────┐ │ │ │ HTTP 插件 │ │ Exec 插件 │ │ Script 插件│ │ │ └────────┬────────┘ └────────┬────────┘ └────┬──────┘ │ │ │ │ │ │ │ └────────────────────┼─────────────────┘ │ │ │ │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ Plugin Manager │ │ │ │ - 插件生命周期管理 │ │ │ │ - 插件配置管理 │ │ │ │ - 插件执行调度 │ │ │ └─────────────────────────────────────────────────────┘ │ │ │ │ │ ┌─────────────────────────────────────────────────────┐ │ │ │ Metrics Pipeline │ │ │ │ - 指标解析 │ │ │ │ - 标签处理 │ │ │ │ - 数据推送 │ │ │ └─────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────┘ HTTP 插件 功能 HTTP 插件从 HTTP 端点获取 Prometheus 格式的指标。 ...

深入了解 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. 配置最佳实践 存储目录： ...

深入了解 AI Observability Agent 的系统架构和设计理念 整体架构图 ┌─────────────────────────────────────────────────────────────────────────────┐ │ AI Observability Agent │ ├─────────────────────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────────┐ ┌─────────────────┐ ┌─────────────────────┐ ┌───────┐ │ │ │ 系统采集器 │ │ 服务抓取器 │ │ OTLP 接收器 │ │ 插件 │ │ │ │ System Collectors│ │ Service Scrapers│ │ (gRPC/HTTP) │ │ 系统 │ │ │ └────────┬────────┘ └────────┬────────┘ └────────┬────────────┘ └──┬────┘ │ │ │ │ │ │ │ │ └────────────────────┼─────────────────────┼───────────────────┘ │ │ │ │ │ │ ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ 数据处理层 │ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────────────────┐ ┌────────┐ │ │ │ │ │ 指标转换 │ │ 成本计算 │ │ 质量评估 │ │ 缓存 │ │ │ │ │ │ (OTLP→Prom) │ │ 引擎 │ │ (规则引擎) │ │ 批处理 │ │ │ │ │ └─────────────┘ └─────────────┘ └─────────────────────────┘ └────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ │ │ │ │ │ │ ┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ 数据上报层 │ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────────────────┐ ┌────────┐ │ │ │ │ │ Remote │ │ 重试策略 │ │ 多端点故障转移 │ │ 本地 │ │ │ │ │ │ Write 客户端 │ │ (指数退避) │ │ (健康检查) │ │ 持久化 │ │ │ │ │ └─────────────┘ └─────────────┘ └─────────────────────────┘ └────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ │ │ │ │ │ └────────────────────────────────┼─────────────────────┼────────────────────────────┘ ↓ ↓ Prometheus/VictoriaMetrics 磁盘存储 核心模块介绍 1. 数据采集层 1.1 系统采集器 (System Collectors) 系统采集器负责采集主机或容器的系统指标： ...