CN103678085A - 一种流量动态可控的系统监控数据采集方法 - Google Patents

Abstract

本发明涉及数据采集和流量控制领域，具体是一种流量动态可控的系统监控数据采集方法,所述的流量动态可控的监控数据采集方法主要分为三个部分，分别是监控数据异步采集处理，流量控制开启检测和流控数据合并机制；所述的监控数据异步采集处理方法如下：通过调用系统线程接口，监控模块在初始化后启动一个单独的监控数据处理线程负责系统数据的多目标处理输出；动态流控的一个总周期可以划分为两个阶段：流控检测阶段T_d和流控执行阶段T_e。本发明同现有技术相比，其优点在于：通过流速权控制算法，保证关键实时系统的平稳运行，能够有效地满足不同监控目标的监控数据采集需求，并通过特征数据的合并方法，保证了落地数据的质量。

Description

一种流量动态可控的系统监控数据采集方法

[技术领域]

本发明涉及数据采集和流量控制领域，具体是一种流量动态可控的系统监控数据采集方法。

[背景技术]

系统状态数据采集模块可以实时记录程序的运行情况、错误的发生现场等数据，并输出采集的数据到多个目标如屏幕，文件和数据库，从而帮助开发人员和运维人员了解系统状态、审计操作流程、排查错误原因、存档系统数据等。因此，在关键实时系统的开发和运行中，特别是对于具有高可用性目标的交易系统来说，数据采集模块的良好设计与实现不仅有利于代码重用，而且对于系统的稳定高效运行具有重要的意义。

当今主流的监控数据采集框架或多或少都借鉴了Log4j库的设计理念。Log4j实现了一个基于Java的数据记录工具框架，在Log4j中定义了3个重要概念，分别是Logger、Appender和Layout：Logger用于定义不同的数据采集对象；Appender描述输出流，如屏幕、文件、GUI组件、Socket服务器、NT事件记录器、syslog进程服务等，通过为Logger指定一个Appender，可以区分不同对象的输出目标；Layout用于指定监控信息的输出格式，通过为Appender来指定一个Layout，可以决定监控信息以何种格式输出，比如是否有带有时间戳，是否包含文件位置信息等，通过这三个组件协同的工作，Log4j为监控数据采集行为控制提供了极大的灵活性，此外，基于预定义的等级和过滤器，可以自由地选择需要记录的数据。

Log4j虽然功能强大，但是该库只是面向Java语言的，因此基于Log4j机制的其他语言替代库相继应运而生，Log4c便是模仿Log4j原理的C语言实现。类似地，它通过定义Category，Appender和Layout三个属性唯一确定一个数据采集对象，Log4c不支持异步数据采集。

Log4g同样是C语言的一个实现，它基于glib的GObject开发，支持异步数据输出，此外Log4g还支持面向CouchDB的数据记录，便于日后利用基于NoSQL环境的大数据分析。Log4cplus和Log4cxx是C++的Log4j实现，它们具有线程安全、灵活输出、以及多粒度控制的特点，但Log4cplus的移植性不高，而Log4cxx虽然通过使用APR增强了移植性，但是APR本身增加了系统的依赖性。此外，Zlog作为一款比较新的数据采集库，通过定义不同的fsync阈值来实现记录监控数据落地请求和磁盘IO工作的异步处理。

可以看到，现有的各种数据采集模块虽然能够实现监控信息的输出，但是在设计上都比较简单，缺乏针对系统状态变化时的动态流量调整，因此在应用系统的实时运行中，如果突然出现大量错误信息需要写文件等情况，会在一段时间内集中产生主机磁盘冲击，此时文件IO读写便会成为系统瓶颈，显著降低系统的整体性能。此外，部分数据采集模块(如log4c)为了实现数据的及时输出，采用同步落地机制，那么在进行数据落地时会阻塞主逻辑的运行，应用进程需要等待IO输出完成才能继续后续代码的执行，于是在监控事件大量突发时，可能会因为磁盘IO吊住主程序的逻辑，从而对生产环境中实时程序的请求响应产生灾难性的影响。

综上，虽然目前有很多监控数据采集框架可供选择，但是关键实时系统的高稳定性和低延迟是重要的运行指标，如果由于监控逻辑的负载影响实时业务程序的运行和业务处理的及时响应，那么在设计上是有显著缺陷的。系统状态数据的采集可以帮助管理人员快速了解系统的运行情况、审计操作流程和排查错误原因，但是对于某些关键实时系统，如证券交易系统的稳定性和高可用性是衡量其设计运行水平的首要指标，那么在监控的事件（如系统错误等）频繁发生的情况下，大规模的数据采集和落地反而会对系统的整体性能和稳定性产生显著影响，严重时甚至会阻塞主应用程序的逻辑。

