一种实时告警方法及系统与流程

本申请涉及计算机领域，尤其涉及一种实时告警方法及系统。

背景技术：

互联网服务系统里业务众多且逻辑复杂，线上机器、软件系统的数量也在不断增加，依靠人工巡检系统的方式发现系统故障、潜在风险及安全隐患的效率越来越低下，而且会不断增加运维人员的工作强度及压力，为了提高发现系统故障的及时性，提高系统维护的专业性、规范性、科学性，同时也能把运维人员从重复的工作中解放出来去做更多有意义的事情，人们提出了一些技术方案。

有人提出一种方法，该方法针对故障告警、日志管理和消息跟踪统一设置关键信息项，当业务系统运行过程中发生异常时会根据预先设置的关键信息项生成包含关键信息内容的告警信息，便于查询故障原因。该方法无需管理员自己录入关键信息，提高了系统可维护性。但是该方法存在以下技术问题：当系统异常存在大量告警时，有效信息会被淹没，实用性差。

还有人提出一种方法，通过定期扫描OSS(服务器)日志，分析判断是否存在故障，针对故障发送告警信息。该方法存在以下技术问题：如果系统并发大，大量机器的海量日志分析存在性能问题；定时去获取日志信息，不够实时。

目前，现有技术方案未能解决告警消息的实时性问题。

技术实现要素：

有鉴于此，为解决相关技术中存在的问题，本申请提供一种实时告警方法及系统。

根据本申请实施例的第一方面，提供一种实时告警方法，所述方法包括：

从至少一个被监控对象采集监控数据，所述监控数据包括所述被监控对象的标识信息；

基于所述监控数据获得目标对象的标识信息，所述目标对象为监控数据异常的被监控对象；

如果所述目标对象的监控数据为首次异常，则发出告警信息，所述告警信息携带所述目标对象的标识信息。

在一个可选的实现方式中，所述监控数据包括错误日志，所述错误日志由所述错误日志对应的目标对象调用SDK接口主动上报。

在一个可选的实现方式中，所述方法还包括：

如果所述目标对象的监控数据非首次异常，则判断是否再次发送所述告警信息；

如果是，则发送所述告警信息。

在一个可选的实现方式中，所述判断是否再次发送所述告警信息，包括：

统计所述目标对象的监控数据异常的次数；根据统计结果确定是否发送所述告警信息。

在一个可选的实现方式中，所述根据统计结果确定是否发送所述告警，包括：

根据所统计的所述监控数据异常的次数的数量和/或时间分布特性确定是否发送所述告警信息。

在一个可选的实现方式中，所述根据统计结果确定是否发送所述告警信息，包括以下一种或多种：

如果所统计的所述监控数据异常的次数大于预设阈值，则发送所述告警信息；

如果所统计的所述监控数据异常的次数在时间上呈周期分布，则发送所述告警信息。

在一个可选的实现方式中，所述告警信息还包括所述目标对象的监控数据异常的次数。

在一个可选的实现方式中，所述目标对象的标识信息包括以下一种或多种：设备标识、进程名、源文件名。

根据本公开实施例的第二方面，提供一种实时告警系统，所述系统包括：

采集模块，被配置为从至少一个被监控对象采集监控数据，所述监控数据包括所述被监控对象的标识信息；

获取模块，被配置为基于所述监控数据获得目标对象的标识信息，所述目标对象为监控数据异常的被监控对象；

告警模块，被配置为如果所述目标对象的监控数据为首次异常，则发出告警信息，所述告警信息携带所述目标对象的标识信息。

在一个可选的实现方式中，所述采集模块，包括：

错误日志采集子模块，被配置为采集错误日志，所述错误日志由所述错误日志对应的目标对象调用SDK接口主动上报。

在一个可选的实现方式中，所述系统还包括：

第一判断模块，被配置为判断所述目标对象的监控数据是否首次异常，以及是否需要发送告警信息，并在需要发送告警信息时通知所述告警模块；

第二判断模块，被配置为根据所述第一判断模块的判断结果确定是否发送所述告警信息，并在需要发送告警信息时通知所述告警模块。

在一个可选的实现方式中，所述系统还包括：

统计模块，被配置为统计所述目标对象的监控数据异常的次数；所述第二判断模块根据统计结果确定是否发送所述告警信息。

在一个可选的实现方式中，所述第二判断模块根据统计结果判断是否确定发送所述告警信息，包括：

根据所统计的所述监控数据异常的次数的数量和/或时间分布特性确定是否发送所述告警信息。

在一个可选的实现方式中，所述第二判断模块根据统计结果确定是否发送所述告警信息，包括以下一种或多种：

