作者：来自 Elastic Daniela Tzvetkova
Elastic 中的 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 APIs
Elastic 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 Hosted（ECH）（支持的较新版本），或
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 key（OpenAI 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）、token（TPM）和图像（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 key（OpenAI 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
（支持资料、图片参考_降重降ai）)