[发明内容]

本发明的目的就是为了解决交易实时系统的系统状态数据的采集过程中，大规模的数据采集和落地会对系统的整体性能和稳定性产生显著影响的技术问题，实现在大规模数据采集和落地时既保证实时系统的平稳运行，又可以有效地满足特征数据的采集和分发工作的一种流量动态可控的系统监控数据采集方法。

为了实现上述目的，发明一种流量动态可控的系统监控数据采集方法，所述的流量动态可控的监控数据采集方法主要分为三个部分，分别是监控数据异步采集处理，流量控制开启检测和流控数据合并机制；

所述的监控数据异步采集处理方法如下：通过调用系统线程接口，监控模块在初始化后启动一个单独的监控数据处理线程负责系统数据的多目标处理输出；单独的监控数据处理线程不停轮询数据输出请求队列，一旦发现有新的请求时，就从队头弹出数据记录并执行真正的输出请求，一直到将队列中的记录处理完毕；

所述的流量控制开启检测方法如下：监控数据采集库的采集接口在进行数据入队操作时，会实时检查系统监控事件的发生频率，并动态调整采集数据的流量，从而避免大量数据操作对系统整体性能的冲击，流控算法首先在流控检测周期内计数到达队列的数据请求数目，一旦该请求数达到或超过请求数阈值，就立即开启流量控制机制，并一直持续到流控执行周期的时间段结束。因此，动态流控的一个总周期可以划分为两个阶段：流控检测阶段T_d和流控执行阶段T_e；

所述的流控数据合并机制方法如下：在流控执行周期，监控数据采集库的采集接口不再将新到的数据加入数据输出请求队列，而是通过初始化时的哈希表进行相同特征数据的合并，从而降低实际数据流量的目标，数据的合并机制是：对于未出现过的特征数据类型，在哈希表里面增加一条；否则，只增加相同记录类型的计数。

所述的单独的监控数据处理线程的数据输出工作为屏幕打印或进行磁盘文件写入或通过网络传输数据至远程的数据库服务器。

所述的流控检测周期设为0，表示始终不执行流控；如果数据输出请求数阈值设为0，表示始终执行流控机制。

所述的监控数据异步采集处理方法需在采集模块初始化时选定异步数据输出请求队列长度，队列长度过小会导致大量监控数据无法入队而被丢弃，所述的异步数据输出请求队列长度选定方法如下：

监控事件数据的到达和监控事件数据的落地之差即为该时间段的队列长度的变化量Δ，在上一个交易日D_T-1，令e_i表示第i秒内发生的事件数，对每条采集的数据定义了m个输出目标，每个输出目标可以通过性能测试数据的平均值获得其单条数据处理时间的期望值

那么单位时间内m个目标的总服务速度（可以处理的数据）为

综上，第i秒对队列的改变量为：

Δ＝e_i-ν_m   (1)

设第i-1秒后的队列长度为L_i-1，那么第i秒后的队列长度即为：

L_i＝max(L_i-1+Δ,0)   (2)

注意因为队列长度不可以为负数，所以在服务速度大于数据到达速度的场景下，队列最小为0；

交易时段总长为t，那么在D_T-1的整个交易时段内队列长度出现过的最大值便可以作为未来队列长度的基准值L_q：

其中α为调和系数，即对历史数据中最坏情况下的队列长度再进行一定系数的放大，以保证未来使用该基准值后，监控数据被丢弃的概率很小，c为某个正整数常量，用于保证队列基准值的最小值，其选取值可以是任意一秒的非零事件数e_i（e_i＞0）。

所述的流量控制具体方法如下：

将一个流控周期T_w划分为流控检测阶段T_d和流控执行阶段T_e，定义λ＝m/T_d，其中，λ为数据到达速度的上限阈值，m为数据输出请求数阈值，数据到达速度超过该阈值时，认为磁盘读写会对系统性能产生不良影响，对于相同的λ值，m设置的越低，T_d就越低，即在一个周期内会越早进入流控执行阶段，系统总体性能的损耗会越少；另一方面，越早进入流控执行阶段，就有越多的监控信息被压缩合并，对输出结果的质量产生削弱。

本发明同现有技术相比，其优点在于：通过流速权控制算法，保证关键实时系统的平稳运行，能够有效地满足不同监控目标的监控数据采集需求，在突发大量落地请求时，IO数据读写的性能损耗不会超过给定的阈值，并通过特征数据的合并方法，保证了落地数据的质量；对算法涉及的关键参数进行了理论分析，给出了计算方法，从而指导用户使用，适用于证券交易系统等大型关键实时系统的状态监控和日志记录场景。

