一、背景与挑战：监控1.0的瓶颈

B站早期监控系统（监控1.0）基于开源工具（如Prometheus+Grafana）搭建，虽能满足基础指标采集与可视化需求，但随着业务规模指数级增长，逐渐暴露出三大核心问题：

1. 数据孤岛与扩展性不足：不同业务线（如视频、直播、社区）的监控数据分散在独立集群，缺乏统一数据模型，导致跨业务告警关联分析困难。例如，直播卡顿问题可能同时涉及CDN节点、推流服务器和数据库，但1.0系统无法自动关联这些指标。
2. 告警疲劳与精准度低：固定阈值告警策略在动态负载场景下频繁误报（如突发流量导致CPU使用率短暂超过80%），而缺乏智能降噪机制。据统计，1.0系统日均告警量超过10万条，其中有效告警不足30%。
3. 资源消耗与成本失控：全量指标采集策略导致存储成本激增，单集群日增数据量达TB级，且历史数据查询延迟超过5秒，无法满足实时根因分析需求。

二、监控2.0架构设计原则

针对上述问题，B站监控2.0架构设计遵循四大原则：

1. 统一数据层：构建全局指标仓库（Metrics Warehouse），定义标准化指标模型（如metric_name、tags、timestamp、value四元组），支持多维度聚合查询。例如，将“视频播放成功率”指标统一为video.play.success_rate，并附加region、device_type等标签。
2. 分层告警体系：引入“基础指标→复合指标→业务指标”三层告警模型。基础指标（如CPU使用率）用于底层资源监控；复合指标（如“单位QPS延迟”）通过流式计算聚合生成；业务指标（如“付费用户转化率”）直接关联业务KPI。
3. 智能降噪与根因定位：集成机器学习模型（如孤立森林算法）识别异常模式，结合知识图谱自动关联相关告警。例如，当检测到“数据库连接池耗尽”告警时，系统可自动关联同机房的“应用服务器响应时间上升”告警，并推荐“扩容连接池”或“优化SQL”等解决方案。
4. 弹性扩展与成本优化：采用“冷热数据分离”存储策略，热数据（近7天）存储在SSD集群，冷数据（历史数据）压缩后存入对象存储；同时引入动态采样机制，对低频指标（如每日UV）按概率采样，减少存储开销。

三、核心模块实现与技术选型

1. 数据采集层：多源异构数据归一化

监控2.0支持多种数据源接入：

• 主机指标：通过Telegraf采集CPU、内存、磁盘等基础指标，支持自定义插件扩展。
• 应用指标：集成Prometheus Exporter规范，业务方可自行暴露指标（如http_requests_total）。
• 日志指标：通过Fluentd采集日志，经正则解析后转换为指标（如“错误日志频率”）。
• 业务数据：通过Kafka接收业务DB变更事件，生成业务指标（如“订单创建数”）。

代码示例（Telegraf自定义插件）：

package main
import (
    "github.com/influxdata/telegraf/plugins/inputs"
)
type BilibiliInput struct {
    Servers []string
}
func (b *BilibiliInput) SampleConfig() string {
    return `
      [[inputs.bilibili]]
        servers = ["http://api.bilibili.com"]
    `
}
func (b *BilibiliInput) Gather(acc inputs.Accumulator) error {
    // 调用B站API获取视频播放量等指标
    metrics := fetchBilibiliMetrics()
    for _, m := range metrics {
        acc.AddFields("bilibili.video",
            map[string]interface{}{"play_count": m.PlayCount},
            map[string]string{"video_id": m.VideoID},
        )
    }
    return nil
}
func init() {
    inputs.Add("bilibili", func() inputs.Input {
        return &BilibiliInput{}
    })
}

2. 存储与计算层：时序数据库优化

监控2.0选用TimescaleDB（基于PostgreSQL的时序数据库）作为核心存储，主要优势包括：

• 高效压缩：通过分段压缩算法，将存储空间减少70%。
• 连续查询优化：支持time_bucket函数实现按时间窗口聚合，例如：

  SELECT time_bucket('5 minutes', time) AS bucket,
       AVG(value) AS avg_cpu
  FROM metrics
  WHERE metric_name = 'cpu.usage'
  GROUP BY bucket;

• 跨节点查询：通过分布式超表（Hypertable）实现水平扩展，支持PB级数据查询。

3. 告警与根因分析层：规则引擎与AI结合

告警规则引擎支持两种模式：

• 静态阈值：适用于已知异常模式（如“磁盘使用率>90%”）。
• 动态基线：通过历史数据训练LSTM模型，自动生成动态阈值。例如，对“电商订单支付成功率”指标，模型可识别节假日波动模式，避免误报。

根因分析流程：

1. 告警聚合：将同一时间窗口内的相关告警合并为“事件”。
2. 拓扑感知：结合CMDB（配置管理数据库）中的依赖关系，构建服务调用链。
3. 影响面评估：通过影响面算法计算事件对核心业务的影响程度（如“支付系统故障导致50%订单失败”）。
4. 解决方案推荐：从知识库中匹配历史类似事件的处理方案。

四、落地实践与效果

1. 分阶段迁移策略

为降低风险，监控2.0采用“灰度发布”模式：

1. 试点阶段：选择直播业务线（日均QPS 10万+）作为试点，验证架构稳定性。
2. 推广阶段：逐步接入视频、社区等业务线，通过Canary部署确保兼容性。
3. 全量阶段：完成所有业务线迁移，关闭1.0系统。

2. 效果对比

指标	监控1.0	监控2.0	提升幅度
日均告警量	10万+	3万+	-70%
告警准确率	28%	85%	+204%
历史数据查询延迟	5-10秒	<1秒	-90%
存储成本（单集群）	50万元/月	15万元/月	-70%

五、经验总结与建议

1. 数据模型设计是关键：统一指标命名规范和标签体系，避免后期数据清洗成本。
2. 告警规则需动态调整：结合业务负载特征（如促销活动）动态优化阈值，减少误报。
3. AI模型需持续迭代：定期用新数据重新训练异常检测模型，适应业务变化。
4. 逐步迁移优于全量替换：通过试点验证架构稳定性，降低生产环境风险。

B站监控2.0架构的落地，不仅解决了1.0系统的扩展性和精准度问题，更为大规模分布式系统的监控提供了可复用的方法论。未来，我们将探索更多AI与监控的融合场景（如自动故障预测），进一步提升系统稳定性。