网络相当于互联网服务的神经系统和循环系统。监控是网络运维团队了解网络服务的眼睛。随着网络规模的快速发展以及运维技术和理念的演进，网络监控不再满足于简单地掌握网络设备的运行状态、流量、时延和丢包等情况。如何准确展现服务可用性，快速发现和定位问题，提升人工和自动化运维效率，是迫切的需求和挑战。本文分为四个部分介绍京东网络团队在监控方向的一些思考和做法：京东网络现状。监控设计思维。京东监控实践。网络监控的观点。京东网络现状我们可以从数据规模上看京东的业务增长。下图是京东从2014年618到2017年618所有出口和专线数据流量的图表，蓝色是专线DCI，红色是互联网的公网流量。从上图可以看出，2017年618的DCI流量增长非常非常快；与前一年相比，几乎翻了一番。主要原因是大数据和一些后台日志分析系统占了很多流量。流量占比大。2017年最大的变化之一就是很多独立的业务都部署了自己的数据中心，而过去京东的各种业务都是混在一起的。不同的业务有自己的数据中心，这说明不同的业务对网络的一些硬件和结构、性能和质量的要求是不同的。过去（尤其是2013年和2014年期间），京东只解决基本的通信问题，例如带宽或简单的基本硬件可靠性。网络架构的持续优化在网络架构的持续优化中，其实有很多小的细节优化，但只在四个抽象方面进行了持续的投入。国家骨干网结构升级国家骨干网方面，京东长期部署在北方地区即北京，CDN则在全国部署；中后期，一些核心节点和一些Overseas节点。但当时还没有形成覆盖全国的输电网络。今年，我们完成了最重要的第一阶段转型：在北京、上海、广州推出了全国双平面100G传输网络平台，目前正处于建设初期。互联网接入层的建设与改造互联网接入层主要是自建BGP，解决的是互联网优质服务体验问题，不能简单地通过单线、第三方互联网来解决。在方案的设计过程中，一些细节发生了变化。比如城域网，从原来的四核结构变成了双核结构。所有数据中心都将连接到这两个核心。这种结构简单，流量易于调度，在管理、自动化、可视化等方面具有优势。未来，我们要达到这样理想的效果。当南北运营商网络出现大规模网络异常时，我们会在纯路由层面完成业务切换。过去一年半来最痛苦的问题就是网络规模太大。现在一个网络至少有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小时内Internet和DCI的总流量。近24小时全网syslog、drop、crc总量。近6小时全网应用服务方式性能等关键业务异常告警总数。目前，各IDC向全国各省输出网络质量和DCI网络质量。全网网络设备和服务器的当前总数和存活数。基础监控就是要达到这样一个效果：有几个重要的大屏幕，当你在上面看到异常，就说明一定有问题。如上图状态良好，说明网络没有大问题，但不代表没有小问题。京东网络团队在过去一年半的时间里一直在解决以下问题：流量，包括互联网出口、POD上行、DCI实时流量和过去24小时的峰值。与前一天相比，可以看出我们目前做的互联网专线的异常。我们的专线比前一天高了很多，但是曲线的基本结构和波形是一致的，好像没有什么大的问题。过去24小时内各时间点全网SYSLOG总和，每分钟异常数。可能只有0到两三个SYSLOG，但是如果有几十上百个异常，非常直观的看出有问题，然后就非常容易排查和定位。在过去的6小时内，所有业务应用方法调用的性能和指标均出现异常。网络质量监控示例上图，电信去了三个网络异常的省份。可以看到有电信，联通，移动，BGP。电信对电信有异常，说明是本省内部问题。如果只是跨算子，不需要特别处理和注意。在上图中，Internet出口流量有一个用红色框绘制的出口。利用率接近60%，但并未超过过去24小时内的峰值。这并不严重，但需要注意。上图中可以看到箭头所指的SYSLOG告警有30多条，很容易看出问题所在。***A方法：通过性能可以看出有几个毛刺，是不正常的。上图为互联网质量监控。它的基本思路比较简单，展示了从各个机房到各个省的质量监控。每个小方块，从右到左，显示从当前到近60分钟的网络质量，随着时间的推移向左移动，显示过去一小时内是否有异常，以及异常持续时间或时间到恢复正常。上图红圈位置表示某省移动网络有问题。右图中红线为动态报警阈值。阈值不是固定的，而是根据实际监控历史数据计算出的动态阈值，避免一刀切。严厉的判断。DCN网络质量监控最好的例子就是如何监控数据中心的内部网络。微软的一篇论文Pingmesh非常有名，其基本逻辑就是以最小的代价最大化模拟全网状端到端网络黑盒监控效果。从监控结果可以直观的了解机架内、机架间、POD内、POD间、机房的网络质量。以上三张图是京东实际制作的Pingmesh效果。其在数据中心内网的覆盖率接近50%。从监测结果来看，与我们想象的相差甚远。多年来我一直认为数据中心的内网很稳定，但是现在看到有明显的丢包现象。这种监控可以非常直观的发现网络异常，然后基于白盒监控来定位问题的原因。以上是京东网络所做的一些非常有限的工作。做的事情不多，不足的地方也很多。主要问题是跳出白盒监控思维，抽象地看待一个大网络。站在用户的角度去观察。做深做细需要更多的持续思考和实践。网络监控展望监控只是一种工具和手段。监测可以告诉我们应该做什么。上图展示了网络可用性的实现。从上图我们可以分析出两点：互联网建设要重点抓，因为互联网的质量是目前最严重的问题。我们知道，不同数据中心的互联网权重存在巨大差异，我们要找出几个最严重的问题的原因。人为操作导致的故障、运营商的大网络问题、架构的合理性等问题需要进一步分析。2017年，我们在互联网的优化上投入了大量的精力。京东入网下一步还有很多事情要做。从监控方面来看，还有很多细节思路或关键问题没有解决。监控不仅仅是发现问题，还需要把工程师从分析问题中解放出来，让更多的初级工程师去做一些复杂的运维操作。此外，监控是为了更好地实现自动化，提高网络可用性和运维质量和效率。王大勇，京东集团运维部网络运维负责人，高级网络架构师，主要负责数据中心网络的架构设计和运维支持，京东网络团队负责人，负责京东商城、京东云的网络运维。拥有十余年互联网行业工作经验，2013年5月加入京东，此前在新浪网工作近10年。多年从事中大型数据中心网络运维管理工作，熟悉互联网产品应用的常用网络解决方案。在运维领域耕耘十余年的互联网老手。他在京东经历了5次“6.18”大促保障。.
