作者简介：邓凯浪，目前任职于360，主要负责360奇云网络相关产品的研发工作。感兴趣的领域包括高性能网络服务、深包检测及用户态协议栈。

实时监控及分析网络流量对于云计算网络管理非常重要，在奇云的日常网络运营中，我们经常遇到以下一些需求：

1.虚机出现网络质量问题时，需要辅助查询的工具；
例如，用户经常会向我们反馈，某台虚机ping时延高，游戏玩家延迟高，经常掉线，让我们排查虚机网络质量是否有问题。但如果没有流量监控历史数据的话，排障很难进行；

2.精确的公网流量计费系统；
用户购买虚机时，网络资源是按照南北流量收费的，但我们对于虚机的网络流量监控是基于agent的方式，无法区分东西流量和南北流量，因此需要一个精确的计费账单；

3.对用户网络流量的洞察；
给用户提供虚机流量历史明细，流量来源地区、运营商分布，为用户分网络配资源提供决策支持；

针对上述三个需求，我们基于Intel DPDK开发了一套基于网络流的实时分析系统。系统的演进过程中主要经历两个大的版本。

一、Shikra1.0

架构：ntopng + ROLAP + Saiku
通过ntopng采集相关网络质量指标，创建多维分析模型，通过ETL将数据load到数据仓库中，利用Saiku提供即席查询服务。

优点：
基于ntopng的成熟方案，网络相关指标非常全面；

缺点：
1.在高速网络环境下有丢包的现象；
2.不能满足实时性要求；
系统每隔1小时从ntopng中load数据，做ETL处理，再加载到数据仓库中，对外提供查询服务，不能满足实时查询的要求；
3.查询效率低下，响应速度慢；
4.ntopng部分核心组件闭源；

图1. ntopng系统的使用

图2. shikra1.0 多维分析模型

图3. Saiku提供的多维分析即席查询服务

二、Shikra2.0

由于Shikra1.0无法提供实时的网络流量分析。后续我们进行了Shikra2.0的开发。

架构：DPDK + Druid + ELK + Grafana

一图胜千言

图4. Shikra2.0架构设计

通过分光器将流量从核心复制一份到DPDK应用服务器，DPDK应用在高速网络环境对数据包进行采集、处理，得到相应的网络质量指标数据后，写入Kafka，通过Kafka consumer对维度进行分解，网络流明细数据入ES以备历史明细查询，实时流量统计入Druid，提供网络流量实时分析。

在Shikra2.0中，为了解决1.0中丢包的问题，我们使用了DPDK（Intel Data Plane Development Kit）,这是一套Intel推出的专注于网络应用中数据包高效处理的数据平面开发集，运行在用户空间上利用自身提供的数据平面库来收发数据包，绕过了Linux内核协议栈对数据包的处理过程。

图5. DPDK架构图

下图列举了在10GbE线速情况下，处理报文所带来的挑战及DPDK给出的一些方案。

DPDK主要有以下几个核心思想：

1.通过UIO技术将报文拷贝到用户空间进行处理，从而绕过内核协议栈；

图6. 网络报文处理方式 Kernel Space V.S. User Space

2.通过大页内存，提高TLB命中率，降低TLB miss开销，进而提高CPU访问速度；

图7. TLB的使用

3.通过CPU亲和性，绑定网卡和线程到固定的core，减少CPU任务切换；
4.通过无锁队列，减少资源竞争；

下面为Shikra系统使用中的一些截图。

图8. 机房带宽使用监控

图9. 虚机带宽使用监控

图10. 虚机时延实时监控

图11. 虚机地区/运营商时延监控

图12. 网络流历史明细查询

三、Shikra 使用案例

下面结合奇云网络运营中的一个常见问题，来说明Shikra系统在实际中是如何使用的。

问题现象：用户反馈虚机ping时延高。

问题定位步骤：
1.检查虚机公网IP流量监控，确认带宽是否接近用户购买带宽；
2.上述方法未解决，则检查该IP各地区、运营商网络时延是否异常，确认是否部分地区、运营商到虚机网络质量有问题，并检查流量明细数据，得到网络时延较高的网络流；
3.转向运营商告障。