基于ELK采集日志数据方法和装置与流程

基于elk采集日志数据方法和装置
技术领域
1.本技术涉及数据采集技术领域，特别是涉及一种基于elk采集日志数据方法和装置。


背景技术：

2.随着信息技术的发展，对各种业务类型的日志数据进行采集处理变的越来越重要。在实际过程中，往往使用elk完成日志数据的采集。其中，elk是由elasticsearch+logstash+kibana组合而成的技术简称，elasticsearch是基于json开发和支持restful风格的搜索引擎，logstash是具有搜集数据的采集通道，kibana是灵活的可视化平台。其核心是通过采集管道，将分散在不同采集端的日志信息统一采集到搜索引擎中，并通过可视化平台进行可视化展示。在elk实际使用过程中，当日志量过大且采集速度太快时，向搜索引擎写入的速度往往会超过搜索引擎的写入阈值，进而导致日志数据无法写入搜索引擎。
3.为了解决上述问题，可以先将采集端采集到的日志数据写入kafka消息队列中，再通过采集管道将kafka消息队列中的日志数据写入搜索引擎，来避免上述由于日志量过大且采集速度太快而导致无法写入搜索引擎的问题。
4.然而，当由于磁盘爆满而导致日志数据写入kafka消息队列失败时，会导致无法将日志数据写入kafka消息队列，进而造成采集到的日志数据堆积，影响采集端服务的性能或者导致采集端宕机。


技术实现要素：

