CN115080363A - 一种基于业务日志的系统容量评估方法及装置 - Google Patents

Abstract

本申请实施例公开了一种基于业务日志的系统容量评估方法及装置，应用于后端服务器，其中方法包括：采集第一服务节点对应的原始日志数据，其中，所述原始日志数据包括多个功能的日志数据，所述多个功能包括所述第一服务节点提供的证券业务中的功能；对所述原始日志数据进行解析，得到所述多个功能的调用情况，其中，所述调用情况包括调用次数和调用耗时中的至少一项；根据所述多个功能的调用情况控制所述第一服务节点的系统容量。本申请实施例能够从多个维度对系统运行状况进行量化分析，实时展示系统运行趋势变化，为系统容量评估提供数据支持。

Description

一种基于业务日志的系统容量评估方法及装置

技术领域

本申请涉及自动化技术，应用于智能设备、人工智能领域，尤其涉及一种基于业务日志的系统容量评估方法及装置。

背景技术

在信息技术领域，业务监控、异常检测、容量规划、性能调优都需要具体的数据支撑，而仅靠现有技术手段中的CPU、内存、网络流量等基础监控指标已不能满足性能量化分析的要求。随着开源工具的发展，使我们能够使用开源工具实时解析各类业务日志，将日志数据转化为结构化数据汇总后做聚合分析，真正掌控系统实时全貌，看到关键指标的趋势变化。

具体基于证券行业，能够实时准确地把握核心柜台系统的运行状况，对于安全运行尤为重要，不然极有可能造成极大的经济损失，但对证券领域的业务日志数据进行研究时发现，各个柜台的日志数据是分散的，属于非结构化的数据，并且大量的分散数据在处理后得到需要的信息，这对进行业务监控、异常检测、容量规划、性能调优、性能量化分析造成了阻碍。

发明内容

本申请实施例提供了一种基于业务日志的系统容量评估方法及装置，能够从多个维度（功能号、客户号、延时等）对系统运行状况进行量化分析，实时展示系统运行趋势变化，为系统容量评估提供数据支持。及时发现故障隐患，有重点地解决系统运行中的故障，为系统稳定运行保驾护航。

第一方面，本申请实施例提供了一种基于业务日志的系统容量评估方法，包括：

采集第一服务节点对应的原始日志数据，其中，所述原始日志数据包括多个功能的日志数据，所述多个功能包括所述第一服务节点提供的证券业务中的功能；

对所述原始日志数据进行解析，得到所述多个功能的调用情况，其中，所述调用情况包括调用次数和调用耗时中的至少一项；

根据所述多个功能的调用情况控制所述第一服务节点的系统容量。

在现实生活中，系统管理人员为把握核心柜台系统的运行状况，对于安全运行格外重视。但目前商业公司的产品成本高昂，传统的命令行很难应对分散在多台机器上的海量数据，业务日志格式五花八门，且较难为适应日志系统去做专门的改造。现有技术主要是通过CPU、内存、网络流量等基础监控指标对业务进行监控、异常检测、容量规划、性能调优等操作，但各个柜台分散的日志数据会对进行性能调优等操作造成阻碍。而本申请从多个维度（如多个功能的调用情况、多个用户的数据信息）着手，对系统的运行状况进行量化分析，实时展示系统运行趋势变化，为系统容量评估提供数据支持。从而使得业务管理人员能够及时发现故障隐患，有重点地解决系统运行中的故障，维护系统安全。

在一种可能的实施方式中，所述根据所述多个功能的调用情况控制所述第一服务节点的系统容量，包括：

根据所述第一功能的调用情况确定交易时段，其中，所述功能包括业务功能和普通功能，所述业务功能包括委托、登录、转账中的至少一项，所述普通功能为业务系统中的历史查询功能，在所述交易时段所述第一服务节点的调用情况达到预设门限值，所述第一功能为所述业务功能中的任意一个；

根据所述第一功能在所述交易时段的调用情况评估所述第一服务节点的系统容量；

若所述第一服务节点的系统容量小于第一预设阈值，则调整所述普通功能；

根据调整后的所述普通功能控制所述第一服务节点的系统容量，直至所述系统容量大于所述第一预设阈值。

在上述方法中，由于在影响证券系统运行状态的所有时段中，交易时段的系统维护相比非交易时段（如工作日的休息时间或者周末）而言更为关键，因此可以针对交易时段对服务节点的系统容量进行预测。具体的，后端服务器可以通过多个功能（如委托、登录、转账）中的任意一个功能的调用情况确定出该功能的交易时段，再根据该功能在交易时段时第一服务节点的调用情况评估系统容量。若第一服务节点的系统容量小于第一预设阈值（比如服务节点1在根据场内证券交易结算指令确定场内证券交易为买券的交易时，若该系统容量为150个工作进程，当小于第一预设阈值200个工作进程时,则此时后端服务器可以控制服务节点1的系统容量（如可以进行开源节流、归档历史数据、对非关键功能（普通功能）进行降级/关停等操作）直至系统容量重新大于200个工作进程后结束操作。本方案能够通过精确建立数据的筛查机制，筛选出交易时段的功能，从而有针对性地预估预设门限值时的系统容量。

在另一种可能的实施方式中，所述根据所述第一功能的调用情况确定交易时段，包括：

向预测模型输入待预测数据，得到所述第一服务节点的第一功能的交易时段，其中，所述待预测数据包括所述第一功能的调用情况，所述预测模型为根据多条样本数据训练得到的模型，所述样本数据包括特征数据和标签数据，所述特征数据包括各个服务节点的多个功能的历史调用情况，所述标签数据包括所述各个服务节点的多个功能的历史交易时段。

在上述方法中，后端服务器得到第一服务节点的第一功能的交易时段的方式中模型化训练的方式具体可以为：通过获取整套流程的多条样本数据进行训练得到预测模型，得到的预测模型提供从输入到所需输出的准确映射。其中，多条样本数据包括特征数据和标签数据，特征数据包括各个服务节点的多个功能的历史调用情况，标签数据包括各个服务节点的多个功能的历史交易时段。根据多条样本数据训练得到预测模型后，只需要获取第一功能的待预测数据（其中，待预测数据包括第一功能的调用情况），而后将该第一功能的待预测数据输入到预测模型中，而无需再将整套流程重新执行一遍，即可直接根据第一功能的调用情况确定交易时段。通过利用训练模型提高了根据第一功能的调用情况确定交易时段的效率。

在又一种可能的实施方式中，所述原始日志数据还包括用户的数据信息，所述用户的数据信息包括所述用户消耗系统资源的程度、所述用户使用的委托渠道、所述用户关联的客户端的版本信息中的至少一项；

所述根据所述第一功能在所述交易时段的调用情况评估所述第一服务节点的系统容量，包括：

根据所述用户的数据信息和所述第一功能在所述交易时段的调用情况评估所述第一服务节点的系统容量。

在上述方法中，原始日志数据中还可以包括用户的数据信息，其中用户的数据信息包括用户消耗系统资源的程度、用户使用的委托渠道和用户关联的客户端的版本信息中的至少一项，即除了可以从功能的维度了解当前业务系统中哪些功能的调用次数比较多，哪些功能的调用耗时比较大之外，还可以从用户的维度了解哪些用户消耗了过多的系统资源，用户使用的委托渠道，客户端版本信息等，本申请可以通过上述从不同维度、多方面的考量（如用户的数据信息和第一功能在交易时段的调用情况）对系统运行状况进行量化分析，实时展示系统运行趋势变化，从而能够综合评估第一服务节点的系统容量，使得评估结果更加准确，同时也能够为系统容量评估提供有力的数据支持。

