火山引擎 Prometheus 面向大模型场景的优化实践

如果无法正常显示，请先停止浏览器的去广告插件。

1. 火山引擎 Prometheus 的优化实践郭刚平面向大模型场景

2. 目录 01 大模型场景指标观测需求和挑战 02 火山引擎 Prometheus 优化思路 03 火山引擎 Prometheus 优化实践 04 总结与展望

4. 01 大模型场景指标观测需求和挑战

5. 大模型场景 Prometheus AI应用 (MaaS) AI平台 (PaaS) 全栈监控推理服务API MCP 、Agent 开发模型开发模型训练 Ray/ TensorFlow/Argo Workflow/ veRL... 模型推理 SGLang/vLLM/xLLM... Promethe us Workload 调度管理贯穿各层集成度高依赖度深容器平台 AI基础设施 (IAAS) cAdvisor CPU 服务器 kube state metrics GPU 服务器网络 RDMA 分布式存储

6. 大模型场景指标观测需求和挑战高扩展支撑的指标规模上限要高，能够水平扩容高基数问题高性能高可用低门槛查询速度快、能够容忍一定程度的不合理指标打点服务可用性、租户间隔离、请求间隔离接入简单、托管运维、查询方便、告警开箱即用租户QoS保障 HPA可靠性

7. 案例一：火山方舟平台在线推理服务特点 1：面向ToD/ToC 的推理API服务指标规模随用户数线性增长高基数、重查询问题，影响其他小租户特点 2 ：SLO 、成本效率要求高重度依赖基于自定义指标的HPA 可用性要求高典型推理服务架构网关多租户/多AZ容灾存储集群 API Gateway App 推理引擎 vLLM/xLLM/dynamo/sglang... Prefill Pods App Pod 弹性扩缩 HPA/KEDA 分布式缓存镜像加速/模型缓存/KV Cache 重查询轻查询模型 Qwen/Deepseek Decode Pods Prometheus Adapter OSS Promethe us 查询网关超时/失败存储集群租户 B 租户 A 写入网关 CPU 高反压

8. 案例二：自动驾驶云平台特点：大量短生命周期的任务高基数问题自动驾驶云 Workflow Workflow Workflow Prometheus 容器集群每天下午开始RecordingRule 执行失败

9. 02 火山引擎 Prometheus 优化思路

10. 火山引擎 Prometheus 接入中心监控看板告警中心数据消费 RecordingRule 多租户/多AZ容灾存储集群查询网关存储集群 ... 写入网关集群管理(租户元数据、组件弹性扩缩) 存储集群网关监控平台架构

11. 火山引擎 Prometheus 优化思路全层次视角 2 从集群 - > 租户 - > 请求粒度逐层分析看可慢不可瘫 3 1 宁可查询请求慢一点，也要尽量避免整个服务挂掉影响更多用户 4 端到端视角优、治结合从sdk - > agent - > 网关 - > 存储引擎整个链路看从水平、垂直视角，合理优化提升系统上限思路与原则辅以治理解决方案，帮助用户发现、治理不合理使用姿势

12. 火山引擎 Prometheus 优化思路具体解法问题整体方向端到端视角全层次视角集群粒度：识别大流量租户并拆分独立集群高可用：租户QoS 保障高性能/高扩展：高基数问题优、治结合慢查询分析计算节点：查询封禁加强隔离，网关：识别大流量租租户粒度：查询请求shuffle Never 设置兜底户并拆分独立集群 sharding，降低故障域 OOM 设计子用户限流请求粒度：设置自我保护性资源限制高可用： HPA 可靠性可慢不可瘫预测能力治理为主，降低基数细化Qos 限流项 HPA ：增加预测能力，集群粒度：多AZ 容灾降低延迟打点SDK ：不活跃时序自动过期删除集群粒度：数据跨集群分流，统一聚合查询，提升扩展性引擎：小时粒度索引，减少无效扫描打点姿势最佳实践采集Agent ：Agent 侧写入预聚合，降低指标维度