[附图说明]

图1是本发明监控数据异步采集处理结构图；

图2是本发明流控周期划分示意图；

图3是本发明中流控合并机制示意图；

指定图1作为本发明的摘要附图。

[具体实施方式]

下面结合附图对本发明作进一步说明，这种系统的结构和原理对本专业的人来说是非常清楚的。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

实施例1

图1是本发明的监控数据异步采集处理结构图，本部分设计的工作原理是通过调用Linux系统线程接口，监控模块在初始化后启动一个单独的监控数据处理线程（ProcessThread）负责系统数据的多目标处理输出，主程序每次调用数据采集接口时，实际上在内部仅仅将系统状态数据缓存到一个内存中的数据输出请求队列，并没有产生实际的IO操作；那么采集接口在完成入队列操作后，会立即返回并让主程序继续执行其实时应用逻辑，从而在本质上避免了同步操作可能产生的IO吊住主程序的危险。

监控数据处理线程（ProcessThread）不停轮询数据输出请求队列，一旦发现有新的请求时，就从队头弹出数据记录并执行真正的输出请求（可能为多目标输出，如同时打印到屏幕和写入文件），一直到将队列中的记录处理完毕。

监控数据处理线程（ProcessThread）的数据输出工作可能是简单的屏幕打印，可能是进行磁盘文件写入，也可能通过网络传输数据至远程的数据库服务器，但是因为有独立线程执行该操作，所以无论其性能或延迟消耗有多大，都不会阻塞主程序业务逻辑的迅速执行和快速响应。

实施例2

监控数据采集库的采集接口在进行数据入队操作时，会实时检查系统监控事件的发生频率，并动态调整采集数据的流量，从而避免大量数据IO操作对系统整体性能的冲击。该部分设计如下：系统设定3个参数，分别是流控检测周期（rateControlInterval），数据输出请求数阈值（rateControlCount）和流控执行周期（rateControlDuration）。流控算法首先在流控检测周期内计数到达队列的数据请求数目，一旦该请求数达到或超过请求数阈值，就立即开启流量控制机制，并一直持续到流控执行周期的时间段结束。因此，动态流控的一个总周期可以划分为两个阶段：流控检测阶段T_d和流控执行阶段T_e，如图2所示，其中m为检测阶段的数据输出请求数阈值。此外，如果流控检测周期设为0，表示始终不执行流控；如果数据输出请求数阈值设为0，表示始终执行流控机制。

实施例3

在流控执行周期，监控数据采集库的采集接口不再将新到的数据加入数据输出请求队列，而是通过初始化时预先建立好的哈希表进行相同特征数据的合并，从而实现降低实际数据流量的目标。需要根据自己的业务对“相同特征数据”（即Hash Key）的概念进行定义，例如对于证券交易系统，如果监控数据来自相同的PBU或者产品号，那么可以定义为相同的特征数据。数据的合并机制是：对于未出现过的特征数据类型，在e哈希表里面增加一条；否则，只增加相同记录类型的计数。

以系统错误的监控为例：在大量错误突发时，采集接口以“错误类型号”为Hash Key相同特征数据写入每条错误数据，之后对于相同类型的错误只增加错误的发生次数。流控执行周期结束后，采集模块会将哈希表里面的记录统一写入数据输出请求队列，等待ProcessThread（监控数据处理线程）进行处理，同时开启下一轮的流控检测周期。因为对于相同的特征数据进行了合并，所以每个周期需要实际分发和落地的数据量大大降低了。

图3的是上述流控机制的具体应用例：其中，流控检测周期设为3秒，数据输出请求数阈值设为100，流控执行周期为7秒。可以看到，在第3秒的第101个错误发生时，流控机制开启；此后，对于重复出现的错误类型只记录重复次数，并在流控结束后输出哈希表中的内容，包括（错误号，次数）。

实施例4

流量动态可控的监控数据异步采集算法通过监控数据异步采集处理的设计，将数据落地逻辑和主应用程序逻辑解耦，避免了磁盘IO堵住主线程的危险；通过流量控制开启检测算法，实时检测系统状态，动态开启流控机制；通过流控数据合并机制，既有效地降低了实际落地的数据量，又记录了所有监控的特征数据类型，保证了采集的数据质量。

为优化本算法的实施效果，以下对算法的两部分关键参数：数据输出请求队列长度和流控周期参数的选取策略进行介绍。

异步数据输出请求队列长度选取策略：

