一种告警处理方法及装置、设备、存储介质与流程

1.本申请实施例涉及但不限于金融科技(fintech)的信息技术，尤其涉及一种告警处理方法及装置、设备、存储介质。


背景技术：

2.随着计算机技术的发展，越来越多的技术应用在金融领域，传统金融业正在逐步向金融科技(fintech)转变，然而，由于金融行业的安全性、实时性要求，金融科技也对技术提出了更高的要求。然而，金融科技领域下，在告警信息采集平台接收到文件系统相关的告警信息的应用场景中，相关的告警信息通过展示在显示界面上，由相关人员联系对应系统的工作人员对告警信息进行手动处理。因此，需要一种安全、健壮的告警处理方法，用于避免人工手动处理告警信息时耗费人力、存在时延和误操作的问题。


技术实现要素：

3.有鉴于此，本申请实施例为解决相关技术中存在的至少一个问题而提供一种告警处理方法及装置、设备、存储介质。
4.本申请实施例的技术方案是这样实现的：
5.一方面，本申请实施例提供一种告警处理方法，所述方法包括：
6.获取至少一个文件系统集群中每一集群的告警信息；
7.确定每一告警信息的告警类型和集群标识；
8.根据每一所述告警信息的告警类型匹配对应的自愈指令；
9.根据每一所述告警信息的集群标识和告警类型，确定所述告警信息对应的激活因子的状态；
10.根据所述激活因子的状态，执行所述自愈指令，以实现对所述告警信息的处理。
11.又一方面，本申请实施例提供一种告警处理装置，所述装置包括：
12.第一获取模块，用于获取至少一个文件系统集群中每一集群的告警信息；
13.第一确定模块，用于确定每一告警信息的告警类型和集群标识；
14.匹配模块，用于根据每一所述告警信息的告警类型匹配对应的自愈指令；
15.第二确定模块，用于根据每一所述告警信息的集群标识和告警类型，确定所述告警信息对应的激活因子的状态；
16.执行模块，用于根据所述激活因子的状态，执行所述自愈指令，以实现对所述告警信息的处理。
17.再一方面，本申请实施例提供一种计算机设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述方法中的步骤。
18.还一方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述方法中的步骤。
19.本申请实施例提供的告警处理方法，先确定每一告警信息的告警类型和集群标识，然后根据每一所述告警信息的告警类型匹配对应的自愈指令；再根据每一所述告警信息的集群标识和告警类型，确定所述告警信息对应的激活因子的状态；最后根据所述激活因子的状态，执行所述自愈指令，以实现对所述告警信息的处理。这样，能够根据激活因子的状态，判断是否通过自愈指令进行告警信息的自动处理。如此，一方面，能够实现安全、健壮的触发告警信息自愈的流程，避免了告警信息进行人工处理时耗费人力的问题；另一方面，避免了人工处理告警信息时的处理时延和误操作的问题。
附图说明
20.图1为本申请实施例告警处理方法的实现流程示意图；
21.图2a为本申请实施例告警处理方法的实现流程示意图；
22.图2b为本申请实施例告警处理方法的实现流程示意图；
23.图3为本申请实施例告警处理方法的实现流程示意图；
24.图4为本申请实施例告警处理方法的实现流程示意图；
25.图5为本申请实施例告警处理装置的组成结构示意图；
26.图6为本申请实施例中计算机设备的一种硬件实体示意图。
具体实施方式
27.为了使本申请的目的、技术方案和优点更加清楚，下面结合附图和实施例对本申请的技术方案进一步详细阐述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。
28.在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。
29.如果申请文件中出现“第一/第二”的类似描述则增加以下的说明，在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。
30.除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。
31.下面结合附图和实施例对本申请的技术方案进一步详细阐述。
32.本申请实施例提供一种告警处理方法，图1为本申请实施例告警处理方法的实现流程示意图，如图1所示，该方法包括：
33.步骤s101，获取至少一个文件系统集群中每一集群的告警信息；
34.这里，所述文件系统集群在运行过程中将产生表征所述集群运行状态的集群信息。
35.在实施过程中，在所述集群信息满足预先设定的告警规则的情况下，所述文件系
统集群报错，产生所述告警信息。这里，所述预先设定的告警规则可以为每一集群的各项指标的非正常值。
36.步骤s102，确定每一告警信息的告警类型和集群标识；
37.这里，所述告警信息中至少包括：告警类型和集群标识。其中，所述集群标识可以为集群名称、编号等，所述集群标识用于定位所述文件系统集群中某一确定的集群。
38.举例说明，由于文件系统为输入输出密集型应用，所以所述告警类型可以为ceph osd down类型。其中，ceph表示文件系统，osd表示节点，down表示当前节点不可用。所述ceph osd down类型的告警可以由多种情况引起：例如，对应的底层存储介质异常、业务繁忙osd长时间高负载没有及时发送心跳、osd节点时钟偏移过大等。
39.步骤s103，根据每一所述告警信息的告警类型匹配对应的自愈指令；
40.这里，所述自愈指令存储在用于进行告警处理的自愈指令集中，所述自愈指令集存储为告警处理的方法，以封装的指令集形式进行自愈指令的存储。
41.在实施的过程中，将所述自愈指令下发到服务器，服务器执行该指令集即可完成告警处理，在接收到告警信息的情况下，通过系统监控报警框架采集上报的告警信息的告警类型，匹配该告警是否可以找到对应的自愈指令，如果匹配到自愈指令则表示该告警信息对应的告警类型有能力执行自愈，否则，表示无法执行自愈，需要人工处理。所述匹配过程为：在所述自愈指令集中查找告警信息的告警类型；在所述自愈指令集中存在所述告警类型的情况下，将所述告警类型对应的自愈指令确定为所述告警信息的自愈指令。
42.步骤s104，根据每一所述告警信息的集群标识和告警类型，确定所述告警信息对应的激活因子的状态；
43.这里，所述激活因子用于确定是否执行所自愈指令。所述激活因子可以由云管理平台提供，所述激活因子至少包括：所述告警的维修状态、变更状态和重复自愈状态等。
44.在一些实施例中，所述激活因子还可以包括：告警ip地址、最后一次出现告警的时间、本次出现告警的时间和告警级别等。
45.这里，所述激活因子按照告警类型来划分，相同集群上告警类型不同激活因子不同。
46.在一些实施例中，所述步骤s104，根据每一所述告警信息的集群标识和告警类型，确定所述告警信息对应的激活因子的状态，包括：查找与所述告警信息的集群标识和告警类型一致的激活因子；读取所述激活因子的状态字段，以确定所述告警信息对应的激活因子的状态。
47.步骤s105，根据所述激活因子的状态，执行所述自愈指令，以实现对所述告警信息的处理。
48.这里，所述激活因子的状态包括两种：存在所述激活因子和不存在所述激活因子。在存在所述激活因子的情况下，所述激活因子中包括自愈因子的状态，所述自愈因子的状态用于表征所述激活因子是否可用。
49.在实施过程中，可以根据所述激活因子的不同状态可以确定不同的执行所述自愈指令的流程，以实现对所述告警信息的处理。
50.在本申请实施例中，先确定每一告警信息的告警类型和集群标识，然后根据每一所述告警信息的告警类型匹配对应的自愈指令；再根据每一所述告警信息的集群标识和告
警类型，确定所述告警信息对应的激活因子的状态；最后根据所述激活因子的状态，执行所述自愈指令，以实现对所述告警信息的处理。这样，能够根据激活因子的状态，判断是否通过自愈指令进行告警信息的自动处理。如此，一方面，能够实现安全、健壮的触发告警信息自愈的流程，避免了告警信息进行人工处理时耗费人力的问题；另一方面，避免了人工处理告警信息时的处理时延和误操作的问题。
51.本申请实施例提供一种告警处理方法，图2a为本申请实施例告警处理方法的实现流程示意图，如图2a所示，该方法包括：
52.步骤s201，获取至少一个文件系统集群中每一集群的告警信息；
53.步骤s202，确定每一告警信息的告警类型和集群标识；
54.步骤s203，根据每一所述告警信息的告警类型匹配对应的自愈指令；
55.步骤s204，根据每一所述告警信息的集群标识和告警类型，确定所述告警信息对应的激活因子的状态；
56.步骤s205，在所述激活因子的状态为不存在所述激活因子的情况下，根据所述集群标识和告警类型创建对应的激活因子，其中，所述激活因子包括自愈因子状态字段；其中，所述自愈因子状态字段为激活因子中用于表示自愈指令是否可用的字段；
57.举例说明，所述激活因子的数据结构为：
58.{
59.cluster_name:rbd_arm_ft01
60.warn_name:ceph osd.12down
61.warn_ip:10.110.3.8
62.last_time:2020
‑
09
‑
16:15:58:23#上一次出现告警的时间
63.now_time:2020
‑
09
‑
16:15:58:23#本次出现告警的时间
64.ttl_time:120s
65.warn_level:major
66.……………
67.krill result:“ok”#ok代表自愈指令成功执行、wait代表等待自愈指令执行结果、fail代表自愈指令执行失败
68.count:1
69.ims send_time:2020
‑
09
‑
16:15:58:23
70.status:“active”71.}
72.其中，status为自愈因子状态字段，上述的“active”表示激活因子的状态为活跃，cluster_name为集群标识，warn_name为告警类型。在接收到告警类型为ceph osd.12down的告警信息时，调用告警处理的服务器利用告警信息中的cluster_name和warn_name来匹配是否存在激活因子。
73.其中，krill(命令执行平台)result为命令执行平台的执行结果字段。在不存在所述激活因子的情况下，创建对应的激活因子，调用命令执行平台执行对应自愈指令，根据所述自愈指令的执行结果更新创建激活因子的result字段中，如果自愈指令执行失败发送告警给告警信息采集平台通知自愈失败，同时把自愈因子状态设置为不可用inactive。
74.在一些实施例中，调用告警处理的服务器利用告警信息中的cluster_name和warn_name来匹配是否存在激活因子包括：查找与所述告警信息的cluster_name和warn_name一致的激活因子，得到查找结果；在所述查找结果表示当前存在所述cluster_name和warn_name的激活因子时，判断所述告警信息存在激活因子；在所述查找结果表示当前不存在所述cluster_name和warn_name的激活因子时，判断所述告警信息不存在激活因子。
75.步骤s206，在所述自愈因子状态字段为可用的情况下，执行所述自愈指令，得到执行结果，以实现对所述告警信息的处理；
76.举例说明，在所述自愈因子状态字段为可用的情况下，所述状态字段对应的值为active代表激活因子可用。在所述状态字段表示激活因子可用的情况下，可以执行自愈指令。
77.这里，步骤s205和步骤s206提供了一种实现步骤s105的方式。
78.步骤s207，在所述执行结果为自愈成功的情况下，将所述执行结果对应的激活因子放入等待队列中；
79.这里，所述等待队列用于在告警信息自愈后，存储已经执行成功的告警对应的激活因子。等待告警指标的n个采集周期，判断是否能够自愈成功。
80.步骤s208，等待所述自愈指令执行n个周期后，得到所述n个周期内的执行结果；
81.步骤s209，在所述每一周期内的执行结果为自愈成功的情况下，确定所述告警处理成功。
82.这里，所述执行结果将赋值给所述激活因子的结果字段。
83.在一些实施例中，所述方法还包括：
84.在所述执行结果为自愈失败的情况下，将所述自愈因子的状态字段设置为不可用状态，并向人工告警处理平台上报所述告警信息；所述不可用状态用于指示向所述人工告警处理平台上报相同告警类型的告警信息。
85.在一些实施例中，所述方法还包括：
86.在创建所述激活因子情况下，根据所述集群标识所属的集群维修状态、集群变更状态、创建所述激活因子时间戳、上次愈合时间戳和自愈时间间隔，确定所述自愈因子状态字段的状态值。
87.举例说明，云管理平台产生激活因子时，通过公式(1)计算所述自愈因子状态字段的状态值：
88.自愈因子状态字段的状态值＝(集群维修状态&集群变更状态)&((当前时间戳
‑
上次愈合时间戳
–
k*最大自愈时间间隔)>0)公式(1)；
89.其中，&表示与运算，计算后自愈因子状态字段的状态值为1表示active；状态值为0表示inactive；公式中集群维修状态、集群变更状态、上次愈合时间戳通过云管理平台可以通过查询数据库的方式获取；最大自愈时间间隔初始值为3600s，可以通过动态计算获取集群异常的最大自愈时间间隔进行替换,k表示常数值，根据实际情况进行设置，本发明实施例中，通过测试优选将k设为2。
90.在本申请实施例中，一方面，在所述激活因子的状态为不存在所述激活因子的情况下，根据所述集群标识和告警类型创建对应的激活因子，这样，能够在不存在所述激活因子的情况下，避免了告警处理器报错，增加告警处理方法的健壮性；另一方面，在所述执行
结果为自愈成功的情况下，将所述执行结果对应的激活因子放入等待队列中；等待所述自愈指令执行n个周期后，得到所述n个周期内的执行结果，这样，能够在确定激活因子可用的情况下，等待所述自愈指令执行多次，增加了告警处理器的可靠性。
91.本申请实施例提供一种告警处理方法，图2b为本申请实施例告警处理方法的实现流程示意图，如图2b所示，该方法包括：
92.步骤s210，获取至少一个文件系统集群中每一集群的告警信息；
93.步骤s220，确定每一告警信息的告警类型和集群标识；
94.步骤s230，根据每一所述告警信息的告警类型匹配对应的自愈指令；所述自愈指令包括处理所述告警信息所需要执行的处理步骤；
95.步骤s240，根据每一所述告警信息的集群标识和告警类型，确定所述告警信息对应的激活因子的状态；
96.步骤s250，在所述激活因子的状态为存在所述激活因子，且所述激活因子中的自愈因子状态字段为可用的情况下，根据所述激活因子的更新时间字段，确定所述激活因子是否在生命周期内；
97.其中，所述激活因子包括自愈因子状态字段和更新时间字段；其中，所述自愈因子状态字段为激活因子中用于表示自愈指令是否可用的字段，所述生命周期为执行自愈指令的时间和采集告警信息的周期之和；
98.在一些实施例中，所述激活因子生命周期＝命令执行平台执行自愈指令时间+系统监控报警框架采集告警信息的周期，考虑到自愈执行下发存在网络延迟，生产设置会普遍偏大一般为理论值的两倍。
99.步骤s260，在所述激活因子处于生命周期内的情况下，静默所述告警信息；
100.这里，所述激活因子处于生命周期内表征所述告警信息正在执行自愈指令。
101.在一些实施例中，处理所述告警信息的告警处理器具有静默功能，调用所述告警处理器进行告警处理时，检测到所述告警信息对应的激活因子处于生命周期内，所述告警处理器调用静默功能，静默告警，不在对告警进行处理。
102.在实施过程中，在激活因子的生命周期内只可执行一次自愈告警操作，为了避免自愈指令重复执行，在检测到所述告警信息正在执行自愈指令的情况下，需要静默所述告警信息，不再对所述告警信息进行二次处理。
103.步骤s270，在所述激活因子未处于生命周期内的情况下，执行所述自愈指令，得到执行结果，以实现对所述告警信息的处理。
104.在本申请实施例中，在所述激活因子处于生命周期内的情况下，静默所述告警信息；在所述激活因子未处于生命周期内的情况下，执行所述自愈指令，得到执行结果，以实现对所述告警信息的处理。这样，能够使得激活因子的生命周期内只可执行一次自愈告警操作，避免自愈指令重复执行。
105.本申请实施例提供一种告警处理方法，图3为本申请实施例告警处理方法的实现流程示意图，如图3所示，该方法包括：
106.步骤s301，获取至少一个文件系统集群中每一集群的告警信息；
107.步骤s302，确定每一告警信息的告警类型和集群标识；
108.步骤s303，根据每一所述告警信息的告警类型匹配对应的自愈指令；所述自愈指
令包括处理所述告警信息所需要执行的处理步骤；
109.步骤s304，根据每一所述告警信息的集群标识和告警类型，确定所述告警信息对应的激活因子的状态；
110.步骤s305，在所述激活因子的状态为存在所述激活因子，且所述激活因子的自愈因子状态字段为可用的情况下，根据所述激活因子的更新时间字段，确定所述激活因子是否在生命周期内；
111.其中，所述激活因子包括自愈因子状态字段和更新时间字段；其中，所述自愈因子状态字段为激活因子中用于表示自愈指令是否可用的字段，所述生命周期为执行自愈指令的时间和采集告警信息的周期之和；
112.步骤s306，在所述激活因子处于生命周期内的情况下，静默所述告警信息；
113.步骤s307，在所述激活因子未处于生命周期内的情况下，根据每一所述告警信息中的集群标识，获取对应集群的状态拓扑树；
114.这里，所述激活因子未处于生命周期内表明当前告警未执行自愈指令，可以执行自愈指令。
115.这里，所述状态拓扑树用于表示文件系统集群中osd(节点)的分布情况。
116.这里，所述集群标识可以用于确定发出告警信息的集群。
117.步骤s308，根据每一所述告警信息中的异常节点的编号和对应集群的状态拓扑树，查找所述异常节点发生告警的存储介质；
118.举例说明，根据osd编号，利用集群状态拓扑树查找到异常节点的ip地址和对应发生ceph osd down类型告警的存储介质的盘符，确定发生告警的存储介质。
119.步骤s309，对所述存储介质进行评估，得到评估结果；
120.这里，所述特定评估服务至少包括以下之一：存储介质检查服务、时钟矫正服务，文件系统集群质量评估服务。这里，所述存储介质检查服务用于检查所述存储介质是否损坏；所述时钟矫正服务用于确定所述存储介质的时钟需要校正；所述文件系统集群质量评估服务用于确定所述存储介质在时钟正常的情况下，使用率是否超过设定的使用上限值。
121.步骤s310，根据所述评估结果，执行所述自愈指令，得到执行结果，以实现对所述告警信息的处理。
122.举例说明，根据存储介质检查服务、时钟矫正服务，文件系统集群质量评估服务的评估结果，执行所述自愈指令。
123.在一些实施例中，所述步骤s310，根据所述评估结果，执行所述自愈指令，得到执行结果，以实现对所述告警信息的处理，包括：
124.步骤s311a，在所述评估结果为所述存储介质已经损坏的情况下，将所述异常节点中的数据迁移到所述集群中的正常节点上；
125.步骤s312a，将所述异常节点从集群中移除并屏蔽所述告警，以实现对所述告警信息的处理。
126.举例说明，如果检查存储介质已经损坏，命令执行平台会主动触发out操作，将osd从集群中移除，所述集群中的数据自动迁移到正常服务的osd上，同时把存储介质的损坏信息上报告警信息采集平台，屏蔽该告警。
127.在一些实施例中，所述步骤s310，根据所述评估结果，执行所述自愈指令，得到执
行结果，以实现对所述告警信息的处理，包括：
128.步骤s311b，在所述评估结果为所述存储介质的时钟需要校正的情况下，对所述时钟进行校正，以实现对所述告警信息的处理；
129.举例说明，如果检测时钟偏移过大，则自动触发时钟校正，更改所述存储介质中的时间。
130.步骤s311c，在所述评估结果为所述存储介质使用率超过设定的使用上限值，且所述存储介质时钟正常的情况下，对所述异常节点进行重启，以实现对所述告警信息的处理。
131.举例说明，存储介质时钟正常的情况下，对比存储介质使用率是否超95％，在使用率高于95％的情况下，将对osd服务进行重启。
132.在一些实施例中，在所述步骤s310，在所述获取至少一个文件系统集群中每一集群的告警信息之前，所述方法还包括：获取至少一个文件系统集群中每一文件系统集群的监控指标；将不满足预先设定的告警规则的所述监控指标，确定为每一集群的告警信息。
133.这里，所述监控指标可以为文件系统集群的集群信息。例如，可以为某个文件系统集群的访问权限和所述集群中文件的文件拥有者。一般来说，所述文件系统集群开启文件系统的特定组件来获取文件系统集群的监控指标，其中，所述特定组件可以为ceph
‑
mgr组件，ceph
‑
mgr组件支持系统监控报警框架，ceph
‑
mgr组件能够把文件系统集群的信息暴露出来，在实施时，系统监控报警框架通过定时发送请求给ceph
‑
mgr组件可以获取文件系统集群的监控指标。
134.这里，所述预先设定的告警规则可以为每一集群的各项指标的非正常值。
135.在实施的过程中，系统监控报警框架通过ceph
‑
mgr获取当前集群的信息，通过规则对比发现osd的状态为down，触发规则上报至告警处理器。
136.在本申请实施例中，一方面，在所述评估结果为所述存储介质已经损坏的情况下，将所述异常节点中的数据迁移到所述集群中的正常节点上；将所述异常节点从集群中移除并屏蔽所述告警，以实现对所述告警信息的处理，这样，可以对存储介质损坏问题进行自愈；另一方面，在所述评估结果为所述存储介质的时钟需要校正的情况下，对所述时钟进行校正，以实现对所述告警信息的处理；在所述评估结果为所述存储介质使用率超过设定的使用上限值，且所述存储介质时钟正常的情况下，对所述异常节点进行重启，以实现对所述告警信息的处理，这样，可以对存储介质的时钟需要校正和使用率超过设定的使用上限值等问题进行自愈，提高了告警处理的实效性，避免了人工处理的时延。
137.相关技术中，在告警信息采集平台接收到文件系统相关的告警信息的情况下，相关的告警信息被展示在显示界面上，由相关人员联系对应系统的工作人员对告警信息进行手动处理。
138.相关技术中，存在以下缺点：1)文件系统告警人工处理，耗费人力；2)文件系统的异常告警，需要相关人员进行响应和处理，在相关人员无法及时处理的情况下，业务受影响时间长；3)相关人员进行文件系统的告警异常处理时，需要对产生告警异常的系统特别熟悉，因此，在不熟悉的情况下，相关人员存在误操作风险。
139.本申请实施例提供一种告警处理方法，该方法包括：
140.1)监控系统的自愈流程
141.文件系统开启特定组件，所述特定组件可以为ceph
‑
mgr组件，ceph
‑
mgr组件支持
系统监控报警框架(prometheus)，ceph
‑
mgr组件能够把文件系统集群的信息暴露出来，系统监控报警框架通过定时发送请求给ceph
‑
mgr组件可以获取文件系统集群的监控指标。在系统监控报警框架内部根据预设的各项指标的告警规则，指标触发告警规则之后直接发送给告警处理器(alertmanager)。这里，所述告警处理器负责对于系统监控报警框架产生的告警进行统一处理，可以在告警处理器中设定告警规则，进行可自愈告警的筛选；设定自愈条件，把符合自愈条件的告警发送给命令执行平台进行自愈处理，不满足自愈条件的告警发送给人工告警处理平台，通知人工进行告警处理。
142.文件系统为输入输出密集型应用，所以所述告警类型可以为ceph osd down类型。所述ceph osd down类型的告警可以由多种情况引起：例如，对应的底层存储介质异常、业务繁忙osd长时间高负载没有及时发送心跳、osd节点时钟偏移过大等。
143.系统监控报警框架通过ceph
‑
mgr获取当前集群的信息，通过规则对比发现osd的状态为down，触发规则上报至告警处理器，告警处理器根据上报的ceph告警，查询对应集群的激活因子，根据所述激活因子判断是否进行自愈处理。
144.如果激活因子满足激活条件，进行自愈处理，在命令执行平台根据请求的协议，通过传入告警的集群标识和osd编号，利用集群状态拓扑树查找到异常节点的ip地址和对应发生ceph osd down类型告警的存储介质，告警处理器依次调用被命令执行平台封装的存储介质检查服务、ntp时钟矫正服务、ceph集群质量评估服务对存储介质进行评估。如果检查存储介质已经损坏，命令执行平台会主动触发out操作，将osd从集群中移除，并将osd上的数据自动迁移到正常服务的osd上，同时把介质损坏信息上报告警信息采集平台，屏蔽该告警；如果检测时钟偏移过大，则自动触发时钟校正服务；对于ceph集群质量进行评估计算，如果检测存储介质使用率超过95％，并且存储介质和时钟检查都正常，将对osd服务进行重启；如果无法和以上情况进行匹配，直接将告警信息上报告警信息采集平台。
145.激活因子不满足条件，直接把告警传输给告警信息采集平台。在本次处理完成之后，发送到告警信息采集平台之前会对集群的激活因子进行存储，提供给后面的告警使用。
146.2)告警处理器判断是否可执行自愈
147.告警处理器判断是否可自愈由两个方面组成：自愈指令集+激活因子组成；自愈指令集为告警处理的方法组成的集合，转化为已封装的指令集，正常情况下只需发到服务器执行该指令集即可完成告警处理，告警处理器在接收到告警信息时，通过系统监控报警框架采集上报的告警类型字段匹配该告警是否可以找到对应的自愈指令，如果匹配到自愈指令集则表示该告警有能力执行自愈，否则反之；激活因子，前述条件均已经满足的情况下，接收到的告警为可自愈告警，激活因子表征是否执行自愈操作，激活因子由云管理平台提供，可以高效避开维修中、变更中的集群，对已经发送自愈执行的告警重复自愈等非正常情况下错误的自愈处理。
148.3)激活因子
149.激活因子由云管理平台生成，按照告警类型来划分，相同集群上告警类型不同激活因子不同，激活因子的生命周期＝命令执行平台执行自愈指令时间+系统监控报警框架采集告警信息的周期。在实施过程中，设置为激活因子的生命周期的两倍，在激活因子的生命周期内只可执行一次自愈告警操作，以避免自愈指令重复执行。以ceph osd down为例，激活因子的数据结构为：
150.{
151.cluster_name:rbd_arm_ft01
152.warn_name:ceph osd.12down
153.warn_ip:10.110.3.8
154.last_time:2020
‑
09
‑
16:15:58:23#上一次出现告警的时间
155.now_time:2020
‑
09
‑
16:15:58:23#本次出现告警的时间
156.ttl_time:120s
157.warn_level:major
158.……………
159.命令执行平台_result:“ok”#ok代表自愈指令成功执行、wait代表等待自愈指令执行结果、fail代表自愈指令执行失败
160.count:1
161.告警信息采集平台_send_time:2020
‑
09
‑
16:15:58:23
162.status:“active”#active代表激活因子可用、inactive代表激活因子不可用，该状态不可以执行自愈指令
163.}
164.当告警处理器接收到告警类型为ceph osd.12down的告警信息时，告警处理器利用告警信息中的cluster_name和warn_name来匹配是否存在激活因子：
165.在不存在激活因子的情况下，创建对应的激活因子，执行对应命令执行平台自愈指令，自愈脚本的执行结果填写在创建激活因子的命令执行平台_result字段中，如果自愈指令执行失败，发送告警给告警信息采集平台通知自愈失败，同时把激活因子状态设置为不可用inactive。
166.在存在激活因子的情况下，状态为可用状态active，根据update_time计算是否在激活因子生命周期中，如果在所述生命周期内，调用告警处理器静默功能主动静默本次告警，否则调用命令执行平台继续下发自愈指令进行处理。
167.4)激活因子状态计算
168.告警处理器判断是否可自愈，需要关注激活因子的状态，当激活因子的状态为active则表示可以进行自愈操作，会自动执行自愈指令集；当激活因子状态为inactive则表示不可执行自愈操作。
169.云管理平台产生激活因子会计算激活因子对应的状态值，公式如下：
170.激活因子状态值＝(集群维修状态&集群变更状态)&((当前时间戳
‑
上次愈合时间戳
–
k*最大自愈时间间隔)>0)。
171.其中，所述激活因子状态值为激活因子的自愈因子状态字段的状态值，&表示与运算，计算后激活因子状态值为1表示active；状态值为0表示inactive；公式中集群维修状态、集群变更状态、上次愈合时间戳通过云管理平台可以通过查询数据库的方式获取；最大自愈时间间隔初始值为3600s，可以通过动态计算获取集群异常的最大自愈时间间隔进行替换,k表示常数值，根据实际情况进行设置，本发明实施例中，通过测试优选将k设为2。
172.5)更新激活因子
173.在自愈后的处理阶段需要做两方面工作：一方面，获取自愈的执行情况回填到激
活因子中，比如count、命令执行平台_result等字段；另一方面，将已经执行成功的告警对应的激活因子放入等待队列中，等待告警指标的t个采集周期，判断是否自愈成功。如果采集的指标还是存在异常则将告警因子的状态设置为inactive，把激活因子设置为不可用，将告警信息直接上报告警信息采集平台。
174.本申请实施例中，所述告警信息采集平台是用于采集并存储告警信息；所述告警处理器用于对所述告警信息中满足自愈条件的告警信息进行处理；所述人工告警处理平台用于通知人工对未满足自愈条件的告警进行处理。
175.本申请实施例将结合图4提供的告警处理系统，以ceph osd down告警类型的自愈规则为例，来提供一种告警处理方法，该方法包括：
176.步骤s401，系统监控报警框架41采集各个文件系统集群42的监控指标；
177.这里，系统监控报警框架通过ceph
‑
mgr获取当前集群的状态。
178.在一些实施例中，所述方法还包括：系统监控报警框架41根据所述监控指标和预设各项指标的告警规则，确定告警信息；系统监控报警框架41将所述告警信息发送给告警处理器43。
179.步骤s402，告警处理器43(alertmanager)根据所述告警信息进行告警匹配；
180.这里，所述告警匹配为告警处理器判断所述告警信息是否可执行自愈。
181.在实施过程中，告警处理器43在接收到告警信息时，通过系统监控报警框架41采集上报的告警类型字段主动匹配该告警信息是否可以找到对应的自愈指令，如果匹配到自愈指令集则表示该告警有能力执行自愈，否则反之。
182.在所述告警满足自愈条件可执行自愈的情况下，执行步骤s404；在所述告警未满足自愈条件的情况下，执行步骤s405；
183.步骤s403，告警处理器43从云管理平台44获取激活因子；
184.步骤s404，告警处理器43在所述告警满足自愈条件且激活因子的状态为可用的情况下，调用命令执行平台46对所述告警进行处理；
185.这里，激活因子的状态为可用则表示可以进行自愈操作，会自动执行自愈指令集。
186.步骤s405，告警处理器43在所述告警未满足自愈条件的情况下，上报告警信息采集平台45所述告警自愈失败。
187.基于前述的实施例，本申请实施例提供一种告警处理装置，该装置包括所包括的各模块、以及各模块所包括的各单元，可以通过计算机设备中的处理器来实现；当然也可通过具体的逻辑电路实现；在实施的过程中，处理器可以为中央处理器(cpu)、微处理器(mpu)、数字信号处理器(dsp)或现场可编程门阵列(fpga)等。
188.图5为本申请实施例告警处理装置的组成结构示意图，如图5所示，所述装置500包括第一获取模块501、第一确定模块502、匹配模块503、第二确定模块504和执行模块505，其中：
189.第一获取模块501，用于获取至少一个文件系统集群中每一集群的告警信息；
190.第一确定模块502，用于确定每一告警信息的告警类型和集群标识；
191.匹配模块503，用于根据每一所述告警信息的告警类型匹配对应的自愈指令；所述自愈指令包括处理所述告警信息所需要执行的处理步骤；
192.第二确定模块504，用于根据每一所述告警信息的集群标识和告警类型，确定所述
告警信息对应的激活因子的状态；
193.执行模块505，用于根据所述激活因子的状态，执行所述自愈指令，以实现对所述告警信息的处理。
194.在一些实施例中，所述执行模块505，包括：生成单元和第一执行单元，其中：生成单元，用于在所述激活因子的状态为不存在所述激活因子的情况下，根据所述集群标识和告警类型创建对应的激活因子，其中，所述激活因子包括自愈因子状态字段；其中，所述自愈因子状态字段为激活因子中用于表示自愈指令是否可用的字段；第一执行单元，用于在所述自愈因子状态字段为可用的情况下，执行所述自愈指令，得到执行结果，以实现对所述告警信息的处理。
195.在一些实施例中，所述装置500还包括：存储模块、时延模块和第三确定模块，其中：存储模块，用于在所述执行结果为自愈成功的情况下，将所述执行结果对应的激活因子放入等待队列中；时延模块，用于等待所述自愈指令执行n个周期后，得到所述n个周期内的执行结果；第三确定模块，用于在所述每一周期内的执行结果为自愈成功的情况下，确定所述告警处理成功。
196.在一些实施例中，所述装置500还包括设置模块，其中：设置模块，用于在所述执行结果为自愈失败的情况下，将所述自愈因子的状态字段设置为不可用状态，并向人工告警处理平台上报所述告警信息；所述不可用状态用于指示向所述人工告警处理平台上报相同告警类型的告警信息。
197.在一些实施例中，所述执行模块505，包括：确定单元、静默单元和第二执行单元，其中：确定单元，用于在所述激活因子的状态为存在所述激活因子，且所述自愈因子状态字段为可用的情况下，根据所述激活因子的更新时间字段，确定所述激活因子是否在生命周期内，所述生命周期为执行自愈指令的时间和采集告警信息的周期之和；静默单元，用于在所述激活因子处于生命周期内的情况下，静默所述告警信息；第二执行单元，用于在所述激活因子未处于生命周期内的情况下，执行所述自愈指令，得到执行结果，以实现对所述告警信息的处理。
198.在一些实施例中，所述装置500还包括：第二获取模块、查找模块和评估模块，其中：第二获取模块，用于根据每一所述告警信息中的集群标识，获取对应集群的状态拓扑树；查找模块，用于根据每一所述告警信息中的异常节点的编号和对应集群的状态拓扑树，查找所述异常节点发生告警的存储介质；评估模块，用于对所述存储介质进行评估，得到评估结果；所述第一执行单元或所述第二执行单元，还用于根据所述评估结果，执行所述自愈指令，得到执行结果，以实现对所述告警信息的处理。
199.在一些实施例中，所述第一执行单元或所述第二执行单元，还用于在所述评估结果为所述存储介质已经损坏的情况下，将所述异常节点中的数据迁移到所述集群中的正常节点上；将所述异常节点从集群中移除并屏蔽所述告警，以实现对所述告警信息的处理。
200.在一些实施例中，所述第一执行单元或所述第二执行单元，还用于在所述评估结果为所述存储介质的时钟需要校正的情况下，对所述时钟进行校正，以实现对所述告警信息的处理；在所述评估结果为所述存储介质使用率超过设定的使用上限值，且所述存储介质时钟正常的情况下，对所述异常节点进行重启，以实现对所述告警信息的处理。
201.在一些实施例中，所述装置500还包括：第三获取模块和第四确定模块，其中：第三
获取模块，用于获取至少一个文件系统集群中每一文件系统集群的监控指标；第四确定模块，用于将不满足预先设定的告警规则的所述监控指标，确定为每一集群的告警信息。
202.在一些实施例中，所述装置500还包括第五确定模块，其中：第五确定模块，用于在创建所述激活因子情况下，根据所述集群标识所属的集群维修状态、集群变更状态、创建所述激活因子时间戳、上次愈合时间戳和自愈时间间隔，确定所述自愈因子状态字段的状态值。
203.以上装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。
204.需要说明的是，本申请实施例中，如果以软件功能模块的形式实现上述的告警处理方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read only memory，rom)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本申请实施例不限制于任何特定的硬件和软件结合。
205.对应地，本申请实施例提供一种计算机设备，包括存储器和处理器所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述方法中的步骤。
206.对应地，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述方法中的步骤。
207.这里需要指出的是：以上存储介质和设备实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请存储介质和设备实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。
208.需要说明的是，图6为本申请实施例中计算机设备的一种硬件实体示意图，如图6所示，该计算机设备600的硬件实体包括：处理器601、通信接口602和存储器603，其中
209.处理器601通常控制计算机设备600的总体操作。
210.通信接口602可以使计算机设备通过网络与其他终端或服务器通信。
211.存储器603配置为存储由处理器601可执行的指令和应用，还可以缓存待处理器601以及计算机设备600中各模块待处理或已经处理的数据(例如，图像数据、音频数据、语音通信数据和视频通信数据)，可以通过闪存(flash)或随机访问存储器(random access memory，ram)实现。
212.应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。上述本申请实施例
序号仅仅为了描述，不代表实施例的优劣。
213.需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
214.在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。
215.上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。
216.另外，在本申请各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
217.本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(read only memory，rom)、磁碟或者光盘等各种可以存储程序代码的介质。
218.或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、rom、磁碟或者光盘等各种可以存储程序代码的介质。
219.以上所述，仅为本申请的实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。