如果所统计的所述监控数据异常的次数大于预设阈值，则确定发送所述告警信息；

如果所统计的所述监控数据异常的次数在时间上呈周期分布，则确定发送所述告警信息。

在一个可选的实现方式中，所述告警信息还包括所述目标对象的监控数据异常的次数。

在一个可选的实现方式中，所述目标对象的标识信息包括以下一种或多种：设备标识、进程名、源文件名。

根据本公开实施例的第三方面，提供一种设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为：

从至少一个被监控对象采集监控数据，所述监控数据包括所述被监控对象的标识信息；

基于所述监控数据获得目标对象的标识信息，所述目标对象为监控数据异常的被监控对象；

如果所述目标对象的监控数据为首次异常，则发出告警信息，所述告警信息携带所述目标对象的标识信息。

本公开的实施例提供的技术方案可以包括以下有益效果：

本公开中，通过判断监控数据是否首次发生异常，并针对首次发生异常的监控数据立即发出告警，保证了告警的实时性。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

图1是本申请实施例中一应用环境的网络图。

图2A是本申请根据一示例性实施例示出的一种实时告警方法的部分流程图。

图2B是本申请根据一示例性实施例示出的另一种实时告警方法的流程图。

图2C是本申请根据一示例性实施例示出的另一种实时告警方法的流程图。

图2D是本申请根据一示例性实施例示出的另一种实时告警方法的流程图。

图2E是本申请根据一示例性实施例示出的一个实时告警过程示意图。

图3A是本申请根据一示例性实施例示出的一种实时告警系统的框图。

图3B是本申请根据一示例性实施例示出的另一种实时告警系统的部分框图。

图3C是本申请根据一示例性实施例示出的另一种实时告警系统的框图。

图3D是本申请根据一示例性实施例示出的另一种实时告警系统的框图。

图3E是本申请根据一示例性实施例示出的另一种实时告警系统的框图。

图4是本申请实时告警装置所在的监控告警平台的一种硬件结构图。

图5A是本申请根据一示例性实施例示出的一种实时告警系统的结构示意图。

图5B是本申请根据一示例性实施例示出的另一种实时告警系统的结构示意图。

图5C是本申请根据一示例性实施例示出的另一种实时告警系统的结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

图1是一个互联网服务系统的示意图，服务系统中为用户提供各种业务的业务系统种类很多，例如，图中的设备100a、设备100b、设备100c均可以充当服务器100，作为服务提供方为客户端101提供各种服务；在一台设备上，也可以通过多个应用程序(例如，客户端101上的应用程序x1、应用程序x2、应用程序x3等)在本地为用户提供各种服务。从图1中可以看出，提供服务的一方可以是通过远程的方式，也可以是通过本地的方式来实现。由于互联网服务类型多样，业务逻辑复杂，网络情况的不确定、服务过程的不可预知或者开发人员的疏忽等各种原因都会造成服务出现问题，如何在服务出现问题的第一时间让相关人员得到有用的告警信息十分重要。

本申请中，将服务提供方作为被监控对象，被监控对象可以是可能发生故障的硬件设备、应用程序等，例如可以是处于物联网中的家电设备(电扇、冰箱、洗衣机、电视等)、同一台计算机上的各种应用程序等。监控数据可以根据被监控对象的不同特性来确定其种类。例如，当被监控对象是内存时，监控数据可以是内存的使用情况；当被监控对象为CPU时，监控数据可以是CPU使用率；当被监控对象是网络时，监控数据可以是网络的连接状况，比如是否出现网络抖动；当被监控对象为计算机上某种应用程序时，被监控对象可以是应用程序的运行数据、日志等。

如图2A所示，图2A是本申请根据一示例性实施例示出的一种实时告警方法的部分流程图，包括以下步骤S200至S204：

在步骤S200中，从至少一个被监控对象采集监控数据，所述监控数据包括所述被监控对象的标识信息；

在步骤S202中，基于所述监控数据获得目标对象的标识信息，所述目标对象为监控数据异常的被监控对象；

在步骤S204中，如果所述目标对象的监控数据为首次异常，则发出告警信息，所述告警信息携带所述目标对象的标识信息。

监控数据的种类多样可以保证监控告警的全面性，监控数据的具体种类可以根据实际需要来设定，本申请对此不作限制。

当被监控对象出现问题时监控数据会产生异常，监控数据产生异常的原因有很多，比如CPU使用率过高，内存剩余量不足，应用程序逻辑错误，应用访问的服务不存在，应用抛出异常(比如异常关闭)等。本申请将监控数据异常的被监控对象作为本申请中的目标对象，例如目标对象可以是出现问题的硬件设备(比如使用率过高的CPU、剩余量不足的内存)或者发生异常的应用程序(比如异常关闭的应用)。

