告别运维负担:腾讯实现Prometheus的Serverless化实践 王国梁 腾讯云日志服务CLS研发负责人 Prometheus的兴起以及面临的挑战 目录 常见集群化解决方案对比 如何实现Serverless化的Prometheus服务? Prometheus在Serverless后的收益和优势 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 基于KV数据库 基于关系数据库 原生时序数据库 时序数据库的产生和发展 产生背景: •物联网、云计算和大数据技术的发展,大量的时间序列数据 •时序数据对延迟、吞吐等要求更高 •数据规模巨大,成本敏感,对压缩比和降采样有要求 •场景更复杂,需要支持特定的高效查询和分析需求 写入 存储 查询 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 云对象存储 混合型 磁盘 内存 •写多读少,99%是写入 •平稳、持续、高吞吐 •实时性要求高 •存储规模大,周期长 •成本特别敏感 •压缩比 •查询延迟敏感 •多维分析 •高基数 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 Prometheus的架构 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 Prometheus的“如日中天”到“力不从心” 亮点: 亮点 瓶颈 •“师出名门”:Kubernetes源于Google的Borg系统,Prometheus的设计理念则受到了Google的BorgMon的启发。 •云原生友好:与Kubernetes集成紧密,简单易用,安装配置简单,随着Kubernetes的“风”流行,服务发现机制自适应环境 •开箱即用:自带套件,告警、UI等 规模受限 性能瓶颈 •社区活跃且支持强:提供了大量的集成、插件、工具和文档。瓶颈: 1.存储限制:默认使用本地存储,存储时间有限。 简单易用 运维复杂 2.查询性能瓶颈:单机服务,复杂的查询、大量的时间序列数据以及频繁的查询请求可能导致查询延迟增加。 生态友好 成本高 3.运维复杂性:大规模环境,管理多个Prometheus实例、数据备份和恢复、监控告警等方面可能增加运维的复杂性,尤其是自建集群而言。 4.高可用性和容错性:缺少自身高可用性机制,单点故障可能导致监控数据的丢失或不可用。 5.数据存储和清理:需要定期清理本地的数据,以释放存储空间。这需要进行合理的数据保留策略和清理操作,以避免存储空间不足或数据丢失。 6.其他:单机过热、OOM、重启慢等等 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 Prometheus服务的高可用方案对比 联邦集群 基础HA基础HA+远端存储 基础HA+远端存储+联邦集群 实例级分割 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 方案 Prom单机及集群 Thanos VictoriaMetrics Cortex/Mimir M3 流行度 广泛 广泛 一般 一般 弱 架构 单机/联邦 集群 单机/集群 集群 集群 存储 磁盘 磁盘/对象存储 磁盘 磁盘/对象存储 磁盘/对象存储 扩展性 弱 一般 一般 强 强 可靠性 弱,单机本地 一般,副本 一般,副本 强,支持WAL,副本,对象存储 强 多租户 弱 有限 强 强 强 兼容性 完全兼容 完全兼容 兼容 完全兼容 兼容 成本 高 高 低(规模相关) 低 一般 性能 低 一般 强 强 强 容灾 弱 一般 一般 强 强 常见集群化Prometheus方案方案对比 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 Cortex/Mimir原生架构的优劣 Cortex优势: •原生兼容Prometheus协议,底层基于Prometheus的TSDB •支持WAL、副本以及对象存储具备数据高可靠性 •架构分布式、存算分离,读写都支持横向扩展,查询支持多级缓存,性能高 Cortex劣势: •社区逐渐没落,Mimir和Cortex渐行渐远,后期维护成本高 •除AWS是主要维护和采用者,业界大规模使用较少 •Mimir更新迭代块,但开源协议不友好 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 为什么要基于Cortex/Mimir? 核心诉求:完全兼容Prometheus+时序查询性能要高(或可扩展)+低廉的部署成本 ●支持多租户:CLS本身是云服务,多租户隔离是刚需 ●可扩展和弹性能力:不支持集群架构部署和扩展,在数据规模到一定程度后将无法支撑服务 ●功能和协议兼容:与开源社区生态友好,具备进出的开放能力,尤其要支持Prometheus协议/OpenTelemetry协议 ●高可扩展性:具备简单清晰的技术架构和技术栈,考虑维护成本以及后续增强的可能性 ●容忍一些易用性和功能缺陷:不完美但可以自研去解决和优化 ●开放开源:避免商业化版权问题,避免卡脖子,尽量选择完全开源的系统 ●研发成本:尽量站在巨人基础上,不要闭门造车 对比Cortex、Thanos和VictoriaMetrics来看: ●Thanos实质来讲就是Prometheus联邦,本质还是Prometheus集群,违背了我们的弹性能力初衷,并且不支持多租户 ●Cortex,原生兼容Prometheus协议,底层基于Prometheus的TSDB,支持WAL、副本以及对象存储具备数据高可靠性、支持横向扩展,查询支持多级缓存,性能高;缺点是开源版本目前在乱序支持(已解决)、副本同步(待解决)、查询负载均衡(已解决)、租户级数据生命周期管理(可解决)功能不足、架构依赖有些复杂(已解决),但目前看后续都可以解决。 ●VictoriaMetrics性能高,可以极大优化存储资源(数据、索引和Value分开存储压缩),优化了标签搜索,所有组件都可以水平扩展,最大缺点是集群版本比较弱,此外就是vmstorage不是完全无状态的服务,宕机情况下有数据丢失的风险,不支持长期存储。 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 PrometheusvsCortex存储模型 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 PrometheusvsCortex存储模型 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 架构裁剪和增强 架构裁剪:去除全部可选组件(Alertmanager、ConfigsAPI、Overridesexporter、Queryfrontend、Queryscheduler、Ruler)等 依赖选型:ETCD、MySQL、Redis,不依赖Memcached GOPS全球运维大会暨XOps技术创新峰会2024·北京站 全链路的优化和改造 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 Compactor Distributor Ingester 基于流量/QPS弹性 基于CPU/MEM弹性 COS Query-forntend Querier Store-gateway CLB 架构增强:负载均衡+弹性接入+熔断限流 基于QPS/CPU/MEM弹性基于CPU/MEM弹性基于CPU/MEM弹性 Kubernetes GOPS全球运维大会暨XOps技术创新峰会2024·北京站 MemSnapshot WALReply Mem 性能优化:启动加速+投递打散 WAL 1 2 3 4 5 6 7 8 9 WALReply Mem WAL 1 2 3 4 5 6 7 8 9 Query- frontend Querier Store- gateway COS 本地计算的算子串行迭代 Ingester 性能优化:多节点拉取+算子并行 20wTS:max()查询耗时24s 拉取batch过小,每次 128ts或1M,效率低 14s7s GOPS全球运维大会暨XOps技术创新峰会2024·北京站 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 性能优化:多节点拉取+算子并行 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 增强:对TSDB的乱序支持 增强:对TSDB的乱序支持(WALvsWBL) HEAD (t,v)append insert(t,v) memory disk oooMmapdChunks MmapdChunks WBL WAL oooHeadChunk Chunk WAL:Write-Ahead-Log,先记录日志再写入存储(处理有序数据)WBL:Write-Behind-Log,先写入存储再记录日志(处理乱序数据) MergedQuerier query GOPS全球运维大会暨XOps技术创新峰会2024·北京站 mergedOOOChunks oooMmappedChunks oooHeadChunk blockQueriers inOrderHeadQuerier outOfOrderHeadQuerier GOPS全球运维大会暨XOps技术创新峰会2024·北京站 容灾:数据恢复能力兜底 规模和收益 性能提升10倍+ GOPS全球运维大会暨XOps技术创新峰会2024·北京站 X大客户 游戏、教育、新能源头部企业 PB级/天 PB级每天的流量写入,存储规模数十PB X-场景 容器/CVM基础设施、物联网、游戏、 计量等等 未来展望 基于负载的流量调度 GOPS全球运维大会暨XOps技术创新峰会2024·北京站 •基于集群节点负载的流量路由调度 •一致性Hash环的优化和容错规避 •全局副本元信息管理 •基于查询规模预估调度 •GooseFS加速数据拉取,性能提升100% •算子并行和优化 百万TS秒级查询 Thanks GOPS全球运维大会暨XOps技术创新峰会2024·北京站 THANKS 感谢大家观看 2024.6.28