在又一种可能的实施方式中，所述根据所述多个功能的调用情况控制所述第一服务节点的系统容量之前，还包括：

根据所述第一服务节点的第一功能在预设周期内的历史调用耗时确定所述第一功能的平均调用耗时；

根据单位工作进程的量化值、所述第一功能的调用次数和所述平均调用耗时确定工作总进程的量化值，其中，所述单位工作进程的量化值属于预设的单位值；

根据所述工作总进程的量化值确定第一服务节点达到所述预设门限值时的系统容量。

在上述方法中，后端服务器在根据多个功能的调用情况控制第一服务节点的系统容量之前，还可以先根据第一服务节点的第一功能在预设周期内的历史调用耗时确定第一功能的平均调用耗时（比如获取服务节点1对应的“网上交易”业务日志数据中“委托”功能在09:10:00至09:40:00时间段内的历史调用耗时将09:10:00至09:40:00时间段内的调用耗时值进行平均，得到平均调用耗时后，再获取“委托”功能达到预设门限值（即交易时段峰值）时的调用次数，最后综合一个工作进程每秒处理的笔数得出需要的工作进程（即工作总进程的量化值）。通过工作总进程的量化值表征第一服务节点（服务节点1）达到预设门限值时的系统容量。本方案基于对工作进程进行量化分析，从而体现第一服务节点达到预设门限值时的系统容量，能够使得针对系统容量的数据的筛查机制更可靠。

在又一种可能的实施方式中，所述根据所述第一功能在所述交易时段的调用情况评估所述第一服务节点的系统容量，包括：

若所述第一功能在预设时间段内的调用次数大于第二预设阈值和/或所述调用耗时大于第三预设阈值，则确定所述第一服务节点的系统容量为异常状态。

在上述方法中，若根据第一功能在所述交易时段的历史耗时与历史调用次数的趋势对比，发现系统容量状态异常（如“委托”功能在交易时段中的平均历史调用次数为8000次/min，大于第二预设阈值5000次/min，和/或平均历史调用耗时为30ms，大于第三预设阈值5ms，观察发现系统现阶段会间歇性的出现异常耗时突起），则后端服务器可以确定第一服务节点（服务节点1）的系统性能为异常状态，此时在监控程序中表征为波形图的起伏大且紧凑，若排查后确定其故障原因是数据库的监控程序长期运行，在重启该监控程序后，波形图趋于平稳。本方案能够通过监控系统平台实时可视化地展示系统运行的趋势变化，从而及时发现故障隐患，保障系统安全运行的稳定性。

在又一种可能的实施方式中，所述若所述第一功能的调用次数大于第一预设阈值和/或耗时大于第二预设阈值，则确定所述第一服务节点的系统容量为异常状态之后，还包括：

向与终端绑定的管理所述第一服务节点的业务人员发送报警信号，其中，所述报警信号用于通知所述业务人员排查故障；

将所述系统容量为异常状态对应的所述第一服务节点的日志数据存储在异常业务数据库中。

在上述方法中，能够及时对系统的运行状态进行监测，一旦发现系统容量的状态异常，可以通过报警器将系统容量的状态异常的情况及时地反馈给与终端绑定的业务管理人员，使得业务管理人员能够更加迅速地获知系统容量的异常情况，以便及时发现故障隐患，排查故障，有重点地解决系统运行中的故障，减少因系统容量的异常状态造成损失，为系统的稳定运行保驾护航。

第二方面，本申请实施例提供一种基于业务日志的系统容量评估装置，应用于后端服务器，该装置包括采集单元、解析单元和控制单元，该装置用于实现第一方面或第一方面任一种可能的实施方式所描述的方法。

需要说明的是，上述第二方面所描述的装置所包含的处理器，可以是专门用于执行这些方法的处理器（便于区别称为专用处理器），也可以是通过调用计算机程序来执行这些方法的处理器，例如通用处理器。可选的，至少一个处理器还可以既包括专用处理器也包括通用处理器。

可选的，上述计算机程序可以存在存储器中。示例性的，存储器可以为非瞬时性（non-transitory）存储器，例如只读存储器（Read Only Memory，ROM），其可以与处理器集成在同一块器件上，也可以分别设置在不同的器件上，本申请实施例对存储器的类型以及存储器与处理器的设置方式不做限定。

在一种可能的实施方式中，上述至少一个存储器位于上述装置之外。

在又一种可能的实施方式中，上述至少一个存储器位于上述装置之内。

在又一种可能的实施方式之中，上述至少一个存储器的部分存储器位于上述装置之内，另一部分存储器位于上述装置之外。

本申请中，处理器和存储器还可能集成于一个器件中，即处理器和存储器还可以被集成在一起。

第三方面，本申请实施例提供一种基于业务日志的系统容量评估设备，该设备包括处理器和存储器；所述存储器中存储有计算机程序；处理器执行计算机程序时，计算设备执行前述第一或者第一方面任一项所描述的方法。

第四方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当所述指令在至少一个处理器上运行时，实现前述第一或者第一方面任一项所描述的方法。

第五方面，本申请提供了一种计算机程序产品，计算机程序产品包括计算机指令，当所述指令在至少一个处理器上运行时，实现前述第一或者第一方面任一项所描述的方法。该计算机程序产品可以为一个软件安装包，在需要使用前述方法的情况下，可以下载该计算机程序产品并在计算设备上执行该计算机程序产品。

本申请第二至第五方面所提供的技术方法，其有益效果可以参考第一方面的技术方案的有益效果，此处不再赘述。

附图说明

下面将对实施例描述中所需要使用的附图作简单的介绍。

图1是本申请实施例提供的一种基于业务日志的系统容量评估的系统架构示意图；

图2是本申请实施例提供的一种基于业务日志的系统容量评估方法的流程示意图；

图3是本申请实施例提供的一种业务日志数据对应的多个业务功能的调用情况的示意图；

图4是本申请实施例提供的一种第一服务节点的系统容量状态的示意图；

图5为本申请实施例提供的一种确定第一功能的平均调用耗时的示意图；

图6为本申请实施例提供的一种确定第一功能的平均调用次数的示意图；

图7为本申请实施例提供的一种根据原始日志数据评估第一服务节点的系统容量的示意图；

图8是本申请实施例提供的一种基于业务日志的系统容量评估装置80的结构示意图；

图9是本申请实施例提供的一种基于业务日志的系统容量评估设备90的结构示意图。

具体实施方式

下面结合本申请实施例中的附图对本申请实施例进行描述。

为了便于理解，先对本申请实施例涉及的技术术语进行简单介绍。

1.Fluentd、Filebeat、Metricbeat等Agent，是开源社区中流行的日志、指标采集工具,采用Agent方式可以支持大多数主流操作系统，同时Agent也支持大量的应用软件监测；使用Agent除了获得中央处理器（Central Processing Unit / Processor，CPU）、磁盘等基本信息外，还可以获得平均负载、IO状态、控制台命令（NetStat）结果、日志监测、虚拟内存、文件和目录的监测以及NT注册表监测等信息，使用Agent还可以支持自定义脚本监测器，实现对私有业务系统的监测。

