sFlow网络流量采集器设计与性能控制研究

吴 烁，林南晖

（1.华南师范大学计算机学院，广东 广州 510631，汕头大学网络与信息中心，广东 汕头 515063；2.华南师范大学网络中心，广东 广州 510631）

sFlow网络流量采集器设计与性能控制研究

吴 烁1，林南晖2

（1.华南师范大学计算机学院，广东 广州 510631，汕头大学网络与信息中心，广东 汕头 515063；2.华南师范大学网络中心，广东 广州 510631）

基于给出的sFlow采集器设计框架，研究了采集器的线程管理和性能监测技术，设计了能适应网络流量变化，并长期稳定工作的采集器.

sFlow采集器；线程管理；性能监测

0 引 言

流量监测是网络管理中一项重要任务，监测数据为网络的优化、故障的发现、异常事件的预警提供了必不可少的依据.当今网络的特点是规模大，结构复杂，主干速度高（10 Gbps），应用种类多.传统的网管与流量测量技术（SNMP、RMON、Sniffer等）已无法满足现代网络流量监测的需要[1].在这种背景下，sFlow技术得到了越来越多的重视.

sFlow是InMon公司提出的网络流量监测技术，版本v4于2001年成为互联网网络流量监测标准（RFC3176）[2]，最新版本是v5[3].尽管当前已有不少支持sFlow流量采集及监测的软件[4]，但商业软件功能、性能的限制，特别是原始流量数据访问权限的不足，都制约着流量分析研究的进行.关于sFlow的相关研究和文献报道多专注于构建基于sFlow网络流量监测系统的整体方案或如何利用sFlow来达到特定监测目的，很少详细讨论sFlow采集器的设计.而对于sFlow报文信息内容，多数文献只简单描述其中部分字段，很少对信息内容作深入探讨.事实上，sFlow采集器是sFlow监测系统最基础的部分，没有采集器，就无法进行数据的采集、存储以及后继的分析.本文重点讨论采集器的设计及实现细节，详细解释报文信息字段含义，以及在流量采集中的作用，随后给出一个sFlow采集器总的设计框架.基于这个框架，再通过线程池管理、性能监测、缓冲区调节等，使得采集器能适应网络流量的变化，从而长期稳定地工作.

1 sFlow技术

1.1 技术框架

基于sFlow技术的网络流量监测系统框架[5]如图1所示，内嵌在设备（交换机/路由器）里的专用集成电路ASIC对经过设备的数据包进行采样，提供数据包自身信息；转发/路由表提供与数据包相关的路径信息；端口计数器提供端口统计信息.Agent将来自三种信息源的信息组装成sFlow报文，发送到sFlow采集器.采集器接收sFlow报文后，按sFlow数据格式规范解析报文，得到有用的流量信息，供后续流量分析使用.可见，sFlow报文包含了sFlow系统监测的所有数据，正确理解sFlow报文结构以及各字段含义，对于采集器的设计是相当重要的.

图1 监测系统框架

1.2 相关概念

1.2.1 采样机制、样本和记录

sFlow是基于采样的技术，Packet flow sampling按采样率N对通过设备端口的网络数据包进行数据包采样；Counter sampling按采样间隔定时从端口计数器（interface counter）获取各端口的统计信息.两种采样机制产生相应的样本：流样本（flow sample）和计数器样本（counter sample）.流样本描述网络数据包特性，不仅包含原始数据包的包头信息，还可以包含与原始包传送过程相关的信息.计数器样本描述端口流量特性，同样包含了多种丰富的计数信息.样本中的信息是用记录（record）的格式来组织各种信息的，相应的有流记录（flow record）和计数器记录（counter record）.

1.2.2 sFlow报文

单个样本的长度比较小，只有IP数据包可支持的最大长度的十几分之一，但产生频率高，数量多，用一个IP数据包发送一个样本浪费资源，所以将几个样本组装起来发送，节省资源且不影响实时性.sFlow报文是网络设备向sFlow采集器传送样本所使用的网络报文，是一个UDP报文，由Agent采用XDR标准（RFC1832）封装，其中包含了Agent的信息和若干个流样本和计数器样本.值得注意的是，每个sFlow报文中承载的是多个采样样本，而不是单一一个采样样本.如果误把sFlow报文中的相关数据当成一个采样数据来统计，必然导致错误结果.

1.3 报文结构及信息字段

