一、背景与挑战：从监控1.0到2.0的演进

B站作为国内领先的视频社区，业务覆盖直播、弹幕、视频点播、云游戏等多元化场景，日均亿级流量对系统稳定性提出极高要求。早期监控1.0架构采用”Prometheus+Grafana”开源组合，虽能满足基础指标采集与可视化需求，但在以下场景暴露出明显短板：

1. 多维度数据孤岛：指标、日志、链路追踪分散在多个系统，故障定位需跨平台切换，平均MTTR（平均修复时间）长达30分钟。
2. 动态扩缩容适配不足：容器化部署后，Pod频繁启停导致监控目标动态变化，传统静态配置方式产生大量无效告警。
3. 智能化能力缺失：依赖阈值告警，无法识别业务波动模式，夜间低峰期流量下降30%时误报率高达40%。

为解决上述问题，B站启动监控2.0架构升级，目标构建”统一数据湖+智能分析+场景化告警”的新一代监控体系。

二、架构设计：分层解耦的监控中台

2.1 总体架构

监控2.0采用”四层三中台”设计：

• 数据采集层：支持Telegraf、Filebeat、SkyWalking Agent等多协议接入，通过Kafka实现流量削峰。
• 数据处理层：
  • 实时计算：Flink流处理引擎完成指标聚合（如QPS、错误率）与异常检测。
  • 离线计算：Spark对历史数据进行根因分析模型训练。
• 数据存储层：
  • 时序数据库：自研TSDB替代InfluxDB，支持百万级时间线存储，压缩率提升60%。
  • 索引数据库：Elasticsearch存储日志与Trace数据，支持秒级全文检索。
• 应用服务层：
  • 统一查询API：封装PromQL、SQL、Lucene等多种查询语法。
  • 智能分析中台：集成Prophet时序预测、Isolation Forest异常检测等算法。
  • 告警运营中台：支持告警收敛、降噪、自动分派等策略配置。

2.2 关键技术创新

动态目标发现机制

针对K8s环境，开发基于CRD（Custom Resource Definition）的ServiceMonitor自动发现组件：

apiVersion: monitoring.bilibili.com/v1
kind: ServiceMonitor
metadata:
  name: example-app
spec:
  selector:
    matchLabels:
      app: example
  endpoints:
  - port: web
    path: /metrics
    interval: 15s

通过Watch机制实时感知Pod变化，自动更新Prometheus配置，解决动态扩缩容导致的监控空白问题。

多模态数据关联

构建”指标-日志-Trace”关联索引：

1. 指标异常时，自动提取时间窗口（±5min）内的相关日志。
2. 通过日志中的TraceID定位全链路调用，使用Mermaid语法生成调用拓扑：

   graph TD
    A[Web Server] -->|HTTP| B(API Gateway)
    B -->|gRPC| C[Order Service]
    C -->|MySQL| D[Database]

3. 结合Trace的Span标签（如db.query）定位慢查询，将MTTR从30分钟压缩至8分钟。

三、落地实践：从POC到全量推广

3.1 灰度发布策略

采用”核心业务优先、依赖链反向”的推广顺序：

1. 第一阶段：覆盖支付、弹幕等核心业务，验证架构稳定性。
2. 第二阶段：接入推荐、搜索等中台服务，优化查询性能。
3. 第三阶段：全量推广至边缘业务，建立统一监控标准。

实施过程中，通过Canary部署监控2.0与1.0并行运行，对比关键指标：
| 指标 | 监控1.0 | 监控2.0 | 提升幅度 |
|———————-|————-|————-|—————|
| 数据延迟 | 15s | 3s | 80% |
| 告警准确率 | 65% | 92% | 41.5% |
| 存储成本 | 100% | 65% | 35% |

3.2 典型场景优化

弹幕洪峰监控

在跨年晚会等场景，弹幕量突增10倍导致传统阈值告警失效。监控2.0采用：

1. 动态基线算法：基于历史7天数据自动生成动态阈值曲线。
2. 流量预测模型：LSTM网络预测未来10分钟流量，提前扩容资源。
   实施后，弹幕系统可用率从99.2%提升至99.95%。

云游戏卡顿分析

针对云游戏场景，构建”端到端”监控体系：

1. 客户端采集：通过WebGL API获取帧率、延迟等数据。
2. 边缘节点监控：部署Node Exporter采集GPU利用率、网络抖动。
3. 根因定位：结合Trace数据判断卡顿源于编码参数错误还是网络拥塞。
   优化后，玩家平均卡顿时长从2.3s降至0.7s。

四、经验总结与建议

4.1 架构设计原则

1. 统一而非集中：保留业务线自定义监控能力，通过标准接口接入中台。
2. 计算存储分离：实时计算与离线计算使用不同资源池，避免相互干扰。
3. 渐进式演进：优先解决核心痛点（如告警误报），再逐步扩展功能。

4.2 技术选型建议

1. 时序数据库：自研TSDB适合超大规模场景，中小团队可考虑M3DB或TDengine。
2. 流计算引擎：Flink Stateful Functions适合复杂状态管理，Spark Structured Streaming适合简单聚合。
3. 可视化工具：Grafana插件生态丰富，但自定义面板需评估开发成本。

4.3 团队能力建设

1. SRE角色转型：从”被动救火”转向”主动优化”，建立SLA/SLO体系。
2. 数据治理机制：制定指标命名规范（如app_name.service.metric），避免指标爆炸。
3. AIOps实践：优先在告警收敛、根因分析等场景落地AI，避免盲目追求全自动化。

五、未来展望

监控2.0架构已稳定运行18个月，下一步将聚焦：

1. 可观测性融合：整合Metrics、Logging、Tracing、Profiling四维数据。
2. 低代码配置：通过UI拖拽生成监控看板与告警策略。
3. 边缘计算支持：适配IoT设备轻量级监控需求。

B站的实践表明，监控系统升级需平衡技术先进性与业务适配性，通过”数据驱动优化、场景验证效果”的闭环，最终实现从成本中心到价值中心的转变。