bilibili 《B 站监控架构 2.0 落地实践》

如何获得讲师PPT：

扫码关注公众号，后台回复「Q417」即可获得讲师PPT哟～

还能一键订阅后续精彩活动内容～

Q&A环节答疑：

1、支持otel没？

目前是框架层已经支持。B站已经建立了一个统一的框架，可以支持Java、Go等技术。

2、怎么解决发生生产故障时，大量产研刷新监控系统，导致监控系统卡顿的问题？

之前的1.0架构可能面临一些挑战，这是一个复杂的问题，不能仅靠单一解决方案来处理。监控系统的稳定性需要从数据采集、写入、存储到查询的各个环节进行综合保护。过去，产品性能有限可能导致了卡顿问题。现在，我们已在查询层实施了几项改进措施：首先，使用VVN替代了旧技术；其次，对大量指标数据进行了预聚合处理；最后，对于如B站弹幕直播这类高流量场景，我们采用了自动化转换技术。

3、对于 VM 的索引结构，在进行查询时，如何优化索引的查找效率，以进一步提高查询性能？

他提出的问题是关于如何优化查询。根据我的理解，我们目前没有对VM存储进行大规模改造。我们的主要策略是在数据写入时控制指标生成的速率，特别是高级指标和标签。

在监控方面，我们的处理方式如下：在数据采集环节，我们实施了三项限制措施。例如，对于一个实例，我们默认设置了四个磁盘的限制。如果用户超出了这些限制，我们会向用户发送告警，这是标准操作。同时，我们会分析用户的指标是否符合规范。如果指标规范，我们会放行；如果不规范，我们会采取措施避免产生高级指标。目前，我们主要在采集阶段实施了这些限制，而对于VM本身的代码，我们还没有进行过多的修改。

4、调度策略中基于实例和容量维度进行调度，具体的算法是怎样的？ 如何保证已分配的采集点下次仍能拿到最近的采集配置，实现平滑调度？

由于时间限制，我简要说明一下我们如何实现平滑调度的问题。在我们进行二级调度更新时，由于内存数据可能会丢失，我们引入了一个机制。在二级架构重启期间，采集器会向二级架构报告其采集配置。简单来说，步骤如下：

1. 等待所有采集点向二级架构上报它们当前的采集目标。
2. 收集完毕后，再从主控(master)获取最新的采集目标列表。

通过比较这两个数据集，我们可以确定每个采集器当前负责的采集任务，从而实现平滑调度。这一过程主要依赖于采集节点向二级架构上报其已获取的采集基础信息，然后与主控进行同步。这个问题在最初版本时确实导致了一些不均衡，但我们通过上述机制成功解决了这一问题。

5、查询网关的封禁、限流和降采具体是如何实现的？采用了哪些技术手段来防止系统被拉挂？

查询网关的封禁机制是这样的：我们通过开放API提供服务时，HDPK会生成一个token，该token基于两个属性进行哈希处理：账号和APP ID。账号用于颁发给用户，而APP ID则便于在出现问题时追踪到相应的负责人。基于这些信息，我们生成了token来解决认证问题。

在HDB查询方面，我们设置了监控点来记录谁访问了接口以及他们的查询行为。此外，我们还实施了基于时间窗口的限流措施，目前默认的请求数为每秒300次。

至于降采，我们目前采取的是随机降采策略，这在处理大量流量时尤其有用。如果用户在短时间内无法完全停止请求，我们通过随机降采来减轻服务器压力。这种策略虽然使用不多，但在流量激增时能有效减轻服务器负担。

6、升级的成本有哪些？

升级到2.0版本的过程中，我们面临了显著的成本问题。作为从1.0版本到2.0版本的全程参与者，我见证了从最初的架构细节逐步完善到全面覆盖的整个过程。迁移工作耗时约半年，主要涉及人力成本，并需要确保在迁移过程中不出现重大故障。

为此，我们制定了详尽的预案，确保迁移过程的可观测性和可恢复性。最大的挑战在于运维成本。尽管如此，迁移完成后，我们实现了资源的有效利用和成本的降低，同时支持的业务量也有所增加。

7、对于不同网络的移动端应用怎么做拨测？

目前，我们的工作重点不包括移动端的测试。我们主要进行的是协议拨测，包括TC、HDB和SMP等协议。这些测试不涉及移动端。

8、Thanos是不在使用了吗？

对，前面都全部下掉了。目前是不再有了。基本上都是全部用VMN这一套方案。

9、针对解决指标断点，这个解决方法可以再说一下嘛？

关于VMA指标的采集，我们设定了每30秒采集一次数据的频率。在重启过程中，采集任务可能会被调度到其他设备上。这种调度可能会导致耗时增加，大约需要40秒。因此，下一个数据点的采集可能会受到影响。

为了解决这个问题，我们在collect退出时不会立即停止，而是让二级架构停止上报心跳，这样它就不会接收到最新的配置，但会继续根据当前的配置采集一个周期的数据。这可能会导致在01秒到05秒之间出现数据重复。

目前，我们在select阶段实施了去重机制，如果在15秒内检测到重复的数据点，我们只保留一个。这样的措施有助于避免数据重复的问题。

10、blackbox-exporter能做代理或者走代理吗？

目前，我们确实进行了一些探测工作，但主要限于网络部分，且场景较少涉及黑盒探测。探测过程通常是通过代理方式进行的。

11、告警是用vmalert吗？指标写入有延迟，promql查询可能会有误告警，怎么解决呢？

目前，我们的告警系统是基于BM的上层封装了一层调度层来下发告警规则。存在的问题包括可能的协会延迟和误报。在IDC采集方面，由于写入操作基本没有延迟，告警通常及时。但在云环境中，如果通过公网传输，网络不稳定时可能会产生较大的延迟，导致告警延迟或不触发。

针对海外节点，我们保留使用本地旁路进行告警计算的做法，但这种情况很少见，通常只在海外网络不稳定时使用。至于BM系统的企业微信延迟问题，目前还好，没有因为写入问题导致误报。

如果真的遇到延迟问题，可能需要一个兜底方案。例如，如果系统级问题导致业务层面的误报，可能需要实施高级抑制措施，以避免不必要的告警。

12、边缘节点的prometheus如何避免因重启导致的采集数据中断，用什么冗余架构？

我们之前讨论了由于重写web目录可能导致数据中断的问题。为了解决这个问题，我们采用了双采策略。这种架构设计是为了应对OM（可能指运维操作）的频繁性。如果出现问题，我们的操作是删除web目录并快速重启，以减少对用户的影响。

目前，我们基本上能够实现分钟级的终端服务。对于云上的监控量，由于不是特别大，我们提前进行了容量预估，并尽量在低峰期进行重启，以避免像IDC那样在OM期间出现平板的情况。我们的目标是尽量减少对用户的影响，并通过双采策略来避免数据中断。