sFlow报文的结构见图2，sFlow报文由报文头部、流样本和计数器样本的集合构成.报文头部主要是与Agent有关的信息，具体的字段见表1.Agent_address是产生报文的Agent地址.Sub_agent_id是Agent中各Sub Agent的标识号，在分布式环境下，是由各个Sub Agent处理各自管辖的流量分支的.Datagram_SN可用于检测sFlow报文是否丢失.由于各个Sub Agent的Uptime可能不同步，因此在设计中使用的是采集器接收到报文的时间.

图2 报文结构

表1 报文头部结构

流样本和计数器样本都是由样本头部以及若干个记录构成的.流样本头部主要是与数据源（交换机端口）、采样参数有关的信息，具体字段见表2；计数器样本头部只有表2中的部分字段，意义相同，不再赘述.Data_format后12位用来区分样本的类别，根据类别的不同，采集器进入不同的程序分支继续解析后面的字段.Sample_length可用于解析过程中的越界判别.Sample_SN标识来自同一数据源（交换机端口等）的不同样本，可用于检测样本是否丢失.Datasource_type_index（或Datasource_type，Datasource_index）描述数据来源，在后续的流量统计、分析过程都有重要作用.Drops可用于Agent的超荷告警.

表2 流样本头部结构

续表2

sFlow标准v5[3]定义了16种流记录和6种计数器记录.除了原始包头记录（raw packet header record）的字段稍微复杂，其它记录字段的名称都具较好的自描述性，不在此一一列举.表3以原始包头记录为例说明记录的格式，其它记录的详细信息参见文献［3］.Header_protocol标识了Header字段对应的包头类型，例如，Header_protocol=1说明是以太网帧头部，Header protocol=11说明是IP包头部.得到包头类型，就可按规定格式对包头进一步解析，进而得到上层协议的相关信息，如端口号等.Header_size可用于包头解析过程中的越界判别.正确理解了sFlow报文结构及字段含义，解析sFlow报文就不存在大的问题了.解析过程要注意的一点是，以字段为单位读取多个字节后，要先对这些字节作网络字符顺序-主机字符顺序的转换，然后才转换成该字段所对应的数据格式.

表3 原始包头记录结构

2 采集器设计

2.1 框架

采集器由管理控制线程、接收线程、解析线程、性能监测线程构成，见图3.

管理控制线程根据配置信息初始化变量创建并启动其它线程.初始化工作完成后，管理控制线程负责处理性能监测线程的结果或响应用户命令.用户命令主要是修改各种配置信息.

图3 采集器框架

接收线程循环读取指定Socket端口（UDP6343）的数据包.在.Net中，UDPClient.receive采用阻止同步的工作模式，当没有数据包到达时，接收线程被阻塞，只有接收到数据包时，线程才会执行后面的代码.接收线程接收到UDP包后，首先判别包的来源地址是不是许可地址，丢弃非许可地址来源的包，提取许可包中的sFlow报文（去掉UDP头部），然后连同报文接收的时间一起写入接收缓冲队列ReceiveBuff；接着进行缓冲判别，如果接收缓冲队列已满，则将缓冲队列交解析线程解析，并创建新的缓冲队列；最后，继续下一接收操作.

对于接收缓冲队列中的每个sFlow报文，解析线程通过构造SQL语句片段的方式保存所需的字段信息，最后形成一个完整的SQL语句.为了不频繁地连接数据库，SQL语句被暂时存放在SQL语句队列中，直到解析线程处理完接收缓冲队列的所有报文，才执行写入数据库的操作.同一时间内，系统有多个解析线程，并通过线程池来管理这些线程.

性能监测线程定时向管理控制线程汇报系统工作状态，发送错误或超荷告警.

2.2 线程管理及线程池

报文采集是一个高速、海量的数据处理过程，采集器的设计不可避免地要涉及到多线程管理的问题，这里主要是指多个解析线程的管理.

由于网络流量变动较大，固定数量线程轮询方式不能很好地工作，既不能高效利用系统资源，也不能很好地适应流量变化.当网络流量较低时，可能多个线程一直轮空；而当网络流量很高时，又会由于线程数不足、处理不及而导致丢包.如果增加线程数量，又由于访问公共缓冲区的需要而进行互斥控制，系统性能也将随着下降.采集器以被动接收模式工作，只能尽力而为地处理接收到的数据包，在这种情况下，固定长度的公共缓冲区无法满足需求.但如果使用长度可变的公共缓冲区，在基于垃圾回收机制的开发工具（如JAVA、.Net）中，可能会由于内存泄漏而使系统最终陷入瘫痪状态.一个简单的模型可避免使用公共缓冲区：每接收到一个报文就创建一个新线程进行处理，处理完成后再销毁线程释放资源.但是，由于线程的创建、销毁都要占用一定的CPU时间，在频繁的任务请求过程中也会占用很大部分CPU资源，因此不适宜用于采集器的开发.

