京东大规模数据中心网络运维监控之眼

我们可以从数据量表上来看京东的业务增长，下面是京东的一张覆盖了 2014 年 618 到 2017 年 618 所有的出口和专线的数据流量的图表。蓝色是专线 DCI，红色是互联网的公网流量。

从上图中，大家可以看到 2017 年 618 的 DCI 流量增长非常非常快；对比上一年，它已经翻了将近一倍，主要的原因是大数据和一些后台的日志分析等系统占了很大比例的流量。

2017 年***的一个变化就是很多独立的业务部署了自己的数据中心，而以前京东的各个业务混杂到一起。

不同的业务出现了自己的数据中心，说明了不同的业务对网络的一些硬件和结构、性能和品质有了不同要求。

而以前（特指在 2013 年和 2014 年期间）京东是仅仅来解决基本的通讯问题，比如：带宽或者简单基础的硬件可靠性问题。

网络架构的持续优化

在网络架构的持续优化上实际有很多小的细节优化，但是抽象出来的只有四个方面进行了持续的投入。

全国骨干网结构升级

对于全国骨干网来说，京东在很长一段时间内是部署在北方地区也就是北京，而 CDN 却是部署在全国；中后期在广州也部署了一些核心的节点，以及部分海外节点。

但是，当时并没有形成一个整体全国性的传输网络。今年，我们完成了改造的最重要的***阶段：启动了在北京、上海、广州三地双平面的全国 100G 传输网络平台，目前处于建设初期。

互联网接入层建设改造

互联网接入层主要是自建 BGP，解决的是互联网质量的业务体验问题，而我们没办法简单通过单线、第三方互联网解决。

在方案的设计过程中还发生了一些细节的变化，比如说：城域网从原来的四核心改为双核心结构，所有的数据中心都会双接到这两个核心上，这样结构简单、流量易于调度，在管理、自动化、可视等各个方面都有优势。

在未来我们想达到这样一个理想效果，当南北运营商网络出现大面积网络异常的时候，我们在纯粹路由的层面完成业务切换。

DCN 二层到三层的改造

我们最近一年半最痛苦的问题是网络规模太大了，现在一个网络里面至少 10 个 POD，有大量的服务器和 Docker，当前架构下设备的性能、稳定性达到了上限。

网络设备不能简单地关注端口密度、带宽容量、电源容量等，还要考虑 ARP、路由等各类表项资源，它们都是影响系统的重要因素。

在二层网络里我们做一次网络核心的故障处理，从故障状态到可用状态整个过程大概经历了五六个小时以上而且是两天完成，整个过程就像拆弹一样，操作复杂且有极高风险。

所以我们后来在运维、基础架构上列了几个规矩：

• 网络可以做到可以在 10 分钟内完成应急案处理。
• 部分网络损失不对网络造成致命伤害。
• 结构要非常简单，具备较好的可扩展性、可运维性。

提高网络割接的可靠性

网络主要有运维和建设两个方向。过去一年半里，京东网络团队有 60% 以上的精力消耗到建设上，因为发展太快了。已发生的夜间割接，2016 年 300 多次、2017 上半年超过 300 次。

为了确保网络操作的可靠性，我们建立了标准化的 SOP 操作文档、技术方案审核、双人操作等多种机制。并且，我们已在推动自动化工具逐步替代手工操作。

网络环境愈发严峻

除上述的问题外，如今的网络环境也愈发严峻。目前的网络规模越来越大，变更次数越来越高，业务场景越来越复杂。比如：上面我们提到过的为业务特别树立的一个独立的数据中心，就会出现特有的故障。

另外网络抖动问题会越发明显，通常这抖动网络上不易感知，而应用系统或用户对抖动问题却很敏感。

从做事情的角度，从提供良好服务的角度，我们应该分析到底原因是什么，该怎样解决、谁来解决。

运维工作量和效率也是非常大的挑战，例如：业务方提出 500 台服务器的从单网卡改为双网卡的 Bond，同期发生几起不易定位原因的故障需要分析排查，每件工作都是对运维力量的剧烈消耗。

当人员大量消耗在这些事务性工作上的时候就没办法做好架构优化、改进的工作了。从团队利用率上来说，我们的工作效率实际上是下降了的。

大家看上面这张图，这是 2016 年部分时期的可用性统计指标。图中有几个结果很差的互联网可用性，通常是有一些故障和问题导致的，这些问题大量的消耗了我们的运维资源，是我们***先要去解决的问题。

业务要求日益增高

之前业务要求相对简单，带宽不够则尽量做成 1:1 收敛比，设备可靠性不够则增加冗余，容量不够则扩大规模。

现在业务对超大规模数据中心、超大路由表项、低延时、25G/40G 差异化接入都提出了更高的要求。