数据输出请求队列是主线程和监控数据处理线程之间缓存数据的桥梁，异步采集机制要求在采集模块初始化时logQueueLen（输入队列长度参数），如果队列长度过小会导致大量监控数据无法入队而被丢弃。虽然内存空间是个比较富裕的资源，但是仍然需要基于其自身系统的应用场景和性能需求计算队列长度基准值。

从排队论的角度看：监控事件数据的到达相当于顾客，而数据的落地相当于服，在单位时间段中，“到达顾客数”与“服务完成数”之差即为该时间段的队列长度的变化量Δ。假设历史数据可以反映事件到达率的分布，那么对于需要监控和采集的事件，首先统计其历史数据：以交易业务为例，在上一个交易日D_T-1，令e_i表示第i秒内发生的事件数；如果期望对每条采集的数据定义了m个输出目标，每个输出目标可以通过性能测试数据的平均值获得其单条数据处理时间的期望值

那么单位时间内m个目标的总服务速度（可以处理的数据）为

综上，第i秒对队列的改变量为：

Δ＝e_i-ν_m   (1)

设第i-1秒后的队列长度为L_i-1，那么第i秒后的队列长度即为：

L_i＝max(L_i-1+Δ,0)   (2)

注意因为队列长度不可以为负数，所以在服务速度大于数据到达速度的场景下，队列最小为0。

假设交易时段总长为t，那么在D_T-1的整个交易时段内队列长度出现过的最大值便可以作为未来队列长度的基准值L_q：

其中α为调和系数，即对历史数据中最坏情况下的队列长度再进行一定系数的放大，以保证未来使用该基准值后，监控数据被丢弃的概率很小，c为某个正整数常量，用于保证队列基准值的最小值，其选取值可以是任意一秒的非零事件数e_i（e_i＞0）。

例如，假设D_T-1的交易时间为5秒，系统每秒平均处理2条数据，α选取1.8，c选取1那么对于如下事件发生率e_i，可以采用上述公式计算队长基准值：

即

为了让计算结果更代表一般情况，可以对n天的历史数据D_T-1～D_T-n分别进行统计并计算L_q，再最终选取其中的最大值作为异步队列长度基准值。

流控参数选择策略：

一个流控周期T_w划分为两个阶段：流控检测阶段T_d和流控执行阶段T_e，如图2所示，定义λ＝m/T_d(m为数据输出请求数阈值)为数据到达速度的上限阈值，即一旦超过该阈值，便认为磁盘读写会对系统性能产生影响，可基于自己的系统参数和业务需求选定该值。但是，对于相同的λ值，m设的越低，T_d就越低，即在一个周期内会越早进入流控阶段，系统总体性能的损耗会越少；但是另一方面，越早进入流控阶段，就有越多的监控信息被压缩合并，对输出结果的质量产生削弱。

将流控参数m的选择问题定义如下：

a.在一个周期内，数据采集对系统性能的影响必须低于某个阈值；

b.在一个周期内，流控机制对数据质量的损耗必须低于某个阈值；

c.在满足a和b的前提下，最小化流控机制对性能的影响和数据质量的影响。

因为

以及T_e＝T_w-T_d，所以对于给定的一个流控周期，一旦确定数据输出请求数阈值m，便可以计算出其他流控周期长度，所以计算出m是流控参数选择的关键。

为解决该问题，需要对性能花费和数据质量这个两个概念进行定义。从总体看，性能花费正比于一个周期内需要输出的数据记录数，而数据质量的损耗正比于该周期内合并的记录数，因此可以用一个周期中IO输出的监控数据量分别描述这两个指标。综上，令λ表示可以接受数据到达速度的上限，令h为使用哈希表进行数据合并的压缩率，令T_w为一个流控周期，那么该时间段的性能影响y_p和数据质量损耗y_q分别为：

$y_p=m+(T_w-\frac{m}{\mathrm{\λ}})\mathrm{\λ}(1-h)---\left(4\right)$

$y_q=(T_w-\frac{m}{\mathrm{\λ}})\mathrm{\λh}---\left(5\right)$

y_p是流控检测阶段和流控执行阶段需要处理的数据之和，而y_q是流控执行阶段合并的数据量，因此，流控参数m的选择问题可以定义为一个一维线性规划问题：

miny＝(ω₁y_p+ω₂y_q)

s.t.

y_p≤c₁λT_w,y_q≤c₂hλT_w,m∈[0,λT_w]   (6)

ω₁+ω₂＝1

ω₁,ω₂,c₁,c₂∈[0,1]

