一种索引服务器的监控方法及监控设备与流程

1.本公开涉及数据处理分析技术领域，尤其涉及一种索引服务器的监控方法及监控设备。


背景技术：

2.索引服务是搜索服务中的关键模块，稳定性至关重要，如果针对索引服务的监控不到位就会对业务产业影响，所以需要建立一套监控方法来针对提供索引服务的索引服务器进行监控发现问题。目前市场上有各种的监控平台，通常是从独立的角度来进行监控的，因此得到的监控参数比较零散，在索引服务出现问题的时，需要从大量零散的监控参数中人为分析出现的故障，因此无法快速准确的确定索引服务中故障的问题。


技术实现要素：

3.为了解决上述技术问题或者至少部分地解决上述技术问题，本公开提供了一种索引服务器的监控方法及监控设备。
4.为了实现上述目的，本公开实施例提供的技术方案如下：
5.第一方面，本公开实施例提供一种索引服务器的监控方法，该方法可以应用于监控索引服务器；
6.获取目标监控信息，所述目标监控信息包括：导入数据的监控信息、索引服务状态的监控信息、以及索引服务使用的监控信息中的至少一项；
7.确定所述目标监控信息对应的目标报警规则，所述目标报警规则对应于至少一个故障设置；
8.在所述目标监控信息满足所述目标报警规则时，输出针对所述至少一个故障的报警信息。
9.作为本公开实施例一种可选的实施方式，所述目标监控信息包括：导入数据的监控信息：
10.在调用第一api导入第一数据到消息队列时，若存在第一请求错误，则将所述第一请求错误记录在日志文件，所述第一api为所述消息队列的api；
11.所述第一数据导入到所述消息队列之后，在调用第二api接口将所述消息队列中的所述第一数据导入索引服务时，若存在第二请求错误，则将所述第二请求错误记录到所述日志文件；
12.从所述日志文件中获取所述第一请求错误，和/或，所述第二请求错误；
13.从所述消息队列中获取消费数据数量，和/或，未消费数据数量；
14.将所述第一请求错误、所述第二请求错误、所述消费数据数量和所述未消费数据数量中的至少一项，作为所述导入数据的监控信息。
15.作为本公开实施例一种可选的实施方式，所述目标报警规则包括以下至少一种：
16.存在所述第一请求错误；
17.存在所述第二请求错误；
18.所述消费数据数量小于或等于第一数量阈值；
19.在第一时长内，所述消费数据数量小于或等于第一数量阈值；
20.所述未消费数量大于或等于第二数量阈值；
21.在第二时长内，所述未消费数据数量大于或等于第二数量阈值；
22.所述未消费数量与所述消费数量的比例大于或等于预设比例；
23.在第三时长内，所述未消费数量与所述消费数量的比例大于或等于预设比例；
24.消息积压率大于或等于比率阈值，所述消息积压率为：在第四时长内，所述未消费数量与所述消息队列对应的数据总量的比值。
25.作为本公开实施例一种可选的实施方式，所述索引服务器为包括多个服务器的服务器集群，所述目标监控信息包括：索引服务状态的监控信息；
26.所述获取目标监控信息，包括：
27.获取所述多个服务器的运行状态信息；所述运行状态信息包括以下至少一种：
28.负载率、索引服务的慢查询日志；
29.其中，所述负载率包括：cpu使用率、内存使用率、带宽占用率、磁盘占用率中的至少一种。
30.作为本公开实施例一种可选的实施方式，所述目标报警规则包括以下至少一种：
31.单个服务器的负载率大于或等于第一预设比率；
32.总负载率大于或等于第二预设比率；
33.存在负载差值大于或等于预设差值的两个服务器；
34.存在所述索引服务的慢查询日志；
35.所述索引服务的慢查询日志指示所述索引服务的响应时长大于或等于预设时长。
36.作为本公开实施例一种可选的实施方式，所述目标监控信息包括：索引服务使用的监控信息；
37.所述获取目标监控信息，包括：
38.若索引服务使用过程中，出现目标错误，则将所述目标错误记录到所述日志文件，所述目标错误包括：未连接到所述索引服务器，以及连接所述索引服务器超时中的至少一项；
39.若索引服务使用过程中，保存用户的搜索记录，搜索记录中包括：用户id、时间、索引服务器标识、搜索耗时时长。
40.从所述日志文件中获取所述目标错误记录，作为所述索引服务使用的监控信息。
41.作为本公开实施例一种可选的实施方式，所述目标报警规则包括以下至少一种：
42.存在所述目标错误；
43.所述搜索耗时时长大于或等于预设时长。
44.作为本公开实施例一种可选的实施方式，所述获取目标监控信息，包括：
45.通过导入第一模拟数据，获取所述导入数据的监控信息；
46.和/或，
47.通过针对第二模拟数据使用索引服务，获取所述索引服务状态的监控信息，和/或，索引服务使用的监控信息。
48.作为本公开实施例一种可选的实施方式，所述输出报警信息，包括：
49.基于所述报警信息，显示报警界面；所述报警界面中包括至少一个功能控件，所述至少一个功能控件用于触发针对所述至少一个故障的处理操作，其中，每个功能控件用于触发针对一个或多个的故障的处理操作。
50.第二方面，提供一种索引服务器的监控装置，包括：
51.获取模块，用于获取目标监控信息，所述目标监控信息包括：导入数据的监控信息、索引服务状态的监控信息、以及索引服务使用的监控信息中的至少一项；
52.确定模块，用于确定所述目标监控信息对应的目标报警规则，所述目标报警规则对应于至少一个故障设置；
53.输出模块，用于在所述目标监控信息满足所述目标报警规则时，输出针对所述至少一个故障的报警信息。
54.第三方面，提供一种监控设备，包括：处理器、存储器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如第一方面或其可选的实施方式中的任一项的索引服务器的监控方法。
55.第四方面，本公开一种计算机可读存储介质，包括：计算机可读存储介质上存储计算机程序，计算机程序被处理器执行时实现如第一方面或其可选的实施方式中的任一项的索引服务器的监控方法。
56.第五方面，提供一种计算机程序产品，包括：当计算机程序产品在计算机上运行时，使得计算机实现如第一方面或其可选的实施方式中的任一项的索引服务器的监控方法。
57.本公开实施例提供的技术方案与现有技术相比具有如下优点：可以获取导入数据的监控信息、索引服务状态的监控信息、以及索引服务使用的监控信息三个方面中的监控信息，并且可以基于不同监控信息设置对应的目标报警规则，并将这些报警规则关联到至少一个故障设置，这样在监控信息满足目标报警规则的情况下，就可以输出针对至少一个故障的报警信息，无需人为分析监控参数或者报警信息，就可以获知索引服务器所提供的索引服务中存在何种故障，从而可以快速准确的确定索引服务中的故障。
附图说明
58.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。
59.为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
60.图1为本公开实施例提供的一种场景示意图；
61.图2为本公开实施例提供的一种监控设备的模块化示意图；
62.图3为本公开实施例提供的一种监控信息采集流程示意图；
63.图4为本公开实施例提供的一种索引服务器的监控方法的流程示意图；
64.图5为本公开实施例提供的一种监控装置的结构示意图；
65.图6为本公开实施例提供的一种监控设备的硬件结构示意图。
具体实施方式
66.为了能够更清楚地理解本公开的上述目的、特征和优点，下面将对本公开的方案进行进一步描述。需要说明的是，在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合。
67.在下面的描述中阐述了很多具体细节以便于充分理解本公开，但本公开还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本公开的一部分实施例，而不是全部的实施例。
68.目前市场上有各种的监控平台，通常是从独立的角度来进行监控的，因此得到的监控参数比较零散，在索引服务出现问题时，需要从大量零散的监控参数中人为分析出现的故障，因此无法快速准确的确定索引服务中故障的问题。
69.为了解决上述问题，本公开实施例中提供了一种索引服务器的监控方法，可以获取导入数据的监控信息、索引服务状态的监控信息、以及索引服务使用的监控信息三个方面中的监控信息，并且可以基于不同监控信息设置对应的目标报警规则，并将这些报警规则关联到至少一个故障设置，这样在监控信息满足目标报警规则的情况下，就可以输出针对至少一个故障的报警信息，无需人为分析监控参数或者报警信息，就可以获知索引服务器所提供的索引服务中存在何种故障，从而可以快速准确的确定索引服务中的故障。
70.本公开实施例提供的索引服务器的监控方法可以应用于监控设备，该监控设备可以为索引服务器中的部分器件，或者该监控设备可以为独立于索引服务器的一个设备。本公开实施例中所涉及的监控装置可以为上述监控设备中可以实现上述监控方法的功能模块或者功能实体。
71.如图1所示，为本公开实施例提供的一种场景示意图，该场景中包括：索引服务器11、监控设备12，以及客户端13，客户端14和客户端15，其中，任一客户端可以通过访问索引服务器11，来让索引服务器11为其提供索引服务。其中，索引服务器11会基于客户端访问时提供的信息，为客户端提供索引服务，返回搜索结果。本公开实施例中监控设备12可以用于对索引服务器进行监控，收集监控信息并基于收集的监控信息，按照相应的报警规则进行判断，在出现异常时，输出针对故障的报警信息，并且可以进行故障处理。
72.如图2所示，为本公开实施例中一种监控设备的模块化示意图，该监控设备包括：监控采集模块21、监控分析模块22和报警及故障处理模块23。
73.(1)监控采集模块21，用于从多个维度进行监控信息的采集，并将采集得到的监控信息，发送至监控分析模块22；
74.示例性的，如图3所示，本公开实施例提供的一种监控信息采集流程示意图，通过图3所示的方式对需要采集的监控信息进行了一个简要的划分，按3个维度来区分，这3个维度组合起来其实就是一条数据的处理流程，从原始数据到最终被搜索业务使用的过程。如图3中所示，维度1是导入数据过程的监控信息获取、该过程中索引服务器导入数据时，会先将数据导入到消息队列中，然后再从消息队列中导入到索引服务，对于维度1所采集的监控信息本公开实施例中称为导入数据的监控信息；维度2是索引服务的运行状态的监控信息获取，本公开实施例中对于维度2所采集的监控信息称为索引服务状态的监控信息；维度3是索引服务使用时，搜索业务的监控信息获取，本公开实施例中对于维度3所采集的监控信息称为索引服务使用的监控信息。
75.(2)监控分析模块22，用于基于监控信息利用对应的报警规则进行综合分析，从而确定是否存在问题，并将分析结果反馈给报警及故障处理模块23；
76.(3)报警及故障处理模块23，用于基于分析结果进行一些故障报警，并且提供一些可以快速处理这些故障的功能控件，供维护人员及时处理这些故障。
77.如图4所示，为本公开实施例提供的一种索引服务器的监控方法，该方法包括：
78.401、获取目标监控信息。
79.402、确定目标监控信息对应的目标报警规则。
80.其中，目标监控信息包括：导入数据的监控信息、索引服务状态的监控信息、以及索引服务使用的监控信息中的至少一项。
81.本公开实施例中，可以通过导入第一模拟数据，获取所述导入数据的监控信息。
82.本公开实施例中，还通过针对第二模拟数据使用索引服务，获取所述索引服务状态的监控信息，和/或，索引服务使用的监控信息。
83.需要说明的是，本发明实施例中所涉及的导入数据是指针对数据插入、数据删除、数据更新等一种或多种数据发生变化的操作。
84.由于在没有数据发生变化的情况下，索引服务的程序不运行，无法得到上述监控信息，发现不了故障。此时可以通过模拟脚本去模拟数据导入，以及模拟使用索引服务，这样模拟脚本可以将整个索引服务的流程所涉及到的部分都去运行，这样就能获取到各个维度的监控信息。对于索引服务，可以定义多个脚本，每个脚本完成不同的事情，例如，数据插入、数据更新、数据删除的，这样就可以完成了数据插入、更新和删除操作。进一步的，还可以添加查询脚本，针对数据的变化，通过搜索业务接口，就可以查询到对应信息。
85.其中，目标报警规则对应于至少一个故障设置。
86.本发明实施例中，报警规则是对应于监控信息进行设定的，具体应用哪种报警规则取决于采集了哪些监控信息。
87.也就是说，目标监控信息存在以下几种情况：
88.情况1：导入数据的监控信息；
89.情况2：索引服务状态的监控信息；
90.情况3：索引服务使用的监控信息；
91.情况4：导入数据的监控信息和索引服务状态的监控信息；
92.情况5：索引服务状态的监控信息和索引服务使用的监控信息；
93.情况6：导入数据的监控信息和索引服务使用的监控信息；
94.情况7：导入数据的监控信息、索引服务状态的监控信息、以及索引服务使用的监控信息。
95.针对上述情况1，目标监控信息包括导入数据的监控信息，那么获取导入数据的监控信息的方式包括：
96.实施例方式一：在调用第一api导入第一数据到消息队列时，若存在第一请求错误，则将请求错误记录在日志文件，第一api为消息队列的api；第一数据导入到消息队列之后，在调用第二api接口将消息队列中的第一数据导入索引服务时，若存在第二请求错误，则将第二请求错误记录到日志文件，第二api接口为索引服务的api接口；
97.从日志文件中获取第一请求错误，和/或，第二错误请求错误；
98.从消息队列中获取消费数据数量，和/或，未消费数据数量；
99.将第一请求错误、第二错误请求错误、消费数据数量和未消费数据数量中的至少一项，作为导入数据的监控信息。
100.其中，第一请求错误包括：向客户端请求超时，客户端与消息队列连接不上。
101.第二请求错误包括：向消息队列请求超时，消息队列与索引服务连接不上，索引服务数据写入速度低于速度门限。
102.本公开实施例中，索引服务为索引服务器中提供索引功能的功能模块，将第一数据导入索引服务可以理解为保存在索引服务器中索引功能所对应的数据库中。
103.针对上述实施方式一中获取的导入数据的监控信息，目标报警规则可以包括以下至少一种：
104.(a)存在第一请求错误；
105.(b)存在第二请求错误；
106.(c)消费数据数量小于或等于第一数量阈值；
107.(d)在第一时长内，消费数据数量小于或等于第一数量阈值；
108.(e)未消费数量大于或等于第二数量阈值；
109.(f)在第二时长内，未消费数据数量大于或等于第二数量阈值；
110.(g)未消费数量与消费数量的比例大于或等于预设比例；
111.(h)在第三时长内，未消费数量与消费数量的比例大于预设比例；
112.(i)消息积压率大于或等于比率阈值，消息积压率为：在第四时长内，未消费数量与消息队列对应的数据总量的比值。
113.其中，第一时长、第二时长、第三时长与第四时长可以基于实际需求进行设置，这些时长可以设置为相同也可以设置不同，本公开实施例中不做限定。
114.实施例方式二：可以直接通过调用第二api接口，将第一数据从客户端导入索引服务，在此过程中，若出现第三请求错误，则将该第三请求错误记录在日志文件中；从日志文件中获取该第三请求错误，作为导入数据的监控信息。
115.其中，第三请求错误包括：向客户端请求超时，客户端与索引服务连接不上，索引服务数据写入速度低于速度门限。
116.针对上述实施方式二中，获取的导入数据的监控信息，目标报警规则可以为：(j)存在第三请求错误。
117.需要说明的是，在实际数据导入过程中，可能会存在实施方式一和实施方式二的导入数据的方案都存在的情况，那么可以将上述报警规则中(a)至(i)的9种规则中的一种或多种，与报警规则(j)相结合形成最终的报警规则。
118.针对上述情况2：索引服务器为包括多个服务器的服务器集群，目标监控信息为索引服务状态的监控信息，那么获取索引服务状态的监控信息的方式包括：
119.获取多个服务器的运行状态信息；运行状态信息包括：负载率和索引服务的慢查询日志中的至少一种：其中，负载率包括：cpu使用率、内存使用率、带宽占用率、磁盘占用率中的至少一种。
120.也即，上述运行状态信息包括：cpu使用率、内存使用率、带宽占用率、磁盘占用率和索引服务的慢查询日志中的至少一种。
121.针对上述情况2，目标报警规则可以包括以下至少一种：
122.(k)单个服务器的负载率大于或等于第一预设比率；
123.如果一个服务器的cpu使用率超过一定比率，说明该服务器的计算资源不够，针对用户的搜索请求，需要耗费更多的时间。如果一个服务器的内存使用率超过一定比率，说明服务器无法处理更多用户的请求了，超过一定的量级服务就会宕机，将无法为用户提供搜索请求。基于此可以针对单个服务的负载率(cpu使用率、内存使用率)，设置对应阈值。
124.(l)总负载率大于或等于第二预设比率；
125.(m)存在负载差值大于或等于预设差值的两个服务器；
126.从整个服务器集群的角度来看，也可以其整体负载情况，整个集群的磁盘使用率，如果磁盘使用率超过阈值，并且访问的数据为近期数据，这种情况需要对索引服务器的集群做冷热数据隔离。
127.从整个服务器集群的角度来看整个集群负载使用率(cpu、内存、磁盘对的使用率)超过阈值，且消息队列消费超过阈值，说明集群整体的负载较大，需要考虑增加服务器集群中的服务器数量，或者将原有索引服务拆分到多个服务器集群去提供服务。
128.如果存在负载差值大于预设差值的两个服务器，那么对集群的访问是不均匀的，需要优化集群的访问策略，均衡服务器的服务范围。
129.(n)存在索引服务的慢查询日志；
130.(o)索引服务的慢查询日志指示索引服务的响应时长大于或等于预设时长。
131.在实际应用中，上述报警规则还可以与其他报警规则相结合，形成综合性的报警规则，例如，上述报警规则中(a)至(j)的10种规则中的一种或多种，与上述报警规则中(k)至(o)5种规则中的一种或多种相结合，形成最终的报警规则。
132.本公开实施例中，日志文件中的不同日志信息是通过多次采集得到的，可以区分不同日志信息的存储格式和日志信息类型，去为日志信息划分类型和等级，我们把这些日志信息存储在搜索服务器中，可以供后续查询分析。示例性的，还可以针对一些日志文件中的特殊信息进行标注，来表征这类信息的作用。
133.情况3：目标监控信息为索引服务使用的监控信息，那么获取索引服务使用的监控信息的方式包括：
134.若索引服务使用过程中，出现目标错误，则将目标错误记录到日志文件，目标错误包括：未连接到索引服务器，以及连接索引服务器超时中的至少一项；
135.若索引服务使用过程中，保存用户的搜索记录，搜索记录中包括：搜索耗时时长。
136.从所述日志文件中获取所述目标错误记录以及所述搜索耗时时长，作为所述索引服务使用的监控信息。
137.其中，未连接到索引服务器，说明索引服务处理存在故障，说明索引服务器可能存在故障，或者，客户端与索引服务器之间的网络连接出现问题。
138.连接索引服务器超时，即索引服务处理用户搜索请求超时，说明索引服务负载较大。
139.针对上述情况3，目标监控信息为索引服务使用的监控信息，那么对应的目标报警规则可以包括以下至少一种：
140.(p)存在目标错误；
141.(q)搜索耗时时长大于或等于预设时长。
142.在实际应用中，上述报警规则还可以与其他报警规则相结合，形成综合性的报警规则，例如，上述报警规则中(a)至(o)15种规则中的一种或多种，与上述规则(p)和/或(q)相结合，形成最终的报警规则。
143.进一步的，上述搜索记录中还可以包括：用户id、搜索时间、服务器标识等。
144.通过对该搜索记录的分析，可以了解搜索服务器中各个服务器的使用情况，进而能分析出集群中各个服务器的负载情况，从而方便后续对整个搜索服务器中的多个服务器进行负载均衡的调整。
145.进一步的，报警规则还可以设置对应的使用时间频率，限定在一定时间间隔内不会重复使用。
146.403、判断目标监控信息是否满足目标报警规则。
147.若目标监控信息满足目标报警规则，则执行下述404；若目标监控信息不满足目标报警规则，则返回执行上述401。
148.404、输出针对至少一个故障的报警信息。
149.在一些实施例中，输出针对至少一个故障的报警信息包括：基于所述报警信息，显示报警界面；报警界面中包括至少一个功能控件，所述至少一个功能控件用于触发针对所述至少一个故障的处理操作，其中，每个功能控件用于触发针对一个或多个的故障的处理操作。
150.本公开实施例中，通过增加一些可以及时进行故障处理的控件，可以通过这些功能控件能快速的处理线上问题，比如，通过短信里的暂停消息队列处理的功能控件，可以触发暂时停用消息队列的处理，以给运维人员争取时间来修复问题。
151.规则一：每1分钟运行1次，即每分钟基于以下2个规则进行一次判断，如果规则均满足，则输出报警信息：
152.规则1：80％api接口调用超过300ms(即，存在第一请求错误，向客户端请求超时)；
153.规则2：服务器cpu使用率超过80％以上(即服务器负载率大于或等于第二预设比率)；
154.则发送报警给手机号码150xxxxxxxx，报警内容可以为：当前搜索服务访问量较大且响应时间较慢，服务器整体负载较高，应该进行服务限流。
155.规则二：每5分钟运行1次，即每5分钟基于以下2个规则进行一次判断，如果规则均满足，则输出报警信息：
156.规则1：消息队列消息堆积数量超过2000条(即未消费数据数量过多)；
157.规则2：服务器cpu使用率低于80％，内存使用率低于80％；
158.则发送报警信息给手机号码150xxxxxxxx,报警内容为索引业务正常，消息队列积压消费慢。
159.本公开实施例提供一种索引服务器的监控方法，可以获取导入数据的监控信息、索引服务状态的监控信息、以及索引服务使用的监控信息三个方面中的监控信息，并且可以基于不同监控信息设置对应的目标报警规则，并将这些报警规则关联到至少一个故障设置，这样在监控信息满足目标报警规则的情况下，就可以输出针对至少一个故障的报警信息，无需人为分析监控参数或者报警信息，就可以获知索引服务器所提供的索引服务中存
在何种故障，从而可以快速准确的确定索引服务中的故障。
160.如图5所示，本公开实施例提供一种索引服务器的监控装置，包括：
161.获取模块501，用于获取目标监控信息，所述目标监控信息包括：导入数据的监控信息、索引服务状态的监控信息、以及索引服务使用的监控信息中的至少一项；
162.确定模块502，用于确定所述目标监控信息对应的目标报警规则，所述目标报警规则对应于至少一个故障设置；
163.输出模块503，用于在所述目标监控信息满足所述目标报警规则时，输出针对所述至少一个故障的报警信息。
164.作为本公开实施例一种可选的实施方式，所述目标监控信息包括：导入数据的监控信息：
165.所述获取模块501，具体用于：
166.在调用第一api导入第一数据到消息队列时，若存在第一请求错误，则将所述请求错误记录在日志文件，所述第一api为所述消息队列的api；
167.所述第一数据导入到所述消息队列之后，在调用第二api接口将所述消息队列中的所述第一数据导入索引服务时，若存在第二请求错误，则将所述第二请求错误记录到所述日志文件，其中，所述第二api接口为索引服务的api接口；
168.从所述日志文件中获取所述第一请求错误，和/或，所述第二错误请求错误；
169.从所述消息队列中获取消费数据数量，和/或，未消费数据数量；
170.将所述第一请求错误、所述第二错误请求错误、所述消费数据数量和所述未消费数据数量中的至少一项，作为所述导入数据的监控信息。
171.作为本公开实施例一种可选的实施方式，所述目标报警规则包括以下至少一种：
172.存在所述第一请求错误；
173.存在所述第二请求错误；
174.所述消费数据数量小于或等于第一数量阈值；
175.在第一时长内，所述消费数据数量小于或等于第一数量阈值；
176.所述未消费数量大于或等于第二数量阈值；
177.在第二时长内，所述未消费数据数量大于或等于第二数量阈值；
178.所述未消费数量与所述消费数量的比例大于或等于预设比例；
179.在第三时长内，所述未消费数量与所述消费数量的比例大于或等于预设比例；
180.消息积压率大于或等于比率阈值，所述消息积压率为：在第四时长内，所述未消费数量与所述消息队列对应的数据总量的比值。
181.作为本公开实施例一种可选的实施方式，所述索引服务器为包括多个服务器的服务器集群，所述目标监控信息包括：索引服务状态的监控信息；
182.所述获取模块501，具体用于：
183.获取所述多个服务器的运行状态信息；所述运行状态信息包括以下至少一种：
184.负载率、索引服务的慢查询日志；
185.其中，所述负载率包括：cpu使用率、内存使用率、带宽占用率、磁盘占用率中的至少一种。
186.作为本公开实施例一种可选的实施方式，所述目标报警规则包括以下至少一种：
187.单个服务器的负载率大于或等于第一预设比率；
188.总负载率大于或等于第二预设比率；
189.存在负载差值大于或等于预设差值的两个服务器；
190.存在所述索引服务的慢查询日志；
191.所述索引服务的慢查询日志指示所述索引服务的响应时长大于或等于预设时长。
192.作为本公开实施例一种可选的实施方式，所述目标监控信息包括：索引服务使用的监控信息；
193.所述获取模块501，具体用于：
194.若索引服务使用过程中，出现目标错误，则将所述目标错误记录到日志文件，所述目标错误包括：未连接到所述索引服务器，以及连接所述索引服务器超时中的至少一项；
195.若索引服务使用过程中，保存用户的搜索记录，搜索记录中包括：搜索耗时时长。
196.从所述日志文件中获取所述目标错误记录和所述搜索耗时时长，作为所述索引服务使用的监控信息。
197.作为本公开实施例一种可选的实施方式，所述目标报警规则包括以下至少一种：
198.存在所述目标错误；
199.所述搜索耗时时长大于或等于预设时长。
200.所述获取模块501，具体用于：
201.通过导入第一模拟数据，获取所述导入数据的监控信息；
202.和/或，
203.通过针对第二模拟数据使用索引服务，获取所述索引服务状态的监控信息，和/或，索引服务使用的监控信息。
204.所述输出模块503，具体用于：
205.基于所述报警信息，显示报警界面；所述报警界面中包括至少一个功能控件，所述至少一个功能控件用于触发针对所述至少一个故障的处理操作，其中，每个功能控件用于触发针对一个或多个的故障的处理操作。
206.如图6所示，本公开实施例提供一种监控设备，该监控设备包括：处理器601、存储器602及存储在所述存储器602上并可在所述处理器601上运行的计算机程序，所述计算机程序被所述处理器601执行时实现上述方法实施例中的索引服务器的监控方法的各个过程。且能达到相同的技术效果，为避免重复，这里不再赘述。
207.本发明实施例提供一种计算机可读存储介质，其特征在于，该计算机可读存储介质上存储计算机程序，该计算机程序被处理器执行时实现上述方法实施例中索引服务器的监控方法的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
208.其中，该计算机可读存储介质可以为只读存储器(read-only memory，rom)、随机存取存储器(random access memory，ram)、磁碟或者光盘等。
209.本发明实施例提供一种计算程序产品，该计算机程序产品存储有计算机程序，计算机程序被处理器执行时实现实现上述方法实施例中索引服务器的监控方法的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
210.本领域技术人员应明白，本公开的实施例可提供为方法、系统、或计算机程序产品。因此，本公开可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施
例的形式。而且，本公开可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质上实施的计算机程序产品的形式。
211.本公开中，处理器可以是中央处理单元(central processing unit，cpu)，还可以是其他通用处理器、数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现成可编程门阵列(field-programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
212.本公开中，存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)。存储器是计算机可读介质的示例。
213.本公开中，计算机可读介质包括永久性和非永久性、可移动和非可移动存储介质。存储介质可以由任何方法或技术来实现信息存储，信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。根据本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
214.需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括要素的过程、方法、物品或者设备中还存在另外的相同要素。
215.以上仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。