特别是网络的稳定性，网络团队需要更全面、精细的感知网络，快速发现和定位问题，减少重复问题的发生，制定有效的应急预案，确保高水准的网络可用性。

另外，业务希望获得更多的网络信息和数据，以帮助业务进行更好的部署、管理和调度。例如及时准确的主机 IP 网络接入位置信息、流量和网络质量信息等，需要网络团队开放更多的 API 和功能支持上层应用。

***，网络排障和问题分析，是各个业务团队的常规需求，要么是网络运维团队协助排障，要么是开发出友好的工具提供给业务自助完成，显然后者是良性发展的必然选择。

监控设计思考

明确监控目标

明确监控目标的几个关键性步骤：

• 首先，“网络是不是好的”，核心是定义“好”的标准。
• 其次，要准确感知到网络异常，关键是做到对网络核心监控项准确监控。
• ***，要快速定性问题并触发应对措施，核心是决策机制，确定严重程度、影响面。

定义网络“好”的标准

什么是网络“好”的标准？用户觉得好才是真的好。

网络工程师在面对问题时的本能是排查分析问题的原因、尝试修复故障，往往眼里只有网络设备、功能协议的运行情况，异常状态和现象，而忽视了网络服务的核心是满足业务的联通性需要。

当网络规模到了一定程度之后，一两条链路或几台设备的好与坏说明不了整体网络服务是不是好的问题。

网络团队要站在更高的层面，脱离只关注白盒、只关注网络设备的思维，从用户视角看网络服务情况。

找到感知网络的有效方法

知道什么是好网络，我们就要搞定感知网络，就要模拟用户的视角，做黑盒监控。

京东网络团队在 2016 年下半年开始在黑盒监控方向走的比较快，进行了大量的实践和尝试。黑盒监控本质上还是白盒，但需要改变思维方式。

例如：交换机板卡重启仅仅是导致网络抖动的原因之一，用户视角看到的是网络抖动，在处理逻辑上要先定性网络出现了抖动再定位是什么原因引起的。

另外，在做网络核心项监控时，要抓大放小，不要什么都想一步做好，把最常见的、最严重的故障优先识别出来，首先解决核心问题。

网络异常处理的预案与决策机制

网络异常主要有两类：

• 依靠网络自身的健壮性，可以自愈或承受的，往往这种仅降低网络的健康度、增加了不可用的风险；这类异常不是我们关注的重点。
• 明显影响了网络局部或全部服务的可用性，但又没有导致网络服务中断或完全不可用，只能通过人工干预来执行应急预案的异常事件；这种问题才是最关键的、需要及时处理的。

网络监控到底要做什么

这是一个简单的总结，网络监控要干什么？随着监控的深入，我们发现想象的网络质量跟我们主观实际测到的确实不一样。

监控要看啥呢？故障可用性、健康度、交付质量，就是一个新的网络建设完以后，这部署立刻部署上、完成验收、操作的影响。我们做一个专线切换真的就是平滑的吗？我们下线板卡没有影响吗？

但是因为没有数据我们以为是好的、还有运行状态。做好以上这些才是网络监控要做的事情。

京东监控实践

监控的前期准备

准备工作如下：