2.Syslog，中文名称为系统日志协议，Syslog是在一个IP网络中转发系统日志信息的标准，它是在美国加州大学伯克利软件分布研究中心(BSD)的TCP/IP系统实施中开发的，目前已成为工业标准协议，可用它记录设备的日志。Syslog记录着系统中的任何事件，管理者可以通过查看系统记录随时掌握系统状况。系统日志通过Syslog进程记录系统的有关事件，也可以记录应用程序运作事件。通过适当配置，还可以实现运行Syslog协议的机器之间的通信。通过分析这些网络行为日志，可追踪和掌握与设备和网络有关的情况。

3. Kafka，是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。这种动作(网页浏览，搜索和其他用户的行动)是在现代网络上的许多社会功能的一个关键因素。这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。对于像Hadoop一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群来提供实时的消息。

4.Logstash，是一个数据处理器，可以同时组合和转换来自多个数据源的数据，然后将其发送到需要的日志管理平台。其主要特点为：①从不同的数据源集摄取数据:日志、度量、web应用程序、数据存储、AWS，同时不丢失并发性。②实时数据解析。③从非结构化数据创建结构。④用于数据安全的管道加密。

请参见图1，图1是本申请实施例提供的一种基于业务日志的系统容量评估的系统架构示意图，该系统包括后端服务器101和终端设备102。后端服务器101中包括数据采集模块103、数据库104、训练设备105、数据解析模块106、输出模块107。

后端服务器101可以为一个服务器或者多个服务器组成的服务器集群，可以是电脑、上位机、用于计算的设备，后端服务器101主要用于通过数据采集模块103采集第一服务节点对应的原始日志数据（包括业务日志数据和其它日志数据）；通过数据解析模块106对原始日志数据进行解析，得到多个功能的调用情况；以及根据多个功能的调用情况控制第一服务节点的系统容量后通过输出模块107展示。

终端设备102是具有处理能力和数据收发能力的装置。终端设备102可以是计算机、笔记本电脑、平板电脑、掌上电脑、台式机、诊断仪、手机、超级移动个人计算机（Ultra-mobile Personal Computer，UMPC）、上网本、个人数字助理（Personal DigitalAssistant，PDA）等。在本申请实施例中，终端设备102为应用程序（Application，APP）。

终端设备102的用户所对应的用户分组可以是业务管理人员、系统维护人员以及研发人员。该业务管理人员可以通过终端设备102登录，通过终端设备102接收后端服务器101发送的针对第一服务节点出现故障的报警信号，其中，该报警信号用于通知业务管理人员排查故障。

数据采集模块103用于基于与后端服务器101耦合的代理模块Agent获取业务系统的原始日志数据。

数据库104用于存储解析协议，即后端服务器101从数据库104的预设配置（其中，预设配置包含原始日志数据中的各个业务日志格式的解析协议以及其它日志的解析协议）中根据所需的业务日志数据的标识查找该业务日志数据对应的解析协议进行后续解析操作。

训练设备105用于后端服务器101对各个服务节点的多个功能的历史调用情况和各个服务节点的多个功能的历史交易时段进行训练，得到第一服务节点的第一功能的交易时段的预测模型，其中，预测模型/规则可以是数学模型或算法模型等，通过预测模型/规则的算法预测可以得到第一服务节点的第一功能的交易时段。

需要说明的是，在实际应用中，数据库104中的解析协议可以来自于数据采集模块103的采集，也有可能是由用户进行编辑得到的。另外需要说明的是，训练设备105也不一定完全基于数据库104的训练数据集进行预测模型/规则的训练，也有可能从后端服务器101或其它地方获取训练数据集进行模型训练，上述描述不应该作为对本申请实施例的限定。

下面结合图1对本申请实施例的方法进行详细介绍。

请参见图2，图2是本申请实施例提供的一种基于业务日志的系统容量评估方法的流程示意图。可选的，该方法可以应用于图1所述系统。

如图2所述的方法至少包括步骤S201至步骤S203。

步骤S201：后端服务器采集第一服务节点对应的原始日志数据。

具体的，第一服务节点对应的原始日志数据的来源可以有很多种，比如上述第一服务节点对应的原始日志数据可以由终端设备发送至后端服务器，具体的，举例来说，如若终端设备获取到了“网上交易”服务节点对应的原始日志数据后，可以对该原始日志数据进行格式化处理，再将格式化处理后的原始日志数据输出到日志文件中，最后再将该日志文件通过传输媒介发送至后端服务器。再如，后端服务器可以通过数据采集工具Agent、Syslog 等方式实现第一服务节点的原始日志数据的实时采集，根据各个服务器、设备或IT系统的不同，可以提供不同的日志采集方式。在本申请实施例中，第一服务节点上部署了与后端服务器耦合的代理模块Agent，因此可以通过Agent方式实现原始日志数据的采集，具体的，首先将Agent安装完毕之后，还需要配置采集项，即指定Agent对业务系统上的哪些原始日志数据需要采集，在本申请实施例中，后端服务器可以通过设置对业务系统上的业务日志数据（如功能、用户数据信息）和其他日志数据（如系统CPU、占用率）进行采集。另外，在通过Agent采集完第一服务节点对应的原始日志数据后，可以将第一服务节点对应的原始日志数据存储在Kafka中向后端服务器发送该原始日志数据。

步骤S202：后端服务器对原始日志数据进行解析，得到多个功能的调用情况。

其中，原始日志数据中包括但不限定于仅包括业务日志数据和其它日志数据，业务日志数据包括多个功能的日志数据，多个功能包括服务节点提供的证券业务中的功能，比如多个功能中包括业务功能和普通功能，进一步的，业务功能还包括委托、登录、转账中的至少一项，而普通功能即为业务系统中的历史查询或其他非关键业务功能；多个功能中的业务功能的调用情况包括但不限于调用次数和调用耗时中的至少一项。

后端服务器可以在采集到第一服务节点对应的原始日志数据之后，筛选出原始日志数据中的业务日志数据，在确定出需要的业务日志数据后，再根据该业务日志数据得到该业务日志数据中的多个业务功能的调用情况。举例来说，若后端服务器在采集到服务节点1对应的原始日志数据后，可以筛选出该原始日志数据中的业务日志数据有“网上交易”“风险管控”“柜台管理”等日志数据。

具体的，后端服务器可以从数据库中的预设配置（其中，预设配置包含原始日志数据中的各个业务日志格式的解析协议以及其它日志的解析协议）中确定服务节点1对应的“网上交易”业务日志数据标识查找“网上交易”业务日志数据对应的解析协议，例如可以由研发人员预先建立“网上交易”业务日志数据与解析协议之间相对应的映射表，使得后端服务器能够在映射表中查找业务日志数据需要的解析协议，然后根据对应的解析协议解析“网上交易”业务日志数据（解析协议可以为金证kcbp日志、金证mid日志等）。因此，后端服务器需要从数据库中根据不同格式的业务日志数据标识获得相应的解析协议，根据相应的解析协议，基于数据处理器Logstash解析业务日志数据的内容。应说明的是，本申请实施例后续主要针对业务日志数据为“网上交易”进行详细说明。举例来说，后端服务器在对“网上交易”业务日志数据的内容解析后，可以得到“网上交易”业务日志数据的多个业务功能（如“委托”功能、“登录”功能、“查询”功能）的调用情况。其中，用户日常交易中常用的操作指令，一般都包括委托、查询资金、查询持仓；为满足委托的要求，还需要查询在委托时可以交易的数量等，这些是交易时段用户日常应用的功能，通常会以1∶5或者是1∶6的比例进行，即一个委托指令伴随着5个或者6个查询指令。

