本发明涉及计算机技术领域，尤其涉及一种分析系统稳定性的方法及装置。
背景技术：
随着计算机技术和互联网技术的发展，中国的互联网产业的规模不断膨胀，大量的在线业务被不断地设计出来，为了保证这些在线业务正常运行，需要实时这些业务所在系统的运行状况
目前，绝大多数系统监控采用针对某项系统运行指标设定阀值，通过比较运行值与阀值的大小来判断系统运行状态是否正常，但是这种静态的设置监控指标的监控方式，只能够解决一些较粗粒度的指标监控，比如监控cpu的负载情况、网络端口的阻塞情况等指标的监控，仅能够判定系统是否超载。并且在实际应用中，监控的效果不够智能、灵活，目前的监控策略往往都存在监控场景单一、判定方式僵化的问题，尤其是对于很多复杂情景下的系统运行状况，难以做出正确的判定。
而为了提高系统的稳定性，最常见的方式是为系统进行扩容。在新系统申请或扩容时，也会参考指标监控评估出所需机器配置与数量。但是由于这些指标监控的阀值，往往又是根据人的经验确定，受个人经验影响，很不准确。
技术实现要素：
本发明的实施例提供一种分析系统稳定性的方法及装置，能够提高监控系统稳定性的智能化程度和准确度。
在目前已有的技术中通常是通过一些人为直接设定的指标来监控系统异常，往往受个人经验影响，较粗粒度的指标监控也已经难以保障系统监控的准确度。监控的准确度较低直接导致了系统扩容后往往都还需要调试系统，前后调试系统也需要很多时间。监控的准确度较低，也导致了在系统调试后，在线业务都很容易出现一些运行故障、事故，这就有需要分配相应的人力进行故障排查，从而增加了运营商的经营成本，占用了大量的人力资源。
针对传统的系统监控手段中通过阀值来判断系统运行状况时暴露的缺陷：如监控场景单一、判定方式僵化，判定结果与事实不符等问题，在本实施例中，通过采集多项关联系统监控项数据并对数据进行整合分析、建立数学模型，通过判断采集到的系统监控数据是否符合数学模型来判断系统运行状况，摒弃了以往对于单一监控项设定阀值的来判断系统运行状况的方式，使的系统监控更加准确，全面。例如：从而使得将订单量这种静态的业务数据的监控指标和系统运行的其他动态数据的监控指标结合起来成为可能，使得多个维度的监控指标融合，量化为相关系数，再通过相关系数分析系统的运行状态。
由于是基于系统的历史性能表现综合多指标统计分析，技术人员不需要再进行针对不同业务场景手动去调整各系统监控项阀值的繁琐操作，避免了不同业务场景下出现监控报警不准确的情况，提高了现有监控手段的智能化程度和准确度。
附图说明
为了更清楚地说明本发明实施例中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。
图1为本发明实施例提供的系统架构示意图；
图2a为本发明实施例提供的方法流程示意图；
图2b为本发明实施例提供的具体实例的示意图；
图3、图4为本发明实施例提供的装置结构示意图。
具体实施方式
为使本领域技术人员更好地理解本发明的技术方案，下面结合附图和具体实施方式对本发明作进一步详细描述。下文中将详细描述本发明的实施方式，所述实施方式的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施方式是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的任一单元和全部组合。本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样定义，不会用理想化或过于正式的含义来解释。
本实施例中的方法流程，具体可以在一种如图1所示的系统上通过计算机软件执行，具体来说，涉及计算机软件系统性能监控，软件算法编程，监控数据整合分析，数学模型建立。
该系统包括：业务系统、分析服务器和后台数据库，系统的各端设备相互之间可以通过互联网建立信道，并通过各自的数据传输端口进行数据交互。
本实施例中所揭示的分析服务器，在硬件层面上具体可以是工作站、超级计算机等设备，或者是由多台服务器组成的一种用于数据处理的服务器集群，或者分析服务器的功能也可以集成在后台数据库、业务系统或者其他的硬件系统中，即后台数据库、业务系统或者其他的硬件系统通过分配出一定数量的硬件资源，实现分析服务器的功能，具体可以通过目前的虚拟机技术或者分布式计算技术实现不同的计算功能在硬件系统上的集成。其中，分析服务器，可以从监控平台上实时采集监控数据，监控平台用于监控业务系统的运行状态，并记录有关业务系统运行数据的日志、或者业务系统在运行过程中的系统快照等监控数据，监控数据可以依据各监控平台上具体设定的监控指标进行区分。举例来说，本实施例中可能涉及到的监控平台包括但不限于：zabbix(一个基于web界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案)、跨系统同步通信框架(rsf)、跨系统异步通信框架(esb)等。
后台数据库中，存储了业务系统运行时的运行数据，比如：价格数据、物流数据、订单数据等等。后台数据库具体可以采用目前常见的数据库架构、类型。
业务系统，在硬件层面上具体可以是由多台服务器、超算等具备计算功能的硬件设备组成的，一种用于运营在线业务的系统，比如在线购物平台上运营的促销系统、订单系统、通知系统等。
本发明实施例提供一种分析系统稳定性的方法，如图2a所示，包括：
s1、采集与监控指标关联的运行数据。
具体的，所述监控指标至少包括：运行业务系统的硬件设备的处理器的空闲时间百分比、所述处理器的写入/读出等待时间百分比、所述处理器的用户程序占用时间百分比、内存使用百分比、磁盘读写端口的使用率等有关硬件设备的计算资源的指标，网卡发送的数据流量和所述网卡接受数据流量等有关硬件设备的通信资源的指标中的至少一项。以及业务系统在运行过程中生成并大多数会被记录为可调取日志的数据，比如包括了：所述系统的异常数量、所述系统的服务调用量、所述系统的响应时间、所述系统的业务异常量和所述系统的订单量等多组数据中的至少一项。监控指标具体可以作为与之相关联的运行数据的标签。
例如，如图2b所示，分析服务器通过设置定时任务的方式访问zabbix等监控系统，接口调用量数据采集系统，各类监控平台等，来获取一段时间的多项数据并落地存储，比如：采集一段时间内的zabbix系统监控指标(如1min内的系统平均负载)，zabbix系统的监控指标包括了：处理器的空闲时间百分比、所述处理器的写入/读出等待时间百分比、所述处理器的用户程序占用时间百分比、内存使用百分比、磁盘读写端口的使用率、网卡发送的数据流量和所述网卡接受数据流量。具体的，可以通过一段时间内的多次采集，形成历史采样集合，并记录为监控对比表，以便于将系统当前的运行数据与已有的监控对比表进行对比分析，从而快速找出发生异常的监控指标。
其中，所述系统的服务调用量可以理解为：业务系统在运行时调用每一项服务内容的次数，比如调用查询服务、比价服务、广播服务等业务服务。
所述系统的响应时间可以理解为：业务系统在运行时针对某一些业务功能的响应时间。
所述系统的业务异常量可以理解为：业务系统在运行时通过自带的检测手段实时自检报出的业务异常的数量。
所述系统的订单量可以理解为：在某一时间段内，业务系统所处理的订单数量，其中，所处理的订单数量可以理解为已经处理完毕的订单数量、正在处理的订单数量，或者是二者之和。
s2、利用不同的监控指标之间的相关性，从所采集的运行数据中选择待处理的运行数据，并确定波动范围。
其中，监控指标之间的相关性，在相关性较为显著的指标间建立相关对应的数据模型，确定其相关系数的值，通过相关系数的值来量化监控指标之间的相关性。以便于后续结合应用实际情况为模型输出结果设定合理的波动范围，从而通过波动范围检测待处理的运行数据是否存在异常情况。具体的，每一个监控指标指向某一类的运行数据，待处理的运行数据可以理解为：存在相关性的2个监控指标各自分别对应的运行数据。
待处理的运行数据包括：n组运行数据，且在所述n组运行数据中至少存在一对具有相关性的监控指标，即第i组运行数据关联的监控指标与第j组运行数据关联的监控指标存在相关性，n≥2，1≤i≤n、1≤j≤n且i≠j。
例如：从而使得将订单量这种静态的业务数据的监控指标和系统运行的其他动态数据的监控指标结合起来成为可能，使得多个维度的监控指标融合，量化为相关系数，再通过相关系数分析系统的运行状态。
在本实施例总，为分析方便统一单位，可以针对所采集的运行数据进行数据削平拉伸处理，计算各组数据间的方差，协方差，相关系数。
s3、根据所述波动范围，获取系统当前的运行数据的异常情况。
在目前已有的技术中通常是通过一些人为直接设定的指标来监控系统异常，往往受个人经验影响，较粗粒度的指标监控也已经难以保障系统监控的准确度。监控的准确度较低直接导致了系统扩容后往往都还需要调试系统，前后调试系统也需要很多时间。监控的准确度较低，也导致了在系统调试后，在线业务都很容易出现一些运行故障、事故，这就有需要分配相应的人力进行故障排查，从而增加了运营商的经营成本，占用了大量的人力资源。
在本实施例中，通过采集多项关联系统监控项数据并对数据进行整合分析、建立数学模型，通过判断采集到的系统监控数据是否符合数学模型来判断系统运行状况，摒弃了以往对于单一监控项设定阀值的来判断系统运行状况的方式，使的系统监控更加准确，全面。例如：从而使得将订单量这种静态的业务数据的监控指标和系统运行的其他动态数据的监控指标结合起来成为可能，使得多个维度的监控指标融合，量化为相关系数，再通过相关系数分析系统的运行状态。
针对传统的系统监控手段中通过阀值来判断系统运行状况时暴露的缺陷：如监控场景单一、判定方式僵化，判定结果与事实不符等问题，本发明提出了基于整合一段周期内系统的多项监控数据，并建立相关性的数学模型，向模型输入系统的监控数据，通过对输出结果进行分析，得出系统运行状态的结论。由于是基于系统的历史性能表现综合多指标统计分析，技术人员不需要再进行针对不同业务场景手动去调整各系统监控项阀值的繁琐操作，避免了不同业务场景下出现监控报警不准确的情况，提高了现有监控手段的智能化程度和准确度。
在本实施例中，步骤s2：所述利用不同的监控指标之间的相关性，从所采集的运行数据中选择待处理的运行数据，并确定波动范围，可以包括：
建立所述待处理的运行数据的数据模型。通过所述数据模型确定相关系数的值，并设定所述相关系数的波动范围。
其中，通过指标综合来分析各组数据之间的相关性，比如：cpu负载的波动率与订单量的有显著关系，与网卡也有关系，而与业务系统的异常率则没有直接关系，那么cpu负载的波动率与订单量的相关系数、与网卡的相关系数，就会高于与业务系统的异常率的相关系数。在相关性较为显著(比如相关系数较高)的指标间建立相关对应的数据模型，确定其相关系数具体的值，并结合应用实际情况为模型输出结果设定合理的波动范围。
在对采集的各项数据进行单位统一处理后，并计算各组数据间的相关系数，筛选出相关系数较高的监控项，根据相关系数建立相关监控项间的方程式，对系统各种运行状态下的运行数据输入模型方程，计算出相关系数的值，从中统计出正常情况下相关系数的值的范围,以及系统异常情况下相关系数的值的范围作为系统运行状况的判断依据。
具体的，所述建立所述待处理的运行数据的数据模型，包括：
采集至少两组不同的运行数据，并获取每两组不同的运行数据之间相关系数。若其中两组数据的相关系数大于预设值，则建立相关系数大于预设值的两组运行数据的数据模型。例如，依据数据模型判断系统运行状态的具体实现场景如下:
采集一段时间的系统运行正常情况下的监控到的运行数据，标记为data1,data2,data3,data4…输入这些数据，对数据进行统一单位的操作，然后每两组数据进行计算相关系数，输出所有相关系数p12,p13,p14,p23,p24,p34。
相关系数如下计算公式1所示：
其中，e是数学期望，cov表示协方差，σx和σy是标准差，∑为求和，x、y分别表示两种系统参数(系统参数可以根据具体的业务系统类型设定)，n表示取值数量，μ表示换算系数。
1、输入所有相关系数，进行筛选，输出数值高的相关系数的对应的两组数据，如：p14为0.77，对应的数据为data1、data4。其中，数值高的相关系数可以理解为：若相关系数绝对值大于预设值，则表明对应参数相关性较强并满足线性关系。具体的预设值的优选值为0.6。
2、将各两组数据分别代入公式进行计算，可以采用如下所示的计算公式2，
其中，
具体的，对采集自不同时间段的运行数据进行1-2步骤计算，多次计算求值后，根据所获取的相关系数的值，可以得到的一个分布范围。经过大量数据的计算后，可以得到一个相对比较稳定的分布范围，即可作为所述波动范围，即将同一个相关系数在多次计算后所得的分布情况作为所述波动范围。
在实际运行时，可以每隔一段时间定时获取前一阶段时间的数据，计算出相关系数的值，如100.2和50.6。相关系数和对应的波动范围进行比较，如果超出范围且差距大于设置的超出值，比如：100.2超出上限70.5的42.12％，大于设置的10％，则判定为异常，并进行相应的报警。报警时，则根据设置中的手机号，向相关人员的邮箱地址等发送报警信息。再比如：系统异常时通过快照的形式采集当前的运行数据，并输入对应数学模型进行计算，若得到的输出结果超出设定的波动范围则判定为异常情况。举例来说，历史数据订单量10w的时候，cpu负载只有30％，订单量10w的时候，cpu负载突然增长至50％则说明存在问题。但在传统的人工设定阈值的方案中，告警的阈值往往都会高于50％，因此对于这种情况，仅以单纯的阀值检测方式，则依然会认为cpu负载没问题不存在异常。
在本实施例中，步骤s3：所述根据所述波动范围，获取所述系统当前的运行数据的异常情况的具体实现方式，可以包括：
采集所述系统当前的运行数据，并通过所建立的数据模型输出所述系统当前的运行数据的计算结果。当所述计算结果不符合所述波动范围时，判定所述系统当前的运行数据的异常。
其中，所述计算结果不符合所述波动范围可以理解为：所述计算结果的具体数值落在所述波动范围的数值区间之外；而所述计算结果的具体数值不完全落在所述波动范围的数值区间之内，和所述计算结果的具体数值完全落在所述波动范围的数值区间之内的情况，则表示所述计算结果符合所述波动范围。或者，所述计算结果不符合所述波动范围可以理解为：所述计算结果的具体数值不完全落在所述波动范围的数值区间之内，只有所述计算结果的具体数值完全落在所述波动范围的数值区间之内的情况，才表示所述计算结果符合所述波动范围。
进一步的，还包括：
当判定所述系统当前的运行数据的异常时，提取异常信息。并根据所述异常信息发出预警。
其中，所述异常信息至少包括所述系统的主机ip地址、所述监控指标和对应发生异常的运行数据的接口信息。例如：分析服务器采集数据输入对应数学模型进行计算，若得到的输出结果超出设定的波动范围则判定为异常情况，并记录下相关的主机ip、监控指标和对应的接口类别，并发出报警，将相关信息通过邮件或短信的形式发送给相关系统负责人。
在实际应用中，适用于多种业务场景，基于具体的业务场景将数据模型用编程进行实现，之后设置定时任务，对于数据模型中涉及到的系统监控项数据进行采集，并输入数据模型，获取相关系数的值，再判断其是否属于正常范围，若超出正常范围则调用预警模块，包括预警短信发送模块，与预警邮件发送模块，接收人可以动态配置，发送预警信息。使得对系统运行状态的判定从静态的比较某一项监控数据与阀值的大小，转变为综合分析多项监控数据相关性是否正常，从而使得系统监控更加智能、全面与准确。举例一个典型的场景：比如新代码发布前后，各项指标均没有超过阀值，但是在业务量没有变化的情况下，系统资源占用明显上升，则通过指标综合分析可判断出可能是程序本身出了问题，及时预警。从而克服了传统的监控方法中使用业务场景单一、无法动态监控、分析结果不准确的缺点，提高了监控的灵活性。
在本实施例中，还提供一种根据所判定的异常情况，进一步确定是否需要基于异常情况的发生频率进行系统资源扩容/缩容的方案，具体包括：
获取所述系统的历史异常数据，并根据所述历史异常数据推算所述系统的扩容或缩容需求。根据所述系统的扩容或缩容需求，调整分配给所述系统的资源数量。
其中，所述历史异常数据包括了在指定时间段内所述系统已发生的异常情况和对应所述已发生的异常情况的异常信息。扩容或缩容需求，可以理解为对于系统的硬件资源的调整值，比如：需要新增/减少的处理器数量、内存数量、磁盘空间数量等，调整值为正则表示需要增加、为负则表示需要减少。例如：分析服务器可以根据订单量和各个指标之间的内在联系计算出服务器规模和订单量的对应模型，为服务器扩容及后续申请新机器提供辅助。在计算服务器规模时，根据输入的订单量、各个系统调用量数据、服务器规模、数据读写方式和服务器资源率的历史数据，大致推算出需要的机器配置及数量。从而为技术人员快速提供可供参考的扩容/缩容的方案。
本发明还提供一种分析系统稳定性的装置，具体可以运行在如图1所示的分析服务器上，该装置如图3所示的，包括：
数据采集模块，用于采集与监控指标关联的运行数据；
预处理模块，用于不同的监控指标之间的相关性，从所采集的运行数据中选择待处理的运行数据，并确定波动范围；
分析模块，用于利用根据所述波动范围，获取系统当前的运行数据的异常情况。
其中，所述预处理模块，具体用于采集至少两组不同的运行数据，并获取每两组不同的运行数据之间相关系数；若其中两组数据的相关系数大于预设值，则建立相关系数大于预设值的两组运行数据的数据模型；之后通过所述数据模型确定相关系数的值，并设定所述相关系数的波动范围；
所述监控指标至少包括：处理器的空闲时间百分比、所述处理器的写入/读出等待时间百分比、所述处理器的用户程序占用时间百分比、内存使用百分比、磁盘读写端口的使用率、网卡发送的数据流量和所述网卡接受数据流量、所述系统的服务调用量、所述系统的响应时间、所述系统的业务异常量和所述系统的订单量中的至少一项；
所述分析模块，具体用于采集所述系统当前的运行数据，并通过所建立的数据模型输出所述系统当前的运行数据的计算结果；当所述计算结果不符合所述波动范围时，判定所述系统当前的运行数据的异常。
进一步的，如图4所示的，该装置还包括：
报警模块，用于当判定所述系统当前的运行数据的异常时，提取异常信息，所述异常信息至少包括所述系统的主机ip地址、所述监控指标和对应发生异常的运行数据的接口信息；根据所述异常信息发出预警；
校准模块，用于获取所述系统的历史异常数据，并根据所述历史异常数据推算所述系统的扩容或缩容需求，其中，所述历史异常数据包括了在指定时间段内所述系统已发生的异常情况和对应所述已发生的异常情况的异常信息；并根据所述系统的扩容或缩容需求，调整分配给所述系统的资源数量。
在本实施例中，通过采集多项关联系统监控项数据并对数据进行整合分析、建立数学模型，通过判断采集到的系统监控数据是否符合数学模型来判断系统运行状况，摒弃了以往对于单一监控项设定阀值的来判断系统运行状况的方式，使的系统监控更加准确，全面。例如：从而使得将订单量这种静态的业务数据的监控指标和系统运行的其他动态数据的监控指标结合起来成为可能，使得多个维度的监控指标融合，量化为相关系数，再通过相关系数分析系统的运行状态。
针对传统的系统监控手段中通过阀值来判断系统运行状况时暴露的缺陷：如监控场景单一、判定方式僵化，判定结果与事实不符等问题，本发明提出了基于整合一段周期内系统的多项监控数据，并建立相关性的数学模型，向模型输入系统的监控数据，通过对输出结果进行分析，得出系统运行状态的结论。由于是基于系统的历史性能表现综合多指标统计分析，技术人员不需要再进行针对不同业务场景手动去调整各系统监控项阀值的繁琐操作，避免了不同业务场景下出现监控报警不准确的情况，提高了现有监控手段的智能化程度和准确度。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。对于设备实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。