一种数据获取方法、设备、系统及存储介质与流程

1.本技术涉及信息技术领域，尤其涉及一种数据获取方法、设备、系统以及计算机可读存储介质。


背景技术：

2.在实际应用中，为了确保多样化云设备的稳定运行、各类型云服务的稳定提供、海量数据请求的稳定响应，需要对云设备、云服务以及数据请求响应过程进行实时监控。在相关技术中，为了对云环境实时监控，通常需要在监控端定义各种告警模板，当物理机设备将其捕获到的告警数据发送至监控端时，监控端就根据接收到的告警数据与告警模板的匹配关系，确定告警数据对应的告警类别。然而，上述告警数据处理方式，在监控端收到的告警数据量较大时，监控端的数据处理负荷激增，且监控端固定的告警模板也导致监控的灵活性不足，也容易导致由于新类型的告警数据无法成功匹配而产生数据丢失。


技术实现要素：

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.本技术还提供了一种数据获取系统，所述数据获取系统包括如前任一实施例所述
的第一设备以及如前任一实施例所述的第二设备。
35.本技术还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如前任一项所述的应用于第一设备的数据获取方法、或如前任一项所述的应用于第二设备的数据获取方法。
36.由以上可知，本技术提供的应用于第一设备的数据获取方法中，第一设备能够通过与至少一个第二设备之间的通信连接，对至少一个第二设备进行监控；在确定与任一第二设备对应的用于供任一第二设备获取至少一种状态数据、并整理状态数据得到携带有类型信息的告警数据的目标格式文件后，通过通信连接将目标格式文件发送至任一第二设备后，还能接收到任一第二设备发送的携带有类型信息的告警数据。
37.如此，本技术提供的应用于第一设备的数据获取方法，能够根据对任一第二设备监控的需要设定对应的目标格式文件，以供第二设备获取所需要的状态数据从而得到与监控需求对应的、携带有类型信息的告警数据，如此，一方面使得第一设备对任一第二设备的监控更加灵活全面，能够降低由于任一第二设备新类型的状态数据无法匹配而导致的数据丢失的概率；另一方面，在第一设备为服务端设备的情况下，还能够缓解相关技术中由监控服务端对告警数据再次进行匹配运算产生的负荷。
附图说明
38.图1为相关技术中告警数据的处理流程示意图；
39.图2为本技术提供的第一种应用于第一设备的数据获取方法的流程示意图；
40.图3为本技术提供的第二种应用于第一设备的数据获取方法的流程示意图；
41.图4为本技术提供的数据获取方法的具体实现流程图；
42.图5为本技术提供的应用于第二设备的数据获取方法的实现流程图；
43.图6为本技术提供的应用于第一设备和第二设备的数据获取方法的流程图；
44.图7为本技术提供的一种第一设备的结构示意图；
45.图8为本技术提供的一种第二设备的结构示意图；
46.图9为本技术提供的一种数据获取系统的结构示意图。
具体实施方式
47.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述。
48.应当理解，此处所描述的具体实施例仅仅用以解释本技术，并不用于限定本技术。
49.本技术涉及信息技术领域，尤其涉及一种数据获取方法、设备、系统以及计算机可读存储介质。
50.图1所示为相关技术中告警数据的处理流程示意图。
51.在图1中，对告警数据的处理可以包括以下步骤：
52.步骤101、根据上级网关分析需求，定义告警模板。
53.步骤102、在执行监控的服务器端设备加载告警模板。
54.步骤103、接收到告警数据时，根据告警数据与告警模板确定模板告警。
55.步骤104、上报模板告警至上级网关。
56.相关技术的以上告警数据处理方法中的告警模板，是以上级网关的分析需求确定的，而非根据实际监控对象的运行特点确定的，因此，这样的告警模板无法实现对每个监控对象差异化的、灵活的运行状态监控，也就无法体现出每个监控对象客户端的实际监控需求。另一方面，在监控对象客户端上报的告警数量激增时，监控端的匹配运算量会激增，并且，若未及时维护和更新告警模板文件，则很容易产生告警漏报的问题，从而可能会丢失一些严重级别的告警数据，或者一些敏感告警数据。
57.为了解决以上问题，本技术实施例提供了一种数据获取方法，该方法降低了第一设备即监控端对告警数据的处理负荷以及告警数据丢失的概率，且能够根据第二设备设定对应的目标格式文件，从而使得第一设备对第二设备的监控更加灵活全面。
58.图2为本技术实施例提供的第一种应用于第一设备的数据获取方法的流程示意图。需要说明的是，应用于第一设备的数据获取方法，可以是由第一设备的处理器来实现的。其中，第一设备的处理器，可以是特定用途集成电路(application specific integrated circuit，asic)、数字信号处理器(digital signal processor，dsp)、数字信号处理装置(digital signal processing device，dspd)、可编程逻辑装置(programmable logic device，pld)、现场可编程逻辑门阵列(field programmable gate array，fpga)、中央处理器(central processing unit，cpu)、控制器、微控制器、微处理器中的至少一种。
59.在一种实施方式中，第一设备，可以是与至少一个第二设备处于同一云平台的、且能够对至少一个第二设备进行监控的电子设备。其中，云平台可以是前文中提到的政务云等，还可以是openstack等云计算平台。第一设备，可以是能够实现对至少一个第二设备中的操作系统运行状态、硬件使用情况、应用程序运行状态、进程和/或线程运行状态等至少之一进行监控的设备。其中，硬件可以包括网卡、端口、硬盘等。
60.在一种实施方式中，第一设备，可以是配置有具备监控功能的环境的电子设备。示例性地，监控功能的环境，可以为ansible。其中，ansible是一种自动化运维工具，其基于python开发，实现了批量系统配置、批量程序部署、批量运行命令等功能。
61.在一种实施方式中，至少一个第二设备的类型可以不同，示例性地，第二设备的类型可以是按照功能来区分的，比如openstack中的控制节点、计算节点。示例性地，任一第二设备，可以安装有能够搜集和获取第二设备运行状态的应用软件的设备。其中，上述应用软件可以包括应用程序监控框。
62.在一种实施方式中，任一第二设备，可以是配置有sensu的设备。其中，sensu是一个开源的基础设施和应用程序监控解决方案，它可以监控服务器、相关服务和应用程序健康状况，并通过第三方集成发送警报和通知。sensu用ruby编写，可以使用rabbitmq或redis来处理消息，它使用redis来存储数据。
63.在一种实施方式中，第一设备对至少一个第二设备进行监控，可以是通过获取至少一个第二设备发送的指定类型的运行状态信息实现的。示例性地，第一设备可以是在满足指定条件时监控第二设备的。其中，指定条件，可以包括以下至少之一：至少一个第二设备的运载负荷超过一预设阈值、至少一个第二设备的指定运行时段、至少一个第二设备的运行模式发生切换、至少一个第二设备与访问客户端之间建立连接的个数超过一指定数值等。
64.如图2所示，本技术实施例提供的数据获取方法，可以包括以下步骤：
65.步骤201、确定与任一第二设备对应的目标格式文件。
66.其中，目标格式文件，用于供任一第二设备获取至少一种状态数据、并整理至少一种状态数据得到携带有类型信息的告警数据。
67.在一种实施方式中，类型信息，可以表示告警数据的类型，还可以是在目标格式文件中定义的标识信息。
68.在一种实施方式中，状态数据，可以表示任一第二设备的运行状态数据、或者任一第二设备的指定类型的运行状态数据、或者任一第二设备指定时段内的运行状态数据、或者任一第二设备满足指定条件时的发送的运行状态数据。
69.在一种实施方式中，状态数据，可以包括第二设备的硬件运行状态数据或软件运行状态数据。其中，硬件运行状态数据，可以包括内存使用率、硬盘利用率、网卡负载率、端口占用情况等；软件运行状态数据，可以包括操作系统运行状态数据、应用软件运行状态数据、进程运行状态数据、线程运行状态数据等。
70.在一种实施方式中，目标格式文件中，可以包含有至少一种类型信息。其中，类型信息可以表示第二设备的设备类型、状态数据的类型的至少之一；还可以包括对至少一种状态数据进行整理、以得到携带有类型信息的告警数据的规则；还可以包括获取至少一种状态数据的条件和时机。示例性地，不同的第二设备对应的目标格式文件可以不同。
71.步骤202、通过通信连接，将目标格式文件发送至任一第二设备。
72.在一种实施方式中，将目标格式文件发送至任一第二设备，可以是在目标格式文件确定之后立即执行的操作，或者，可以是在任一第二设备就绪之后才执行的操作。
73.步骤203、通过通信连接，获取任一第二设备发送的告警数据。
74.在一种实施方式中，任一第二设备发送的告警数据，可以是依据目标格式文件对状态数据进行整理之后得到的数据，其可以携带有与状态数据对应的原始状态信息、该状态信息对应的告警级别、该状态信息对应的类型信息、该状态信息的来源等信息。
75.由以上可知，本技术实施例提供的应用于第一设备的数据获取方法，第一设备能够通过与至少一个第二设备之间的通信连接，对至少一个第二设备进行监控；在确定与任一第二设备对应的用于供任一第二设备获取至少一种状态数据、并整理状态数据得到携带有类型信息的告警数据的目标格式文件后，可以通过通信连接将目标格式文件发送至任一第二设备，还能接收到任一第二设备发送的携带有类型信息的告警数据。
76.如此，本技术实施例提供的应用于第一设备的数据获取方法，能够根据对任一第二设备监控的需要设定对应的目标格式文件，以供第二设备获取所需要的状态数据从而得到与监控需求对应的告警数据，这样一来，一方面使得第一设备对任一第二设备的监控更加灵活全面，能够降低由于任一第二设备新类型的状态数据无法匹配而导致的数据丢失的概率；另一方面，在第一设备为服务端设备的情况下，还能够缓解相关技术中由监控服务端对告警数据再次进行匹配运算产生的负荷。
77.基于前述实施例，本技术实施例提供了一种应用于第一设备的数据获取方法。
78.图3所示为本技术实施例提供的第二种应用于第一设备的数据获取方法的流程示意图。该数据获取方法可以包括以下步骤：
79.步骤301、获取至少一个功能配置文件。
80.其中，每一功能配置文件，包括任一第二设备获取任一类型的状态数据、以及对任
一类型的状态数据进行整理的规则。
81.在一种实施方式中，每一功能配置文件，可以包括至少一种类型的状态数据的获取规则以及整理规则。
82.在一种实施方式中，状态数据的获取规则，可以包括获取状态数据的条件和时机；或者可以包括获取状态数据的类型范围的确定规则；或者包括状态数据的获取方式确定的规则。
83.在一种实施方式中，状态数据的获取规则，可以通过状态数据获取脚本的方式来体现。示例性地，状态数据获取脚本可以对待获取的状态数据的类型、条件、时机、方式、状态数据存储位置等至少之一进行约束的规则。示例性地，状态数据的获取规则，可以包括多条获取规则。比如，第一获取规则，可以表示获取状态数据的时机；第二获取规则，可以表示获取状态数据的条件等。
84.在一种实施方式中，状态数据的整理规则，可以包括以下至少之一：对状态数据进行筛选并整理的规则、对状态数据进行量化以及根据量化结果进行分类的规则、将类型信息添加至状态数据的整理结果的规则。示例性地，类型信息可以以标识信息的形式体现，并且，该标识信息可以包含在每一功能配置文件中。
85.在一种实施方式中，每一功能配置文件，可以是通过第一设备中安装的具备监控功能的应用或者系统、或者第一设备中安装的自动化监控工具确定的。示例性地，每一功能配置文件，可以是通过第一设备中安装的ansible获取的。示例性地，每一功能配置文件可以为在ansible中定义的*.yml文件。
86.示例性地，first.yml文件可以以如下方式体现：
87.{name:mem_usage，command:"check-memory-percent"，type:"内存"，alarm_title:"内存利用率超过阈值"，oid:1.3.6.1.4.1.49022.2.21.2.1.5}
88.在上述代码中，name:mem_usage、command:"check-memory-percent"、type:"内存"、alarm_title:"内存利用率超过阈值"以及oid:1.3.6.1.4.1.49022.2.21.2.1.5均以键值对的形式出现。
89.其中，name:mem_usage，表示当前功能配置文件中需要获取的状态参数的name为“mem_usage”；command:"check-memory-percent"，表示当前功能配置文件中需要执行的command为“check-memory-percent”；type:"内存"表示当前功能配置文件中获取的状态参数的type为“内存”；alarm_title:"内存利用率超过阈值"，用于表示当前功能配置文件中获取状态数据对应的alarm_title为“内存利用率超过阈值”；oid:1.3.6.1.4.1.49022.2.21.2.1.5，表示当前功能配置文件获取到的状态参数的对象标识符(object identification，oid)为“1.3.6.1.4.1.49022.2.21.2.1.5”。
90.在一种实施方式中，command对应的check-memory-percent，可以为底层监控指令，或者可以自动执行的脚本、或者满足一定条件能够被触发执行的脚本。
91.在一种实施方式中，可以定义多个*.yml文件，比如，first.yml、second.yml以及third.yml等。这些*.yml文件中分别对唯一的一种状态数据进行约束。
92.步骤302、基于至少一个功能配置文件，确定目标格式文件。
93.在一种实施方式中，基于至少一个功能配置文件，确定目标格式文件，可以是将至少一个功能配置文件进行组合，并对组合结果进行精简合并处理，从而确定目标格式文件。
w85-c 90"，表示获取监控数据的command为“/opt/sensu/embedded/bin/ruby/opt/sensu/embedded/bin/check-cpu.rb-w 85-c 90”；type:"cpu"，表示监控的状态数据的type为“cpu”；alarm_title:"cpu利用率超过阈值"，表示状态数据对应的告警数据的alarm_title为“cpu利用率超过阈值”；oid:1.3.6.1.4.1.49022.2.15.2.1.3.48，表示告警数据对应的oid为“1.3.6.1.4.1.49022.2.15.2.1.3.48”。
111.在上述代码中，name:disk_usage，表示状态数据的name为“disk_usag”；command:"/opt/sensu/embedded/bin/ruby/opt/sensu/embedded/bin/check-disk-usage.rb-t xfs,ext4-w 85"，表示获取监控数据的command为“/opt/sensu/embedded/bin/ruby/opt/sensu/embedded/bin/check-disk-usage.rb-t xfs,ext4-w 85”；type:"磁盘"，表示监控的状态数据的type为“磁盘”；alarm_title:"磁盘空间利用率超过阈值"，表示状态数据对应的告警数据的alarm_title为“磁盘空间利用率超过阈值”；oid:1.3.6.1.4.1.49022.2.21.2.1.4，表示告警数据对应的oid为“1.3.6.1.4.1.49022.2.21.2.1.4”。
112.在一种实施方式中，在功能配置文件为*.yml文件的条件下，对应的第一个目标格式文件ff.yml，可以是如下形式：
[0113][0114]
在上述代码中，name:interface，表示监控的状态数据的name为“interface”；command:"/opt/sensu/embedded/bin/check_linux_bonding
‑‑
disable-sysfs"，表示获取监控数据的command为“/opt/sensu/embedded/bin/check_linux_bonding
‑‑
disable-sysfs”；type:"网卡"，表示监控的状态数据的type为“网卡”；alarm_title:"网卡异常"，表示状态数据对应的告警数据的alarm_title为“网卡异常”；oid:1.3.6.1.4.1.49022.2.21.2.1.3，表示告警数据对应的oid为“1.3.6.1.4.1.49022.2.21.2.1.3”。
[0115]
在上述代码中，name:swap_usage，表示状态数据name为“swap_usage”；command:"/opt/sensu/embedded/bin/ruby/opt/sensu/embedded/bin/check-swap-perc ent.rb-w 85-c 90"，表示获取监控数据的“command/opt/sensu/embedded/bin/ruby/opt/sensu/embedded/bin/check-swap-percent.rb-w 85-c 90”；type:"swap"，表示监控的状态数据的type为“swap”；alarm_title:"swap利用率超过阈值"，表示状态数据对应的告警数据的alarm_title为“swap利用率超过阈值”；oid:1.3.6.1.4.1.49022.2.15.2.1.3.51，表示告警数据对应的oid为“1.3.6.1.4.1.49022.2.15.2.1.3.51”。
[0116]
步骤303、通过通信连接，将目标格式文件发送至任一第二设备。
[0117]
示例性地，步骤303还可以通过以下方式来实现：
[0118]
在第一设备通过通信连接、检测到任一第二设备处于环境就绪状态的情况下，通过通信连接，将目标格式文件发送至任一第二设备。
[0119]
其中，环境就绪状态，表示任一第二设备处于已经配置获取状态数据环境的状态。
[0120]
在一种实施方式中，环境就绪状态，可以表示任一第二设备已经成功安装有捕获至少一种任一类型的状态数据的应用程序，且该应用程序已经处于就绪状态；或者任一第二设备已经成功配置有捕获至少一种任一类型的状态数据的框架，且该框架能够正常运行；或者任一第二设备已经成功安装了具备监控功能的客户端，比如sensu客户端，且sensu客户端能够正常运行。
[0121]
在一种实施方式中，通过通信连接，将目标格式文件发送至任一第二设备的过程中，目标格式文件，可以根据第一设备中配置的监控环境与任一第二设备中配置的监控环境进行转换，得到格式更加简洁的数据。
[0122]
在一种实施方式中，更加简洁的格式，可以是轻量级的数据交换格式。更加简洁的格式，可以是javascript对象简谱(javascript object notation，json)。
[0123]
示例性地，一种可能的json格式的数据如下所示：
[0124][0125][0126]
在上述代码中，所有数据都是以键值对的形式存储的，比如，checks键，对应于前述文件中的关键词checks，其对应的值为：
[0127][0128]
在上述代码中，command、interval、handler、alarm_type、alarm_oid、standalone均为json数据格式中的键，以上各个键的冒号后面的数据，表示各个键对应的值。
[0129]
在上述代码中，item对应于目标格式文件中的关键词common中的每一{}中的数据。其中，item.name与目标格式文件中每一{}中关键词name对应的键值相同，示例性地，item.name可以为“cpu_usage”；item.command与目标格式文件中每一{}中关键词command对应的键值相同，示例性地，item.command可以为“/opt/sensu/embedded/bin/ruby/opt/sensu/embedded/bin/check-cpu.rb-w 85-c 90”；item.type与目标格式文件中每一{}中关键词type对应的键值相同，示例性地，item.type可以为“cpu”；item.alarm_title与目标格式文件中每一{}中关键词alarm_title对应，示例性地，item.alarm_title可以为“cpu利用率超过阈值”；item.oid可以与目标格式文件中每一{}中关键词oid对应的键值相同，示例性地，item.oid可以为“1.3.6.1.4.1.49022.2.15.2.1.3.48”；。
[0130]
在上述代码中，interval对应的值为300，可以表示状态数据获取的时间间隔，其单位可以为毫秒；handler对应的值为"snmptrap"，表示向第一设备发送的状态数据打包成简单网络管理协议(simple network management protocol，snmp)trap消息格式。其中，snmp是tcp/ip协议族的一部分，通过snmp可以使设备之间能够方便地交换管理信息；standalone对应的值为true，可以表示第二设备中的监控框架能够独立运行。
[0131]
示例性地，与上述json格式对应的实际json数据可以如下所示：
[0132]
上述代码中各个键值对的含义前文已经说明，此处不再赘述。
[0133]
与*.yml文件相比，json格式更加简洁，数据构成也更加清晰，从而为任一第二设备获取状态数据并填充状态数据提供了便利。
[0134]
示例性地，本技术实施例提供的数据获取方法还可以通过步骤b1-b2实现对任一第二设备环境状态的配置：
[0135]
步骤b1、获取任一第二设备的设备标识。
[0136]
在一种实施方式中，任一第二设备的设备标识，可以包括任一第二设备的物理地址、或任一第二设备的ip地址、或任一第二设备的用户名和密码。
[0137]
在一种实施方式中，任一第二设备的设备标识，可以是由任一第二设备发送至第一设备的，或者根据需求配置文件获取的。
[0138]
在一种实施方式中，可以将任一第二设备的设备标识，添加在*.yml文件中的host字段中，如下所示：
[0139]
[1]
[0140]
83.245.2.33
[0141]
[2]
[0142]
83.245.2.32
[0143]
[physicalservers:children]
[0144]1[0145]2[0146]
在上述代码中，[1]83.245.2.33表示第一台第二设备的ip地址为83.245.2.33；[2]83.245.2.32表示第二台第二设备的ip地址为83.245.2.32；[physicalservers:children]1 2表示physicalservers组中包括上述第一台第二设备以及第二台第二设备，也就是说，当前第一设备的监控目标包括第一台第二设备以及第二台第二设备。
[0147]
步骤b2、基于设备标识，通过通信连接，向任一第二设备发送环境配置指令。
[0148]
其中，环境配置指令，用于供任一第二设备配置获取至少一种任一类型的状态数据的环境。
[0149]
在一种实施方式中，环境配置指令中，可以包括任一第二设备能够配置的环境，比如，任一第二设备能够配置sensu客户端。也就是说，不同的第二设备所配置的环境，可以是根据第二设备的实际参数来确定的。
[0150]
示例性地，在第一设备中部署有ansible的条件下，向任一第二设备发送环境配置指令，可以是通过ansible的批量部署来实现的。其中，第一设备通过ansible执行的批量部署操作，可以根据对任一第二设备的具体监控需求进行。
[0151]
示例性地，具体监控需求，包括任一第二设备的属性参数，其中，任一第二设备的属性参数，可以包括任一第二设备的硬件属性参数和/或软件属性参数。硬件属性参数，包括任一第二设备的硬件配置，比如cpu主频、内存容量、硬盘、网卡、端口等；软件属性参数，包括任一第二设备所安装的操作系统、需要监控的目标应用软件、需要监控的目标线程、需要监控的目标进程等。如此，可以实现第一设备对多个第二设备的针对性的监控。
[0152]
在一种实施方式中，第一设备通过ansible的批量部署，可以指示每一第二设备完成sensu客户端的安装，从而使得每一第二设备能够成功配置获取至少一种任一类型状态数据的环境。
[0153]
在一种实施方式中，第一设备发送的环境配置指令，可以是与发送目标格式文件同时执行的。示例性地，目标格式文件可以作为环境配置指令的附加参数，发送至任一第二设备，在第二设备基于环境配置指令执行环境配置操作之后，就可以直接解析目标格式文件。
[0154]
通过以上操作，当第二设备根据第一设备发送的环境配置指令，完成获取至少一种任一类型的状态数据的环境之后，第一设备就可以通过通信连接检测到第二设备处于环境就绪状态。
[0155]
步骤304、通过通信连接，获取任一第二设备发送的告警数据。
[0156]
图4为本技术实施例提供的数据获取方法的具体实现流程图。
[0157]
如图4所示，在第一设备中安装有ansible、功能配置文件以及目标格式文件为*.yml、任一第二设备中安装的是sensu客户端的条件下，本技术实施例提供的数据获取方法的具体实现流程图可以包括以下步骤：
[0158]
步骤401、在第一设备中安装ansible。
[0159]
步骤402、创建功能配置文件(*.yml)。
[0160]
示例性地，功能配置文件的个数可以有多个。
[0161]
步骤403、获取每一第二设备对应的目标格式文件(*.yml)。
[0162]
示例性地，每一第二设备对应的目标格式文件可以各不相同。
[0163]
步骤404、定义host字段。
[0164]
示例性地，定义host字段可以确定第一设备的监控对象即第二设备。
[0165]
通过步骤403以及步骤404的操作，就可以确定任一第二设备的监控角色，即实现对至少一个第二设备的差异化监控。
[0166]
步骤405、执行ansible指令安装sensu客户端。
[0167]
示例性地，执行ansible指令安装sensu客户端，可以是第一设备指示任一第二设备执行的操作。
[0168]
步骤406、完成安装。
[0169]
示例性地，完成安装可以表示任一第二设备中成功安装sensu，且任一第二设备成功安装sensu的信息，可以是由第二设备发送至第一设备的。
[0170]
至此，第一设备与至少一个任一第二设备之间的监控环境、获取状态数据的环境被配置完成。
[0171]
由以上可知，本技术实施例提供的数据获取方法，应用于第一设备时，首先获取表示包括任一第二设备获取任一类型的状态数据、以及对任一类型的状态数据进行整理的规则的至少一个功能配置文件，基于至少一个功能配置文件确定用于供任一第二设备获取至少一种状态数据、并整理至少一种状态数据得到携带有类型信息的告警数据的目标格式文件，然后通过第一设备与任一第二设备之间的通信连接，将目标格式文件发送至任一第二设备，再获取由任一第二设备发送的告警数据。
[0172]
由此，本技术实施例提供的数据获取方法，在第一设备中确定与任一第二设备对应的目标格式文件并发送至任一第二设备，以供任一第二设备获取状态数据并整理得到携带有类型信息的告警数据，一方面降低了第一设备在接收到告警数据之后再执行类型匹配的计算量，另一方面实现了针对任一第二设备的灵活的、针对性强的监控；并且，根据任一第二设备获取的目标格式文件，也使得降低了任一第二设备中新类型的告警数据的遗漏概率。
[0173]
基于前述实施例，本技术实施例提供了一种应用于第二设备的数据获取方法。第一设备与第二设备之间建立有通信连接，第一设备能够通过通信连接，对第二设备进行监控。
[0174]
如图5所示为本技术实施例提供的应用于第二设备的数据获取方法的实现流程图。该方法可以通过第二设备的处理器来实现。
[0175]
其中，第二设备的处理器，可以是特定用途集成电路asic、dsp、dspd、pld、fpga、cpu、控制器、微控制器、微处理器中的至少一种。
[0176]
在图5中，本技术实施例提供的应用于第二设备的数据获取方法，可以包括以下步骤：
[0177]
步骤501、通过通信连接，接收第一设备发送的目标格式文件。
[0178]
其中，目标格式文件，是由第一设备确定的、用于供第二设备获取至少一种状态数据、并整理至少一种状态数据得到携带有类型信息的告警数据。
[0179]
步骤502、基于目标格式文件，获取至少一种状态数据，并对至少一种状态数据进行整理，得到告警数据。
[0180]
在一种实施方式中，基于目标格式文件，获取至少一种状态数据，并对至少一种状态数据进行整理，得到告警数据，可以是通过以下方式实现的：
[0181]
对目标格式文件进行整合，得到告警模板。其中，告警模板，可以是相对于目标格式文件的格式更加简洁的数据。示例性地，告警模板，可以是json数据。并且，在json数据中携带有目标格式文件中的每一有效数据。示例性地，对目标格式文件进行整合，得到告警模板，可以是在第二设备中环境配置成功后就执行的。
[0182]
步骤503、通过通信连接，发送告警数据至第一设备。
[0183]
由以上可知，本技术提供的应用于第二设备的数据获取方法，第二设备与第一设备之间建立有通信连接，第一设备能够通过该通信连接对第二设备进行监控，第二设备能够通过通信连接，接收第一设备发送的目标格式文件，并基于目标格式文件获取至少一种状态数据，然后对至少一种状态数据进行整理，得到告警数据，再将告警数据发送至第一设备。
[0184]
如此，本技术实施例提供的应用于第二设备的数据获取方法，第二设备在接收到第一设备发送的目标格式文件之后，能够根据目标格式文件来获取状态数据，并整理状态数据，从而实现了第一设备对第二设备的灵活的、有针对性的监控；并且，由于目标格式文件是与第二设备对应的，因此，也降低了第二设备中新类型的状态数据丢失的概率；再者，由第二设备对状态数据进行整理得到携带有类型信息的告警数据后，再发送至第一设备，也降低了第一设备在接收到每一状态数据后，再对状态数据进行类型匹配才能得到准确类型的告警数据的运算量。
[0185]
在一些实施例中，步骤501之前，第二设备还可以通过通信连接，接收第一设备发送的环境配置指令。基于环境配置指令，配置获取状态数据的环境。
[0186]
其中，环境配置指令，用于供第二设备配置获取至少一种任一类型的状态数据的环境。
[0187]
在一些实施例中，步骤502可以通过步骤c1-步骤c3来实现：
[0188]
步骤c1、基于目标格式文件，获取第一规则和第二规则。
[0189]
其中，第一规则，包括第二设备获取至少一种状态数据的方式；第二规则，包括对至少一种状态数据整理的规则。
[0190]
在一种实施方式中，基于目标格式文件，获取第一规则和第二规则，可以是基于目标格式文件，获取告警模板，再基于告警模板获取第一规则和第二规则。
[0191]
在一种实施方式中，第一规则，可以包括获取的状态数据的类型、时机、条件等信息；第二规则，可以包括对至少一种状态数据进行整理的脚本或方法的至少之一。
[0192]
步骤c2、基于第一规则，获取至少一种状态数据。
[0193]
在一种实施方式中，基于第一规则，获取至少一种状态数据，可以是基于获取的状态数据的类型、时机、条件等信息，获取至少一种状态数据。
[0194]
步骤c3、基于第二规则，对至少一种状态数据中的每一类型的状态数据进行整理，得到告警数据。
[0195]
在一种实施方式中，告警数据，可以是基于对至少一种状态数据进行整理的脚本或方法，并依据该脚本或方法，对至少一种状态数据进行整理，从而得到告警数据。
[0196]
在一种实施方式中，第二设备得到的告警数据中携带有告警级别、告警类型、第二设备标识、告警发生的时间等信息。
[0197]
基于前述实施例，本技术实施例提供了应用于第一设备和第二设备的数据获取方法。图6所示为本技术实施例提供的应用于第一设备601和第二设备602的数据获取方法的流程图。
[0198]
在图6中，首先，第一设备601与第二设备602之间建立通信连接；其次，第一设备601执行状态检测，以确定第二设备602是否处于环境就绪状态；然后，在检测到第二设备处
于环境就绪状态的情况下，第一设备601向第二设备602发送目标格式文件；最后，第二设备602向第一设备301发送告警数据，示例性地，第二设备602接收到目标格式文件后，基于目标格式文件获取状态数据，并根据状态数据得到告警数据。
[0199]
由以上可知，本技术实施例提供的应用于第一设备601和第二设备602的数据获取方法，降低了第一设备对告警数据类型匹配的运算量；实现了对第二设备的灵活的、针对性更强的监控、减少了对第二设备中新类型的状态数据丢失的概率。
[0200]
基于前述实施例，图7为本技术实施例提供的一种第一设备601的结构示意图。本技术实施例提供的一种第一设备601，与至少一个第二设备602之间建立有通信连接，对至少一个第二设备602进行监控；第一设备包括：第一处理模块701、第一发送模块702和第一接收模块703；其中：
[0201]
第一处理模块701，用于确定与任一第二设备对应的目标格式文件；其中，目标格式文件，用于供任一第二设备获取至少一种状态数据、并整理至少一种状态数据得到携带有类型信息的告警数据；
[0202]
第一发送模块702，用于通过通信连接，将目标格式文件发送至任一第二设备。
[0203]
第一接收模块703，用于通过通信连接，获取任一第二设备发送的告警数据。
[0204]
在一些实施方式中，第一处理模块701，用于获取至少一个功能配置文件；其中，每一功能配置文件，包括任一第二设备获取任一类型的状态数据、以及对任一类型的状态数据进行整理的规则。
[0205]
第一处理模块701，还用于基于至少一个功能配置文件，确定目标格式文件。
[0206]
在一些实施方式中，第一处理模块701，用于获取需求配置文件；其中，需求配置文件，表示任一第二设备获取至少一种状态数据的需求数据。
[0207]
第一处理模块701，还用于基于需求配置文件，对至少一个功能配置文件进行整合，得到整合结果；基于整合结果，确定目标格式文件。
[0208]
在一些实施方式中，第一发送模块702，用于在第一设备通过通信连接、检测到任一第二设备处于环境就绪状态的情况下，通过通信连接，将目标格式文件发送至任一第二设备；其中，环境就绪状态，表示任一第二设备处于已经配置获取至少一种任一类型的状态数据环境的状态。
[0209]
需要说明的是，示例性地，第一处理模块701、第一发送模块702以及第一接收模块703，可以通过第一设备的处理器来实现，具体的，上述处理器可以为特定用途集成电路asic、dsp、dspd、pld、fpga、cpu、控制器、微控制器、微处理器中的至少一种。可以理解地，用于实现上述处理器功能的电子器件还可以为其它，本技术实施例不作具体限定。
[0210]
如此，本技术实施例提供的第一设备601，能够根据对任一第二设备602监控的需要设定对应的目标格式文件，以供第二设备602获取所需要的状态数据从而得到与监控需求对应的告警数据，一方面使得第一设备601对任一第二设备602的监控更加灵活全面，还能够降低由于任一第二设备602新类型的状态数据无法匹配而导致的数据丢失的概率；另一方面，在第一设备601为服务端设备的情况下，还能够缓解相关技术中由监控服务端对接收到的告警数据再次进行匹配运算产生的负荷。
[0211]
基于前述实施例，本技术提供了一种第二设备602。图8所示为本技术实施例提供的一种第二设备602的结构示意图。
[0212]
在图8中，第二设备602与第一设备601之间建立有通信连接；第二设备602包括第二接收模块801、第二处理模块802以及第二发送模块803；其中：
[0213]
第二接收模块801，用于通过通信连接，接收第一设备发送的目标格式文件；其中，目标格式文件，是由第一设备确定的、用于供第二设备获取至少一种状态数据、并整理至少一种状态数据得到携带有类型信息的告警数据；
[0214]
第二处理模块802，用于基于目标格式文件，获取至少一种状态数据，并对至少一种状态数据进行整理，得到告警数据；
[0215]
第二发送模块803，用于通过通信连接，发送告警数据至第一设备。
[0216]
在一些实施方式中，第二处理模块802，用于基于目标格式文件，获取第一规则和第二规则；其中，第一规则，包括第二设备获取至少一种状态数据的方式；第二规则，包括对至少一种状态数据整理的规则；
[0217]
第二处理模块802，还用于基于第一规则，获取至少一种状态数据；基于第二规则，对至少一种状态数据中的每一类型的状态数据进行整理，得到告警数据。
[0218]
需要说明的是，示例性地，第二接收模块801、第二处理模块802以及第二发送模块803，可以通过第二设备的处理器来实现，具体的，上述处理器可以为特定用途集成电路asic、dsp、dspd、pld、fpga、cpu、控制器、微控制器、微处理器中的至少一种。可以理解地，用于实现上述处理器功能的电子器件还可以为其它，本技术实施例不作具体限定。
[0219]
本技术实施例提供的第二设备602，在接收到第一设备601发送的目标格式文件之后，能够根据目标格式文件来获取状态数据，并整理状态数据，从而实现了第一设备601对第二设备602的灵活的、有针对性的监控；并且，由于目标格式文件是与第二设备602对应的，因此，也降低了第二设备602中新类型的状态数据丢失的概率；再者，由第二设备602对状态数据进行整理得到携带有类型信息的告警数据后，再发送至第一设备601，也降低了第一设备601在接收到每一状态数据后，再对状态数据进行类型匹配才能得到准确类型的告警数据的运算量。
[0220]
基于前述实施例，本技术实施例提供了一种数据获取系统9。图9为本技术实施例提供的一种数据获取系统9的结构示意图。如图9所示，该数据获取系统9包括如前任一实施例所述的第一设备601以及第二设备602。
[0221]
基于前述实施例，本技术实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现前任一项应用于第一设备的数据获取方法、或任一项应用于第二设备的数据获取方法。
[0222]
在一些实施例中，本发明实施例提供的装置具有的功能或包含的模块可以用于执行上文方法实施例描述的方法，其具体实现可以参照上文方法实施例的描述，为了简洁，这里不再赘述。
[0223]
上文对各个实施例的描述倾向于强调各个实施例之间的不同之处，其相同或相似之处可以互相参考，为了简洁，本文不再赘述。
[0224]
本发明所提供的各方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。
[0225]
本发明所提供的各产品实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的产品实施例。
[0226]
本发明所提供的各方法或设备实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的方法实施例或设备实施例。
[0227]
需要说明的是，上述计算机可读存储介质可以是只读存储器(read only memory，rom)、可编程只读存储器(programmable read-only memory，prom)、可擦除可编程只读存储器(erasable programmable read-only memory，eprom)、电可擦除可编程只读存储器(electrically erasable programmable read-only memory，eeprom)、磁性随机存取存储器(ferromagnetic random access memory，fram)、快闪存储器(flash memory)、磁表面存储器、光盘、或只读光盘(compact disc read-only memory，cd-rom)等存储器；也可以是包括上述存储器之一或任意组合的各种电子设备，如移动电话、计算机、平板设备、个人数字助理等。
[0228]
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其它变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其它要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
[0229]
上述本技术实施例序号仅仅为了描述，不代表实施例的优劣。
[0230]
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本技术的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本技术各个实施例所描述的方法。
[0231]
本技术是参照根据本技术实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其它可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其它可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0232]
这些计算机程序指令也可存储在能引导计算机或其它可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0233]
这些计算机程序指令也可装载到计算机或其它可编程数据处理设备上，使得在计算机或其它可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其它可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0234]
以上仅为本技术的优选实施例，并非因此限制本技术的专利范围，凡是利用本技术说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其它相关的技术领域，均同理包括在本技术的专利保护范围内。