告警数据采集方法、装置、电子设备及存储介质与流程

1.本技术涉及告警数据技术，尤其涉及一种告警数据采集方法、装置、电子设备及存储介质。


背景技术：

2.随着告警数据技术的发展，运营商的电子设备可以通过企业服务总线esb直采的方式，采集各省端的操作维护中心omc(operation and maintenance center)所上报的告警数据，存储至告警数据库中，以保证告警数据库中告警数据的完整性。
3.目前，在操作维护中心与电子设备之间发生通信中断时，先确定通信中断期间，再补采通信中断期间各操作维护中心的告警数据。
4.然而，由于各操作维护中心中补采上来的告警数据是乱序的，直接将乱序的告警数据存储于告警数据库中，会使得告警数据库中存储的告警数据的准确度较低。


技术实现要素：

5.本技术提供一种告警数据采集方法、装置、电子设备及存储介质，用以解决现有技术中，补采告警数据的准确度较低的技术问题。
6.第一方面，本技术提供一种告警数据采集方法，包括：
7.向至少一个操作维护中心发送数据补采请求；
8.获取所述至少一个操作维护中心响应于所述数据补采请求所返回的多个补传告警数据，所述多个补传告警数据是预估通信中断期间未上传至电子设备的告警数据，实际的通信中断期间位于所述预估通信中断期间内；
9.从告警数据库中获取所述至少一个操作维护中心在所述预估通信中断期间的多个告警数据；
10.基于同一告警事件的清除告警状态发生在活动告警状态之后的预设配对策略，将所述预估通信中断期间的多个告警数据与对应的补传告警数据进行配对，获得多个状态更新的告警数据；
11.将所述多个状态更新的告警数据缓存至告警数据库中。
12.在一个实施例中，所述向至少一个操作维护中心发送数据补采请求，包括：
13.判断预设时长内各省端的操作维护中心上传的多个实时告警数据的流水号是否连续；
14.若确定存在至少一个操作维护中心上传的多个实时告警数据的流水号不连续，则向所述至少一个操作维护中心下发数据补采请求。
15.在一个实施例中，在所述判断预设时长内各省端的操作维护中心上传的多个告警数据的流水号是否连续之前，还包括：
16.在实时将各省端的操作维护中心的多个实时告警数据上传至所述告警数据库中的过程中，按照所述预设配对策略将接收到的多个第一实时告警数据，与对应的第二实时
告警数据进行配对；第一实时告警数据是告警事件为活动告警状态的实时告警数据，第二实时告警数据为与所述第一实时告警数据为同一告警事件且为清除告警状态；
17.将未能配对的第二实时告警数据进行存储。
18.在一个实施例中，所述获取所述至少一个操作维护中心响应于所述数据补采请求所返回的多个补传告警数据，包括：
19.判断所述多个补传告警数据的数量是否大于预设值；
20.若确定小于预设值，则获取所述至少一个操作维护中心通过实时数据传输通道所返回的多个补传告警数据；
21.若确定大于或者等于所述预设值，则获取所述至少一个操作维护中心通过文件传输通道所返回的多个补传告警数据。
22.第二方面，本技术提供一种告警数据采集装置，包括：
23.补采请求获取模块，用于向至少一个操作维护中心发送数据补采请求；
24.补传数据获取模块，用于获取所述至少一个操作维护中心响应于所述数据补采请求所返回的多个补传告警数据，所述多个补传告警数据是预估通信中断期间未上传至电子设备的告警数据，实际的通信中断期间位于所述预估通信中断期间内；
25.告警数据获取模块，用于从告警数据库中获取所述至少一个操作维护中心在所述预估通信中断期间的多个告警数据；
26.数据配对模块，用于基于同一告警事件的清除告警状态发生在活动告警状态之后的预设配对策略，将所述预估通信中断期间的多个告警数据与对应的补传告警数据进行配对，获得多个状态更新的告警数据；
27.配对数据缓存模块，用于将所述多个状态更新的告警数据缓存至告警数据库中。
28.第三方面，本技术提供一种电子设备，包括：处理器，以及与所述处理器通信连接的存储器；
29.所述存储器存储计算机执行指令；
30.所述处理器执行所述存储器存储的计算机执行指令，以实现如第一方面所述的方法。
31.第四方面，本技术提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如第一方面所述的方法。
32.本技术提供的告警数据采集方法、装置、电子设备及存储介质，向至少一个操作维护中心发送数据补采请求；获取所述至少一个操作维护中心响应于所述数据补采请求所返回的多个补传告警数据，所述多个补传告警数据是预估通信中断期间未上传至电子设备的告警数据，实际的通信中断期间位于所述预估通信中断期间内；从告警数据库中获取所述至少一个操作维护中心在所述预估通信中断期间的多个告警数据；基于同一告警事件的清除告警状态发生在活动告警状态之后的预设配对策略，将所述预估通信中断期间的多个告警数据与对应的补传告警数据进行配对，获得多个状态更新的告警数据；将所述多个状态更新的告警数据缓存至告警数据库中。由于在补采多个补传告警数据之后，遵循同一告警事件的清除告警状态发生在活动告警状态之后这一预设配对策略，对预估通信中断期间的多个告警数据与对应的补传告警数据进行配对，即可使预估通信中断期间为活动告警状态
的告警事件，能与补采上来的发生在其后的为清除告警状态的同一告警事件进行配对，以及可使预估通信中断期间为清除告警状态的告警事件，能与补采上来的发生在其前面的为活动告警状态的同一告警事件匹配，从而使告警数据库中的告警数据的状态进行更新，获得准确的各告警数据。
附图说明
33.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本技术的实施例，并与说明书一起用于解释本技术的原理。
34.图1是本技术一实施例的关于补采会产生时序混乱的示意图；
35.图2为实现本技术实施例的告警数据采集方法的一种应用场景图；
36.图3为本技术一实施例的实现告警数据采集方法的流程示意图；
37.图4为本技术另一实施例的实现告警数据采集方法的流程示意图；
38.图5为本技术实现告警数据采集方法的结构示意图；
39.图6为用来实现告警数据采集方法中的电子设备的结构示意图。
40.通过上述附图，已示出本技术明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本技术构思的范围，而是通过参考特定实施例为本领域技术人员说明本技术的概念。
具体实施方式
41.这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本技术相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本技术的一些方面相一致的装置和方法的例子。
42.为了清楚理解本技术的技术方案，首先对现有技术的方案进行详细介绍。
43.传统方式中，在操作维护中心与电子设备之间发生通信中断时，通常是补采各操作维护中心的告警事件为活动告警状态的告警数据。然而，由于各操作维护中心中补采上来的数据是乱序的，直接将乱序的告警数据存储于告警数据库中，会使得告警数据库中存储的告警数据的准确度降低。传统方案的缺陷，具体可以理解为：由于各操作维护中心自身的原因，从各操作维护中心补采至电子设备的告警数据是乱序的，经常出现同一告警事件的清除告警状态先于活动告警状态到达电子设备，由于对应的该告警事件的活动告警状态还未到达电子设备，因此传统方案中，该告警事件的清除告警状态会被电子设备清除。由于该告警事件的清除告警状态先到达并被丢弃，之后再上传的该告警事件的活动告警状态就永远处于活动状态，而无法被清除掉了，这会使得该告警事件实际上已经解除告警，而从告警数据库中导出的该告警事件却是仍在发生告警状态中。
44.示例性的，如图1所示，在时间点2和时间点3之间发生网络中断，导致电子设备没有收到序号2至序号1200之间的活动告警和清除告警，通过上述补采机制在时间点5和时间点6之间把这些丢失的告警数据补采上来。经过丢失和补采机制后，以上这些列出告警数据在电子设备实际收到告警的序号变为：序号1(活动告警1)、序号1300(清除告警3)、序号2(活动告警2)、序号1200(活动告警3)。其中，活动告警1是告警事件1处于活动告警状态，活
动告警2是告警事件2处于活动告警状态，活动告警3是告警事件3处于活动告警状态，清除告警3是告警事件处于清除告警状态。
45.可以看出经过以上过程之前正常顺序的一对告警数据(活动告警3和清除告警3)，到达电子设备的告警顺序已经相反，即清除告警3比活动告警3先到达。由于清除告警3到达时，电子设备中还没有活动告警3，更新操作没有任何作用，更新操作后，该条清除告警即被丢弃；后续当活动告警3到达并入库后，由于之前的清除告警3因为已经先到达并丢弃，活动告警3就永远处于活动状态无法被清除掉。
46.所以在面对现有技术的技术问题时，发明人通过创造性的研究后发现，为了提高告警数据库中存储的告警数据的准确度。因此，电子设备先补采获得多个补传告警数据，再将补采上来的多个补传告警数据，与告警数据库中已存储的预估通信中断期间的多个告警数据，基于预设配对策略进行配对，获得多个状态更新的告警数据并存储于告警数据库中。由于在补采多个补传告警数据之后，遵循同一告警事件的清除告警状态发生在活动告警状态之后这一预设配对策略，对预估通信中断期间的多个告警数据与对应的补传告警数据进行配对，即可使预估通信中断期间为活动告警状态的告警事件，能与补采上来的发生在其后的为清除告警状态的同一告警事件进行配对，以及可使预估通信中断期间为清除告警状态的告警事件，能与补采上来的发生在其前面的为活动告警状态的同一告警事件匹配，从而使告警数据库中的告警数据的状态进行更新，获得准确的各告警数据。
47.如图2所示，本技术实施例提供的告警数据采集方法的应用场景，在该应用场景中对应的网络架构中包括电子设备10和至少一个操作维护中心20，电子设备10和至少一个操作维护中心20之间进行通信连接。电子设备10向至少一个操作维护中心20发送数据补采请求；获取至少一个操作维护中心20响应于数据补采请求所返回的多个补传告警数据，多个补传告警数据是预估通信中断期间未上传至电子设备10的告警数据，实际的通信中断期间位于预估通信中断期间内。从告警数据库中获取至少一个操作维护中心20在预估通信中断期间的多个告警数据；基于同一告警事件的清除告警状态发生在活动告警状态之后的预设配对策略，将预估通信中断期间的多个告警数据与对应的补传告警数据进行配对，获得多个状态更新的告警数据；将多个状态更新的告警数据缓存至告警数据库中。
48.下面以具体地实施例对本技术的技术方案以及本技术的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本技术的实施例进行描述。
49.图3是本技术一实施例提供的告警数据采集方法，如图3所示，本实施例提供的告警数据采集方法的执行主体是电子设备。则本实施例提供的告警数据采集方法包括以下步骤：
50.步骤101，向至少一个操作维护中心发送数据补采请求。
51.其中，操作维护中心是指操作维护系统中的各功能实体，其下可以管理多个网络设备。一个省端可以设置多个操作维护中心，电子设备通过企业服务总线的socket传输通道与省端的某个操作维护中心建立实时告警集连接后，操作维护中心会实时上报其管理的网络设备的相关告警数据，并在每条发出的告警数据上打上告警流水号的标签。其中，操作维护中心会实时上报其管理的网络设备的相关告警数据，可理解为每个操作维护中心可以通过企业服务总线esb(enterprise service bus)上报自身管理的多个网络设备的网络故
障、供电故障等。对于告警事件、活动告警状态和清除告警状态，可以这样理解：例如，a网络设备发生网络故障，或者发生供电故障均可以作为一个告警事件，且为活动告警状态。一段时间后，将发生网络故障的a网络设备维修好之后，该告警事件变为清除告警状态。每一个告警数据包括一个告警事件和该告警事件的状态，告警事件的状态即为活动告警状态或清除告警状态。
52.各操作维护中心上传告警数据时，是相互独立且并行传输的，互相之间不受影响，因此当某操作维护中心与电子设备的企业服务总线断开连接时，其他省端的操作维护中心不会受到影响。并且在电子设备侧，可以设置各操作维护中心的多个告警数据分区存储，且各分区携带有对应的操作维护中心的标识，从而当检查出某个分区的告警数据不连续时，可以基于该分区携带的操作维护中心的标识，立即确定出与电子设备发生通信中断的操作维护中心。
53.通信中断会导致部分告警数据未能上传至电子设备中，而操作维护中心中仍有缓存，因在操作维护中心与电子设备之间发生了网络断开之后，可以向操作维护中心发送数据补采请求，以从中重新获取之前未能成功上传的告警数据。
54.步骤102，获取所述至少一个操作维护中心响应于所述数据补采请求所返回的多个补传告警数据。
55.其中，多个补传告警数据是预估通信中断期间未上传至电子设备的告警数据。实际的通信中断期间位于预估通信中断期间内。实际的通信中断期间是指实际上操作维护中心与电子设备开始断开连接至重新连接的期间。实际的通信中断期间位于预估通信中断期间内，是指预估通信中断期间的断开连接的时间点早于实际的通信中断期间的断开连接的时间点，且预估通信中断期间的重新连接的时间点晚于实际的通信中断期间的重新连接的时间点。之所以获取预估通信中断期间未上传至电子设备的告警数据，是因为操作维护中心与电子设备之间时钟机制存在偏差，以及二者之间隔了若干网络层传输，告警数据在传输上存在传输延迟，因此电子设备无法准确知道实际的通信中断期间从何时开始断开，以及于何时重新连接，以一个更长的时间段(预估通信中断期间)作为补采告警数据的区间，可以防止遗漏待补传的告警数据。
56.每一个补传告警数据包括一个告警事件和该告警事件的状态。告警事件的状态即前述的为活动告警状态或清除告警状态。
57.步骤103，从告警数据库中获取所述至少一个操作维护中心在所述预估通信中断期间的多个告警数据。
58.其中，该至少一个操作维护中心即步骤101中的至少一个操作维护中心，是与电子设备发生通信中断的操作维护中心。此处从告警数据库中获取的至少一个操作维护中心在预估通信中断期间的告警数据，是实际发生通信中断前后通过socket传输通道实时上传至告警数据库中的告警数据。例如，实际的通信中断期间为11:00-11:30，预估通信中断期间为10:00-12:00，实际的通信中断期间没有告警数据能够上传至告警数据库中，因此预估通信中断期间的告警数据实际只包括10:00-11:00，以及11:30-12:00之间的告警数据。
59.步骤104，基于同一告警事件的清除告警状态发生在活动告警状态之后的预设配对策略，将所述预估通信中断期间的多个告警数据与对应的补传告警数据进行配对，获得多个状态更新的告警数据。
60.其中，预设配对策略是根据同一告警事件的清除告警状态应发生在活动告警状态之后这一原则确定的，可以用于将告警数据中告警事件的状态从活动告警状态变为清除告警状态。之所以要设置同一告警事件的清除告警状态发生在活动告警状态之后，是因为任何告警事件，均是先发生告警(即活动告警状态)，才再有解除告警(即清除告警状态)。
61.如前述，由于补采上来的告警数据(即预估通信中断期间的多个告警数据)是乱序的，因此，电子设备对其进行时序校正，将补采上来的多个补传告警数据，与告警数据库中已存储的相应时间段(取预估通信中断期间)的告警数据进行比对，从而将告警数据库中的告警数据的状态进行变更/更新，获得准确的各告警数据。
62.比对的过程即，基于同一告警事件的清除告警状态发生在活动告警状态之后的预设配对策略，预估通信中断期间的多个告警数据分别与对应的补传告警数据进行配对，获得多个状态更新的告警数据。
63.步骤105，将所述多个状态更新的告警数据缓存至告警数据库中。
64.即，状态更新的告警数据是对告警事件的状态进行了准确地变更的告警数据，将多个状态更新的告警数据缓存至告警数据库中，可以提高告警数据库中存储告警数据的准确性。
65.本技术中，向至少一个操作维护中心发送数据补采请求；获取所述至少一个操作维护中心响应于所述数据补采请求所返回的多个补传告警数据，所述多个补传告警数据是预估通信中断期间未上传至电子设备的告警数据，实际的通信中断期间位于所述预估通信中断期间内；从告警数据库中获取所述至少一个操作维护中心在所述预估通信中断期间的多个告警数据；基于同一告警事件的清除告警状态发生在活动告警状态之后的预设配对策略，将所述预估通信中断期间的多个告警数据与对应的补传告警数据进行配对，获得多个状态更新的告警数据；将所述多个状态更新的告警数据缓存至告警数据库中。由于在补采多个补传告警数据之后，遵循同一告警事件的清除告警状态发生在活动告警状态之后这一预设配对策略，对预估通信中断期间的多个告警数据与对应的补传告警数据进行配对，即可使预估通信中断期间为活动告警状态的告警事件，能与补采上来的发生在其后的为清除告警状态的同一告警事件进行配对，以及可使预估通信中断期间为清除告警状态的告警事件，能与补采上来的发生在其前面的为活动告警状态的同一告警事件匹配，从而使告警数据库中的告警数据的状态进行更新，获得准确的各告警数据。
66.作为一种可选实施方式，如图4所示，本实施例中，步骤102，包括以下步骤：
67.步骤201，判断预设时长内各省端的操作维护中心上传的多个实时告警数据的流水号是否连续。
68.其中，预设时长是人为设置的。通过检查预设时长内的多个实时告警数据的流水号是否连续，以确定操作维护中心和电子设备之间是否存在通信中断。连续则无通信中断，不连续则存在通信中断。
69.实时告警数据即告警数据，只是在称呼上做出区别。同一告警事件的活动告警状态和清除告警状态分别占用一个流水号。例如前述的图1中，告警事件3为活动告警状态时，流水号为序号1200，告警事件3为清除告警状态时，流水号为序号1300。
70.步骤202，若确定存在至少一个操作维护中心上传的多个实时告警数据的流水号不连续，则向所述至少一个操作维护中心下发数据补采请求。
71.其中，若确定至少一个操作维护中心上传的多个实时告警数据的流水号不连续，表明该至少一个操作维护中心与电子设备之间存在通信中断，为了补采通信中断期间的告警数据，也可以是更长时间段的告警数据(例如预估通信中断期间)，从而向至少一个操作维护中心下发数据补采请求，以指示至少一个操作维护中心重新上传告警数据。
72.本实施例中，判断预设时长内各省端的操作维护中心上传的多个实时告警数据的流水号是否连续；若确定存在至少一个操作维护中心上传的多个实时告警数据的流水号不连续，则向所述至少一个操作维护中心下发数据补采请求。根据操作维护中心上传的多个实时告警数据的流水号是否连续，以确定各操作维护中心是否与电子设备之间发生通信中断，从而使数据补采请求可以准确下发至应当补传的至少一个操作维护中心中。
73.作为一种可选实施方式，本实施例中，步骤101之前，还包括以下步骤：
74.步骤301，在实时将各省端的操作维护中心的多个实时告警数据上传至所述告警数据库中的过程中，按照所述预设配对策略为接收到的各条实时活动告警状态匹配对应的实时清除告警状态，所述实时告警数据为实时活动告警状态或实时清除告警状态。
75.其中，实时告警数据可以是第一实时告警数据，也可以是第二实时告警数据。第一实时告警数据是告警事件为活动告警状态的实时告警数据，第二实时告警数据为与第一实时告警数据为同一告警事件且为清除告警状态。
76.即，在发生补采之前，正常上传实时告警数据的过程中，是通过企业服务总线的socket传输通道实时将各省端的操作维护中心的多个实时告警数据上传至告警数据库中。在将各实时告警数据上传至告警数据库时，针对每个第一实时告警数据做插入操作，在接收到与该第一实时告警数据为同一告警事件且为清除告警状态的第二实时告警数据时，将该第一实时告警数据和第二实时告警数据进行配对。此处配对时，还需按照预设配对策略进行配对，即该第一实时告警数据发生在第二实时告警数据之前才能成功配对。
77.步骤302，将未能配对的第二实时告警数据存储于所述告警数据库中。
78.此处，与传统方案将未能配对的第二实时告警数据进行删除的方式不同，本实施例中将未能配对的第二实时告警数据进行存储。存储之后，在补采过程中，即可以通过步骤104对这些未能配对的第二实时告警数据进行配对，从而可以防止能与这些未配对的第二实时告警数据的各第一实时告警数据，始终无法改变状态，导致告警数据有误。
79.对于第一实时告警数据也并不能一定在这个阶段能找到对应的第二实时告警数据，未能配对的第一实时告警数据后续也能作为步骤103中告警数据库中存储的告警数据使用。在补采获得对应的补传告警数据时，即可获得对应的状态更新的告警数据。
80.本实施例中，在实时将各省端的操作维护中心的多个实时告警数据上传至所述告警数据库中的过程中，按照所述预设配对策略将接收到的多个第一实时告警数据，与对应的第二实时告警数据进行配对；第一实时告警数据是告警事件为活动告警状态的实时告警数据，第二实时告警数据为与所述第一实时告警数据为同一告警事件且为清除告警状态；将未能配对的第二实时告警数据进行存储。由于将能配对的第一实时告警数据和第二实时告警数据进行了配对，对于未能配对的第二实时告警数据进行了存储，可以在之后将与这些未能配对的第二实时告警数据进行配对的各第一实时告警数据补采上来之后，能对补采上来的各第一实时告警数据的状态进行变更，从而使告警数据库中存储的告警数据的状态较准确。
81.作为一种可选实施方式，本实施例中，步骤102，包括以下步骤：
82.步骤401，判断所述多个补传告警数据的数量是否大于预设值。
83.其中，预设值可以根据经验值确定，例如设置预设值为1000个。
84.步骤402，若确定小于预设值，则获取所述至少一个操作维护中心通过实时数据传输通道所返回的多个补传告警数据。
85.其中，实时数据传输通道即socket传输通道。若补传告警数据的数量小于预设值，指示至少一个操作维护中心仍按照原先实时处理时的socket传输通道上报补传告警数据，从而电子设备可以获取到至少一个操作维护中心通过实时数据传输通道所返回的多个补传告警数据。
86.步骤403，若确定大于或者等于所述预设值，则获取所述至少一个操作维护中心通过文件传输通道所返回的多个补传告警数据。
87.其中，文件传输通道即ftp(filetransferprotocol)传输通道。若补传告警数据的数量大于或等于预设值，则指示至少一个操作维护中心通过ftp传输通道上报补传告警数据，从而电子设备可以获取到至少一个操作维护中心通过文件传输通道所返回的多个补传告警数据。
88.具体地，操作维护中心若确定补传告警数据大于或者等于预设值时，先将这些补传告警数据生成文件存放到操作维护中心的指定目录中，电子设备的ftp传输通道定期扫描操作维护中心的这些指定目录，若发现有新的文件生成，则将新的文件搬移至企业服务总线的指定目录中，完成补传告警数据的上传。
89.本实施例中，判断所述多个补传告警数据的数量是否大于预设值；若确定小于预设值，则获取所述至少一个操作维护中心通过实时数据传输通道所返回的多个补传告警数据；若确定大于或者等于所述预设值，则获取所述至少一个操作维护中心通过文件传输通道所返回的多个补传告警数据。由于针对补传告警数据的数量与预设值进行比较，以采取不同的数据传输通道对补传告警数据进行传输，从而可以高效地利用这些数据传输通道。并且，在数据量较大时，采用文件传输通道传输数据，也可以使得数据传输的效率更高。
90.作为一种可选实施方式，本实施例中，步骤104，包括以下步骤：
91.步骤501，基于所述多个补传告警数据的时间戳，以及所述预估通信中断期间的多个告警数据的时间戳进行排序。
92.其中，操作维护中心上传至电子设备的所有告警数据均携带有时间戳。补传告警数据携带的时间戳是指补传告警数据的发生时间。预估通信中断期间的告警数据携带的时间戳是指预估通信中断期间告警数据的发生时间。将多个补传告警数据和预估通信中断期间的多个告警数据按照时间戳进行排序，可以确定预估通信中断期间各告警数据与多个补传告警数据之间产生时间的先后关系。
93.步骤502，基于同一告警事件的清除告警状态发生在活动告警状态之后的预设配对策略，将所述预估通信中断期间的第一告警数据，与对应的第一补传告警数据进行配对，并将所述预估通信中断期间的第二告警数据，与对应的第二补传告警数据进行配对。
94.其中，第一告警数据是预估通信中断期间告警事件为活动告警状态的告警数据，第一补传告警数据是与第一告警数据为同一告警事件且为清除告警状态的补传告警数据。第二告警数据是预估通信中断期间告警事件为清除告警状态，且未配对的告警数据，第二
补传告警数据是与第二告警数据为同一告警事件且为活动告警状态的补传告警数据。
95.此步骤通过将预估通信中断期间的第一告警数据与补采上来的第一补传告警数据进行配对，以及将预估通信中断期间的第二告警数据与补采上来的第二补传告警数据进行配对，可以使预估通信中断期间的第一告警数据，能与实际的通信中断期间未上传的对应的第一补传告警数据进行配对，以及，使预估通信中断期间的第二告警数据，能与实际的通信中断期间未上传的对应的第二补传告警数据进行配对，从而实现告警事件的状态变更。
96.需要注意的是，预估通信中断期间的第二告警数据和步骤302中的未能配对的第二实时告警数据的关系，可以理解为，预估通信中断期间的第二告警数据是步骤302所述的未能配对的第二实时告警数据中的一部分，取的是预估通信中断期间这一部分的第二实时告警数据。
97.步骤503，获得所述多个状态更新的告警数据。
98.其中，在将预估通信中断期间的所有第二告警数据分别和对应的第二补传告警数据进行配对之后，即可获得多个状态更新的告警数据。此处，应当理解的是，预估通信中断期间的第二告警数据是告警事件为清除告警状态，且未配对的告警数据，为了避免补采上来的多个第二补传告警数据没有配对，导致无法清除告警状态，因此以所有第二告警数据配对完为止。预估通信中断期间的第一告警数据，可能无法在本次补采上来的补传告警数据中找到对应的第一补传告警数据，因此，不必以预估通信中断期间所有第一告警数据配对完为止。
99.本实施例中，基于所述多个补传告警数据的时间戳，以及所述预估通信中断期间的多个告警数据的时间戳进行排序；基于同一告警事件的清除告警状态发生在活动告警状态之后的预设配对策略，将所述预估通信中断期间的第一告警数据，与对应的第一补传告警数据进行配对；并将所述预估通信中断期间的第二告警数据，与对应的第二补传告警数据进行配对；获得所述多个状态更新的告警数据。由于基于补传告警数据和预估通信中断期间的多个告警数据的时间戳，以及预设配对策略，将预估通信中断期间的第一告警数据，与对应的第一补传告警数据进行配对，并将预估通信中断期间的第二告警数据，与对应的第二补传告警数据进行配对，从而可以实现补采之后，预估通信中断期间各告警数据的告警事件的状态得到准确的更新。
100.作为一种可选实施方式，本实施例中，步骤105，还包括以下步骤：
101.步骤601，响应于用户终端发送的数据查询请求，所述数据查询请求包括告警时间。
102.其中，告警时间是指发生告警的时间，可以是具体的时间点，也可以是一段时间。用户通过用户终端发送数据查询请求，一般是基于业务场景的需求，例如对过去一段时间或某个时间点进行告警数据分析，以确定各网络设备后续的可使用状况，或者是否需要维修。
103.步骤602，从所述告警数据库中获取与所述告警时间对应的告警数据，并下发至所述用户终端。
104.即，基于用户需要的告警数据，返回至用户终端。
105.本实施例中，响应于用户终端发送的数据查询请求，所述数据查询请求包括告警
时间；从所述告警数据库中获取与所述告警时间对应的告警数据，并下发至所述用户终端。由于经过步骤101-步骤104处理之后，存储于告警数据库中的告警数据中告警事件的状态是准确的，因此从告警数据库中查询获得的告警数据在用于其他业务场景时，可以有效使用。
106.图5是本技术一实施例提供的告警数据采集装置的结构示意图，如图5所示，本实施例提供的告警数据采集装置40位于电子设备中，则本实施例提供的告警数据采集装置40，包括：
107.补采请求获取模块41，用于向至少一个操作维护中心发送数据补采请求；
108.补传数据获取模块42，用于获取所述至少一个操作维护中心响应于所述数据补采请求所返回的多个补传告警数据，所述多个补传告警数据是预估通信中断期间未上传至电子设备的告警数据，实际的通信中断期间位于所述预估通信中断期间内；
109.告警数据获取模块43，用于从告警数据库中获取所述至少一个操作维护中心在所述预估通信中断期间的多个告警数据；
110.数据配对模块44，用于基于同一告警事件的清除告警状态发生在活动告警状态之后的预设配对策略，将所述预估通信中断期间的多个告警数据与对应的补传告警数据进行配对，获得多个状态更新的告警数据；
111.配对数据缓存模块45，用于将所述多个状态更新的告警数据缓存至告警数据库中。
112.可选地，补采请求获取模块41，在向至少一个操作维护中心发送数据补采请求时，具体用于：判断预设时长内各省端的操作维护中心上传的多个实时告警数据的流水号是否连续；若确定存在至少一个操作维护中心上传的多个实时告警数据的流水号不连续，则向所述至少一个操作维护中心下发数据补采请求。
113.可选地，告警数据采集装置40，在所述判断预设时长内各省端的操作维护中心上传的多个告警数据的流水号是否连续之前，还具体用于：在实时将各省端的操作维护中心的多个实时告警数据上传至所述告警数据库中的过程中，按照所述预设配对策略将接收到的多个第一实时告警数据，与对应的第二实时告警数据进行配对；第一实时告警数据是告警事件为活动告警状态的实时告警数据，第二实时告警数据为与所述第一实时告警数据为同一告警事件且为清除告警状态；将未能配对的第二实时告警数据进行存储。
114.可选地，补传数据获取模块42，在获取至少一个操作维护中心响应于所述数据补采请求所返回的多个补传告警数据时，具体用于：判断所述多个补传告警数据的数量是否大于预设值；若确定小于预设值，则获取所述至少一个操作维护中心通过实时数据传输通道所返回的多个补传告警数据；若确定大于或者等于所述预设值，则获取所述至少一个操作维护中心通过文件传输通道所返回的多个补传告警数据。
115.可选地，数据配对模块44，在基于同一告警事件的清除告警状态发生在活动告警状态之后的预设配对策略，将所述预估通信中断期间的多个告警数据与对应的补传告警数据进行配对，获得多个状态更新的告警数据时，具体用于：基于所述多个补传告警数据的时间戳，以及所述预估通信中断期间的多个告警数据的时间戳进行排序；基于同一告警事件的清除告警状态发生在活动告警状态之后的预设配对策略，将所述预估通信中断期间的第一告警数据，与对应的第一补传告警数据进行配对；所述第一告警数据是预估通信中断期
间告警事件为活动告警状态的告警数据，所述第一补传告警数据是与所述第一告警数据为同一告警事件且为清除告警状态的补传告警数据；并将所述预估通信中断期间的第二告警数据，与对应的第二补传告警数据进行配对；所述第二告警数据是预估通信中断期间告警事件为清除告警状态，且未配对的告警数据，所述第二补传告警数据是与所述第二告警数据为同一告警事件且为活动告警状态的补传告警数据；获得所述多个状态更新的告警数据。
116.可选地，告警数据采集装置40，将所述多个状态更新的告警数据缓存至告警数据库中之后，还用于：响应于用户终端发送的数据查询请求，所述数据查询请求包括告警时间；从所述告警数据库中获取与所述告警时间对应的告警数据，并下发至所述用户终端。
117.图6是根据一示例性实施例示出的一种电子设备的框图，该设备可以是如图6所示，电子设备，包括：存储器51，处理器52；存储器51用于存储处理器可执行指令的存储器；处理器52用于运行计算机程序或指令，以实现如上任意一个实施例提供的告警数据采集方法。
118.其中，存储器51，用于存放程序。具体地，程序可以包括程序代码，程序代码包括计算机操作指令。存储器51可能包含高速ram存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。
119.其中，处理器52可能是一个中央处理器(central processing unit，简称为cpu)，或者是特定集成电路(application specific integrated circuit，简称为asic)，或者是被配置成实施本公开实施例的一个或多个集成电路。
120.可选的，在具体实现上，如果存储器51和处理器52独立实现，则存储器51和处理器52可以通过总线53相互连接并完成相互间的通信。总线53可以是工业标准体系结构(industry standard architecture，简称为isa)总线53、外部设备互连(peripheral component，简称为pci)总线53或扩展工业标准体系结构(extended industry standard architecture，简称为eisa)总线53等。总线53可以分为地址总线53、数据总线53、控制总线53等。为便于表示，图6中仅用一条粗线表示，但并不表示仅有一根总线53或一种类型的总线53。
121.可选的，在具体实现上，如果存储器51和处理器52集成在一块芯片上实现，则存储器51和处理器52可以通过内部接口完成相同间的通信。
122.一种非临时性计算机可读存储介质，当该存储介质中的指令由电子设备的处理器执行时，使得电子设备能够执行上述电子设备的告警数据采集方法。
123.本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本技术的其它实施方案。本技术旨在涵盖本技术的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本技术的一般性原理并包括本技术未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本技术的真正范围和精神由下面的权利要求书指出。
124.应当理解的是，本技术并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本技术的范围仅由所附的权利要求书来限制。