13. 03 火山引擎 Prometheus 优化实践

14. 租户 QoS 保障 1 2 大流量租户故障域隔离识别& 独立拆分 3 Never OOM 设计 4 5 精细、高效的限流慢查询分析& 治理

15. 租户 QoS 保障 1. 大流量租户自动识别& 独立拆分实现形式：创建独立集群是一个k8s CRD ，由一个专用的 controller 负责状态更新共享存储集群共享网关路由网关 CR 的状态分为：Auditing、Creating、Created 、 Routed 租户元信息管理独立存储集群人工确认创建独立集群独立网关逻辑步骤：定义大租户规则(活跃时序超5亿或写入速率超15M samples/s) 持续监控指标跟踪创建独立集群CR ，通过告警触发通知人工确认人工确认，创建独立集群组件大租户识别规则大流量识别& 独立集群创建独立集群ready后，更新路由关系

16. 租户 QoS 保障 2. 故障域隔离 mod hash 查询路由租户A 租户B shuffle sharding 查询路由查询节点 Shuffle Sharding 路由，查询节点降低租户间故障域重合度网关查询节点租户B 查询节点租户C 查询节点租户A 网关查询节点租户C 查询节点查询节点

17. 租户 QoS 保障 2. 故障域隔离代码实现 shuffle sharding 查询路由 func SimpleShuffle(seed int, identifier []byte, endpointsPerCell int) (endpoints []string) { 查询节点租户A r := rand.New(seed * hash(identifier)) 查询节点 eps := GetAllEndpoints() r.Shuffle(len(eps), func(x, y int) { 租户B eps[x], eps[y] = eps[y], eps[x] 网关查询节点 }) 租户C 查询节点 return eps[:endpointsPerCell] }

18. 租户 QoS 保障 3. Never OOM 设计查询节点网关 1 主动设限：实例 & 请求粒度单请求计算内存限制 2 排队请求 40% 用前检查：申请内存前应该判断是否有余量 3 用后清理：及时清理非活跃内存 4 溢出磁盘：超出容量设计部分，考虑溢出磁盘基于排队论的自适应限流计算数据量过大？各个缓存 20% 磁盘 Runtime 5 过载保护：使用自适应限流，避免服务过载 6 监控优化：持续监控各组件内存用量，不断优化溢出自监控

19. 租户 QoS 保障 4. 精细、高效限流限流项示例实现方式限流效果限流项示例限流效果写入速率 10M samples/s 分布式限流返回429 单次查询内存占用 1GB 返回422 查询 QPS 100 count/s 分布式限流返回429 单次查询扫描时序数 10w 返回422 查询扫描时序速率 20000 series/s 分布式限流窗口内查询熔断单次查询扫描点数 10亿查询扫描数据速率 2亿 samples/s 分布式限流窗口内查询熔断单实例并发请求数 500 租户级别，SLA 预算实例级别，兜底保护返回422 返回503

20. 租户 QoS 保障 4. 精细、高效限流如何实现高效的分布式限流？本地均摊限流本地限流通过？ NO YES Redis Ready? YES Redis Ready? 近3m 有实例发生 reject ？计算应请求token 数 max(qps/step, n) 减少对 Redis 压力： YES 1. 优先本地均摊 NO NO NO 返回本地限流结果 Redis 动态步长令牌桶限流 2. 动态均摊实例 QPS 滑动窗口计数器 3. Redis 令牌桶根据QPS 动态请求令牌 Instance Counter 请求redis Throttle Recorder Redis 执行本地token扣减

21. 租户 QoS 保障 5. 慢查询分析& 治理用户在会在不同的场景使用到对于识别到的慢查询，我们希望用对于用户识别到的一些问题子对于一些比较重的查询，比如查询 Promethues的指标，比如业务户能够感知到并且持续去治理优用户或者慢查询语句，需要给超时、或者被兜底限流阈值限流的 HPA、告警、大盘，为不同的化，因此我们会对用户近7天的重到用户一种能力去封禁查询，如果不进行封禁，会导致持使用场景分配不同的子账号，并且配置不同的查询Qouta，就很有必要查询进行展示，便于用户去优化实现原理：慢查询日志&统计实现原理：查询PromQL正则匹配慢查询分析实现原理：查询PromQL + 查询时间范围匹配实现原理：分布式限流子用户限流续的消耗资源手动查询封禁自动查询封禁