如图3所示，图3为本申请实施例提供的一种业务日志数据对应的多个业务功能的调用情况的示意图。举例来说，比如，后端服务器在对“网上交易”业务日志数据的内容解析后，得到“委托”功能的调用情况为第一阶段（比如在线用户为5000人时）的调用次数（即委托笔数）为50笔/秒、调用耗时为30ms；第二阶段（比如在线用户为7500人时）的调用次数为100笔/秒、调用耗时为60ms；第三阶段（比如在线用户为9000人时）的调用次数为150笔/秒、调用耗时为70ms；以及第四阶段（比如在线用户为10000人时）的调用次数为200笔/秒、调用耗时为85ms。

再如，后端服务器在对“网上交易”业务日志数据的内容解析后，得到“转账”功能的调用情况为第一阶段（比如在线用户为4050人时）的调用次数（即转账笔数）为30笔/秒、调用耗时为10ms；第二阶段（比如在线用户为5500人时）的调用次数为45笔/秒、调用耗时为25ms；第三阶段（比如在线用户为8000人时）的调用次数为60笔/秒、调用耗时为45ms；以及第四阶段（比如在线用户为8560人时）的调用次数为70笔/秒、调用耗时为50ms。综上可知，后端服务器接收上述调用情况的数据信息后，可以将上述数据信息以树状图或示意图的方式在平台上对应标注并展示，后端服务器在平台上综合上述数据信息的标注情况，输出业务日志数据对应的多个业务功能的调用情况的示意图。

步骤S203：后端服务器根据多个功能的调用情况控制第一服务节点的系统容量。

具体的，下面以根据第一功能（如“委托”功能）的调用情况确定交易时段为例进行说明，其中，在交易时段第一服务节点的调用情况达到预设门限值，第一功能为上述多个业务功能中的任意一个。

首先，后端服务器根据第一功能在交易时段的调用情况评估第一服务节点的系统容量。具体的，若第一功能的调用次数大于第二预设阈值和/或调用耗时大于第三预设阈值，则确定第一服务节点的系统容量为异常状态，然后可以向与终端绑定的管理第一服务节点的业务人员发送报警信号，其中，报警信号用于通知业务人员排查故障。

其次，将系统容量为异常状态对应的第一服务节点的日志数据存储在异常业务数据库中，该步骤可以用于下次若出现相同情况，则根据此次情况的应对方案对故障进行解决。

最后，若第一服务节点的系统容量小于第一预设阈值，则调整普通功能；根据调整后的普通功能控制第一服务节点的系统容量，直至系统容量大于第一预设阈值。

具体的，由于在影响证券系统运行状态的所有时段中，交易时段的系统维护相比非交易时段（如工作日的休息时间或者周末）而言更为关键，因此可以针对交易时段时服务节点1的系统容量进行预测，具体的，后端服务器可以通过多个功能（委托、登录、转账）中的任意一个功能（如“委托”功能）的调用情况确定出该功能的交易时段，再根据“委托”功能在交易时段时“网上交易”业务日志数据的调用情况评估系统容量。若第一服务节点的系统容量小于第一预设阈值（比如服务节点1在根据场内证券交易结算指令确定场内证券交易为买券的交易时，若该系统容量为150个工作进程，当小于第一预设阈值200个工作进程时,则此时后端服务器可以控制服务节点1的系统容量（如可以进行开源节流、归档历史数据、对非关键功能（如上述所说的系统常设的普通功能）进行降级/关停等操作）直至系统容量重新大于200个工作进程后结束操作。本方案能够通过精确建立数据的筛查机制，筛选出交易时段的功能，从而有针对性地预估预设门限值时的系统容量。

另外，若根据第一功能在交易时段的历史耗时与历史调用次数的趋势对比，发现系统容量状态异常（图4为本申请实施例提供的一种第一服务节点的系统容量状态的示意图，如图4波形图的实线部分所示，若“委托”功能在交易时段中的平均历史调用次数为8000次/min，大于第二预设阈值5000次/min，和/或平均历史调用耗时为30ms，大于第三预设阈值5ms，观察发现系统现阶段会间歇性的出现异常耗时突起），则后端服务器可以确定第一服务节点（服务节点1）的系统性能为异常状态，此时在监控程序中表征为波形图的起伏大且紧凑，若排查后确定其故障原因是数据库的监控程序长期运行，在重启该监控程序后，波形图趋于平稳（如图4波形图的虚线部分所示）。本方案能够通过监控系统平台实时可视化地展示系统运行的趋势变化，从而及时发现故障隐患，保障系统安全运行的稳定性。

另外，一旦发现系统容量的状态异常，可以通过报警器将系统容量的状态异常的情况及时地反馈给与终端绑定的业务管理人员，使得业务管理人员能够更加迅速地获知系统容量的异常情况，以便及时发现故障隐患，排查故障，有重点地解决系统运行中的故障，减少因系统容量的异常状态造成损失，为系统的稳定运行保驾护航。

可选的，根据多个功能的调用情况控制第一服务节点的系统容量之前，后端服务器还可以先根据第一服务节点的第一功能在预设周期内的历史调用耗时确定第一功能的平均调用耗时；然后根据单位工作进程的量化值、第一功能的调用次数和平均调用耗时确定工作总进程的量化值，其中，单位工作进程的量化值属于预设的单位值；最后根据工作总进程的量化值确定第一服务节点达到预设门限值时的系统容量。

具体的，举例来说，若后端服务器获取服务节点1对应的“网上交易”业务日志数据中“委托”功能在周一的09:10:00至09:40:00时间段内的历史调用耗时，图5为本申请实施例提供的一种确定第一功能的调用耗时的示意图，如图5所示，09:10:00的历史调用耗时为32ms，09:15:00的历史调用耗时为35ms，09:20:00的历史调用耗时为40ms，09:25:00的历史调用耗时为40ms，09:30:00的历史调用耗时为30ms，09:35:00的历史调用耗时为37ms，09:40:00的历史调用耗时为31ms，将上述09:10:00至09:40:00时间段内的调用耗时值进行平均，得到平均调用耗时为35ms。另外，周二的09:10:00至09:40:00时间段内的历史调用耗时可以参照上述计算过程得到，此处不再进行过多赘述。获取“委托”功能达到预设门限值（即交易时段峰值）时，如图6所示，图6为本申请实施例提供的一种确定第一功能的调用次数的示意图，由于平均调用次数为每秒5200笔，平均调用耗时为35ms，一个工作进程每秒处理约29笔，根据5200/29得到至少需要约180个工作进程（即工作总进程的量化值）。通过工作总进程的量化值表征第一服务节点（服务节点1）达到预设门限值时的系统容量。本方案基于对工作进程进行量化分析，从而体现第一服务节点达到预设门限值时的系统容量，能够使得针对系统容量的数据的筛查机制更可靠。

可选的，后端服务器得到第一服务节点的第一功能的交易时段的方式中模型化训练的方式具体可以为：向预测模型输入待预测数据，得到第一服务节点的第一功能的交易时段，其中，待预测数据包括第一功能的调用情况，预测模型为根据多条样本数据训练得到的模型，样本数据包括特征数据和标签数据，特征数据包括各个服务节点的多个功能的历史调用情况，标签数据包括各个服务节点的多个功能的历史交易时段。

