CN113055490B - 数据的存储方法及装置 - Google Patents

Abstract

本发明提供了一种数据的存储方法及装置，包括：获取多个业务应用上传的日志消息；使用第一组件将日志消息转化为指标格式的第一指标数据，其中，指标格式是能够被目标实例抓取的数据格式；将第一指标数据发送至目标集群，以通过目标集群存储所述第一指标数据。通过本发明，解决了Promtheus难以管理大量数据的问题。

Description

数据的存储方法及装置

技术领域

本发明涉及通信领域，具体而言，涉及一种数据的存储方法及装置。

背景技术

在采集数据量较小的业务场景下，单实例Prometheus是及数据采集、查询与警报一体化的解决方案。如果数据量大一些会采用切分实例的方式来解决问题，此时数据的查询便需要根据业务路由到不同的Prometheus实例上。维护压力还不是很大，然而当数据量再变大，需要管理几十甚至上百的Prometheus实例时，通过手动路由的方式来管理数据查询便不再是最优的解决方案，并且无法紧急扩容甚至会导致内存溢出。因此会产生一些列连锁反应。对Prometheus合理分片、统一数据出口、数据存储规划，在大业务场景下是不得不面对的问题。

使用Prometheus过程中运维场景主要有两类，其一是伸缩Prometheus实例，第二是Promtheus扩容。这两个场景暴露了4个主要问题：实例伸缩缓慢，Promtheus实例同时承担了数据写入和查询的责任，当查询压力大时，无法根据需求快速伸缩；配置查询繁琐，统一查询层需要路由多Promtheus实例，新增实例需要手动配置路由信息，非常繁琐；数据丢失严重，由于资源限制，Promtheus都是单副本，实例挂了就意味着数据丢失，并且由于启动慢更是加重了数据丢失的问题；容量规划滞后，往往是实例先发生内存溢出再扩容，而这也意味着数据已发生丢失。

针对上述问题，目前尚未存在有效的解决方案。

发明内容

本发明实施例提供了一种数据的存储方法及装置，以至少解决相关技术中Promtheus难以管理大量数据的问题。

根据本发明的一个实施例，提供了一种数据的存储方法，包括：获取多个业务应用上传的日志消息；使用第一组件将所述日志消息转化为指标格式的第一指标数据，其中，所述指标格式是能够被目标实例抓取的数据格式；将所述第一指标数据发送至目标集群，以通过所述目标集群存储所述第一指标数据。

可选地，使用第一组件将所述日志消息转化为指标格式的第一指标数据，包括：对所述多个业务应用上传的日志消息进行清洗，得到待转化日志消息；将所述待转化日志消息转化为所述第一指标数据。

可选地，在将所述待转化日志消息转化为所述第一指标数据之后，所述方法还包括：将所述指标数据记录在第一组件，其中，所述第一组件中记录了历史指标数据；通过所述第一组件对所述指标数据和所述历史指标数据的状态进行维护。

可选地，所述方法还包括：通过所述目标实例在配置文件中抓取第二指标数据，其中，所述配置文件定时请求自定义配置和附件信息，并将所述自定义配置和所述附件信息渲染为目标实例的标准配置。

可选地，所述方法还包括：在第一时间间隔到达时，将所述目标集群中存储的所述第一指标数据上传至存储中心，以通过所述存储中心存储所述第一指标数据；在第二时间间隔到达时，将所述目标实例抓取的所述第二指标数据上传至所述存储中心，以通过所述存储中心存储所述第二指标数据。

可选地，将所述目标集群中存储的所述第一指标数据上传至存储中心，以通过所述存储中心存储所述第一指标数据，包括：对所述第一指标数据进行降采样，得到第一降采样数据；将所述第一降采样数据进行压缩后，存储至所述存储中心。

