主要观点总结
B站监控2.0架构的设计思路、挑战、实施与未来规划。背景：B站基于Prometheus+Thanos完成了统一监控平台，但面临业务增长带来的指标数据爆炸、系统稳定性、查询性能、数据质量等问题。设计思路：采集存储分离、存算分离、时序数据库选型、单元化容灾。挑战：监控系统稳定性、数据可用性、查询性能、故障爆炸半径。实施：数据采集、调度层、采集器、数据存储、数据查询、查询优化、数据可视化、云监控方案。未来规划：支持更长时间Metrics指标数据存储、更细粒度的指标埋点、自监控能力增强、指标平台迭代。
关键观点总结
关键观点1: 背景与痛点
B站基于Prometheus+Thanos完成了统一监控平台，但面临业务增长带来的指标数据爆炸、系统稳定性、查询性能、数据质量等问题。
关键观点2: 设计思路
采集存储分离、存算分离、时序数据库选型、单元化容灾。
关键观点3: 实施与架构
数据采集、调度层、采集器、数据存储、数据查询、查询优化、数据可视化、云监控方案。
关键观点4: 挑战与解决方案
监控系统稳定性、数据可用性、查询性能、故障爆炸半径，通过2.0架构的设计思路实施解决。
关键观点5: 未来规划
支持更长时间Metrics指标数据存储、更细粒度的指标埋点、自监控能力增强、指标平台迭代。
文章预览
背景 众所周知，Metrics指标数据是可观测重要的基石之一，在2021年底的时候，B站基于Promtheus+Thanos 方案，完成了统一监控平台的落地。但随着B站业务迅猛发展，指标数据级也迎来了爆炸式增长，不仅给现有监控系统的稳定(可用性, 云上监控数据质量等)带来冲击，也无法满足公司层面可观测稳定性建设(1-5-10)目标。当前架构面临的痛点总结如下： 稳定性差： 由于当时告警计算是基于Promtheus本地计算的，target监控实例在调度时，一个应用的所有实例必须要被同一个Promtheus采集,每当一些大应用发布时，pod name 等一些元数据指标label就会发生变化，重新构建timeseries 索引时，会占用大量内存，导致Promtheus oom。 用户查询体验差： 频发的oom告警，经常导致数据断点，再加上Promtheus+Thanos 查询性能性能有限，经常出现面板查询慢/超时，open api 查询失败，误告
………………………………