具体的，后端服务器可以通过获取整套流程的多条样本数据进行训练得到预测模型，得到的预测模型提供从输入到所需输出的准确映射。其中，多条样本数据包括特征数据和标签数据，特征数据包括各个服务节点的多个功能的历史调用情况，标签数据包括各个服务节点的多个功能的历史交易时段。根据多条样本数据训练得到预测模型后，只需要获取第一功能的待预测数据（其中，待预测数据包括第一功能的调用情况），而后将该第一功能的待预测数据输入到预测模型中，而无需再将整套流程重新执行一遍，即可直接根据第一功能的调用情况确定交易时段。通过利用训练模型提高了根据第一功能的调用情况确定交易时段的效率。

可选的，原始日志数据还包括用户的数据信息，用户的数据信息包括用户消耗系统资源的程度、用户使用的委托渠道、用户关联的客户端的版本信息中的至少一项；根据用户的数据信息和第一功能在交易时段的调用情况评估第一服务节点的系统容量。

具体的，图7为本申请实施例提供的一种根据原始日志数据评估第一服务节点的系统容量的示意图，如图7所示，除了可以从功能维度（即多个功能交易时段的调用情况，具体的，比如可以包括第一功能的调用次数和第一功能的调用耗时）了解当前业务系统中哪些功能的调用次数比较多，哪些功能的调用耗时比较大之外，还可以从用户维度（即多个用户的数据信息，具体可以包括用户消耗的系统资源以及客户端版本信息）了解哪些用户消耗了过多的系统资源，用户使用的委托渠道，客户端版本信息等（举例来说，若“网上交易”业务日志数据中的“委托”功能在交易时段的调用情况为：总调用次数为200笔/秒、调用耗时为85ms，用户的数据信息包括在该交易时段内在线用户人数有9500人，其中，有5400名用户网速过慢，占用了“委托”功能的系统资源，另外，有3210名用户的客户端版本过低，需要升级更新）。综合上述从不同维度、多方面的考量对系统运行状况进行量化分析，综合得出第一服务节点的系统容量为150个工作进程，以及实时展示系统运行趋势变化，从而使得本申请能够综合评估第一服务节点的系统容量，使得评估结果更加准确，同时也能够为系统容量评估提供有力的数据支持。

在现实生活中，系统管理人员为把握核心柜台系统的运行状况，对于安全运行格外重视。但目前商业公司的产品成本高昂，传统的命令行很难应对分散在多台机器上的海量数据，业务日志格式五花八门，且较难为适应日志系统去做专门的改造。现有技术主要是通过CPU、内存、网络流量等基础监控指标对业务进行监控、异常检测、容量规划、性能调优等操作，但各个柜台分散的日志数据会对进行业务监控、异常检测、容量规划、性能调优等操作造成阻碍。而本申请从多个维度（如多个功能的调用情况、多个用户的数据信息）着手，对系统的运行状况进行量化分析，实时展示系统运行趋势变化，为系统容量评估提供数据支持。从而使得业务管理人员能够及时发现故障隐患，有重点地解决系统运行中的故障，维护系统安全。

上述详细阐述了本申请实施例的方法，下面提供本申请实施例的装置。

可以理解的是，本申请实施例提供的多个装置，例如系统容量评估装置，为了实现上述方法实施例中的功能，其包含了执行各个功能相应的硬件结构、软件模块、或硬件结构和软件结构的组合等。

本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以在不同的使用场景中，使用不同的装置实现方式来实现前述的方法实施例，对于装置的不同实现方式不应认为超出本申请实施例的范围。

本申请实施例可以对装置进行功能模块的划分。例如，可对应各个功能划分各个功能模块，也可将两个或两个以上的功能集成在一个功能模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

例如，以采用集成的方式划分装置各个功能模块的情况下，本申请例举几种可能的处理装置。

请参见图8，图8是本申请实施例提供的一种基于业务日志的系统容量评估装置80的结构示意图，该系统容量评估装置80可以为图1所示的后端服务器或者为该后端服务器中的一个器件，例如芯片、软件模块、集成电路等。该系统容量评估装置80用于实现前述的基于业务日志的系统容量评估方法，例如图2所述的基于业务日志的系统容量评估方法。

一种可能的实施方式中，该系统容量评估装置80可以包括采集单元801、解析单元802和控制单元803。

所述采集单元801，用于采集第一服务节点对应的原始日志数据，其中，所述原始日志数据包括多个功能的日志数据，所述多个功能包括所述第一服务节点提供的证券业务中的功能；

所述解析单元802，用于对所述原始日志数据进行解析，得到所述多个功能的调用情况，其中，所述调用情况包括调用次数和调用耗时中的至少一项；

所述控制单元803，用于根据所述多个功能的调用情况控制所述第一服务节点的系统容量。

在现实生活中，系统管理人员为把握核心柜台系统的运行状况，对于安全运行格外重视。但目前商业公司的产品成本高昂，传统的命令行很难应对分散在多台机器上的海量数据，业务日志格式五花八门，且较难为适应日志系统去做专门的改造。现有技术主要是通过CPU、内存、网络流量等基础监控指标对业务进行监控、异常检测、容量规划、性能调优等操作，但各个柜台分散的日志数据会对进行性能调优等操作造成阻碍。而本申请从多个维度（如多个功能的调用情况、多个用户的数据信息）着手，对系统的运行状况进行量化分析，实时展示系统运行趋势变化，为系统容量评估提供数据支持。从而使得业务管理人员能够及时发现故障隐患，有重点地解决系统运行中的故障，维护系统安全。

另一种可能的实施方式中，在所述根据所述多个功能的调用情况控制所述第一服务节点的系统容量方面，所述控制单元803，具体用于：

根据所述第一功能的调用情况确定交易时段，其中，所述功能包括业务功能和普通功能，所述业务功能包括委托、登录、转账中的至少一项，所述普通功能为业务系统中的历史查询功能，在所述交易时段所述第一服务节点的调用情况达到预设门限值，所述第一功能为所述业务功能中的任意一个；

根据所述第一功能在所述交易时段的调用情况评估所述第一服务节点的系统容量；

若所述第一服务节点的系统容量小于第一预设阈值，则调整所述普通功能；

根据调整后的所述普通功能控制所述第一服务节点的系统容量，直至所述系统容量大于所述第一预设阈值。

在本申请实施例中，由于在影响证券系统运行状态的所有时段中，交易时段的系统维护相比非交易时段（如工作日的休息时间或者周末）而言更为关键，因此可以针对交易时段对服务节点的系统容量进行预测。具体的，后端服务器可以通过多个功能（如委托、登录、转账）中的任意一个功能的调用情况确定出该功能的交易时段，再根据该功能在交易时段时第一服务节点的调用情况评估系统容量。若第一服务节点的系统容量小于第一预设阈值（比如服务节点1在根据场内证券交易结算指令确定场内证券交易为买券的交易时，若该系统容量为150个工作进程，当小于第一预设阈值200个工作进程时,则此时后端服务器可以控制服务节点1的系统容量（如可以进行开源节流、归档历史数据、对非关键功能（普通功能）进行降级/关停等操作）直至系统容量重新大于200个工作进程后结束操作。本方案能够通过精确建立数据的筛查机制，筛选出交易时段的功能，从而有针对性地预估预设门限值时的系统容量。

又一种可能的实施方式中，在所述根据所述第一功能的调用情况确定交易时段方面，确定单元，具体用于：

向预测模型输入待预测数据，得到所述第一服务节点的第一功能的交易时段，其中，所述待预测数据包括所述第一功能的调用情况，所述预测模型为根据多条样本数据训练得到的模型，所述样本数据包括特征数据和标签数据，所述特征数据包括各个服务节点的多个功能的历史调用情况，所述标签数据包括所述各个服务节点的多个功能的历史交易时段。