线程池技术可克服上述模型频繁创建、销毁线程的缺点.线程池通常由1个监视线程、n个任务线程以及任务等待队列组成，n是线程池的尺寸，大小可以动态调整.监视线程负责指派和回收任务线程，监视线程池繁忙状态，维护线程池的大小.任务线程是负责完成具体任务的，可以为每个任务创建私有的缓冲区，任务完成后释放缓冲区.空闲的任务线程组成一个空闲线程队列，阻塞在后台，一直存在系统中，以节省创建和销毁线程的开销，从而显著提高系统的性能.

在本文设计的采集器中，线程池中的任务线程就是解析线程.接收线程为每个任务创建一个私有的缓冲队列，当这个队列已满时，接收线程调用ThreadPool.QueueUser-WorkItem向线程池提交处理请求.ThreadPool.QueueUserWorkItem传递了两个参数，一个是私有缓冲队列，一个则指示执行任务所用的方法，这个方法的流程见图3解析线程部分.当有空闲线程时，线程池调用其中一个作为解析线程，待解析线程完成任务并释放资源后，返回空闲线程队列中；当没有空闲线程时，线程池将任务请求挂在任务等待队列中.

线程池有最大线程数（MaxThreads）和最小空闲线程数（MinIdleThreads）两个重要属性.线程池中的线程（任务线程和空闲线程）总数是由MaxThreads决定的，但由于每个线程要分配堆栈资源，为了节省资源，线程池只保留数量等于MinIdleThreads的空闲线程.当空闲线程数小于MinIdleThreads时，创建新的线程，创建前线程池有半秒的内置迟延，以防止线程刚创建又被销毁.但因为这个内置延迟，有时候任务到达时仍需要等待一段时间才得以执行，尽管正在运行的线程并不多.因此，当短期内有许多任务要处理时，可以通过SetMinThreads来适当增加空闲线程数[6]，会显著增加系统的吞吐量.

2.3 性能监测、调节及告警

sFlow报文是通过UDP传输的，由于此方式具有不可靠性，因此采集器无法保证不丢包，而sFlow技术基于采样的流量统计方式具有一定的误差率，少量的丢包并不影响统计结果.但采集器仍应尽量降低丢包率，而且能报告丢包情况.Datagram_SN和Sample_SN可用于监测丢包情况.性能监测线程定期查询前一分钟收到的报文或样本个数sum以及SN的最大与最小值，当maxSN－minSN＋1＞sum时，向管理控制线程报告报文丢失事件.此外，性能监测线程每隔半秒钟查询当前系统性能状态，如CPU利用率、内存占用情况及线程数，将系统每分钟的最大性能指标记入性能日志中.

采集器可以针对随网络流量而变化的报文的到达速率作相应的调整，同时结合接收缓冲队列长度及线程池MinIdleThreads的管理，以提高处理效率.

较长的接收缓冲能应付流量高峰期的突发流量，同时使CPU时间片得到更好的利用.但在流量比较低时，过长的接收缓冲可能影响实时性能，而过短则会使同时运行的线程过多，互斥访问频繁发生，影响运行效率.使用dotTrace工具（在www.jetbrains.com下载）分别测量每个线程被调用的次数及运行时间，计算多种缓冲队列长度设置下的运行效率，以找到合理的缓冲队列长度.测试双CPU机器的结果是：在几个流量不同的时间段内，当任务线程数为4～6个时，每个包的平均解析时间是比较短的.由此，可以根据任务线程的个数来调节缓冲队列长度，进而使任务线程个数处于比较合理的区

其中N是新的缓冲区大小，C是调节前缓冲区的大小，T是前一分钟最大任务线程数.判别区间是[2，8]而不是[4，6]，是为了防止缓冲长度在某个区间里来回震荡调节.

足够的空闲线程数可保证解析任务立刻执行，通过以下方式调节线程池的MinIdleThreads：每隔一分钟，判断最大与最小任务线程数之差，如果大于MinIdleThreads，则MinIdleThreads＋1；如果小于MinIdleThreads／2，则MinIdleThreads－1.调节过程中还要保证MinIdleThreads不小于CPU个数.

受硬件条件的限制，采集器的处理能力有限，因此必须有出错告警和超荷告警机制.性能监测线程要报告运行中由于链路或设备故障造成的各种错误信息，包括丢包数，非许可的Agent地址，解析错误等.而超荷告警则包括高Drop数，高丢包数等.告警阈值通过配置文件定义，也可以在运行期间由用户重新设定.间，见公式（1），