5.有鉴于此，本技术提供一种基于elk采集日志数据方法和装置，可以避免消息队列不可用而影响采集端服务的性能或者导致采集端宕机的问题。
6.为达到上述目的，本技术主要提供如下技术方案：
7.第一方面，本技术提供了一种基于elk采集日志数据方法，所述方法包括：
8.根据当前业务，确定采集所述当前业务所产生日志数据的日志采集插件；
9.当所述日志采集插件为预设插件时，确定所述预设插件对应的主用消息队列的状态；
10.根据所述主用消息队列的状态，在所述主用消息队列和备用消息队列中，确定待使用的消息队列，所述主用消息队列和所述备用消息队列设置在不同的位置；
11.将所述预设插件采集的日志数据写入待使用的消息队列中；
12.通过采集管道，将所述消息队列中的日志数据写入搜索引擎，以使对搜索引擎中的日志数据进行分析处理。
13.第二方面，本技术提供了一种基于elk采集日志数据装置，所述装置包括：
14.第一确定单元，用于根据当前业务，确定采集所述当前业务所产生日志数据的日志采集插件；
15.第二确定单元，用于当所述第一确定单元确定的日志采集插件为预设插件时，确
定所述预设插件对应的主用消息队列的状态；
16.第三确定单元，用于根据所述第二确定单元确定的主用消息队列的状态，在所述主用消息队列和备用消息队列中，确定待使用的消息队列，所述主用消息队列和所述备用消息队列设置在不同的位置；
17.第一写入单元，用于将所述预设插件采集的日志数据写入第三确定单元确定的待使用的消息队列中；
18.第二写入单元，用于通过采集管道，将所述第一写入单元写入的消息队列中的日志数据写入搜索引擎，以使对搜索引擎中的日志数据进行分析处理。
19.第三方面，本技术提供了一种终端，该终端用于运行程序，其中，该终端运行时执行该第一方面所述的基于elk采集日志数据方法。
20.第四方面，本技术提供了一种存储介质，该存储介质用于存储计算机程序，其中，该计算机程序运行时控制该存储介质所在设备执行该第一方面所述的基于elk采集日志数据方法。
21.借由上述技术方案，本技术提供了一种基于elk采集日志数据方法和装置，当使用预设插件收集当前业务所产生的日志数据时，先确定预设插件对应的主用消息队列的状态，并根据所述主用消息队列的状态，在所述主用消息队列和备用消息队列中，确定待使用的消息队列，将所述预设插件采集的日志数据写入待使用的消息队列中，进而使得通过采集管道，将所述消息队列中的日志数据写入搜索引擎，以使对搜索引擎中的日志数据进行分析处理。这样，本技术由于根据主用消息队列的状态，在主用消息队列和备用消息队列中，确定待使用的消息队列，可以避免消息队列不可用而影响采集端服务的性能或者导致采集端宕机的问题。
22.上述说明仅是本技术技术方案的概述，为了能够更清楚了解本技术的技术手段，而可依照说明书的内容予以实施，并且为了让本技术的上述和其它目的、特征和优点能够更明显易懂，以下特举本技术的具体实施方式。
附图说明
23.为了更清楚地说明本技术实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
24.图1为本技术公开的一种基于elk采集日志数据方法的流程示意图；
25.图2为本技术公开的又一种基于elk采集日志数据方法的流程示意图；
26.图3为本技术公开的又一种确定待使用的消息队列方法的流程示意图；
27.图4为本技术公开的一种在备用消息队列中确定待使用的消息队列方法的流程示意图；
28.图5为本技术公开的一种确定日志数据是否成功写入主用消息队列方法的流程示意图；
29.图6为本技术公开的一种基于elk采集日志数据装置的结构示意图；
30.图7为本技术公开的又一种基于elk采集日志数据装置的结构示意图。
具体实施方式
31.下面将参照附图更详细地描述本技术的示例性实施例。虽然附图中显示了本技术的示例性实施例，然而应当理解，可以以各种形式实现本技术而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本技术，并且能够将本技术的范围完整的传达给本领域的技术人员。
32.随着信息技术的发展，对各种业务类型的日志数据进行采集处理变的越来越重要。在实际过程中，往往使用elk完成日志数据的采集。其中，elk是由elasticsearch+logstash+kibana组合而成的技术简称，elasticsearch是基于json开发和支持restful风格的搜索引擎，logstash是具有搜集数据的采集通道，kibana是灵活的可视化平台。其核心是通过采集管道，将分散在不同采集端的日志信息统一采集到搜索引擎中，并通过可视化平台进行可视化展示。在elk实际使用过程中，当日志量过大且采集速度太快时，向搜索引擎写入的速度往往会超过搜索引擎的写入阈值，进而导致日志数据无法写入搜索引擎。
33.为了解决上述问题，可以先将采集端采集到的日志数据写入kafka消息队列中，再通过采集管道将kafka消息队列中的日志数据写入搜索引擎，来避免上述由于日志量过大且采集速度太快而导致无法写入搜索引擎的问题。
34.然而，当由于磁盘爆满而导致日志数据写入kafka消息队列失败时，会导致无法将日志数据写入kafka消息队列，进而造成采集到的日志数据堆积，影响采集端服务的性能或者导致采集端宕机。
35.为了解决上述问题，本技术实施例提供了一种基于elk采集日志数据方法，该方法的执行主体可以为日数数据的采集端，该采集端可以为用户终端，也可以为其他电子设备，此处并不限定。其具体执行步骤如图1所示，包括：
36.步骤101，根据当前业务，确定采集当前业务所产生日志数据的日志采集插件。
37.在收集日志数据时，由于不同业务的需求不同，所使用的消息队列不同。例如，当对某业务的日志数据的实时性要求较高时，可以将采集到的日志数据写入redis消息队列。当对某业务的日志数据的可靠性要求较高时，可以将采集到的日志数据写入kafka消息队列。
38.步骤102，当日志采集插件为预设插件时，确定预设插件对应的主用消息队列的状态。
39.预设插件可以对应多个消息队列，这些消息队列包括主用消息队列和备用消息队列，并可以切换使用主用消息队列和备用消息队列。具体为，当待使用的消息队列为主用消息队列，且主用消息队列不可用时，将备用消息队列作为待使用的消息队列，并当待使用的消息队列为备用消息队列，且主用消息队列可用时，将主用消息队列作为待使用的消息队列。也就是说，当待使用的消息队列为主用消息队列，且主用消息队列不可用时，将主用消息队列切换至备用消息队列。并当待使用的消息队列为备用消息队列，且主用消息队列可用时，将备用消息队列切换至主用消息队列。
40.需要说明的是，日志采集插件还可以不是预设插件，例如，日志采集插件为redis插件，该redis插件采集的日志数据只能写入到redis消息队列中，不能写入其他消息队列中。日志采集插件还可以为kafka插件，该redis插件采集的日志数据只能写入到kafka消息队列中，不能写入其他消息队列中。
41.步骤103，根据主用消息队列的状态，在主用消息队列和备用消息队列中，确定待使用的消息队列。
42.其中，主用消息队列和备用消息队列设置在不同的位置。例如，主用消息队列设置在磁盘中，备用消息队列设置在内存中，也可以是主用消息队列设置在服务器a中，备用消息队列设置在服务器b中。备用消息队列可以为一个，也可以为多个。假设备用消息队列为一个，例如，当预设插件为第一插件时，将设置在磁盘中的kafka消息队列确定为主用消息队列，将设置在内存中的redis消息队列确定为备用消息队列；当预设插件为第二插件时，将设置在内存中的redis消息队列确定为主用消息队列，将设置在磁盘中的kafka消息队列确定为备用消息队列。
43.假设备用消息队列为多个，在主用消息队列不可用时，需要在多个备用消息队列中选取出一个备用消息队列，并将该备用消息队列作为待使用的消息队列。在多个备用消息队列中选取出一个消息队列的方法可以为将优先级最高的备用消息队列确定为待使用的消息队列，或者，先对每个备用消息队列的状态进行判断，并在多个备用消息队列中选出状态为可用状态的备用消息队列，在状态为可用状态的备用消息队列中，将优先级最高的备用消息队列确定为待使用的消息队列，或者，当主用消息队列不可用时，获取主用消息队列不可用的原因，并对该原因进行分析，并根据该原因，在多个备用消息队列选取出一个消息队列，并将其作为主用消息队列。例如，主用消息队列为kafka消息队列，当kafka消息队列由于磁盘容量过小而导致写入失败时，在备用消息队列中选取出不消耗磁盘容量的消息队列，例如redis消息队列。
44.本步骤涉及到的redis消息队列和步骤102中当日志采集插件为redis插件时涉及到的redis消息队列可以为同一个消息队列，也可以不为一个消息队列。同理，本步骤涉及到的kafka消息队列和步骤102中当日志采集插件为kafka插件时涉及到的kafka消息队列可以为同一个消息队列，也可以不为一个消息队列。
45.步骤104，将预设插件采集的日志数据写入待使用的消息队列中。
46.步骤105，通过采集管道，将消息队列中的日志数据写入搜索引擎，以使对搜索引擎中的日志数据进行分析处理。
47.在本技术实施例中，当使用预设插件收集当前业务所产生的日志数据时，先确定预设插件对应的主用消息队列的状态，并根据所述主用消息队列的状态，在所述主用消息队列和备用消息队列中，确定待使用的消息队列，将所述预设插件采集的日志数据写入待使用的消息队列中，进而使得通过采集管道，将所述消息队列中的日志数据写入搜索引擎，以使对搜索引擎中的日志数据进行分析处理。这样，由于根据主用消息队列的状态，在主用消息队列和备用消息队列中，确定待使用的消息队列，可以避免消息队列不可用而影响采集端服务的性能或者导致采集端宕机的问题。
48.进一步的，本技术还提供了一种基于elk采集日志数据方法，该方法是对图1所示实施例中的具体介绍，具体步骤如图2所示，包括：
49.步骤201，根据当前业务，确定采集当前业务所产生日志数据的日志采集插件。
50.步骤202，当日志采集插件为预设插件时，确定预设插件对应的主用消息队列的状态。
51.步骤203，当主用消息队列的状态为不可用状态时，获取距当前时间点最近的写入
失败时间点。
52.其中，写入失败时间点为当日志数据未成功写入主用消息队列时所记录的时间点。当预设插件为第一插件时，写入失败时间点为kafka写入失败时间点。当预设插件为第二插件时，写入失败时间点为redis写入失败时间点。
53.在本技术中，当主用消息队列的状态为可用状态时，将主用消息队列确定为待使用的消息队列。当主用消息队列的状态为不可用状态时，获取距当前时间点最近的写入失败时间点。例如，当预设插件为第一插件时，检测kafka消息队列的状态，当kafka消息队列的状态为可用状态时，将kafka消息队列的状态确定为待使用的消息队列。当kafka消息队列的状态为不可用状态时，获取距当前时间点最近的kafka写入失败时间点。当预设插件为第二插件时，检测redis消息队列的状态，当redis消息队列的状态为可用状态时，将redis消息队列的状态确定为待使用的消息队列。当redis消息队列的状态为不可用状态时，获取距当前时间点最近的redis写入失败时间点。
54.步骤204，判断写入失败时间点与当前时间点之差是否小于第一预设时长。
55.例如，当预设插件为第一插件时，判断kafka写入失败时间点与当前时间点之差是否小于第一预设时长。当预设插件为第二插件时，判断redis写入失败时间点与当前时间点之差是否小于第一预设时长。
56.其中，第一插件对应的第一预设时长和第二插件对应的第二预设时长可以相同，也可以不相同，对此并不限定。
57.步骤205，如果是，基于备用消息队列，确定待使用的消息队列。
58.在本步骤的具体实施方式中，当备用消息队列为一个时，将该备用消息队列确定为待使用的消息队列。例如，当预设插件为第一插件时，将redis消息队列确定为待使用的消息队列。当预设插件为第二插件时，将kafka消息队列确定为待使用的消息队列。
59.但当备用消息队列为多个时，可以在多个备用消息队列中选取出一个备用消息队列，并将其确定为待使用的消息队列。在多个备用消息队列中选取出一个备用消息队列的方法可以如步骤103中所述的方法。
60.步骤206，如果否，将主用消息队列确定为待使用的消息队列。
61.在本步骤的具体实施方式中，当写入失败时间点与当前时间点之差大于等于第一预设时长时，可能可以将采集到日志数据写入主用消息队列，因此，可以重新将日志数据写入主用消息队列，也就是将主用消息队列确定为待使用的消息队列。例如，当预设插件为第一插件时，将kafka消息队列确定为待使用的消息队列。当预设插件为第二插件时，将redis消息队列确定为待使用的消息队列。
62.步骤207，将预设插件采集的日志数据写入待使用的消息队列中。
63.在将预设插件采集的日志数据写入步骤206确定主用消息队列时，也可能预设插件采集的日志数据未成功写入主用消息队列，因此，为了保证将采集到日志数据传输至搜索引擎，当检测到预设插件采集的日志数据未成功写入主用消息队列中，可以将采集的日志数据写入备用消息队列中。具体步骤包括：判断采集的日志数据是否成功写入所述主用消息队列；如果是，将所述主用消息队列的状态修改为可用状态；如果否，将采集的日志数据写入备用消息队列中。
64.例如，当预设插件为第一插件时，将采集的日志数据写入kafka消息队列，并判断
采集的日志数据是否成功写入kafka消息队列，如果否，则将采集的日志数据写入redis消息队列。当预设插件为第二插件时，将采集的日志数据写入redis消息队列，并判断采集的日志数据是否成功写入redis消息队列，如果否，则将采集的日志数据写入kafka消息队列。
65.步骤208，通过采集管道，将消息队列中的日志数据写入搜索引擎，以使对搜索引擎中的日志数据进行分析处理。
66.在本技术实施例中，当使用预设插件收集当前业务所产生的日志数据时，先确定预设插件对应的主用消息队列的状态，并根据所述主用消息队列的状态，在所述主用消息队列和备用消息队列中，确定待使用的消息队列，将所述预设插件采集的日志数据写入待使用的消息队列中，进而使得通过采集管道，将所述消息队列中的日志数据写入搜索引擎，以使对搜索引擎中的日志数据进行分析处理。这样，由于根据主用消息队列的状态，在主用消息队列和备用消息队列中，确定待使用的消息队列，可以避免消息队列不可用而影响采集端服务的性能或者导致采集端宕机的问题。
67.进一步的，当备用消息队列为多个时，可以在多个备用消息队列中选取出一个备用消息队列，因此，本技术还提供了又一种确定待使用的消息队列方法，该方法是对图2所示实施例中的步骤205中的“基于备用消息队列，确定待使用的消息队列”的具体介绍，具体步骤如图3所示，包括：
68.步骤301，对每个备用消息队列的状态进行判断，并在多个备用消息队列中选出状态为可用状态的备用消息队列。
69.在本步骤的具体实施方式中，由于有些备用消息队列的状态为不可用状态，因此，需要先对每个备用消息队列的状态进行判断，并在这些备用消息队列中筛选出状态为可用状态的备用消息队列。
70.步骤302，在状态为可用状态的备用消息队列中，确定待使用的消息队列。
71.在本步骤的具体实施方式中，在状态为可用状态的备用消息队列中，随机选取出一个备用消息队列，并将其确定待使用的消息队列。当然也可以使用图4所示的方法确定出待使用的消息队列。
72.进一步的，本技术还提供了一种在备用消息队列中确定待使用的消息队列方法，该方法是对图3所示实施例中的步骤302中的“在状态为可用状态的备用消息队列中，确定待使用的消息队列”的具体介绍，具体步骤如图4所示，包括：
73.步骤401，在状态为可用状态的备用消息队列中，确定每个备用消息队列的优先级。
74.其中，技术人员可以根据当前业务的需要，为每个备用消息队列设置对应的优先级。例如，当前业务的需求为实时性需求，可以按照实时性需求设置每个备用消息队列的优先级。
75.步骤402，将优先级最高的备用消息队列确定为待使用的消息队列
。
76.进一步的，在图1至图4所提供实施例的基础上，本技术还提供了一种确定日志数据是否成功写入主用消息队列方法，具体步骤如图5所示，包括：
77.步骤501，在将预设插件采集的日志数据发送给主用消息队列后，判断在第二预设时长内是否检测到ack消息。
78.其中，ack消息是当日志数据成功写入主用消息队列时，主用消息队列调用ack函
数生成的。第二预设时长是技术人员预先设置的时长。
79.在本步骤的具体实施方式中，在将预设插件采集的日志数据发送给主用消息队列后，并将这些日志数据写入主用消息队列，当将这些日志数据成功写入主用消息队列，主用消息队列会调用预先设置的ack函数，并生成ack消息。如果在第二预设时长内检测到ack消息，则确定日志数据成功写入主用消息队列。如果在第二预设时长内未检测到ack消息，则确定日志数据未成功写入主用消息队列。
80.步骤502，如果否，则确定预设插件采集的日志数据未成功写入主用消息队列，并将当前时间点记录为写入失败时间点。
81.在本步骤的具体实施例中，如果否，则确定预设插件采集的日志数据未成功写入主用消息队列，并当主用消息队列的状态为可用状态，则将主用消息队列的状态修改为不可用状态。
82.当将当前时间点记录为写入失败时间点后，可以将该写入失败时间点进行存储，以便当主用消息队列的状态为不可用状态时获取该写入失败时间点。在将上述写入失败时间点进行存储时，还可以将之前存储的写入失败时间点删除，以节省存储空间。
83.步骤503，如果是，则确定预设插件采集的日志数据成功写入主用消息队列。
84.在本步骤的具体实施例中，如果否，则确定预设插件采集的日志数据成功写入主用消息队列，并当主用消息队列的状态为不可用状态，则将主用消息队列的状态修改为可用状态。
85.在图1至图5所述的实施例的基础上，本技术提供了一种具体的实施方式，具体过程如下:
86.第一步：根据当前业务，确定采集所述当前业务所产生日志数据的日志采集插件。
87.第二步：当预设插件为第一插件时，该第一插件可以为技术人员开发的自定义kafkaandredisoutputplugin插件。在将采集到的日志数据发送之前，先对kafkafailstatus进行检测。如果kafkafailstatus为false，则确定kafka集群的状态为可用状态，通过kafka集群发送日志数据，如果发送失败，则将kafkafailstatus修改为true，并将当前时间点确定为kafkafailtime(kafka写入失败时间点)。其中，kafkafailstatus用于指示kafka集群状态的状态，当kafkafailstatus为false时，kafka集群状态的状态为可用状态。当kafkafailstatus为true时，kafka集群状态的状态为不可用状态。
88.如果kafkafailstatus为true，则获取与当前时间点最近的kafkafailtime，并计算当前时间点与kafkafailtime之差是否大于第一预设时长。如果否，则通过redis节点发送日志数据。如果是，则先通过kafka集群发送日志数据。如果发送失败，再通过redis节点发送日志数据。如果发送成功，则将kafkafailstatus修改为true。
89.自定义kafkaandredisoutputplugin插件，根据kafka集群状态的可用状态和不可用保护时长，进行kafka和redis的智能通道选择，提高性能。当kafka集群发生故障，可立即使用redis节点发送消息，保证消息不丢且及时被发送。
90.当预设插件为第二插件时，该第一插件可以为技术人员开发的自定义redisandkafkaoutputplugin插件。在将采集到的日志数据发送之前，先对redisfailstatus进行检测。如果redisfailstatus为false，则确定redis节点的状态为可用状态，通过redis节点发送日志数据，如果发送失败，则将redisfailstatus修改为true，
并将当前时间点确定为redisfailtime(redis写入失败时间点)。其中，redisfailstatus用于指示redis节点的状态，当redisfailstatus为false时，redis节点的状态为可用状态。当redisfailstatus为true时，redis节点的状态为不可用状态。
91.如果redisfailstatus为true，则获取与当前时间点最近的redisfailtime，并计算当前时间点与redisfailtime之差是否大于第一预设时长，如果否，则通过kafka集群发送日志数据，如果是，则先通过redis节点发送日志数据，如果发送失败，再通过kafka集群发送日志数据。如果发送成功，则将redisfailstatus修改为true。
92.自定义redisandkafkaoutputplugin插件，根据redis的可用状态和不可用保护时长，进行kafka和redis的智能通道选择，提高性能。当redis发送消息通过随机节点方式，当redis节点发生故障，可立即使用kafka集群发送消息，保证消息不丢且及时被发送。
93.当日志采集插件为redis插件时，通过redis节点发送日志数据。
94.当日志采集插件为kafka插件时，通过kafka集群发送日志数据。
95.同时，为了实施上述过程，还需要预先搭建redis节点和kafka集群、开发kafkaandredisoutputplugin插件与redisandkafkaoutputplugin插件、filebeat搭建和elk搭建。具体包括：
96.1、redis多节点搭建
97.由于redis节点大部分淘汰策略往往会导致数据被淘汰，从而造成数据丢失的风险，所以需要禁用其淘汰策略，将淘汰策略设置为noeviction，不进行删除，内存满了直接报错，避免日志丢失。
98.在实际过程中，由于filebeat不支持redis集群部署，但支持loadbalance特性，因此，可以搭建多个redis节点，这样，redis节点越多其性能越高。其中，在部署时启用相同的用户名和密码，或者不配置用户名和密码。
99.2、kafka集群搭建
100.kafka集群根据业务规模选择搭建相适应节点的kafka集群，如果对kafka性能要求较高，可以使用ssd固态硬盘当做日志存储使用的磁盘，集群访问不配置用户名和密码，方便配置和使用。
101.3、开发kafkaandredisoutputplugin插件
102.定义插件所需要配置kafka和redis的host列表，其中，redis的host列表可以支持用户名和密码配置。还要对kafka集群状态进行初始化，以使的初始化kafka集群状态kafkafailstatus为false。通过kafka和redis的配置，实现client的connect功能。
103.4、开发redisandkafkaoutputplugin插件
104.定义插件所需要配置kafka和redis的host列表，其中，redis的host列表可以支持用户名和密码配置。还要对redis节点状态进行初始化，以使的初始化redis节点状态kafkafailstatus为false。通过kafka和redis的配置，实现client的connect功能。
105.对kafkaandredisoutputplugin和redisandkafkaoutputplugin分别进行打包，生成kafkaandredisoutputplugin.so和redisandkafkaoutputplugin.so文件。
106.5、filebeat搭建
107.在需要收集日志的业务服务器部署filebeat，将kafkaandredisoutputplugin.so和redisandkafkaoutputplugin.so放到相应目录，配置filebeat的配置文件，如果需要启
用kafaandredisoutputplugin，则添加参数plugin kafkaandredisoutputplugin.so；如果需要启用redisandkafkaoutputplugin，则添加参数plugin redisandkafkaoutputplugin.so；如果同时需要启用，则需要同时添加两个参数；如果需要单独启用redis，则配置redis output时，loadbalance设置为true。
108.6、elk搭建
109.根据业务日志量大小，搭建合适规模的elk集群，并将kafka和redis配置到logstash。当业务产生日志之后，可以通过kibana进行查看日志，一旦业务发生调整，可以修改filebeat的配置，切换对应的output配置来优化通道，以适应业务和架构的调整。
110.进一步的，作为对上述图1-5所示方法实施例的实现，本技术实施例提供了一种基于elk采集日志数据装置，该装置可以避免消息队列不可用而影响采集端服务的性能或者导致采集端宕机的问题。该装置的实施例与前述方法实施例对应，为便于阅读，本实施例不再对前述方法实施例中的细节内容进行逐一赘述，但应当明确，本实施例中的装置能够对应实现前述方法实施例中的全部内容。具体如图6所示，该装置包括：
111.第一确定单元601，用于根据当前业务，确定采集所述当前业务所产生日志数据的日志采集插件；
112.第二确定单元602，用于当所述第一确定单元601确定的日志采集插件为预设插件时，确定所述预设插件对应的主用消息队列的状态；
113.第三确定单元603，用于根据所述第二确定单元602确定的主用消息队列的状态，在所述主用消息队列和备用消息队列中，确定待使用的消息队列，所述主用消息队列和所述备用消息队列设置在不同的位置；
114.第一写入单元604，用于将所述预设插件采集的日志数据写入第三确定单元603确定的待使用的消息队列中；
115.第二写入单元605，用于通过采集管道，将所述第一写入单元604写入的消息队列中的日志数据写入搜索引擎，以使对搜索引擎中的日志数据进行分析处理。
116.进一步的，如图7所示，所述第三确定单元603，包括：
117.获取模块6031，用于当所述主用消息队列的状态为不可用状态时，获取距当前时间点最近的写入失败时间点，所述写入失败时间点为当日志数据未成功写入所述主用消息队列时所记录的时间点；
118.判断模块6032，用于判断所述获取模块6031获取到的写入失败时间点与当前时间点之差是否小于第一预设时长；
119.第一判断结果模块6033，用于如果判断模块6032的判断结果为是，基于所述备用消息队列，确定待使用的消息队列；
120.第二判断结果模块6034，用于如果判断模块6032的判断结果为否，将所述主用消息队列确定为待使用的消息队列。
121.进一步的，如图7所示，所述装置还包括：
122.第一判断单元606，用于判断采集的日志数据是否成功写入所述主用消息队列；
123.第一判断结果单元607，用于如果第一判断单元606为是，将所述主用消息队列的状态修改为可用状态；如果第一判断单元606为否，将采集的日志数据写入备用消息队列中。
124.进一步的，如图7所示，所述装置还包括：
125.第二判断单元608，用于在将所述预设插件采集的日志数据发送给所述主用消息队列后，判断在第二预设时长内是否检测到ack消息，所述ack消息是当日志数据成功写入所述主用消息队列时，所述主用消息队列调用ack函数生成的；
126.第二判断结果单元609，用于如果第二判断单元608为否，则确定所述预设插件采集的日志数据未成功写入所述主用消息队列，并将当前时间点记录为写入失败时间点；如果第二判断单元608为是，则确定所述预设插件采集的日志数据成功写入所述主用消息队列。
127.进一步的，如图7所示，当所述预设插件为第一插件时，将设置在磁盘中的kafka消息队列确定为所述主用消息队列，将设置在内存中的redis消息队列确定为所述备用消息队列；当所述预设插件为第二插件时，将设置在内存中的redis消息队列确定为所述主用消息队列，将设置在磁盘中的kafka消息队列确定为所述备用消息队列。
128.进一步的，如图7所示，当所述备用消息队列为多个时，所述第三确定单元603，包括：
129.筛选模块6035，用于对每个备用消息队列的状态进行判断，并在多个备用消息队列中选出状态为可用状态的备用消息队列；
130.确定模块6036，用于在筛选模块6035筛选出的状态为可用状态的备用消息队列中，确定待使用的消息队列。
131.进一步的，如图7所示，所述确定模块6036，还用于：
132.在状态为可用状态的备用消息队列中，确定每个备用消息队列的优先级；
133.将优先级最高的备用消息队列确定为待使用的消息队列。
134.进一步的，本技术实施例还提供一种处理器，所述处理器用于运行程序，其中，所述程序运行时执行上述图1-5中所述的基于elk采集日志数据方法。
135.进一步的，本技术实施例还提供一种存储介质，所述存储介质用于存储计算机程序，其中，所述计算机程序运行时控制所述存储介质所在设备执行上述图1-5中所述的基于elk采集日志数据方法。
136.在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
137.可以理解的是，上述方法及装置中的相关特征可以相互参考。另外，上述实施例中的“第一”、“第二”等是用于区分各实施例，而并不代表各实施例的优劣。
138.所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再一一赘述。
139.在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本技术也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本技术的内容，并且上面对特定语言所做的描述是为了披露本技术的最佳实施方式。
140.此外，存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)，存储器包括至
少一个存储芯片。
141.本领域内的技术人员应明白，本技术的实施例可提供为方法、系统、或计算机程序产品。因此，本技术可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
142.本技术是参照根据本技术实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
143.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
144.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
145.在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
146.存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)。存储器是计算机可读介质的示例。
147.计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
148.还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。
149.本领域技术人员应明白，本技术的实施例可提供为方法、系统或计算机程序产品。
因此，本技术可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
150.以上仅为本技术的实施例而已，并不用于限制本技术。对于本领域技术人员来说，本技术可以有各种更改和变化。凡在本技术的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本技术的权利要求范围之内。