在本申请实施例中，后端服务器得到第一服务节点的第一功能的交易时段的方式中模型化训练的方式具体可以为：通过获取整套流程的多条样本数据进行训练得到预测模型，得到的预测模型提供从输入到所需输出的准确映射。其中，多条样本数据包括特征数据和标签数据，特征数据包括各个服务节点的多个功能的历史调用情况，标签数据包括各个服务节点的多个功能的历史交易时段。根据多条样本数据训练得到预测模型后，只需要获取第一功能的待预测数据（其中，待预测数据包括第一功能的调用情况），而后将该第一功能的待预测数据输入到预测模型中，而无需再将整套流程重新执行一遍，即可直接根据第一功能的调用情况确定交易时段。通过利用训练模型提高了根据第一功能的调用情况确定交易时段的效率。

又一种可能的实施方式中，所述原始日志数据还包括用户的数据信息，所述用户的数据信息包括所述用户消耗系统资源的程度、所述用户使用的委托渠道、所述用户关联的客户端的版本信息中的至少一项；

在所述根据所述第一功能在所述交易时段的调用情况评估所述第一服务节点的系统容量方面，评估单元，具体用于：

根据所述用户的数据信息和所述第一功能在所述交易时段的调用情况评估所述第一服务节点的系统容量。

在本申请实施例中，原始日志数据中还可以包括用户的数据信息，其中用户的数据信息包括用户消耗系统资源的程度、用户使用的委托渠道和用户关联的客户端的版本信息中的至少一项，即除了可以从功能的维度了解当前业务系统中哪些功能的调用次数比较多，哪些功能的调用耗时比较大之外，还可以从用户的维度了解哪些用户消耗了过多的系统资源，用户使用的委托渠道，客户端版本信息等，本申请可以通过上述从不同维度、多方面的考量（如用户的数据信息和第一功能在交易时段的调用情况）对系统运行状况进行量化分析，实时展示系统运行趋势变化，从而能够综合评估第一服务节点的系统容量，使得评估结果更加准确，同时也能够为系统容量评估提供有力的数据支持。

又一种可能的实施方式中，在所述根据所述多个功能的调用情况控制所述第一服务节点的系统容量之前，所述确定单元，还用于：

根据所述第一服务节点的第一功能在预设周期内的历史调用耗时确定所述第一功能的平均调用耗时；

根据单位工作进程的量化值、所述第一功能的调用次数和所述平均调用耗时确定工作总进程的量化值，其中，所述单位工作进程的量化值属于预设的单位值；

根据所述工作总进程的量化值确定第一服务节点达到所述预设门限值时的系统容量。

在本申请实施例中，后端服务器在根据多个功能的调用情况控制第一服务节点的系统容量之前，还可以先根据第一服务节点的第一功能在预设周期内的历史调用耗时确定第一功能的平均调用耗时（比如获取服务节点1对应的“网上交易”业务日志数据中“委托”功能在09:10:00至09:40:00时间段内的历史调用耗时将09:10:00至09:40:00时间段内的调用耗时值进行平均，得到平均调用耗时后，再获取“委托”功能达到预设门限值（即交易时段峰值）时的调用次数，最后综合一个工作进程每秒处理的笔数得出需要的工作进程（即工作总进程的量化值）。通过工作总进程的量化值表征第一服务节点（服务节点1）达到预设门限值时的系统容量。本方案基于对工作进程进行量化分析，从而体现第一服务节点达到预设门限值时的系统容量，能够使得针对系统容量的数据的筛查机制更可靠。

又一种可能的实施方式中，在所述根据所述第一功能在交易时段的调用情况评估所述第一服务节点的系统容量方面，所述确定单元，还用于：

若所述第一功能在预设时间段内的调用次数大于第二预设阈值和/或所述调用耗时大于第三预设阈值，则确定所述第一服务节点的系统容量为异常状态。

在本申请实施例中，若根据第一功能在交易时段的历史耗时与历史调用次数的趋势对比，发现系统容量状态异常（如“委托”功能在交易时段中的平均历史调用次数为8000次/min，大于第二预设阈值5000次/min，和/或平均历史调用耗时为30ms，大于第三预设阈值5ms，观察发现系统现阶段会间歇性的出现异常耗时突起），则后端服务器可以确定第一服务节点（服务节点1）的系统性能为异常状态，此时在监控程序中表征为波形图的起伏大且紧凑，若排查后确定其故障原因是数据库的监控程序长期运行，在重启该监控程序后，波形图趋于平稳。本方案能够通过监控系统平台实时可视化地展示系统运行的趋势变化，从而及时发现故障隐患，保障系统安全运行的稳定性。

又一种可能的实施方式中，在所述若所述第一功能的调用次数大于第一预设阈值和/或耗时大于第二预设阈值，则确定所述第一服务节点的系统容量为异常状态之后，发送单元，具体用于：

向与终端绑定的管理所述第一服务节点的业务人员发送报警信号，其中，所述报警信号用于通知所述业务人员排查故障；

存储单元，具体用于将所述系统容量为异常状态对应的所述第一服务节点的日志数据存储在异常业务数据库中。

在本申请实施例中，能够及时对系统的运行状态进行监测，一旦发现系统容量的状态异常，可以通过报警器将系统容量的状态异常的情况及时地反馈给与终端绑定的业务管理人员，使得业务管理人员能够更加迅速地获知系统容量的异常情况，以便及时发现故障隐患，排查故障，有重点地解决系统运行中的故障，减少因系统容量的异常状态造成损失，为系统的稳定运行保驾护航。

请参见图9，图9是本申请实施例提供的一种基于业务日志的系统容量评估设备90的结构示意图，该系统容量评估设备90可以为服务器或者为服务器中的一个器件，例如芯片、软件模块、集成电路等。该系统容量评估设备90可以包括至少一个处理器901。可选的还可以包括至少一个存储器903。进一步可选的系统容量评估设备90还可以包括通信接口902。更进一步可选的，还可以包含总线904，其中，处理器901、通信接口902和存储器903通过总线904相连。

其中，处理器901是进行算术运算和/或逻辑运算的模块，具体可以是中央处理器（Central Processing Unit，CPU）、图片处理器（Graphics Processing Unit，GPU）、微处理器（Microprocessor Unit，MPU）、专用集成电路（Application Specific IntegratedCircuit，ASIC）、现场可编程逻辑门阵列（Field Programmable Gate Array，FPGA）、复杂可编程逻辑器件（Complex Programmable Logic Device，CPLD）、协处理器（协助中央处理器完成相应处理和应用）、微控制单元（Microcontroller Unit，MCU）等处理模块中的一种或者多种的组合。

通信接口902可以用于为所述至少一个处理器提供信息输入或者输出。和/或，所述通信接口902可以用于接收外部发送的数据和/或向外部发送数据，可以为包括诸如以太网电缆等的有线链路接口，也可以是无线链路（Wi-Fi、蓝牙、通用无线传输、车载短距通信技术以及其他短距无线通信技术等）接口。可选的，通信接口902还可以包括与接口耦合的发射器（如射频发射器、天线等），或者接收器等。

存储器903用于提供存储空间，存储空间中可以存储操作系统和计算机程序等数据。存储器903可以是随机存储记忆体（Random Access Memory，RAM）、只读存储器（Read-only Memory，ROM）、可擦除可编程只读存储器（Erasable Programmable Read-onlyMemory，EPROM）、或便携式只读存储器（Compact Disc Read-only Memory，CD-ROM）等等中的一种或者多种的组合。