22. 高基数问题 P 2. 采集侧预聚合 1. 提供打点最佳实践最佳实践文档和工具写入前降低维度 A 高基数问题 D 3. 查询优化 4. 写入分片& 聚合查询分治原则特定场景优化 C

23. 高基数问题 1. 打点最佳实践 1 合理设计去除非必要标签，详细信息考虑log或 trace http_request_total 维度 instances 100 path 10 response_code 10 response_size_level 10 基数 100*10*10*10=10w 指标拆分 2 3 根据使用场景，对指标标签进行合理划指标拆分分，避免所有标签都放到同一指标活跃感知及时删除不再活跃时序，提供sdk 实现不活跃指标自动回收 http_reque st_total 维度基数 http_requ 维度 est_size instances 100 instances 100 path 10 response_c ode 10 100*10*1 0=1w path 10 response_ 10 size_level 基数 100*10*1 0=1w

24. 高基数问题 2. 采集侧预聚合优先推荐在 Agent 端配置预聚合 1. 预聚合的资源消耗分散，不易致服务端处理性 cpu_usage_sec onds_total 维度基数 cluster 2 node 100 pod 预聚合 by node 2*100*10 00=20w cpu_usage_sec onds_total 维度基数 cluster 2 node 100 1000 能成为瓶颈 2. 服务端不用做过重的窗口聚合，对整体稳定性和端到端时延有帮助 Prometheus Agent Gateway Query Aggregation Aggrega tion Aggrega tion Storage 2*100=2 00

25. 高基数问题 3. 查询优化增加小时粒度索引倒排索引写请求是否构建小时索引 1. 只保留近2小时，覆盖告警和大部数据租户新增序列统计 curr day last day 分查询场景 metadata data partion 2. 小时粒度索引构建是启发式的，只对序列新增速率超过一定比例的用户开启，一方面节省存储，另一 YES curr hour last hour 方面减少对写入吞吐的影响 data partion 查询范围是否1小时内读请求

26. 高基数问题 4. 分片写入& 聚合查询根据业务集群、指标名等拆分，降低单集群规模和运维压力聚合查询，查询算子下推，并行执行加速查询 histogram_quantile clusterA agent merge result storage 聚合查询引擎 clusterB agent sum by(le) storage 算子下推 sum by(le) sum by(le) sum by(le) storage storage storage

27. HPA 可靠性预测式 iHPA iHPA 为与内场 ByteBrain 团队合作，基于其提供的时序预测模型实现 iHPA 自身提供对于 Metric 的配置，Metric 配置完成后，Controller 会将每一个 iHPA Metric 转换为两个 HPA Metric ，分别对应实时指标和预测指标。 1. 对于实时指标来说，其会直接透传到 HPA Metric ； 2. 对于预测指标来说，iHPA Controller 会进行转换： - 预测指标类型均为 External ，即由 Metric Adapter 提供；

28. 04 总结与展望

29. 总结与展望总结稳定支撑火山引擎方舟数十亿级时序的读写高基数查询P99时延降低 50%+ 读写可用性 99.99% 查询P99时延 600ms 重查询拦截率 95%

30. 总结与展望展望面向 AI，主动洞察增强主动数据分析能力，内置主动异常检测、趋势统一观测，跨层联动夯实基础，稳字当先与火山引擎应用观测 APMPlus 产品联动，统一建设下一代更高性能、更采集、统一观测，提升跨层低成本的时序存储数据联动质量持续加强稳定性& 运维自动化建设预测等能力加速AIOPS 产品化建设，把字节跳动内部成熟能力输出到云上

31.

32. THANKS 大模型正在重新定义软件 Large Language Model Is Redefining The Software