目标对象出现时，需要及时发出告警信息通知相关人员，以使相关人员能够在第一时间处理问题。在本申请中，告警信息可以通过短信或即时通讯软件(比如YY、QQ等)发送。例如，当CPU温度过高时，可以通过短信发送告警信息通知相关人员及时采取相应措施(比如可以关闭某些不必要的应用进程)。具体发送方式可以根据需要来选择，本申请对发送方式不作限制。在一个可选的实现方式中，告警信息还可以包括告警次数，以便引起技术人员注意。比如告警次数为1，表明此类告警信息第一次发生；告警次数为1000，表明次告警信息第1000次发生。

以上所述的监控数据、告警信息可以包含被监控对象的标识信息，标识信息可以用来表示被监控对象且标识信息具有唯一性。当被监控对象出现故障时，可以根据异常数据和告警信息中所携带的标识信息找到目标对象，以便及时解决故障。在一个可选的实现方式中，标识信息可以包括设备标识、进程名、源文件名等中的一种或多种。例如，硬件设备的标识信息可以包括设备标识，日志的标识信息可以包括进程名、原文件名，进程的标识信息可以包括进程名。比如，当洗衣机出现异常导致运行中断时会发出告警信息，此告警信息可以携带有该洗衣机的设备标识，以使监控方通过告警信息识别出发送该告警信息的设备是洗衣机。本领域技术人员应该理解的是，任意能够区别于其他被监控对象的信息，均可以用作本申请中的标识信息。

在本实施例中，从至少一个被监控对象采集监控数据可以是从被监控对象处采集监控数据，也可以是被监控对象主动上报监控数据。

在一个可选的实现方式中，被监控对象可以是硬件设备，比如CPU、内存，对应的监控数据可以是CPU的使用率、内存的剩余量，这些监控数据是从被监控对象处采集而来。例如，可以通过设置一SDK(软件开发包)，通过SDK其中一个接口主动从被监控对象处采集而来。

在一个可选的实现方式中，被监控对象可以是某一应用程序，对应的监控数据可以是日志。日志是网络设备、系统及服务程序等在运作时产生的一个事件记录，每一行日志都记载着日期、时间、使用者及动作等相关操作的描述。日志包括应用程序日志，安全日志、系统日志等，当运行出错(比如应用程序逻辑错误、应用访问的服务不存在等)时会产生错误日志，编程人员和维护人员等可以利用错误日志对系统进行调试和维护。传统技术是通过对服务器日志周期性扫描，分析日志信息，判断是否存在故障信息，并将故障信息生成告警报告。此方法定时去获取日志信息，不够实时；而且如果系统并发大，产生海量日志，分析困难，难以找出故障所在。在一个例子中，可以将错误日志主动上报，以提高告警的实时性。错误日志主动上报可以通过设置一SDK来实现，比如由错误日志对应的进程调用上述SKD另一接口接口主动上报。作为一个例子，如果应用程序出现异常，比如应用程序访问的服务不存在、应用程序抛出异常等，除了上述打印错误日志主动上报以外，还可以由出现异常的应用直接调用上述SDK另一接口(设置为一个主动告警接口)上报错误。

在另一个实施例中，对于目标对象的监控数据是否为首次异常需要进行判断，可以根据判断结果来确定是否发送所述告警信息。可参考图2B，在图2A所述基础上还包括步骤S203：

步骤S203，判断所述目标对象的监控数据是否首次异常；

如果是，则转到步骤S204，发出告警信息。

其中，判断目标对象的监控数据是否首次异常的方式可以有多种，比如可以通过将需要判断的目标对象的监控数据的标识信息与已记录的标识信息做对比得出。监控数据的标识信息可以包括设备标识、代表监控数据种类的标识(比如温度、使用率等)进程名、源文件名、行号等的一种或多种，具体需要根据被监控对象及监控数据确定。例如，被监控对象是CPU，监控数据的种类是CPU的使用率，对应的监控数据的标识信息可以包括CPU的设备信息和使用率标识，表明监控数据是与CPU使用率相关的数据；被监控对象如果是某一应用，监控数据是应用运行时系统记录的日志，对应的监控数据的标识信息可以包括进程名、源文件名、行号，通过进程名可以找到出问题的应用，通过源文件名和行号可以找到出问题的代码。在一个例子中可以对采集的监控数据进行维护，作为例子，可以将异常的监控数据单独存储，在记录异常的监控数据时，除了记录监控数据的标识信息，还可以记录监控数据的异常次数，在首次就异常的监控数据时，可以记录其标识信息，当该监控数据再次异常时，将对应的标识信息出现的次数加1。因此，可以根据已有的记录内容判断监控数据是否首次异常，如果监控数据的标识信息没有记录则说明监控数据为首次异常；如果监控数据的标识信息已有记录则说明非首次异常，将对应的出现异常的次数加1。