该系统容量评估设备90中的至少一个处理器901用于执行前述的方法，例如图2所述实施例所描述的方法。

可选的，处理器901，可以是专门用于执行这些方法的处理器（便于区别称为专用处理器），也可以是通过调用计算机程序来执行这些方法的处理器，例如通用处理器。可选的，至少一个处理器还可以既包括专用处理器也包括通用处理器。可选的，在计算设备包括至少一个处理器901的情况下，上述计算机程序可以存在存储器903中。

可选的，该系统容量评估设备90中的至少一个处理器901用于执行调用计算机指令，以执行以下操作：

采集第一服务节点对应的原始日志数据，其中，所述原始日志数据包括多个功能的日志数据，所述多个功能包括所述第一服务节点提供的证券业务中的功能；

对所述原始日志数据进行解析，得到所述多个功能的调用情况，其中，所述调用情况包括调用次数和调用耗时中的至少一项；

根据所述多个功能的调用情况控制所述第一服务节点的系统容量。

在现实生活中，系统管理人员为把握核心柜台系统的运行状况，对于安全运行格外重视。但目前商业公司的产品成本高昂，传统的命令行很难应对分散在多台机器上的海量数据，业务日志格式五花八门，且较难为适应日志系统去做专门的改造。现有技术主要是通过CPU、内存、网络流量等基础监控指标对业务进行监控、异常检测、容量规划、性能调优等操作，但各个柜台分散的日志数据会对进行业务监控、异常检测、容量规划、性能调优等操作造成阻碍。而本申请从多个维度（如多个功能的调用情况、多个用户的数据信息）着手，对系统的运行状况进行量化分析，实时展示系统运行趋势变化，为系统容量评估提供数据支持。从而使得业务管理人员能够及时发现故障隐患，有重点地解决系统运行中的故障，维护系统安全。

可选的，所述处理器901还用于：

根据所述第一功能的调用情况确定交易时段，其中，所述功能包括业务功能和普通功能，所述业务功能包括委托、登录、查询中的至少一项，所述普通功能为业务系统中的常设功能，在所述交易时段所述第一服务节点的调用情况达到预设门限值，所述第一功能为所述业务功能中的任意一个；

根据所述第一功能在所述交易时段的调用情况评估所述第一服务节点的系统容量；

若所述第一服务节点的系统容量小于第一预设阈值，则调整所述普通功能；

根据调整后的所述普通功能控制所述第一服务节点的系统容量，直至所述系统容量大于所述第一预设阈值。

在本申请实施例中，由于在影响证券系统运行状态的所有时段中，交易时段的系统维护相比非交易时段（如工作日的休息时间或者周末）而言更为关键，因此可以针对交易时段对服务节点的系统容量进行预测，具体的，后端服务器可以通过多个功能（如委托、登录、转账）中的任意一个功能的调用情况确定出该功能的交易时段，再根据该功能在交易时段时第一服务节点的调用情况评估系统容量。若第一服务节点的系统容量小于第一预设阈值（比如服务节点1在根据场内证券交易结算指令确定场内证券交易为买券的交易时，若该系统容量为150个工作进程，当小于第一预设阈值200个工作进程时,则此时后端服务器可以控制服务节点1的系统容量（如可以进行开源节流、归档历史数据、对非关键功能（普通功能）进行降级/关停等操作）直至系统容量重新大于200个工作进程后结束操作。本方案能够通过精确建立数据的筛查机制，筛选出交易时段的功能，从而有针对性地预估预设门限值时的系统容量。

可选的，所述处理器901还用于：

向预测模型输入待预测数据，得到所述第一服务节点的第一功能的交易时段，其中，所述待预测数据包括所述第一功能的调用情况，所述预测模型为根据多条样本数据训练得到的模型，所述样本数据包括特征数据和标签数据，所述特征数据包括各个服务节点的多个功能的历史调用情况，所述标签数据包括所述各个服务节点的多个功能的历史交易时段。

在本申请实施例中，后端服务器得到第一服务节点的第一功能的交易时段的方式中模型化训练的方式具体可以为：通过获取整套流程的多条样本数据进行训练得到预测模型，得到的预测模型提供从输入到所需输出的准确映射。其中，多条样本数据包括特征数据和标签数据，特征数据包括各个服务节点的多个功能的历史调用情况，标签数据包括各个服务节点的多个功能的历史交易时段。根据多条样本数据训练得到预测模型后，只需要获取第一功能的待预测数据（其中，待预测数据包括第一功能的调用情况），而后将该第一功能的待预测数据输入到预测模型中，而无需再将整套流程重新执行一遍，即可直接根据第一功能的调用情况确定交易时段。通过利用训练模型提高了根据第一功能的调用情况确定交易时段的效率。

可选的，所述原始日志数据还包括用户的数据信息，所述用户的数据信息包括所述用户消耗系统资源的程度、所述用户使用的委托渠道、所述用户关联的客户端的版本信息中的至少一项；

所述处理器901还用于：

根据所述用户的数据信息和所述第一功能在所述交易时段的调用情况评估所述第一服务节点的系统容量。

在本申请实施例中，原始日志数据中还可以包括用户的数据信息，其中用户的数据信息包括用户消耗系统资源的程度、用户使用的委托渠道和用户关联的客户端的版本信息中的至少一项，即除了可以从功能的维度了解当前业务系统中哪些功能的调用次数比较多，哪些功能的调用耗时比较大之外，还可以从用户的维度了解哪些用户消耗了过多的系统资源，用户使用的委托渠道，客户端版本信息等，本申请可以通过上述从不同维度、多方面的考量（如用户的数据信息和第一功能在交易时段的调用情况）对系统运行状况进行量化分析，实时展示系统运行趋势变化，从而能够综合评估第一服务节点的系统容量，使得评估结果更加准确，同时也能够为系统容量评估提供有力的数据支持。

可选的，所述处理器901还用于：

根据所述第一服务节点的第一功能在预设周期内的历史调用耗时确定所述第一功能的平均调用耗时；

根据单位工作进程的量化值、所述第一功能的调用次数和所述平均调用耗时确定工作总进程的量化值，其中，所述单位工作进程的量化值属于预设的单位值；根据所述工作总进程的量化值确定第一服务节点达到所述预设门限值时的系统容量。

在本申请实施例中，后端服务器在根据多个功能的调用情况控制第一服务节点的系统容量之前，还可以先根据第一服务节点的第一功能在预设周期内的历史调用耗时确定第一功能的平均调用耗时（比如获取服务节点1对应的“网上交易”业务日志数据中“委托”功能在09:10:00至09:40:00时间段内的历史调用耗时将09:10:00至09:40:00时间段内的调用耗时值进行平均，得到平均调用耗时后，再获取“委托”功能达到预设门限值（即交易时段峰值）时的调用次数，最后综合一个工作进程每秒处理的笔数得出需要的工作进程（即工作总进程的量化值）。通过工作总进程的量化值表征第一服务节点（服务节点1）达到预设门限值时的系统容量。本方案基于对工作进程进行量化分析，从而体现第一服务节点达到预设门限值时的系统容量，能够使得针对系统容量的数据的筛查机制更可靠。

可选的，所述处理器901还用于：

若所述第一功能在预设时间段内的调用次数大于第二预设阈值和/或所述调用耗时大于第三预设阈值，则确定所述第一服务节点的系统容量为异常状态。

