王国梁-最新-告别运维负担：腾讯云对 Prometheus Serverless 化的实践-腾讯-

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