3 实验环境及结果

3.1 实验环境

将采集器运行在一台PC（双核Petium E2160@1.8 GHz，1 G内存）上，采用SQLServer 2005作为后台数据库系统，安装在服务器（4核Xeon3GHz，2G内存）上.sFlow报文来自两台核心交换机（Foundry MG8，Foundry RX4，采样率分别配置为1/1 000和1/2 048）的4个10 Gbps和12个1 Gbps端口，监测校园网主干端口的流出流量.

3.2 结果

最初，采用动态创建线程方式时，采集器经常出现丢包现象.缓冲区长度为1时，每分钟都会出现丢包，增大缓冲区长度可使发生丢包的时间间隔变大，但创建解析线程要耗费比较多的CPU时间，接收线程不能及时创建新的接收缓冲区，因此仍无法杜绝丢包现象.而采用常驻线程轮询方式时，工作不稳定，出现不规则的丢包现象，而且会不定期死机.

改用线程池技术并引入调节机制后，在2009-07-12至2009-09-20期间持续运行采集器.根据性能监测日志记录，CPU占用率低于5%，内存使用维持在12～16 M之间.在此期间，每天采集样本个数在15000000到19000000间，绝大部分时间的丢包率为0，偶尔（几天中的某一秒钟内）有极少量（5～20个）样本丢失，丢包率小于1/750 000.通过对Datagram_SN和Sample_SN丢失时间的记录进行对比，发现丢失并不是在采集器处理过程中发生的，而是在sFlow报文向采集器传输过程中丢失的（即sFlow报文并未到达采集器已丢失，这是由于UDP传输的不可靠性造成的）.

图 4、 5、 6 分别是实验末期（2009-09-17T00：00：00 至 2009-09-20T00：00：00）每小时采集的样本数量、接收缓冲区平均长度以及平均解析线程数量.如图4所示，流量最高和最低时段所采集的样本数量相差是比较悬殊的.对比图4与图5可见，缓冲区长度随着流量的变化而变化.如图6所示，此期间解析线程数维持比较稳定的数量.在高流量的时段，平均线程个数在4到6之间，在2.3节中提到，任务线程数在这个范围内，采集器的效率是比较高的.可见，在持续运行了2个多月后，采集器仍保持良好的调节能力.实验结果表明，采用线程池技术方式的采集器能长期持续稳定地运行.

图4 每小时样本数量

图5 每小时平均缓冲区长度

图6 每小时平均解析线程数量时间

综上可见，本文提出的sFlow采集器框架及技术设计能较好地适应校园网络流量变化，长期稳定工作.

[1] 刘国萍，左维.基于sFlow技术的通信网络流量异常监测方案[J].计算机工程，2007，33（6）：245-247.

[2]Phaal P， Panchen S， Mckee N.InMon Corporation’s sFlow： a method for monitoring traffic in switched and routed networks[EB/OL].http://www.ietf.org/rfc/rfc3176.txt，2001-09-15.

[3] Phaal P.sFlow version 5[EB/OL].http://www.sflow.org/sflow_version_5.txt，2008-04-27.

[4] sFlow.org.sFlow collectors[EB/OL].http://www.sflow.org/products/collectors.php，2009-10-15.

[5] InMon Corporation.sFlow in operation[EB/OL].http://www.sflow.org/process/process_full.htm，2009-03-09.

[6] MicroSoft Corporation.托管线程池[EB/OL].http：//msdn.microsoft.com/zh-cn/library/0ka9477y.aspx，2009-10-15.

Abstract：Based on a given designing framework for sFlow collector， threads management and performance monitoring techniques are studied and a collector with adaptive and longterm stability of traffic is designed and implemented.

Key words：sFlow collector； datagram format； thread pool

Research on Design and Control of sFlow Collector

WU Shuo1，LIN Nan-hui2

（1.School of Computer， South China Normal University,Guangzhou 510631， Guangdong， China； Network and Information Center， Shantou University， Shantou 515063， Guangdong， China； 2.Network Center， South China Normal University， Guangzhou 510631， Guangdong， China）

TP 393.07

A

1001-4217（2010）02-0064-09

2009-10-15

吴烁（1978-），女，广东潮州人，硕士研究生.研究方向：计算机网络.E-mail：swu@stu.edu.cn

教育科研基础设施IPv6技术升级和应用示范项目（CNGI2008-084）