作者来自 Elastic Daniela TzvetkovaElastic 中的 OpenAI 速率限制监控会在每个项目和模型之间映射 “余量headroom”。将已配置的 RPM、TPM 和 IPM 限制与实际使用情况进行对比并在 throttling限流告警触发之前提前规划容量。Elastic 的 OpenAI 集成 现在每五分钟轮询一次速率限制并将其与每个项目和模型的实际使用情况进行对比。你可以在 OpenAI 触发 HTTP 429 之前看到 RPM、TPM 和 IPM 的 headroom余量。当单分钟峰值利用率在连续三次检查中超过你配置的限制的 80% 时会触发一个预构建告警并按项目和模型分组因此某个团队的流量突增不会被组织级平均值掩盖。OpenAI 在项目级别配置这些限制并且上限被限制在或低于组织整体上限。这意味着单个“噪声”项目可能会耗尽自己的配额而组织内其他部分仍然有余量但在此之前这些 headroom 是不可见的直到真正用完。大多数团队第一次发现自己的 OpenAI 项目接近速率限制是在生产流量开始因 HTTP 429 响应而被 throttled限流的时候。OpenAI 在项目级别强制执行速率限制而不是在组织级别因此某个项目中的单一高负载工作流就可能会耗尽该项目的 RPM 或 TPM 上限而组织的其他部分仍然有大量剩余容量。如果没有 OpenAI rate limit 监控来将配置的限制与实际消耗进行对比那么 headroom余量在耗尽之前是不可见的。Elastic 中的 OpenAI API 监控有什么新变化我们很高兴宣布 Elastic OpenAI 集成 的更新。在现有 token 使用量和审计日志覆盖之上该集成现在会按项目轮询 OpenAI 的 List project rate limits Admin API并将结果汇总到项目级和组织级视图中。一个新的 openai.rate_limits 数据集驱动两个新的 dashboard 面板和一个预构建阈值告警规则使团队能够在用户感知到生产影响之前看到每个项目和模型距离被 throttled限流有多近。该集成监控的内容Usage、Audit Logs 和 Rate Limits APIsElastic OpenAI 集成面向在 OpenAI API 平台上运行应用的团队。这些责任人包括开发这些服务的开发者、负责稳定性的 platform 和 SRE 团队以及回答“我们的软件消耗了多少是否在容量边界内”的财务与 FinOps 负责人。该集成从三个 OpenAI Admin API 接口面获取数据Usage API用于统计 token、字符、秒、会话、字节和图像等使用量并在该 Usage API 提供的范围内按项目、模型、用户和 API key 进行归因。Audit Logs API用于记录组织审计事件例如 API key 创建、项目变更和用户活动。Rate Limits API用于获取每个项目和模型的 RPM、TPM 和 IPM 上限以及其他可用的限制维度新的 headroom 视图将每分钟请求、token 和图像限制与实际消耗进行对比。由于所有数据都是从组织级 Admin API 拉取的平台团队可以在 Elastic 中获得跨所有项目、模型和 API key 的统一视图并与他们已经监控的其他遥测数据一起展示而无需修改应用代码或在每个服务中安装 SDK。在使用 OpenAI API 时需要监控的内容运行 OpenAI API 生产工作负载的团队反复出现四类运维需求。Token 使用归因一个 OpenAI 组织通常会服务多个内部团队和产品每个团队都有自己的 project项目、不同模型组合用于最复杂推理任务的 GPT-5.5 Pro、用于日常流量的 GPT-5.4、用于高并发低成本请求的 GPT-5.4 nano以及用于图像、音频和 embeddings 的专用模型以及各自的 user 和 API key 使用分布。当使用模式发生变化时平台团队需要知道是哪个 project、model 和 key 导致了变化从而将消耗归因到正确的团队并决定哪些工作负载应该迁移到更便宜的模型。速率限制 headroom余量OpenAI 在 project 级别而不是 organization 级别对每个 model 强制执行每分钟请求数RPM和每分钟 token 数TPM的速率限制。团队第一次发现接近上限通常是在生产流量开始被 throttled限流的时候。将已配置的限制与实际消耗一起按 project 和 model 展示可以让平台团队提前看到 headroom余量提前规划容量并在用户感知影响之前申请提升限制。审计可见性安全与合规团队需要知道谁创建了 API key、谁修改了项目设置、谁邀请或移除了用户以及这些操作发生的时间。该集成会接入 OpenAI 的组织审计日志使这些事件与使用数据一起进入同一个 Elastic 部署中便于关联分析、告警和长期存储。审计日志接入有两个前提必须在 OpenAI 组织中启用 audit logging并且用于该集成的 Admin API key 必须属于 Organization Owner因为 OpenAI 将审计日志访问限制给该角色。如果缺少任一条件openai.audit 数据集将为空。面向所有角色的粒度同一份数据需要服务不同节奏的需求。SRE 需要分钟级精度来捕捉突发流量并触发限流告警。平台工程师需要小时级视图用于容量规划。财务与 FinOps 负责人需要日级汇总用于报表统计。一套统一的集成同时提供这三种粒度可以避免为不同团队维护多套独立数据管道。Elastic 如何轮询 OpenAI Admin API该集成运行在 Elastic Agent 上并使用 CEL input通用表达语言输入按照计划任务轮询 OpenAI 的 Admin API。认证使用单个 Admin API key并以加密形式存储在 Fleet secret 中同时在 agent 日志中会被脱敏。通过一套配置该集成会从三个 Admin API 数据源中采集数据Usage API 数据集按 project、model、user 和 API key 维度每个数据集对应 OpenAI 暴露的不同工作负载单位openai.completions用于 chat 和 completion 的 token 计数input、output、cached、audio input/output。openai.embeddings用于 embedding token 计数。openai.moderations用于 moderation token 计数。openai.images用于图片数量和尺寸维度。openai.audio_speeches用于文本转语音的字符计数。openai.audio_transcriptions用于语音转文本的时长秒。openai.code_interpreter_sessions用于 code interpreter 会话计数。openai.vector_stores用于 vector store 的字节数统计。Audit Logs API 数据集openai.audit记录组织级审计事件例如 API key 创建、项目变更和用户活动。Rate Limits API 数据集openai.rate_limits新增按 project 和 model 获取速率限制快照包括 RPM、TPM、IPM 以及 OpenAI 返回的其他限制字段并在每次轮询时遍历所有活跃项目分页获取。Ingest pipelines 会负责解析与字段映射使数据可以被查询、可用于 dashboard并与 Elastic Observability 的其他数据保持一致。由于所有数据都是从组织级 Admin API 拉取的因此无需应用侧埋点或 SDK 修改即可获得完整可见性。在 Elastic 中设置 OpenAI 监控需要什么要开始使用 Elastic OpenAI 集成需要一个 Elastic 部署Elastic Cloud HostedECH支持的较新版本或Elastic Cloud Serverless无需版本管理即开即用。一个具有 Admin API 访问权限的 OpenAI 组织。由 Organization Owner 创建的 Admin API key可在 OpenAI 平台设置中生成Settings → Admin keys。如果需要openai.audit数据集必须使用 Owner 级别 key。在 OpenAI 组织中启用 audit logging如果需要审计数据。在主机上安装 Elastic Agent并允许出站 HTTPS 访问api.openai.com或使用无代理部署选项。如何设置 OpenAI 集成在 OpenAI 平台设置中生成一个 Admin API keyOpenAI platform settings。在 Kibana 中进入Management → Integrations搜索OpenAI并点击Add。选择部署模式agentless零安装体验或在你自己的主机上使用Elastic Agent。如有需要可以调整默认配置。每个数据集都有合理默认值Usage 数据集每 5 分钟轮询一次使用 1 分钟 bucket。每个数据集提供一个finalization_grace设置用于控制一个按分钟划分的 usage bucket 何时被认为最终完成。默认0s更偏向实时性一分钟结束后 bucket 就会立即被采集。但实际观测结果OpenAI 未文档化但该集成团队通过对比线上 API 测得显示在高负载情况下 bucket 数值在该时间点之后仍可能继续增长因此在0s下的按分钟统计在高峰期间可能偏低。将finalization_grace设置为15m推荐用于更准确统计会让 bucket 在 grace 窗口结束后才被采集这样结果更接近 Usage API但在极高流量突发期间仍可能存在轻微低估因为 OpenAI 的按分钟计数可能在超过任何固定 grace 窗口后仍被修正上调。代价是 dashboard 和 rate limit headroom 告警会延迟 grace 时间。Rate limits每 5 分钟轮询一次。每次轮询会抓取每个 project 和 model 的完整 RPM、TPM 和 IPM 配置限制。Audit logs以独立节奏轮询并采集所有组织级事件。注意前提条件需要在 OpenAI 组织中启用 audit logging并使用 Organization Owner 的 Admin API key。在 Kibana 中打开 integration assets。几分钟内usage、audit 和 rate limit 数据就会开始流动预构建 dashboard 和告警规则也会准备就绪。完整配置参考见 OpenAI integration 文档。OpenAI rate limit dashboards 展示什么该集成提供一个预构建 Kibana dashboard让你可以立即查看组织级 OpenAI API 消耗情况。概览页会把核心指标总 tokens、总调用次数、top models、top projects、top users 以及 top API keys汇总在一个界面中快速反映当前 OpenAI 使用状态。下面截图展示 OpenAI usage overview dashboard从概览中你可以进一步进入更细的视图以回答前面提到的那些运维需求。按 model、project 和 user 的 token 使用情况Token 指标面板会按 model 和时间维度拆分 token 消耗input、output、cached input、audio input/output覆盖基于 token 的数据集openai.completions、openai.embeddings、openai.moderations。这个视图可以告诉你 token 预算实际流向哪里、哪些工作负载从 prompt caching 中获益最多以及哪些 projects、users 或 API keys 在驱动大部分 token 消耗。你可以按 project 或 model 进行筛选将视图收敛到单个团队或产品。图像、音频以及 vector store 的消耗以 images、characters、seconds、sessions 和 bytes 计量而不是 token会在同一 dashboard 的独立部分中展示。Token 指标面板如下所示速率限制 headroom按 project 和 model新增新的 rate limit headroom 面板会将openai.rate_limits中的已配置限制与 usage 数据集中的实际消耗进行对比并按project_id和model维度展示。对于每一行它都会展示峰值一分钟使用量、已配置的限制以及请求RPM、tokenTPM和图像IPM的利用率百分比。所有行会按 TPM 利用率从高到低排序在并列情况下以 RPM 和 IPM 利用率作为次级排序依据因此 token 压力最高的条目会出现在列表顶部。利用率是基于观察窗口内的峰值一分钟 bucket计算的而不是把 5 分钟或 15 分钟的数据汇总后再去对比 1 分钟上限因此这个面板反映的是“峰值分钟压力”对 1 分钟上限的真实冲击而不会被平均值稀释。按 project 展示的 rate limit headroom 面板如下速率限制 headroom按模型进行组织级汇总新增由于 OpenAI 是在 project 级别强制执行限制的单个 project 视图无法回答“整个组织在gpt-image-2上总共有多少容量”这个问题。新的组织级汇总面板会将所有活跃 projects 中的 RPM、TPM 和 IPM 指标按 model 汇总展示。对于每个 model它会把所有 projects 的限制与使用情况进行聚合。需要注意的是这里的 limit 和 usage 都只是近似的上限值而不是严格精确的组织级统计limit 是所有 project 级别上限的求和usage 是各个 project 的峰值一分钟使用量的求和而这些峰值可能发生在不同的时间窗口中因此它们并不是严格同一时间切片下的真实组织总量但组合起来可以为平台团队提供一个统一的规划基准用于评估新 workload 的容量需求或决定应该由哪个 project 来承载新的用例。组织级汇总面板如下在后台版本2.3.0还会将请求数和 token 数标准化到统一的openai.base.usage_tokens和openai.base.usage_images字段中覆盖所有 usage 数据集。这样即使只启用了部分 usage 数据集headroom 面板也能正确渲染。Elastic 中的 OpenAI 审计日志活动审计面板会展示组织级 audit 事件API key 创建、项目变更、用户邀请以及登录活动使安全与合规团队能够在同一 Elastic 数据中查看“谁在什么时间做了什么”并与 usage 数据一起进行关联分析。审计 dashboard 如下所示速率限制 headroom 的开箱即用告警新增该集成内置了一个预构建的阈值告警规则模板[OpenAI] Rate limit headroom low可以在 integration 的 Assets 标签页中一键安装。默认行为经过优化开箱即用每 5 分钟运行一次回溯最近 15 分钟数据连续 3 次匹配后触发当峰值一分钟 TPM 利用率达到或超过项目/模型限制的 80% 时触发按project_id::model分组告警避免单个项目、单个模型的异常被组织级聚合掩盖80% 阈值及其他参数在 Kibana 安装规则后都可以修改每个团队可以根据自身风险偏好进行调整。在 Elastic Observability 中自定义 OpenAI 告警与 SLO和所有 Elastic 集成一样所有 OpenAI 指标和审计数据都可以直接用于 Elastic Observability 的各类能力中包括SLOs、告警、自定义 dashboard以及日志深度分析。例如为控制单个 project 的 token 消耗可以创建一个自定义阈值规则对相关 usage 数据集中的 token 进行汇总当日或小时总量超过预算时触发告警。为追踪 model 使用结构可以在 Elastic Observability 中定义一个 SLO将使用你批准的低成本 model family 的 OpenAI 请求定义为“good events”将所有 OpenAI 请求定义为“total events”并按openai.base.project_id和openai.base.user_id分组。这样得到的比例就是 SLI设置 7 天滚动 80% 目标可以快速发现哪些 project 或 user 在过度使用更昂贵的模型OpenAI usage 数据粒度的选择集成采集的 OpenAI usage 数据支持不同时间粒度每种粒度在“精度 vs 实时性”之间有权衡1 分钟 bucket用于 rate limit headroom 告警和接近实时的限流预警当finalization_grace为0s默认时数据可以在几分钟内到达但在高流量突发情况下可能低估将finalization_grace调整为15m可以更接近最终一致结果但会延迟 dashboard 和告警在最繁忙的 bucket 中仍可能存在轻微低估小时级视图用于跨 project 和 model 的运维监控与容量规划日级聚合用于 FinOps 报告和成本对账集成自带一个开箱即用的告警规则[OpenAI] Rate limit headroom low同一套数据也可以直接用于自定义 usage 和预算阈值无需额外构建管道。开始使用 Elastic OpenAI 监控Elastic OpenAI 集成已在 Elastic Cloud 中提供包括 Elastic Cloud Hosted 和 Elastic Cloud Serverless。你可以通过 Elastic Cloud 免费试用Elastic Cloud free trial在 OpenAI 平台设置中创建 Admin API keyOpenAI admin keys然后在 Kibana 的Management → Integrations中添加 OpenAI 集成。几分钟内你就可以在 Elasticsearch 中看到 token usage、audit activity 和 rate limit headroom 数据流入并使用预构建 dashboard 和新的限流告警功能。原文OpenAI rate limit monitoring, now with an 80% throttling alert — Elastic Observability Labs