作者：vivo 互联网服务器团队- Ming Yujia
随着网络规模的快速发展，网络状况的良好与否已经直接关系到了企业的日常收益，故障中的每一秒都会导致大量的用户流失与经济亏损。因此，如何快速发现网络问题与定位异常流量已经成为大型企业内必须优先解决的问题，诸多网络流量分析技术也同时应运而生。
随着网络规模的快速发展，网络状况的良好与否已经直接关系到了企业的日常收益，故障中的每一秒都会导致大量的用户流失与经济亏损。每一家企业都在不断完善自己的网络监控手段，但在监控体系建设过程中，却又不可避免的面临以下难点：
网络流量数据庞大：由于网络流量的规模和复杂性都非常高，很难对大量的数据进行有效的监控和分析。
流量数据采集分析建设成本高昂：为获取准确的流量数据，需要使用高效的数据采集技术和大容量的存储设备，以及大量的开发资源，这使得监控成本直线上升。
监控手段单一、缺乏扩展性：传统的监控手段一般只能监控固定的几个数据点，难以针对不同的网络环境进行定制化和扩展。
难以快速定位和解决问题：由于网络流量数据量大、变化频繁，往往需要花费大量的时间和精力才能找出问题根源。
因此，如何利用尽可能低的监控成本快速发现网络问题与定位异常流量已经成为大型企业内必须优先解决的问题，诸多网络流量分析技术也同时应运而生。
sFlow技术就是这样一种高效、灵活的解决方案。它可以通过流量采样技术抽取数据包中的部分信息，从而实现对大量网络流量数据进行持续监控。同时，sFlow技术还具有灵活的配置和扩展性，可以根据实际需求进行定制，并支持多种网络设备和协议。这些优势使得sFlow技术在现代网络监控和管理中得到广泛应用。
主流的网络流量采集主要分为全流量采集与采样流量采集两种。
全流量采集包括端口镜像、分光设备等方式。在流量庞大的网络中，使用端口镜像方式不仅会导致全链路时延增加，而且会使吞吐量庞大情况下的网络设备压力激增。分光设备虽然可以降低链路时延，但同样存在采购价格高昂的门槛。除此之外，由于大型企业内IDC规模庞大，由此导致的全流量数据量也会激增，想要完整的靠自研做好全流量数据分析，不仅需要一定的存储计算资源，也需要一定的软件开发周期，不利于项目的快速搭建成型。
在流量分析系统欠缺的情况下，使用采样分析的优势就体现出来了，相对于全流量，他部署成本低，数据分析代价小，很适合对异常流量的快速定位以及网络内的趋势占比分析。以下主要对比介绍sFlow与Netflow两种采样方式的优缺点。
sFlow在流量监控上范围更广，在满足硬件要求的IDC内部环境，使用sFlow进行采样流量监测，可以有效降低网络设备负载，并且提供实时流量监控手段，以应对突发网络异常场景。
在满足硬件条件的情况下，基于sFlow的基础系统设计很简单，使用sFlow agent + sFlow collector + sFlow analyser即可实现整个流程的数据闭环。
sFlow agent：通过enabled相关网络设备上的sFlow能力，设定采样比等参数并制定收集端相应地址，即可对端口收发流量进行采集。agent侧更重要的反而是如何确定采集的网络设备范围，相对于无目的的全量网络设备部署，针对边界核心网络设备进行部署更有意义，因为所有的对外流量最终都必须经过边界网络设备。在能更好监控外部流量异常的情况下，也能减轻数据存储负担。
sFlow collector：收集并解析agent侧采集传输的 sFlow datagrams。
sFlow analyser：对格式化的数据进行可视化分析展示，以供网络管理员进行有效观测分析。
在确定了基本架构之后，如何进行组件选用与定制化功能扩充，开源解决方案elastiflow为我们提供了很好的示例，笔者基于开源进行了扩展，以满足更多定制化功能。
sFlow agent：使用上报统一vip的形式进行端口流量采样（官方规定的采样比需是2^n），可以利用vip的LB能力进行负载均衡，使得sFlow报文均衡打到收集端固定端口。针对不同的网络线路设定不同的采样比，在降低数据存储的同时也可以保证重要线路更高的精准性。
sFlow collector：使用ELK套件进行数据收集与可视化分析是比较成熟的技术方案之一。因此，收集端我们使用logstash进行原生数据报文收集与解析。elastiflow的作者使用了logstash内原生的udp-sFlow报文解析组件进行数据解析，但笔者在实际测试中发现，虽然该方案能得到结构化更好的数据格式，但在数据解析的性能表现上很差，在数据量庞大的情况下会造成大量数据丢包现象，导致数据准确性下降。而sFlowtool由于底层是基于C语言来编写的，在性能表现上很优异，单物理机（32c64g）即可达到10w+tps，虽然对sFlow报文解析后的数据结构化要弱一点，但可以在后续分析模块对数据进行清洗与结构化构建。sFlowtool分析的数据示例如下所示。经由logstash的数据发送到kafka消息队列中。
[root@server src]# ./sFlowtool -l
FLOW,10.0.0.254,0,0,00902773db08,001083265e00,0x0800,0,0,10.0.0.1,10.0.0.254,17,0x00,64,35690,161,0x00,143,125,80
FLOW后的字段释义如下
agent_address
inputPort
outputPort
src_MAC
dst_MAC
ethernet_type
in_vlan
out_vlan
src_IP
dst_IP
IP_protocol
ip_tos
ip_ttl
udp_src_port OR tcp_src_port OR icmp_type
udp_dst_port OR tcp_dst_port OR icmp_code
tcp_flags
packet_size
IP_size
sampling_ratesFlow analyser：通过从kafka实时消费数据，将数据进行清洗结构化，并借助三方meta data，对解析后的数据进行软件定义，以便于后续存储与分析。
database+display：使用Elasticsearch+Kibana进行存储与可视化展示，同时也可以利用mertic beat对logstash的采集性能进行监控。Kibana作为Bi类的数据可视化方案，提供了大部分可供免费使用的图表及Dashboard，可以很好的进行可视化分析。
拥有原生数据的情况下，我们已经能基于一些ip五元组等进行基本会话流量分析。但是流量数据所能体现的价值远不止这些，利用企业内其他的cmdb等平台，可以为我们的流量数据提供更大价值。
网络设备维度：通过数据内的交换机地址，出入向端口，可以根据采集配置的交换机端口index，判断该条流量出入向。也可基于网络设备ip，赋予其通道，线路，以及设备名等等其他属性。
ip维度：ip五元组提供了探索数据更高的可能，我们可以根据归属ip，判断他的项目，部门等归属信息，也可反向关联域名。这在对异常流量进行分析判断时能够快速定位到所属业务方，很大程度提高了运维效率。
由于Elasticsearch本身的数据压缩效果不够理想，使得我们在进行长时间存储数据时体量庞大臃肿。相应的，olap型数据库Druid很好地解决了这个问题，数据采样后经过分析端严格的结构化处理，可以在Druid内实现很好的数据压缩。除此之外，Druid内嵌的数据预聚合能力也能更好的帮助我们对历史数据进行降精处理，减少存储压力。切换存储引擎后，也就意味着没办法再使用Kibana进行通用展示，使用自研的web服务框架也能够应对灵活的需求场景，实现更多定制化的分析。
虽然流量数据经过了采样降精，但整体的数据量依然很庞大。高效快速的进行流处理，降低整体系统时延至30s内，能够更快的帮助网络管理人员发现问题，除却利用传统的流处理工具外，我们也可以使用Celery来构建一个轻量高效易扩展的分布式流处理集群。
Celery是一个简单、灵活且可靠的，处理大量消息的分布式系统，专注于实时处理的异步任务队列，同时也支持任务调度。我们基于celery实时异步处理的特性，设计 celerybeat → watcher → producer → consumer 的消费链路来进行流处理。
celery beat：作为定时任务的触发器，每1s向watcher队列里派发一个新任务。
watcher worker：在队列中拿到任务后，转发给producer，并根据设置的队列最大值，对producer队列进行拥塞控制。
producer worker：在队列中拿到任务后，从kafka中获取采集的流量数据，按照batch size批量发送给consumer队列，并根据设置的队列最大值，对consumer队列进行拥塞控制。
consumer worker：在队列中拿到任务后，根据本地缓存/共享缓存内的业务信息，对采集数据进行数据清洗，打业务标签等操作，并写入另一kakfa或直接写入database。
每一个角色以及节点可以通过Celery broker进行通信，实现分布式集群部署，针对consumer单元化操作，可以使用eventlet以协程方式启动，以保证集群高并发消费。
通过基于网络cmdb的ip匹配，对流量数据进行机房维度的汇总，可以得到机房整体的对外出入向流量分析，在IDC同外部交互时，整体流量的趋势变化，是判断带宽占用程度的直接标准。
通过对网络设备基于ip+ifindex的逻辑信息映射，可以对核心通道线路做到聚合展示，在针对一些公网线路异常，专用线路带宽打满等异常问题时，通过观察线路分析可以直接准确定位故障发生的第一时间点。
虽然sflow只截取了报文的头部信息而不包含数据包部分，但ip五元组本身也提供了极大的网络流量分析价值。
利用会话信息，我们可以准确有效的定位异常流量的ip归属，通过ip+服务端口的，我们甚至可以定位具体产生流量异常的服务与进程，从而做出下一步决策。除此之外，ip也能同企业内CMDB产生联动，定位到ip所属资源的所在资源组，从而得到不同部门/行政组产生的流量占比分析，这同时也有利于在产生异常流量时第一时间感知到相关业务，并进行通知管控。
除了结合内部信息，通过运营商提供的归属地信息，我们可以查看ip访问的来源，进行相关归属地分析与Dashboard制作。
要实现对网络全面、实时的监控分析必须依靠先进有效的网络监控协议和技术来满足业务日益增长的需求。基于sFlow的流量分析虽然在轻量化构建上有着很大的优势，在面对异常流量时也能够基于流量趋势与分布占比做出快速反应。但sFlow本身的采样却不包含报文内数据包的信息，针对一些sql注入、数据安全等等网络安全攻防问题，没办法提供准确定位与解决方案。因此，全流量分析也应是流量分析系统未来必不可少的一环，两者相结合才能够提供更全面、更精细化的流量监控，为数据中心的网络安全保驾护航。
虽然sFlow技术在网络性能监控和管理领域中得到了广泛应用，但在未来更大规模的网络流量场景冲击下，还需要具备更多的能力：
1.支持更多协议和应用：sFlow监控的思想不仅适用于网络流量，还可以监控应用流量、虚拟化环境、云平台等。未来，sFlow技术应该支持更多的协议和应用，以更好地适应新型网络环境。
2.自适应流量采集技术：sFlow技术的流量采集技术是固定周期的，但是随着网络流量的变化，固定周期的采集可能无法准确反映网络实时状态。未来，sFlow监控技术应该支持自适应流量采集技术，能够根据实际网络流量变化自动调整采集周期。
3.便捷的管理功能：sFlow目前的配置更多依赖于网络管理人员在交换机上进行配置，无法实现一键下发，自动发现，快速调整采样比等等功能，未来更需要一个能够便捷下发命令，热加载配置变更的sFlow管理平台。