本申请将告警信息分两阶段发送，对于监控数据的首次异常立即发送告警信息，保证了告警实时性；对于非首次异常的监控数据暂不发送告警信息，避免了大量重复告警的干扰。

但是，由于并非所有的告警信息都能正常发送到相关人员并引起相关人员注意，比如可能由于设备故障或网络原因导致告警信息发送失败，也可能信息正常发送但相关人员未能注意或重视告警信息。这时由于故障未能得到处理，告警信息会源源不断的发出，以使告警信息发送到相关人员并引起注意。因此，在某些例子中，对于监控数据的非首次异常可以进一步判断，对于符合一定条件的(比如满足重要级别或达到一定次数)可以再次发送告警信息，保证告警信息发到相关人员并引起相关人员注意。具体方法流程如图2C所示，在图2B所述基础上还包括步骤S206：

在步骤206中，如果所述目标对象的监控数据非首次异常，判断是否再次发送所述告警信息；

如果是，则转到步骤204。

告警信息两阶段发送是为了有效减少重复告警信息的干扰，在本实施例中，判断是否再次发送所述告警信息可以预设条件。该预设条件可以是告警信息的重要级别，比如对于CPU、内存、系统应用等重要硬件和重要应用的告警信息重要级别设为重要，风扇、摄像头等硬件的告警信息重要级别设为一般，对于重要级别的告警信息再次发送，一般级别的告警信息不再次发送；另外，该条件也可以是异常数据出现的次数，比如异常数据出现的次数达到一定值就再次发送告警信息。作为一个例子，还可以设置一定时器，对监控数据的非首次异常定时检查，当满足上述预设条件时，再次发送告警信息。

在一个可选的实现方式中，可以统计异常数据出现的次数，然后根据统计结果判断是否再次发送告警信息，可参考图2D。

如图2D所示，在前述图2C的基础上还包括步骤S205：

步骤S205，统计所述目标对象的监控数据异常的次数；

步骤206根据所述统计结果确定是否再次发送所述告警信息。

在一个可选的实现方式中，根据所述统计结果确定是否再次发送告警信息可以是根据所统计的所述监控数据异常的次数的数量和/或时间分布特性确定是再次否发送所述告警信息。

在一个可选的实现方式中，所述根据所统计的所述监控数据异常的次数的数量确定是否再次发送所述告警信息，包括：

如果所统计的所述监控数据异常的次数大于预设阈值，则确定再次发送所述告警信息。比如预设阈值为1000次，则当统计的异常次数大于1000次时，就确定再次发送所述告警信息，同时可以将异常次数同所述告警信息一起发送。

在一个可选的实现方式中，所述根据所统计的所述监控数据异常的时间分布特性确定是否再次发送所述告警信息，包括：

如果所统计的所述监控数据异常的次数在时间上成周期分布，则确定再次发送所述告警信息。比如以5分钟一个周期，在6个周期内，如果所述监控数据异常的次数比较均匀的散落在4个或4个以上的周期，则确定再次发送所述告警信息，同时可以将监控数据异常的次数同所述告警一起发送。

如图2E所示，是本申请根据一示例性实施例示出的一个实时告警的流程图。以服务器内存为被监控对象，对应的监控数据为内存剩余量，服务器在运行过程中，不同时刻可能会打开或者关闭不同的应用程序，内存剩余量也会随之动态变化，当内存剩余量不足时，系统会产生告警信息提示相关人员。

步骤S210，服务器内存在运行中产生各种数据包括内存剩余量相关的数据。

步骤S211，监控方采集监控数据，本例中，采集监控数据可以是监控方通过调用SDK接口从被监控对象处采集，在一个例子中，采集数据也可以是被监控对象通过调用SDK接口主动上报监控数据。

步骤S212，对采集来的监控数据进行分析，判断该监控数据是否异常，如果监控数据异常(内存剩余量不足)，则转到步骤S213，获取监控数据的标识信息(内存的设备标识)；如果监控数据正常，则转到步骤S217，不作处理。

S214，通过将内存的设备标识与监控方已记录的标识信息作对比，判断该监控数据是否首次异常，如果为首次异常，转到步骤S215发送告警信息给相关人员(步骤S216)，发送方式可以通过短信、即时通讯软件(YY、QQ等)，告警信息携带异常数据的标识信息，使相关人员可以知道问题所在；如果非首次异常，转到步骤S218。