可选地，将所述目标实例抓取的所述第二指标数据上传至所述存储中心，以通过所述存储中心存储所述第二指标数据，包括：对所述第二指标数据进行降采样，得到第二降采样数据；将所述第二降采样数据进行压缩后，存储至所述存储中心。

可选地，通过所述目标集群存储所述第一指标数据之后，所述方法还包括：获取数据查询请求，其中，所述数据查询请求用于请求获取目标指标数据；在目标集群、存储中心、目标实例、第一组件和第二组件中查询所述目标指标数据，其中，所述第二组件中存储了对历史数据执行计算后得到的指标数据。

根据本发明的另一个实施例，提供了一种数据的存储装置，包括：获取模块，用于获取多个业务应用上传的日志消息；转化模块，用于使用第一组件将所述日志消息转化为指标格式的第一指标数据，其中，所述指标格式是能够被目标实例抓取的数据格式；发送模块，用于将所述第一指标数据发送至目标集群，以通过所述目标集群存储所述第一指标数据。

根据本发明的又一个实施例，还提供了一种存储介质，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。

根据本发明的又一个实施例，还提供了一种电子装置，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述任一项方法实施例中的步骤。

通过本发明，由于获取多个业务应用上传的日志消息；使用第一组件将日志消息转化为指标格式的第一指标数据，其中，指标格式是能够被目标实例抓取的数据格式；通过第二消息中间键将第一指标数据发送至目标集群，以通过目标集群存储所述第一指标数据。因此，可以解决Promtheus难以管理大量数据问题，达到Promtheus可以对大量数据进行管理的效果。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是本发明实施例的一种数据的存储方法的移动终端的硬件结构框图；

图2是根据本发明实施例的数据的存储的流程图；

图3是根据本发明可选实施例的Thanos-ingest数据ETL流程示意图；

图4是根据本发明可选实施例的job翻译机制示意图；

图5是根据本发明可选实施例的Thanos-ingest OSS存储中心示意图；

图6是根据本发明可选实施例的查询场景的数据流示意图；

图7是根据本发明可选实施例的预聚合计算的数据流示意图；

图8是根据本发明可选实施例的整个架构数据流程图；

图9是根据本发明可选实施例的完整架构示意图；

图10是根据本发明实施例的数据的存储装置的结构框图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

本申请实施例一所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。以运行在移动终端上为例，图1是本发明实施例的一种数据的存储方法的移动终端的硬件结构框图。如图1所示，移动终端10可以包括一个或多个(图1中仅示出一个)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)和用于存储数据的存储器104，可选地，上述移动终端还可以包括用于通信功能的传输设备106以及输入输出设备108。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述移动终端的结构造成限定。例如，移动终端10还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。