在本申请实施例中，若根据第一功能在交易时段的历史耗时与历史调用次数的趋势对比，发现系统容量状态异常（如“委托”功能在交易时段中的平均历史调用次数为8000次/min，大于第二预设阈值5000次/min，和/或平均历史调用耗时为30ms，大于第三预设阈值5ms，观察发现系统现阶段会间歇性的出现异常耗时突起），则后端服务器可以确定第一服务节点（服务节点1）的系统性能为异常状态，此时在监控程序中表征为波形图的起伏大且紧凑，若排查后确定其故障原因是数据库的监控程序长期运行，在重启该监控程序后，波形图趋于平稳。本方案能够通过监控系统平台实时可视化地展示系统运行的趋势变化，从而及时发现故障隐患，保障系统安全运行的稳定性。

可选的，所述处理器901还用于：

向与终端绑定的管理所述第一服务节点的业务人员发送报警信号，其中，所述报警信号用于通知所述业务人员排查故障；

将所述系统容量为异常状态对应的所述第一服务节点的日志数据存储在异常业务数据库中。

在本申请实施例中，能够及时对系统的运行状态进行监测，一旦发现系统容量的状态异常，可以通过报警器将系统容量的状态异常的情况及时地反馈给与终端绑定的业务管理人员，使得业务管理人员能够更加迅速地获知系统容量的异常情况，以便及时发现故障隐患，排查故障，有重点地解决系统运行中的故障，减少因系统容量的异常状态造成损失，为系统的稳定运行保驾护航。

本申请还提供了一种算机可读存储介质，所述计算机可读存储介质中存储有指令，当所述指令在至少一个处理器上运行时，实现前述的基于业务日志的系统容量评估方法，例如图2所述的方法。

本申请还提供了一种计算机程序产品，该计算机程序产品包括计算机指令，在被计算设备执行时，实现前述的基于业务日志的系统容量评估方法，例如图2所述的方法。

本申请实施例中，“举例来说”或者“比如”等词用于表示作例子、例证或说明。本申请中被描述为“举例来说”或者“比如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用“举例来说”或者“比如”等词旨在以具体方式呈现相关概念。

本申请中实施例提到的“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项（个）或复数项（个）的任意组合。例如，a、b、或c中的至少一项（个），可以表示：a、b、c、（a和b）、（a和c）、（b和c）、或（a和b和c），其中a、b、c可以是单个，也可以是多个。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A、同时存在A和B、单独存在B这三种情况，其中A、B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。

以及，除非有相反的说明，本申请实施例使用“第一”、“第二”等序数词是用于对多个对象进行区分，不用于限定多个对象的顺序、时序、优先级或者重要程度。例如，第一设备和第二设备，只是为了便于描述，而并不是表示这第一设备和第二设备的结构、重要程度等的不同，在某些实施例中，第一设备和第二设备还可以是同样的设备。

上述实施例中所用，根据上下文，术语“当……时”可以被解释为意思是“如果……”或“在……后”或“响应于确定……”或“响应于检测到……”。以上所述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的构思和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (10)

1.一种基于业务日志的系统容量评估方法，其特征在于，应用于后端服务器，所述方法包括：

采集第一服务节点对应的原始日志数据，其中，所述原始日志数据包括多个功能的日志数据，所述多个功能包括所述第一服务节点提供的证券业务中的功能；

对所述原始日志数据进行解析，得到所述多个功能的调用情况，其中，所述调用情况包括调用次数和调用耗时中的至少一项；

根据所述多个功能的调用情况控制所述第一服务节点的系统容量。

2.根据权利要求1所述的方法，其特征在于，所述根据所述多个功能的调用情况控制所述第一服务节点的系统容量，包括：

根据第一功能的调用情况确定交易时段，其中，所述功能包括业务功能和普通功能，所述业务功能包括委托、登录、转账中的至少一项，所述普通功能为业务系统中的历史查询功能，在所述交易时段所述第一服务节点的调用情况达到预设门限值，所述第一功能为所述业务功能中的任意一个；

根据所述第一功能在所述交易时段的调用情况评估所述第一服务节点的系统容量；

若所述第一服务节点的系统容量小于第一预设阈值，则调整所述普通功能；

根据调整后的所述普通功能控制所述第一服务节点的系统容量，直至所述系统容量大于所述第一预设阈值。

3.根据权利要求2所述的方法，其特征在于，所述根据所述第一功能的调用情况确定交易时段，包括：

向预测模型输入待预测数据，得到所述第一服务节点的第一功能的交易时段，其中，所述待预测数据包括所述第一功能的调用情况，所述预测模型为根据多条样本数据训练得到的模型，所述样本数据包括特征数据和标签数据，所述特征数据包括各个服务节点的多个功能的历史调用情况，所述标签数据包括所述各个服务节点的多个功能的历史交易时段。

4.根据权利要求2所述的方法，其特征在于，所述原始日志数据还包括用户的数据信息，所述用户的数据信息包括所述用户消耗系统资源的程度、所述用户使用的委托渠道、所述用户关联的客户端的版本信息中的至少一项；

所述根据所述第一功能在所述交易时段的调用情况评估所述第一服务节点的系统容量，包括：

根据所述用户的数据信息和所述第一功能在所述交易时段的调用情况评估所述第一服务节点的系统容量。

5.根据权利要求2或3所述的方法，其特征在于，所述根据所述多个功能的调用情况控制所述第一服务节点的系统容量之前，还包括：

根据所述第一服务节点的第一功能在预设周期内的历史调用耗时确定所述第一功能的平均调用耗时；

根据单位工作进程的量化值、所述第一功能的调用次数和所述平均调用耗时确定工作总进程的量化值，其中，所述单位工作进程的量化值属于预设的单位值；

根据所述工作总进程的量化值确定第一服务节点达到所述预设门限值时的系统容量。

6.根据权利要求2所述的方法，其特征在于，所述根据所述第一功能在所述交易时段的调用情况评估所述第一服务节点的系统容量，包括：

若所述第一功能的调用次数大于第二预设阈值和/或所述调用耗时大于第三预设阈值，则确定所述第一服务节点的系统容量为异常状态。

7.根据权利要求6所述的方法，其特征在于，所述若所述第一功能的调用次数大于第一预设阈值和/或耗时大于第二预设阈值，则确定所述第一服务节点的系统容量为异常状态之后，还包括：

向与终端绑定的管理所述第一服务节点的业务人员发送报警信号，其中，所述报警信号用于通知所述业务人员排查故障；

将所述系统容量为异常状态对应的所述第一服务节点的日志数据存储在异常业务数据库中。

8.一种基于业务日志的系统容量评估装置，其特征在于，应用于后端服务器，包括采集单元、解析单元和控制单元，其中：

所述采集单元，用于采集第一服务节点对应的原始日志数据，其中，所述原始日志数据包括多个功能的日志数据，所述多个功能包括所述第一服务节点提供的证券业务中的功能；

所述解析单元，用于对所述原始日志数据进行解析，得到所述多个功能的调用情况，其中，所述调用情况包括调用次数和调用耗时中的至少一项；

所述控制单元，用于根据所述多个功能的调用情况控制所述第一服务节点的系统容量。

9.一种基于业务日志的系统容量评估设备，其特征在于，所述设备包括处理器和存储器，所述存储器用于存储计算机指令，所述处理器用于调用所述计算机指令，以实现权利要求1-7中任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有指令，当所述指令在至少一个处理器上运行时，实现如权利要求1-7中任一项所述的方法。

Images