从性能参数到业务大数据，浅谈直播 CDN 服务监控

线上服务的有效监控和数据收集，一直是后端服务离不开的话题。直播 CDN 作为一种经典的分布式系统，监控以及数据收集更是必不可少的工作。如何对海量的服务集群有效的监控和保活，又如何抓取集群中的碎片数据中来优化服务。不得不说是一个值得无止境讨论和优化的事情。

机器站在巨人的肩膀上用着轮子

作为分布式集群，物理层上的最小单位自然是机器。对于一台机器而言，常规性能指标自然就是 CPU、内存、网卡的使用情况。这些性能有很多方式去获取，而视频云采用的是网易的哨兵系统。哨兵系统是网易的监控系统，提供了非常详细和即时的性能指标。

借由哨兵这个强大的轮子，我们能非常方便的在机器级别上，做出有效的监控。例如当网卡流量或者 CPU 异常的时候，可以快速的报警采取处理。当然，不光光可以监控机器是否能正常运行，也可以监控是否被恶意攻击，这个暂且不谈。

性能指标与业务融合

当然，只有机器级的数据，是远远不够的。俗话说，不与业务贴合的数据，不是好数据。作为直播 CDN 服务，最常规的参数，自然是音视频码率和延迟。

细心的看官们可能发现了几个比较特殊的统计。
为什么统计了总码率也统计了音视频单独的码率？
这是因为在真实的场景中，总码率并不一定能还原出我们需要的场景，有很多情况会需要单独的分析音视频码率，例如用户主动关闭了视频输出或者机器采样性能不足导致的视频卡顿，这个时候只需要配合帧率的统计，就可以快速还原场景。当然，视频码率本身也不是一个固定的数值。视频云也针对弱网提供
QoS（即可变码率）的功能。

推送延迟 push_delay 是什么？
推送延迟，是一个衡量 C/S 之间网络情况的参数。当这个参数发生波动的时候，则说明C端的包到达 S 的时间比预计要长。能够反映出网络的抖动情况。如果计算这个数值呢？简单来说，是使用了 RTMP 包头部的时间戳。如果非要用一个公式解释一下，我觉得应该是：

• Delay=abs ( (当前 RTMP 包的到达时间-上个 RTMP 包的到达时间) – (当前 RTMP 包的时间戳–上个 RTMP 包的时间戳) )

计算每个包到达服务器所消耗时间的差异值，用于代表网络的抖动。当然，还需要做其他很多事情，例如加权和 jitter 算法来减少误差和避免。

为什么还有 send_kbps？
其实这也挺好理解，因为 CDN 本身是分布式系统，在节点和节点间需要做路径选择，然后从节点到节点传输，从而实现加速。Send_kbps 其实就是前一个节点向后一个节点的发送码率。那么这就涉及到了一个问题，如果去 trace 某一条流的数据呢？对于每一条流，我们会给予一个唯一的标记，在节点间传递的时候，我们会给流添加一个自增的标记 Hops。通过这个标记，可以精准的找到这条流在节点件的走向，从而把各个节点的数据聚合在一起
其他，我们还会抓取一些类似源 IP，用户设备等客户端的信息。这些信息能帮忙我们走进大数据时代（笑。

整体数据服务的架构

分布式系统中，每一个节点都会产生大量的统计和性能数据。所以在视频云，有一个完整的统计架构来作出支持。从最前端的数据采集、传输，到汇总，然后到计算集群，最后输出。每一个服务都各司其职。让我们来看看整体架构。

对于每一个区域，会有一个数据汇聚的服务器，负责从流媒体服务器收集数据。最初的元数据，经过数据汇聚服务器汇总、过滤和压缩以后。统一上报到中心集群中的统计服务器。统计服务器会将所有的统计数据，逐一落库，储存在数据仓库中。其余的数据计算集群，会从数据仓库中定时进行读取计算。具体的计算间隔，会根据业务类型不同而不同。例如运维平台会主要读取一些机器级别的数据，进行分析和报警。大数据计算集群则会对数据进行计算，得出优化方向，此处我们稍后再聊。业务数据展示平台则是会实时的输出数据（例如码率和延迟），用于提供给用户和技术支持查询。当然，还有其他各种各样的数据处理服务，这里就不再一一介绍。

数据能做的一些事情

最后，我们聊一聊数据。在这个大数据时代，有了数据却不做事情，等同于浪费。那么，有了这些数据以后，我们做了什么事情呢？当然，最显而易见的，就是调整调度策略，增设布点。例如，上图的大数据的运算结果，南京电信的网络权重比较差，这就说明南京电信地区需要进行排查。而南京移动的用户量较大，也说明南京地区应该增设服务点。

此外，数据和性能指标的上报，也会被用于均衡负载调度。例如某一个节点压力较大的时候，或者性能不稳定的时候，这个节点的调度优先级就会被降低（即不太会被优先分配给用户）。

还有更多干货，欢迎关注网易 MC 官方微信公众号：