• AAA [ http://www.pro-bono-publico.de/projects/tac_plus.html ]
• NTP [ http://www.ntp.org ]
• SNMP [ python + go ]
• SYSLOG [ http://www.balabit.com/network-security/syslog-ng/ ]
• CMDB [ mysql + php + python ]

特别是需要手工维护的信息，例如：设备管理 IP、互联网出口、专线接口等。

今年京东 618 的流量采集比以往有一个突破，以前的采集密度是分钟级，今年到了 10 秒级，并给我们带来巨大的震撼。

这个震撼就是我们发现原来的流量统计偏差很大，10 秒采集的结果数值增加了 20%，也就是说如果跑了 80% 的带宽，实际上是 96% 甚至***。

在前期，我们需要为监控做一些基础的工作：

• 一定要有 AAA，解决设备的统一管理问题。
• NTP，设备时间一定要正确。
• 要具备基本的 SNMP 采集能力。
• SYSLOG 可以帮我们了解很多未发现问题，进行回溯和追踪；前三点都是看事中出了什么问题，而 SYSLOG 是看事后出现什么问题，所以 SYSLOG 很重要，特别捕捉事前没见过的日志。
• 基础信息是整个监控的基础，需要注意的是很多基础信息是必须手工定义的，例如：哪些接口是专线？某台设备是什么角色等等。这类信息我称之为管理信息，是很难脱离人为因素完全自动化的。

基本面监控

基本面监控的核心逻辑是：

• 有一些显而易见的状况，说明网络一定出了问题。
• 那么就找到问题并呈现出来，先回答是否有问题（是不是好的）。

目前京东网正在使用的有：

• 互联网出口、POD 上联、DCI 的实时流量和近 24 小时流量峰值。
• 近 6 小时互联网、DCI 的总流量环比。
• 近 24 小时全网 syslog、drop、crc 的总量。
• 近 6 小时全网应用服务方法性能等关键业务异常报警的总量。
• 当前各 IDC 出口到全国各省网络质量、DCI 网络质量。
• 当前全网网络设备、服务器的总量与存活数。

基本面监控就是要做到这样一个效果：有几个重要的大屏，当你看到上面有异常的时候，就表明就一定出现了问题。如果上面的状态显示良好，说明网络没有什么大的问题，但不代表没有小的问题。

京东网络团队最近一年半就是在解决下面这几个问题：

• 流量，包括互联网出口、POD 上联、DCI 的实时流量和近 24 小时的峰值。
• 流量环比，目前我们做的互联网专线，通过环比可以看出异常来，我们专线远高于头一天，但是曲线基本结构波形是一致的，看起来问题都不大。
• 近 24 小时全网 SYSLOG 在各个时间点的总和，每一分钟异常数。SYSLOG 可能只有 0 到两三个，但是出现大量异常有几十个、上百个，就可以非常直观的看出有问题发生，接下来再去排查定位就非常容易了。
• 近 6 个小时所有业务应用方法调用性能和指标异常。

互联网质量监控的事例

上图中电信到三个省份互联网出现异常了，可以看到有电信、联通、移动还有 BGP。

电信到电信出现异常，说明是这个省内部的问题。如果仅仅是跨运营商则不需要特别的处理和关注。

上图中互联网出口流量，有一个红框画出来的出口，使用率特接近 60%，但没有超出过去 24 小时的峰值，不算严重但需要关注。

上图中可以看到箭头指出位置有 30 多个 SYSLOG 报警，很容易看出问题来。

***一个方法：通过性能可以看到有几个毛刺是不正常的。

上图是互联网质量监控，它的基本思路比较简单，展示各个机房到各个省份的质量监控。

每个小方格，从右到左是当前到近 60 分钟的网络质量，并随着时间推移向左移动，来表现过去一小时内是否有异常发生、以及异常的持续时间或恢复正常的时间。

上图的红圈位置表示有一个省的移动网络出现问题，右边图片中的红线是动态报警阈值，阈值不是固定的，而是根据实际监控的历史数据计算得出的动态阈值，这样可以避免一刀切的粗暴判断方式。

DCN 网络质量监控的事例

***是数据中心内部网络怎么去监控。微软的一篇名为 Pingmesh 的论文非常知名，它的基本逻辑是以最小的代价***化的模拟 full-mesh 的端到端网络黑盒监控效果。

从监控结果可以直观的得出来机架内、机架间、POD 内、POD 间、机房间网络质量。

上面三张图片是京东实际做出来的 Pingmesh 效果，在数据中心内网它的覆盖率接近 50%。

从监控结果看跟我们想象的远远不一样，我在很多年里一直认为数据中心内网很稳定，现在看到是有明显丢包的情况。

这类监控可以非常直观地发现网络的异常，接下来再基于白盒监控去定位问题的原因是什么。

以上是京东网络做的很有限的一些工作，做的并不多、存在很多不足，主要问题还是希望从白盒监控思维中跳出来，抽象的去看一个大的网络，从用户视角观察，要做深做细需要有更多持续的思考和实践。

网络监控展望

监控只是工具和手段，监控可以告诉我们要做好什么事，上图是网络可用性的达成情况。

从上图中我们可以分析出两件事情：

• 我们应该把主要精力放在互联网建设上，因为互联网质量是当前最严重的问题。
• 我们知道了不同数据中心互联网重量的巨大差异，其中有几个问题最严重的我们要找到原因。有人为操作导致故障、运营商大网问题、架构合理性问题等，需要去进一步分析。

在2017年我们相当大的精力是放在互联网的优化上。京东的网络下一步还有好多事情要做，就从监控这一项还有好多细节想法或者关键的问题没解决。

监控不只是简单的发现问题，还需要让工程师从问题分析里解放出来，让更初级的工程师做一些复杂的运维操作。

另外，监控是为了更好的实现自动化，提高网络可用性和运维质量效率。

王大泳，京东集团运维部网络运维负责人、资深网络架构师，主要负责数据中心网络的架构设计和运维支撑，京东网络团队负责人，承担京东商城和京东云的网络运维工作。拥有十余年互联网行业工作经验，2013 年 5 月加入京东，之前在新浪网工作近 10 年，多年来一直从事中大型数据中心网络的运维管理工作，熟悉互联网产品应用的常见网络解决方案。互联网老兵一枚，在运维相关方向摸爬滚打十几年，在京东经历了 5 次“6.18”大促保障，是京东***、二届架构委员会常委，《京东技术解密》一书联名作者。