步骤S218，统计监控数据异常的次数。

步骤S219，根据步骤S218统计的结果判断是否再次发送告警信息，判断依据可以是异常次数的阈值和/或分布周期。本例中，可以预先设置异常次数的阈值为1000次，当异常次数达到1000次时就再次发送告警信息，否则不发送(步骤S220)；也可以预先设置5个时间周期，如果异常次数比较均匀的分布在5个时间周期内，则再次发送告警信息，否则不发送(步骤S220)。再次发送的告警信息可以携带异常次数，提醒相关人员注意。

与前述实时告警方法的实施例相对应，本申请还提供了实时告警系统及其所应用的设备。

如图3A所示，图3A是本申请根据一示例性实施例示出的一种实时告警系统的框图，所述系统包括：采集模块30，获取模块32，告警模块34。

采集模块30，被配置为从至少一个被监控对象采集监控数据，所述监控数据包括所述被监控对象的标识信息。

获取模块32，被配置为基于所述监控数据获得目标对象的标识信息，所述目标对象为监控数据异常的被监控对象。

告警模块34，被配置为如果所述目标对象的监控数据为首次异常，则发出告警信息，所述告警信息携带所述目标对象的标识信息。

在一个可选的实现方式中，所述标识信息包括设备信息、进程名、源文件名和行号。

如图3B所示，图3B是本申请根据一示例性实施例示出的另一种实时告警系统的部分框图，该实施例在前述图3A所述的实施例的基础上，所述采集模块30，包括：错误日志采集子模块301。

错误日志采集子模块301，被配置为采集错误日志，所述错误日志由所述错误日志对应的目标对象调用SDK接口主动上报。

如图3C所示，图3C是本申请根据一示例性实施例示出的另一种实时告警系统的框图，该实施例实在前述图3B所述的实施例的基础上，获取模块42和告警模块44之间，还包括：第一判断模块33。

第一判断模块33，被配置为判断所述目标对象的监控数据是否首次异常，以及是否需要发送告警信息，并在需要发送告警信息是通知所述告警模块。

如图3D所示，图3D是本公开根据一示例性实施例示出的另一种实时告警系统的框图，该实施例在前述图3C所述的实施例的基础上，第一判断模块33和告警模块34之间，还包括：第二判断模块36。

第二判断模块36，被配置为根据所述第一判断模块的判断结果确定是否发送所述告警信息，并在需要发送告警信息时通知所述告警模块。

如图3E所示，图3E是本申请根据一示例性实施例示出的另一种实时告警系统的框图，该实施例在前述图3D所述的实施例的基础上，第一判断模块33和第二判断模块36之间还包括：统计模块35：

统计模块35，被配置为被配置为统计所述目标对象的监控数据异常的次数；所述第二判断模块根据统计结果确定是否再次发送所述告警信息。

在一个可选的实现方式中，所述第二判断模块根据统计结构判断是否确定再次发送所述告警信息，包括：

根据所统计的所述监控数据异常的次数的数量和/或时间分布特性确定是否发送所述告警信息。

在一个可选的实现方式中，所述第二判断模块根据统计结果确定是否再次发送所述告警信息，可以包括以下一种或多种：

如果所统计的所述监控数据异常的次数大于预设阈值，则确定再次发送所述告警信息；

如果所统计的所述监控数据异常的次数在时间上呈周期分布，则确定再次发送所述告警信息。

与前述实时告警方法的实施例相对应，本申请还提供了实时告警装置的实施例。

本申请实时告警装置的实施例可以应用在监控告警平台上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在监控告警平台的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图4所示，为本申请实时告警装置所在监控告警平台的一种硬件结构图，除了图4所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的监控告警平台通常根据该平台的实际功能，还可以包括其他硬件，对此不再赘述。

请参考图图5A，为本申请根据一示例性实施例示出的一种监控告警系统的结构示意图。从图中可以看出，监控告警系统包括被监控对象50，监控告警平台51(采集模块511，获取模块512，第一判断模块513)，统计模块52，第二判断模块53，告警模块54。

对于图5A中所示的监控告警系统的结构还可以做如下变动，将统计模块52和第二判断模块52合并为一个模块(图5B)；第二判断模块52、统计模块52、告警模块53合并到监控告警平台中(图5C)；监控告警平台还可添加数据存储、数据清洗过滤、配置管理、告警查询等功能模块。凡是在本公开系统结构的基础上采用本公开所述方法对系统结构所做的改动都在本公开的保护范围内。

上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。