存储器104可用于存储计算机程序，例如，应用软件的软件程序以及模块，如本发明实施例中的数据的存储方法对应的计算机程序，处理器102通过运行存储在存储器104内的计算机程序，从而执行各种功能应用以及数据处理，即实现上述的方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至移动终端10。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括移动终端10的通信供应商提供的无线网络。在一个实例中，传输装置106包括一个网络适配器(Network Interface Controller，简称为NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置106可以为射频(Radio Frequency，简称为RF)模块，其用于通过无线方式与互联网进行通讯。

在本实施例中提供了一种运行于上述移动终端的数据的存储方法，图2是根据本发明实施例的数据的存储的流程图，如图2所示，该流程包括如下步骤：

步骤S202，获取多个业务应用上传的日志消息；

步骤S204，使用第一组件将所述日志消息转化为指标格式的第一指标数据，其中，所述指标格式是能够被目标实例抓取的数据格式；

步骤S206，将所述第一指标数据发送至目标集群，以通过所述目标集群存储所述第一指标数据。

由于获取多个业务应用上传的日志消息；使用第一组件将日志消息转化为指标格式的第一指标数据，其中，指标格式是能够被目标实例抓取的数据格式；通过第二消息中间键将第一指标数据发送至目标集群，以通过目标集群存储所述第一指标数据。因此，可以解决Promtheus难以管理大量数据问题，达到Promtheus可以对大量数据进行管理的效果。

可选地，上述步骤的执行主体可以为终端等，但不限于此。

作为一个可选的实施方式，目标实例可以是Prometheus，第一组件可以是Thanos-ingest组件。由于部分应用或数据比较特殊，其监控数据不能直接被Prometheus抓取，例如业务应用中的日志消息。因此需要采用主动写入的方式上传指标数据，通过组件Thanos-ingest可以完成将日志消息转化为Prometheus可以抓取指标数据格式，Thanos-ingest是内部孵化出来适配Thanos-ingest做数据摄入的组件，主要解决事件型到指标型数据转化的问题。

作为一个可选的实施方式，如图3所示是根据本发明可选实施例的Thanos-ingest数据ETL流程示意图，多个业务应用包括图中的业务应用01、业务应用02和业务应用N，N的数值可以根据实际应用场景而定，例如可以是100、1000等，在此不作限定。业务应用的日志由日志采集进程统一收集，然后将采集到的日志消息写入kafka topic1(消息中间键)。flink流可以将日志消息格式化为Thanos-ingest接受的数据指标格式，并将其发送到kafka topic2。Thanos-ingest通过kafka topic2获取到标准event数据，标准event数据会在Thanos-ingest内部维护状态并持久化为指标，得到Prometheus可以抓取的第一指标数据。Thanos-ingest将第一指标数据发送到目标集群thanos-prom，通过目标集群thanos-prom存储第一指标数据。在本实施例中，通过Thanos-ingest组件可以将Prometheus无法抓取的数据格式转化为指标格式的数据，以使Prometheus能够抓取数据并对其进行管理。

可选地，使用第一组件将所述日志消息转化为指标格式的第一指标数据，包括：对所述多个业务应用上传的日志消息进行清洗，得到待转化日志消息；将所述待转化日志消息转化为所述第一指标数据。

作为一个可选的实施方式，可以flink流通过kafka topic1消息将数据格式化为Thanos-ingest接受的数据指标格式，并且发送到kafka topic2；Thanos-ingest通过消费kafka topic2，拿到标准event数据，待转化日志消息可以是标准event数据，标准event数据会在Thanos-ingest内部维护状态并持久化为指标。在本实施例中，通过flink流对日志消息进行清洗可以去除一些不需要的数据，例如重复数据。flink流可以将日志消息转化为第一组件Thanos-ingest接受的数据格式，以方便Thanos-ingest将日志消息转化为Prometheus可以接受的指标数据。

可选地，在将所述待转化日志消息转化为所述第一指标数据之后，所述方法还包括：将所述指标数据记录在所述第一组件，其中，所述第一组件中记录了历史指标数据；通过所述第一组件对所述指标数据和所述历史指标数据的状态进行维护。

作为一个可选的实施方式，Prometheus指标是有状态的，如count，bucket类型的series都要做累加，因此需要维护这个上下文状态。Thanos-ingest在指标转化过程中通过window操作记录了每一条series的前文数据，并将当前接收到的数据更新到series，如此即维护了指标的前后状态。拥有维护指标状态的能力是Thanos-ingest在Thanos架构中非常重要的原因。

可选地，所述方法还包括：通过所述目标实例在配置文件中抓取第二指标数据，其中，所述配置文件定时请求自定义配置和附件信息，并将所述自定义配置和所述附件信息渲染为目标实例的标准配置。

作为一个可选的实施方式，数据的采集可以包括以下不同的数据采集场景：Java语业务应用：可完成对Java应用指标数据的统一暴露；非Java语言的业务应用：Prometheus可以对Go、Python等其它语言提供开源Client，间接支持指标上报；数据库组件：比如MySQL，Redis数据库的指标数据采集，则通过开源exporter完成；k8s系统级指标：通过抓取kubelet cadvisor指标数据以及抓取监测k8s资源部署的kube-status-metrics组件即可。

由于Prometheus实例数量很大，要抓取上面的指标数据不可能逐一手动修改Prometheus的配置文件，可以利用Prometheus在k8s集群支持自动发现的机制以及Prometheus配置文件支持热加载这两个特性做到配置文件灵活且快速地安全更新，如图4所示是根据本发明可选实施例的job翻译机制示意图。其中，自定义配置可以不是标准的Promethues job配置，可以是根据具体业务需求特别编写的一套配置文件，在此基础上加入附件信息再渲染出最终的Prometheus job。附件信息可以是被抓取指标白名单，部分指标并不需要关心，因此可以被忽略。转译job的过程是一个定时任务，它会定时请求自定义配置和附件信息，从而渲染出标准Prometheus job，之后通过k8s api更新到目标Prometheus configmap，调用/-/reload接口通知Prometheus重新加载一次配置即可完成一次配置更新。

可选地，所述方法还包括：在第一时间间隔到达时，将所述目标集群中存储的所述第一指标数据上传至存储中心，以通过所述存储中心存储所述第一指标数据；在第二时间间隔到达时，将所述目标实例抓取的所述第二指标数据上传至所述存储中心，以通过所述存储中心存储所述第二指标数据。

作为一个可选的实施方式，上述存储中心可以是OSS。如图5所示是根据本发明可选实施例的Thanos-ingest OSS存储中心示意图。数据的收集主要有两种方式，即Prometheus主动抓取以及Thanos-ingest对事件型数据到指标型数据的转化。Prometheus主动抓取得到第二指标数据，Thanos-ingest对事件型数据的转化得到第一指标数据。Prometheus和Thanos-ingest数据落盘都依赖TSDB，Prometheus抓取的数据在运行内存中会保留第一时间间隔，Thanos-ingest转化的数据会在运行内存中保留第二时间间隔，第一时间间隔和第二时间间隔的时长可以根据实际情况而定，可以相同也可以不同，例如可以是2小时，也可以是第一时间间隔为1小时，第二时间间隔是1.5小时，具体时长可以根据实际情况设这。因为本地存储终究是有限的，于是超过时间间隔的数据会被打包为block，通过sidecar组件同步到OSS存储中心。

可选地，将所述目标集群中存储的所述第一指标数据上传至存储中心，以通过所述存储中心存储所述第一指标数据，包括：对所述第一指标数据进行降采样，得到第一降采样数据；将所述第一降采样数据进行压缩后，存储至所述存储中心。

可选地，将所述目标实例抓取的所述第二指标数据上传至所述存储中心，以通过所述存储中心存储所述第二指标数据，包括：对所述第二指标数据进行降采样，得到第二降采样数据；将所述第二降采样数据进行压缩后，存储至所述存储中心。

作为一个可选的实施方式，OSS存储数据会随着时间越来越大，当查询历史数据时，在大量数据中筛选需要的一份是非常耗时的。并且监控数据的价值会随着时间降低，因此针对历史数据可以做降采样方案，以提高查询速度。于是Compactor组件便完成了这样的工作。具体地，可以对第一指标数据和第二指标数据进行降采样，得到降采样数据(第一降采样数据、第二降采样数据)，然后对降采样数据进行压缩，将压缩数据存储至存储中心。可以达到提高查询速度的技术效果。

可选地，通过所述目标集群存储所述第一指标数据之后，所述方法还包括：获取数据查询请求，其中，所述数据查询请求用于请求获取目标指标数据；在目标集群、存储中心、目标实例、第一组件和第二组件中查询所述目标指标数据，其中，所述第二组件中存储了对历史数据执行计算后得到的指标数据。

作为一个可选的实施方式，如图6所示是根据本发明可选实施例的查询场景的数据流示意图。数据查询是整个流程的核心，Thanos-querier是Thanos集群数据的出口，上游数据来来自目标实例Prometheus、存储中心oss、第一组件Thanos-ingest以及第二组件Thanos-rule。Thanos-store是查询oss中数据必要的网关组件，查询历史数据基本都会经过它取数据，因此它的性能也关系到用户体验。在此基础上部署了预聚合PromQL指标数据的Thanos-rule组件，通过在Thanos-rule中配置预聚合规则，Thanos-rule间隔预定时间计算一次结果生成新的指标，预定时间可以根据实际情况而定，例如2分钟。于是数据查询便可直接落到新指标上，达到加速查询的目的。产品层面中的查询绝大部分属于图表查询，包括即席查询。因此绝大部分查询属于query_range类型，部署Thanos-frontend可以优化查询速度。

由于业务需要查询部分复杂的PromQL，并且耗时较大，因此使用Thanos-rule组件提前计算相关数据，这样能极大提高查询体验。由于预聚合计算基本只会算最近时间段的数据，因此数据上游全部来自Prometheus内存中的热数据。通过Thanos-querier数据出口拿到数据便可以计算出相应指标数据，然后和Prometheus一样内存存储最近2小时热数据，历史数据打块上传到OSS，如图7所示是根据本发明可选实施例的预聚合计算的数据流示意图。任何外部应用查询指标数据都会走Thanos-querier(或Thanos-frontend)，通过该数据接口在产品层面上可以做到：即席查询：通过产品封装，在Thanos-querier上层引入应用程序，业务应用可以简单地查询各种数据；图表看板：通过在产品中实现图表看板配置功能，业务应用可以快捷查看多种指标数据；监控警报：在完成Prometheus和Thanos基础建设后，警报数据源请求压力的问题引刃而解。

使用Prometheus过程中运维场景主要有两类，其一是伸缩Prometheus实例，第二是Promtheus扩容。这两个场景暴露了4个主要问题：实例伸缩缓慢：Promtheus实例同时承担了数据写入和查询的责任，当查询压力大时,无法根据需求快速伸缩；配置查询繁琐：统一查询层需要路由多Promtheus实例,新增实例需要手动配置路由信息,非常繁琐；数据丢失严重：由于资源限制,Promtheus都是单副本，实例挂了就意味着数据丢失，并且由于启动慢更是加重了数据丢失的问题；容量规划滞后：往往是实例先发生内存溢出再扩容，而这也意味着数据已发生丢失。为了解决这些问题，本申请引入Thanos架构，并在此基础之上做深度定制开发与部署，主要目的：解决实例分片不清晰的问题；增强Prometheus数据采集能力；统一的时序数据查询入口；提升时序数据查询速度；完善的历史数据存储以及历史数据的快速响应。

作为一个可选的实施方式，针对Prometheus集群的不足，Prometheus-Thanos整个架构方案在数据采集、数据存储、数据查询三个方面具有显著优势，下文将从这三个方面展开叙述，如图8所示是根据本发明可选实施例的整个架构数据流程图，其中，Aliyun-oss用于存储Prometheus的历史数据，Prometheus内存一般只保留2小时数据，每2小时数据会打块，然后传到oss；Thanos-compact用于对oss中的数据降采样，对于历史数据，在保证查询速度的前提下，一般不需要很细时间粒度；Thanos-store作为于oss交互的媒介，一般查询历史数据都得通过store；Thanos-query是指标查询的核心组件，它的数据来源：Prometheus、Thanos-store(获取oss的数据)、Thanos-recevier；Thanos-frontend用于Thanos-query的查询前端，起到拆分长查询和缓存查询结果的作用；Thanos-rule主要用作预聚合，官方称之为记录规则。从Prometheus角度看，各个集群分别部署着一套Prometheus应用，每一套按功能可划分为三个类别(k8s层面指标、主机层面指标、应用层面指标)，因此针对一般集群至少需要部署三个Prometheus实例。每一个Prometheus pod含2个容器(Prometheus及其sidecar)，sidecar主要用作将数据块上传到oss。

作为一个可选的实施方式，如图9所示是根据本发明可选实施例的完整架构示意图，其中，指标采集层用于Prometheus和Thanos-ingest数据采集；持久存储层：历史数据都存到OSS；指标查询层：Thanos-querier上游接Prometheus、OSS、以及Thanos-store数据，下游可直接面向产品层面或Thanos-frontend。通过定制组件Thanos-ingest实现了事件型数据的转化，通过Thanos-rule实现了指标加速查询，多个组件相互配合体现了分布式架构在指标数据处理上的问题解决能力。在此基础上实现高可用、横向扩展将变得越来越简单。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

在本实施例中还提供了一种数据的存储装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图10是根据本发明实施例的数据的存储装置的结构框图，如图10所示，该装置包括：获取模块1002，用于获取多个业务应用上传的日志消息；转化模块1004，用于使用第一组件将所述日志消息转化为指标格式的第一指标数据，其中，所述指标格式是能够被目标实例抓取的数据格式；发送模块1006，用于将所述第一指标数据发送至目标集群，以通过所述目标集群存储所述第一指标数据。

可选地，上述装置用于通过如下方式实现使用第一组件将所述日志消息转化为指标格式的第一指标数据：对所述多个业务应用上传的日志消息进行清洗，得到待转化日志消息；将所述待转化日志消息转化为所述第一指标数据。

可选地，上述装置用于在将所述待转化日志消息转化为所述第一指标数据之后，将所述指标数据记录在第一组件，其中，所述第一组件中记录了历史指标数据；通过所述第一组件对所述指标数据和所述历史指标数据的状态进行维护。

可选地，上述装置用于通过所述目标实例在配置文件中抓取第二指标数据，其中，所述配置文件定时请求自定义配置和附件信息，并将所述自定义配置和所述附件信息渲染为目标实例的标准配置。

可选地，上述装置用于在第一时间间隔到达时，将所述目标集群中存储的所述第一指标数据上传至存储中心，以通过所述存储中心存储所述第一指标数据；在第二时间间隔到达时，将所述目标实例抓取的所述第二指标数据上传至所述存储中心，以通过所述存储中心存储所述第二指标数据。

可选地，上述装置用于通过如下方式实现将所述目标集群中存储的所述第一指标数据上传至存储中心，以通过所述存储中心存储所述第一指标数据：对所述第一指标数据进行降采样，得到第一降采样数据；将所述第一降采样数据进行压缩后，存储至所述存储中心。

可选地，上述装置用于通过如下方式实现将所述目标实例抓取的所述第二指标数据上传至所述存储中心，以通过所述存储中心存储所述第二指标数据：对所述第二指标数据进行降采样，得到第二降采样数据；将所述第二降采样数据进行压缩后，存储至所述存储中心。

可选地，上述装置用于在通过所述目标集群存储所述第一指标数据之后，获取数据查询请求，其中，所述数据查询请求用于请求获取目标指标数据；在目标集群、存储中心、目标实例、第一组件和第二组件中查询所述目标指标数据，其中，所述第二组件中存储了对历史数据执行计算后得到的指标数据。

需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述各个模块以任意组合的形式分别位于不同的处理器中。

本发明的实施例还提供了一种存储介质，该存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。

可选地，在本实施例中，上述存储介质可以被设置为存储用于执行以下步骤的计算机程序：

S1，获取多个业务应用上传的日志消息；

S2，使用第一组件将所述日志消息转化为指标格式的第一指标数据，其中，所述指标格式是能够被目标实例抓取的数据格式；

S3，将所述第一指标数据发送至目标集群，以通过所述目标集群存储所述第一指标数据。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(Read-Only Memory，简称为ROM)、随机存取存储器(Random Access Memory，简称为RAM)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。

本发明的实施例还提供了一种电子装置，包括存储器和处理器，该存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。

可选地，上述电子装置还可以包括传输设备以及输入输出设备，其中，该传输设备和上述处理器连接，该输入输出设备和上述处理器连接。

可选地，在本实施例中，上述处理器可以被设置为通过计算机程序执行以下步骤：

S1，获取多个业务应用上传的日志消息；

S2，使用第一组件将所述日志消息转化为指标格式的第一指标数据，其中，所述指标格式是能够被目标实例抓取的数据格式；

S3，将所述第一指标数据发送至目标集群，以通过所述目标集群存储所述第一指标数据。

可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (9)

1.一种数据的存储方法，其特征在于，包括：

获取多个业务应用上传的日志消息；

使用第一组件将所述日志消息转化为指标格式的第一指标数据，其中，所述指标格式是能够被目标实例抓取的数据格式；

将所述第一指标数据发送至目标集群，以通过所述目标集群存储所述第一指标数据；

通过所述目标实例在配置文件中抓取第二指标数据，其中，所述配置文件定时请求自定义配置和附件信息，并将所述自定义配置和所述附件信息渲染为目标实例的标准配置。

2.根据权利要求1所述的方法，其特征在于，使用第一组件将所述日志消息转化为指标格式的第一指标数据，包括：

对所述多个业务应用上传的日志消息进行清洗，得到待转化日志消息；

将所述待转化日志消息转化为所述第一指标数据。

3.根据权利要求2所述的方法，其特征在于，在将所述待转化日志消息转化为所述第一指标数据之后，所述方法还包括：

将所述指标数据记录在所述第一组件，其中，所述第一组件中记录了历史指标数据；

通过所述第一组件对所述指标数据和所述历史指标数据的状态进行维护。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在第一时间间隔到达时，将所述目标集群中存储的所述第一指标数据上传至存储中心，以通过所述存储中心存储所述第一指标数据；

在第二时间间隔到达时，将所述目标实例抓取的所述第二指标数据上传至所述存储中心，以通过所述存储中心存储所述第二指标数据。

5.根据权利要求4所述的方法，其特征在于，将所述目标集群中存储的所述第一指标数据上传至存储中心，以通过所述存储中心存储所述第一指标数据，包括：

对所述第一指标数据进行降采样，得到第一降采样数据；

将所述第一降采样数据进行压缩后，存储至所述存储中心。

6.根据权利要求4所述的方法，其特征在于，将所述目标实例抓取的所述第二指标数据上传至所述存储中心，以通过所述存储中心存储所述第二指标数据，包括：

对所述第二指标数据进行降采样，得到第二降采样数据；

将所述第二降采样数据进行压缩后，存储至所述存储中心。

7.根据权利要求1至6中任一项所述的方法，其特征在于，在通过所述目标集群存储所述第一指标数据之后，所述方法还包括：

获取数据查询请求，其中，所述数据查询请求用于请求获取目标指标数据；

在目标集群、存储中心、目标实例、第一组件和第二组件中查询所述目标指标数据，其中，所述第二组件中存储了对历史数据执行计算后得到的指标数据。

8.一种数据的存储装置，其特征在于，包括：

获取模块，用于获取多个业务应用上传的日志消息；

转化模块，用于使用第一组件将所述日志消息转化为指标格式的第一指标数据，其中，所述指标格式是能够被目标实例抓取的数据格式；

发送模块，用于将所述第一指标数据发送至目标集群，以通过所述目标集群存储所述第一指标数据；

所述装置还用于通过所述目标实例在配置文件中抓取第二指标数据，其中，所述配置文件定时请求自定义配置和附件信息，并将所述自定义配置和所述附件信息渲染为目标实例的标准配置。

9.一种存储介质，其特征在于，所述存储介质中存储有计算机程序，其中，所述程序可被终端设备或计算机运行时执行所述权利要求1至7任一项中所述的方法。

Images