其中线性规划目标函数_y为性能花费和质量损耗的加权平均值，目标求解最小化该值的流控参数m（即问题定义的c），y_p≤c₁λT_w和y_q≤c₂hλT_w分别描述性能花费必须低于某个阈值，而数据质量损耗也必须低于某个阈值（即问题定义的a和b）。

对于一维线性规划，通过函数作图法可以方便地求出最优解；此外，也可以使用Mathematica等数学软件求出最优解,求出m后，就可以得出

以及T_e＝T_w-T_d。

Claims (5)

1.一种流量动态可控的系统监控数据采集方法,其特征在于所述的流量动态可控的监控数据采集方法主要分为三个部分，分别是监控数据异步采集处理，流量控制开启检测和流控数据合并机制；

所述的监控数据异步采集处理方法如下：通过调用系统线程接口，监控模块在初始化后启动一个单独的监控数据处理线程负责系统数据的多目标处理输出；单独的监控数据处理线程不停轮询数据输出请求队列，一旦发现有新的请求时，就从队头弹出数据记录并执行真正的输出请求，一直到将队列中的记录处理完毕；

所述的流量控制开启检测方法如下：监控数据采集库的采集接口在进行数据入队操作时，会实时检查系统监控事件的发生频率，并动态调整采集数据的流量，从而避免大量数据操作对系统整体性能的冲击，流控算法首先在流控检测周期内计数到达队列的数据请求数目，一旦该请求数达到或超过请求数阈值，就立即开启流量控制机制，并一直持续到流控执行周期的时间段结束。因此，动态流控的一个总周期可以划分为两个阶段：流控检测阶段T_d和流控执行阶段T_e；

所述的流控数据合并机制方法如下：在流控执行周期，监控数据采集库的采集接口不再将新到的数据加入数据输出请求队列，而是通过初始化时的哈希表进行相同特征数据的合并，从而降低实际数据流量的目标，数据的合并机制是：对于未出现过的特征数据类型，在哈希表里面增加一条；否则，只增加相同记录类型的计数。

2.如权利要求1所述的一种流量动态可控的系统监控数据采集方法，其特征在于所述的单独的监控数据处理线程的数据输出工作为屏幕打印或进行磁盘文件写入或通过网络传输数据至远程的数据库服务器。

3.如权利要求1所述的一种流量动态可控的系统监控数据采集方法，其特征在于所述的流控检测周期设为0，表示始终不执行流控；如果数据输出请求数阈值设为0，表示始终执行流控机制。

4.如权利要求1所述的一种流量动态可控的系统监控数据采集方法，其特征在于所述的监控数据异步采集处理方法需在采集模块初始化时选定异步数据输出请求队列长度，队列长度过小会导致大量监控数据无法入队而被丢弃，所述的异步数据输出请求队列长度选定方法如下：

监控事件数据的到达和监控事件数据的落地之差即为该时间段的队列长度的变化量Δ，在上一个交易日D_T-1，令e_i表示第i秒内发生的事件数，对每条采集的数据定义了m个输出目标，每个输出目标可以通过性能测试数据的平均值获得其单条数据处理时间的期望值

那么单位时间内m个目标的总服务速度（可以处理的数据）为综上，第i秒对队列的改变量为：

Δ＝e_i-ν_m   (1)

设第i-1秒后的队列长度为L_i-1，那么第i秒后的队列长度即为：

L_i＝max(L_i-1+Δ,0)   (2)

注意因为队列长度不可以为负数，所以在服务速度大于数据到达速度的场景下，队列最小为0；

交易时段总长为t，那么在D_T-1的整个交易时段内队列长度出现过的最大值便可以作为未来队列长度的基准值L_q：

其中α为调和系数，即对历史数据中最坏情况下的队列长度再进行一定系数的放大，以保证未来使用该基准值后，监控数据被丢弃的概率很小，c为某个正整数常量，用于保证队列基准值的最小值，其选取值可以是任意一秒的非零事件数e_i（e_i＞0）。

5.如权利要求1所述的一种流量动态可控的系统监控数据采集方法，其特征在于所述的流量控制具体方法如下：

将一个流控周期T_w划分为流控检测阶段T_d和流控执行阶段T_e，定义λ＝m/T_d，其中，λ为数据到达速度的上限阈值，m为数据输出请求数阈值，数据到达速度超过该阈值时，认为磁盘读写会对系统性能产生不良影响，对于相同的λ值，m设置的越低，T_d就越低，即在一个周期内会越早进入流控执行阶段，系统总体性能的损耗会越少；另一方面，越早进入流控执行阶段，就有越多的监控信息被压缩合并，对输出结果的质量产生削弱。

Images