高稳定监控架构落地实践

主要观点总结

文章介绍了架构师在2021年底B站基于Prometheus+Thanos方案完成统一监控平台落地后，随着业务增长，面临监控指标数据量级爆炸式增长的问题，导致现有系统稳定性差、查询体验差、云上监控数据质量差。为了解决这些问题，设计并实现了监控2.0架构，采用采集存储分离、存算分离、时序数据库选型、单元化容灾等策略，解决了现有监控系统的痛点，并介绍了监控2.0架构的落地挑战、整体架构、功能架构概览、数据来源、数据采集、数据存储、数据查询、数据可视化、云监控方案以及未来规划等关键点。

关键观点总结

关键观点1: 现有监控系统的痛点

稳定性差、查询体验差、云上监控数据质量差

关键观点2: 监控2.0架构的设计思路

采集存储分离、存算分离、时序数据库选型、单元化容灾

关键观点3: 监控2.0架构的落地挑战

监控系统自身稳定性、数据可用性、查询性能、故障爆炸半径

关键观点4: 整体架构和功能架构概览

数据源、数据采集、数据存储、数据查询、数据可视化

关键观点5: 云监控方案

云上数据回源到idc存储集群、vm-auth组件的使用

关键观点6: 未来规划

支持更长时间Metrics指标数据存储、支持更细粒度的指标埋点、自监控能力增强、指标平台迭代

文章预览

架构师（JiaGouX） 我们都是架构师！ 架构未来，你来不来？ 背景 众所周知，Metrics指标数据是可观测重要的基石之一，在2021年底的时候，B站基于Promtheus+Thanos 方案，完成了统一监控平台的落地。但随着B站业务迅猛发展，指标数据级也迎来了爆炸式增长，不仅给现有监控系统的稳定(可用性, 云上监控数据质量等)带来冲击，也无法满足公司层面可观测稳定性建设(1-5-10)目标。当前架构面临的痛点总结如下： 稳定性差： 由于当时告警计算是基于Promtheus本地计算的，target监控实例在调度时，一个应用的所有实例必须要被同一个Promtheus采集,每当一些大应用发布时，pod name 等一些元数据指标label就会发生变化，重新构建timeseries 索引时，会占用大量内存，导致Promtheus oom。 用户查询体验差： 频发的oom告警，经常导致数据断点，再加上Promtheus+Thanos 查询性能性 ………………………………