关于数据库:使用-Prometheus-Grafana-打造-TiDB-监控整合方案

作者介绍：王天宜

Prometheus + Grafana 作为一套普适的监控零碎广泛应用于各种应用环境中。

本文次要介绍是否将 TiDB + Prometheus 新搭建的监控零碎，迁徙到已有的监控零碎的计划。

对资源比拟缓和，高可用需要不强烈的用户，咱们倡议间接通过 Prometheus Label 进行集群的划分，做到 All in One 的 Prometheus 监控环境。对资源拮据，高可用需要比拟强烈的用户，能够思考应用 Prometheus 多租户的解决方案。

Grafana 作为一个无状态的利用，如果有高可用的需要，能够思考通过 Keepalived + Haproxy 的构造部署成高可用的架构。

从本文中，你将将理解到：

• 如何将不同的 TiDB 集群 Prometheus 监控平台整合到同一 Prometheus 平台中
• 如何通过 Grafana 查看 Prometheus 中的 metric
• 如何将不同集群的 cluster 标签注入到 Grafana dashboard 中
• 如何通过 Grafana HTTP API 批量将报表导入到 Grafana 中
• 如何解决大量指标数据造成的 Prometheus 性能问题
• 如何将 Prometheus 中的数据导入到关系型数据库中进行查问或指标剖析
• 如何实现 Prometheus 的高可用和高租户

本文的思路导读：

• 我想做什么：将每个集群独立的 Prometheus + Grafana 整合到对立的平台，繁多入口进行查问
• Prometheus 如何整合：应用独立的 Prometheus 拉取不同集群的 metric，通过 label 进行辨别
• Grafana 如何整合：须要将每一个 expr 都推入集群的标签信息加以隔离，生成新的报表，应用 Grafana HTTP API 批量导入报表
• 整合后可能带来的危险：Prometheus 数据量炸库，性能迟缓
• 怎么办：拆库！为什么刚合并的库要拆分？
• 拆分的指标：Prometheus 程度扩大，数据集中存储近程库
• 数据集中存储计划：应用 prometheus-postgresql-adapter + TimescaleDB 进行数据存储
• 数据集中存储有什么问题：Dashboard 的 expr 须要从 Timescale DB 中读取，原来的基于 PromSQL 的 expr 无奈应用
• 如何解决 SQL 转换 PromSQL 的问题：在 Timescale 上再接一层 Prometheus 进行转换
• Prometheus 的程度扩大和多租户计划：Thanos

有一些话要提前说一下：

• 作为一个长期奋斗于一线，到了二线三线也放不下一线的 DBA，我最关怀三件事件（排名有先后）：
• 饭碗拿的好：正确性，数据不能少
• 我想睡得早：稳定性，早晨不报警
• 安心去养老：查问是产品的问题，关我 DBA 什么事件
• 为此，作为一位非驰名 DBA，我整顿了一下 TiDB 监控整合计划的思路
• 本文是思路，不敢叫做计划
• 本息记录了，我拿出一个计划，再颠覆这个计划的迭代过程
• 每个计划都有本人的独特性，所以没有最好的计划，只有最实用的计划

试验的集群环境

操作系统环境介绍

[root@r30 .tiup]# cat /etc/redhat-release
CentOS Stream release 8
[root@r30 .tiup]# uname -r
4.18.0-257.el8.x86_64

TiDB 集群环境介绍

作为试验环境，咱们部署了两套 TiDB 集群，tidb-c1-v409，tidb-c2-v409。

在一台独立的机器上，我通过 TiUP 部署了一套集群 tidb-monitor 零碎后，只保留 Grafana 与 Prometheus 组件。删除了其余的 TiDB 组件。这套 tidb-monitor 集群是为了模仿咱们已有的监控平台，将 tidb-c1-v409 与 tidb-c2-v409 的监控迁徙到 tidb-monitor 上。

现行的 TiDB 监控框架概述

Prometheus 在 TiDB 中的利用

Prometheus 是一个领有多维度数据模型的、灵便的查问语句的时序数据库。

Prometheus 作为热门的开源我的项目，领有沉闷的社区及泛滥的胜利案例。

Prometheus 提供了多个组件供用户应用。目前，TiDB 应用了以下组件：

• Prometheus Server：用于收集和存储工夫序列数据
• Client 代码库：用于定制程序中须要的 Metric
• Alertmanager：用于实现报警机制

Grafana 在 TiDB 中的利用

Grafana 是一个开源的 metric 剖析及可视化零碎。

TiDB 应用 Grafana 来展现 TiDB 集群各组件的相干监控，监控项分组如下图所示：

Prometheus & Grafana 存在的问题

随着集群数量的减少，局部用户可能存在以下的需要：

• 多套 TiDB 集群无奈共享一套监控集群
• Prometheus 自身不具备高可用性随着数据量的增长
• Prometheus 的查问速度会升高

于此，咱们思考是否能够整合不同集群的 Prometheus 和 Grafana，做到多集群共用一套建监控零碎。

Prometheus 的整合计划

Prometheus 简介

TiDB 应用开源时序数据库 Prometheus 作为监控和性能指标信息存储计划，应用 Grafana 作为可视化组件进行信息的展现。Prometheus 广义上是软件自身，即 prometheus server，狭义上是基于 prometheus server 为外围的各类软件工具的生态。除 prometheus server 和 grafana 外，Prometheus 生态罕用的组件还有 alertmanager、pushgateway 和十分丰盛的各类 exporters。prometheus server 本身是一个时序数据库，相比应用 MySQL 做为底层存储的 zabbix 监控，领有十分高效的插入和查问性能，同时数据存储占用的空间也十分小。如果要应用 prometheus server 接管推送的信息，数据源和 prometheus server 两头须要应用 pushgateway。

Prometheus 监控生态十分欠缺，能监控的对象十分丰盛。具体的 exporter 反对对象可参考官网介绍 exporters 列表。Prometheus 能够监控的对象远不止官网 exporters 列表中的产品，有些产品原生反对不在下面列表，如 TiDB; 有些能够通过规范的 exporter 来监控一类产品，如 snmp_exporter; 还有些能够通过本人写个简略的脚本往 pushgateway 推送；如果有肯定开发能力，还能够通过本人写 exporter 来解决。同时有些产品随着版本的更新，不须要下面列表中的 exporter 就能够反对，比方 ceph。随着容器和 kurbernetes 的一直落地，以及更多的软件原生反对 Prometheus，置信很快 Prometheus 会成为监控畛域的领军产品。

Prometheus 架构介绍

Prometheus 的架构图如下：

Prometheus 生态中 prometheus server 软件用于监控信息的存储、检索，以及告警音讯的推送，是 Prometheus 生态最外围的局部。Alertmanger 负责接管 prometheus server 推送的告警，并将告警通过分组、去重等解决后，按告警标签内容路由，通过邮件、短信、企业微信、钉钉、webhook 等发送给接收者。大部分软件在用 Prometheus 作为监控时还须要部署一个 exporter 做为 agent 来采集数据，然而有局部软件原生反对 Prometheus，比方 TiDB 的组件，在不必部署 exporter 的状况下就能够间接采集监控数据。PromQL 是 Prometheus 数据查询语言，用户能够通过 prometheus server 的 web UI，在浏览器上间接编写 PromQL 来检索监控信息。也能够将 PromQL 固化到 grafana 的报表中做动静的展现，另外用户还能够通过 API 接口做更丰盛的自定义性能。Prometheus 除了能够采集动态的 exporters 之外，还可要通过 service discovery 的形式监控各种动静的指标，如 kubernetes 的 node,pod,service 等。除 exporter 和 service discovery 之外，用户还能够写脚本做一些自定义的信息采集，而后通过 push 的形式推送到 pushgateway，pushgateway 对于 prometheus server 来说就是一个非凡的 exporter，prometheus server 能够像抓取其余 exporters 一样抓取 pushgateway 的信息。

Promethes 的 Label 应用规定

Prometheus 依据 Label 辨别不同的 Metric

在主机中能够增加不同的 Label，能够用于辨别雷同名称不同集群的 metric，也能够用于聚合雷同集群的不同 metric：

## modify prometheus.conf
static_configs:
- targets: ['localhost:9090']
  labels:
    cluster: cluster_1
    
 ## check prometheus configuration file
 ./promtool check config prometheus.yml
 
 ## reconfig the prometheus
 kill -hup <prometheus_pid>
 
 ## get the cpu source aggregation
 sum(process_cpu_seconds_total{cluster='cluster_1'})

能够 通过标签进行或保留数据采集：

## stop the metric collection for the jobs with the label cpu_metric_collection_drop
scrape_configs:
  - job_name: 'cpu_metric_collection'
    static_configs:
    - targets: ['localhost:9090']
    relabel_configs:
    - action: drop
      source_labels: ['cpu_metric_collection_drop']
      
## keep the metric collection for the jobs with the label cpu_metric_collection_keep
scrape_configs:
  - job_name: 'cpu_metric_collection'
    static_configs:
    - targets: ['localhost:9090']
    relabel_configs:
    - action: keep
      source_labels: ['cpu_metric_collection_keep']

Prometheus 的 relabel 操作

在 Prometheus 监控体系中，标签 Label 是一个极为重要的参数。在一个集中、简单的监控环境中，咱们可能无法控制正在监控的资源以及他们的指标数据。从新定义监控的标签能够在简单的环境中，无效的管制和治理数据指标。在 Prometheus 拉取 exportor 的数据后，会对数据标签进行编辑，也容许用户通过 relabel_configs 参数解决标签，包含批改、增加以及删除不必要的标签。

# The source labels select values from existing labels. Their content is concatenated
# using the configured separator and matched against the configured regular expression
# for the replace, keep, and drop actions.
[source_labels: '[' <labelname> [, ...] ']' ]

# Separator placed between concatenated source label values.
[separator: <string> | default = ;]

# Label to which the resulting value is written in a replace action.
# It is mandatory for replace actions. Regex capture groups are available.
[target_label: <labelname>]

# Regular expression against which the extracted value is matched.
[regex: <regex> | default = (.*) ]

# Modulus to take of the hash of the source label values.
[modulus: <int>]

# Replacement value against which a regex replace is performed if the
# regular expression matches. Regex capture groups are available.
[replacement: <string> | default = $1]

# Action to perform based on regex matching.
[action: <relabel_action> | default = replace]

在以上的例子中，<relabel_action> 能够蕴含以下的集中操作：

• replace：应用 replacement 的值替换被 regex 正则匹配到 source_label；
• keep：保留被匹配到的标签的 metric，删除未被匹配到标签的 metric;
• drop：删除被匹配到的标签的 metric，保留未被匹配到标签的 metric；
• hashmod：将 target\_label 设置成 source\_label 的 modulus 配置的 hash 值；
• labelmap：将 regex 匹配到的所有标签的名称配置成新的标签，值配置成新标签的值；
• labeldrop：将合乎规定的标签删除，保留未被匹配的标签；
• labelkeep：将合乎规定的标签保留，删除未被匹配的标签。

通过以上对 Prometheus Label 的介绍，咱们能够思考应用 Label 这种个性，来标记辨别不同的 TiDB 集群。

通过 Label 来辨别 TiDB 中不同的集群信息

批改 Prometheus 的配置文件的几种计划

以 tidb 这个 job 为例，咱们来实现一个最根本的配置。批改 tidb job 次要有两种思路：

• 创立一个 tidb job，应用 relabel_configs 给这个 job 别离打上两个标签，tidb-c1-v409 与 tidb-c2-v409
• 创立两个 tidb job，job-tidb-c1-v409 与 job-tidb-c2-v409

计划一：创立 tidb job，通过 relabel_configs 辨别不同的 cluster

## The first way - create one job for tidb, and distinguish different clusters by relabel_configs operation
  - job_name: "tidb"
    honor_labels: true # don't overwrite job & instance labels
    static_configs:
    - targets:
      - '192.168.12.31:12080'
      - '192.168.12.32:12080'
      - '192.168.12.33:12080'
      - '192.168.12.31:22080'
      - '192.168.12.32:22080'
      - '192.168.12.33:22080'

    relabel_configs:
      - source_labels: ['__address__']
        regex: '(.*):12080'
        target_label: 'cluster'
        replacement: 'tidb-c1-v409'
      - source_labels: ['__address__']
        regex: '(.*):22080'
        target_label: 'cluster'
        replacement: 'tidb-c2-v409'

在下面的配置中：

• ‘address’示意 targets 过滤出来的地址，在这个例子中，能够过滤出六个值，192.168.12.3{1,2,3}:{1,2}2080；
• regex 示意通过正则表达式将下面 source_labels 过滤出来的后果进行匹配；
• target_label 示意将标签 address 重命名为 cluster；
• replacement 示意将正则表达式匹配进去的后果重命名为 tidb-c1-v409 或者 tidb-c2-v409；
• 从新加载 prometheus 配置文件，在 prometheus 的 GUI 页面，status -> targets 外面能够看到以下的后果。

计划二：创立不同的 job 以辨别不同的 cluster

## The second way - create two jobs for different clusters
  - job_name: "tidb-c1-v409"
    honor_labels: true # don't overwrite job & instance labels
    static_configs:
    - targets:
      - '192.168.12.31:12080'
      - '192.168.12.32:12080'
      - '192.168.12.33:12080'
      labels:
        cluster: tidb-c1-v409

  - job_name: "tidb-c2-v409"
    honor_labels: true # don't overwrite job & instance labels
    static_configs:
    - targets:
      - '192.168.12.31:22080'
      - '192.168.12.32:22080'
      - '192.168.12.33:22080'
      labels:
        cluster: tidb-c2-v409

在下面的配置中：

• job_name 能够作为辨别两个不同 cluster 的标识；
• 针对不同的 job，target 外面只配置独立的集群 endpoints 信息；
• 通过 labels 打一个集群的标签；
• 从新加载 prometheus 配置文件，在 prometheus 的 GUI 页面，status -> targets 外面能够看到以下的后果。

很难比拟两种计划的优劣，第一种计划缩小了 job 数量，然而减少了 job 外面 label 的数量。第二种计划，缩小了 job 外面 label 的数量，然而减少了 job 的数量。就如同计算 2 3 4，很难比拟是 (2 3) 4 好一些还是 2 (3 4) 好一些。

Prometheus 配置文件的批改案例

应用第一种计划，通过 relabel_configs 进行集群的辨别。

针对于 blackbox\_exporter，因为两套集群部署上有机器的交加，理论的生产环境中，从节俭资源的角度上思考，只起一个 blackbox\_exporter 就能够了。

在改试验环境中，能够参考 prometheus-example。

当咱们从新家在 Prometheus 服务后，能够在 Prometheus 的 web GUI 中的 status -> target 中查看所有的 job 是否都是 UP 的状态。

随机查看一个 metric，例如 pd\_regions\_status，能够看到 cluster 标签有两个值，tidb-c1-v409 与 tidb-c2-v409。

Grafana 整合计划

在 Grafana 中查看 Datasource 的信息

因为在 Prometheus 曾经把所有的 metric 整合到同一个 Prometheus 中，所以须要在 Grafana 中配置这个 Prometheus。

查看 Grafana 中的报表

以 overview 报表为例，发现报表的显示有一点异样。两个集群的信息混到了一起，没有方法辨别。本例中，tidb-c1-v409 与 tidb-c2-v409 别离有三个 TiDB 节点，但在 overview dashboard 中，这留个节点信息被混在一起。

咱们以 overview dashboard -> service port status 为例，剖析一下报表的定义关上 service port status 的定义，能够查看到 tidb 的公式为 count(probe_success{group="tidb"} == 1)

发现短少 cluster 的信息，手动推动 cluster 信息，

count(probe_success{cluster="tidb-c1-v409", group="tidb"} == 1)

批改后能够失常显示 tidb-c1-v409 的 TiDB 节点信息。

将 cluster 的信息推入到 dashboard 中

通过手工推入 cluster 的信息，咱们能够验证 dashboard 能够失常显示。

以下的逻辑，能够试用 脚本推入 cluster 信息到 dashboard 中：

• 通过 curl -s http://192.168.12.34:9090/api… 命令能够查看到所有的 metric 的 url 遍历这些 url，取得到所有的 metric
• 遍历所有的 metric 信息，在报表中一个一个推入 cluster 信息，以 overview.json 为例
• 对于“expr”:“node\_memory\_MemAvailable\_bytes”这样自身没有选项的公式，间接推入 cluster 信息变为“expr”:“node\_memory\_MemAvailable\_bytes{cluster=“tidb-c1-v409”}”
• 对于“expr”:“\ncount(probe\_success{group=“tidb”} == 1)”这样自身曾经有了选项的公式，增加 cluster 信息变为“expr”:“\ncount(probe\_success{cluster=“tidb-c1-v409”,group=“tidb”} == 1)”

能够参考脚本 tidb\_dashboard\_inject_cluster.sh 1

运行 tidb\_dashboard\_inject_cluster.sh 脚本进行 cluster 信息注入，留神每次须要从新复制原始的 dashboard 文件夹而后运行脚本：

[root@r34 ~]# rm -rf dashboards && cp -r dashboards-bak/ dashboards && ./tidb_dashboard_inject_cluster.sh "tidb-c1-v409" "/root/dashboards" "192.168.12.34:9090"

查看注入后的脚本：

[root@r34 dashboards]# cat overview.json | grep expr | grep -v tidb-c1-v409
              "expr": "sum(increase(tidb_server_execute_error_total[1m])) by (type)",
              "expr": "sum(rate(tikv_channel_full_total[1m])) by (instance, type)",
              "expr": "sum(rate(tikv_server_report_failure_msg_total[1m])) by (type,instance,store_id)",

这几个在 /tmp/tidb-metirc 中都没有呈现过，能够手动更改一下。因为并没有获取到 metric，prometheus 也没有这个 metric，所以改不改不是那么重要。

将重定义的报表导入到 Grafana 中

能够惆怅过脚本 import-dashboard.sh 批量的将 dashboard 通过 Grafana API 导入到 Grafana 中。

具体的过成与原理能够参考【SOP 系列 14】如何多个 TiDB 集群共用一个 Grafana。

指标整合后所引入的新问题

通过以上的操作，咱们曾经能够做到将不同集群的 Prometheus 和 Grafana 整合到同一 Prometheus + Grafana 监控平台。这样做有什么危险：

• 整合过程中可能要引入新的 bug – 这是无奈防止的，要想定制化，就要容忍 bug。在前期运维中只会越来越好
• 大量的 metric 信息可能会造成
• Prometheus 的性能问题 Prometheus 和 Grafana 还没有高可用

不仅仅是 TiDB 的监控，包含 Kubernetes 的监控再也，也采纳了一套集群一套监控的形式进行 metric 的采集。因为 Prometheus 自身只反对单机部署，并不反对集群部署形式，咱们无奈高可用或者程度扩容。Prometheus 的数据存储能力也受限于单机的磁盘容量。在 All in One 的场景中，Prometheus 采集的数据量太大，耗费了大量的资源，可能无奈达到最佳的性能。拆分 Prometheus 势在必行。

然而理论环境中，为了节约资源，为了不便运维，很多企业是像上文的形式，将多个不同的集群监控整合到一个监控平台中。多快好省这种理念在监控平台上很难实现。多就不能快，良久不能省。

解决性能问题能够从以下的几个方面来思考：

• 删除那些使用率低，占用空间高的低性价比指标
• 缩减 Prometheus 存储的历史记录的保留策略
• 将 Prometheus 的数据流入到数仓中
• 应用联邦的形式进行数据汇总

解决性价比较低的指标

针对于那些使用率低，占用空间很高的指标来说，如果业务需要能够满足，那么该当尽早的删除他们。这样的低性价比指标，很有可能会造成 Prometheus 的 OOM。能够通过以下的报警规定找到占用大量空间的指标，如果使用率不高，能够在 relabel_config 中应用 drop 命令删除掉。

count by (\_\_name\_\_)({\_\_name\_\_=~".+"}) > 10000

Prometheus 的拆分问题

咱们方才做了什么：把不同的集群信息整合到一个监控平台中。咱们要做什么：把一个监控平台的数据拆分到多个 Prometheus 中。

进行 Prometheus 的拆分，能够从以下的几个维度进行思考：

• 从业务维度进行拆分
• 对超大的业务进行分片

从业务维度进行拆分

从业务维度进行拆分，这种形式刚好和咱们的指标是相同的。如果这样拆分的话，那么我什么都不做就挺好的。

对超大的业务做分片

当业务及其简单，或者历史数据要长时间保留的时候，能够思考将业务进行分片，将一个大的业务拆分成多个 group。在这种状况下，咱们拆都来不及，更没有必要进行数据整合。

在拆与整合之间进行衡量与斗争

整合的话，可能会带来性能的问题。为了解决性能问题，咱们有将 Prometheus 拆离开。To be or not to be, it is a question。假如咱们采取一种混合的模式进行斗争：

那么可能会引入新的问题，咱们的查问可能来自于不同的 datasource。在一个 dashboard 中，咱们无奈对不能的 dashboard 中进行聚合查问。为了解决这个问题，大体上有两种计划：

• Prometheus 联邦查问

  • 每个业务线都有本人的 Prometheus 监控零碎，这个 Prometheus 可能要监控多个子系统
  • 由一个核心的 Prometheus server 聚合多个业务线的 Prometheus

• 数据的集中式存储将

  • Prometheus 中的数据定期导入到数仓中，Prometheus 只保留短时间内的数据
  • 把 Prometheus 只当做一个 adapter，不进行数据存储，采集后的数据间接汇总到数据库中
  • Prometheus 自身就是一个时序数据库，能够应用其余的库代替，如 InfluxDB（开源版本不反对高可用）或者 TimescaleDB

将 Prometheus 的数据集中存储

Prometheus + Grafana 这一套监控零碎，实质上和数仓的模式十分相似，都是数据库 + 报表展现的模式。

Grafana 也是一个反对多种数据源的报表工具，除了 Prometheus，咱们还能够将数据存储在 PostgreSQL 或 MySQL 这样的关系型数据库中。

咱们有两种计划将 metric 导入到数据库中：

• 间接通过程序将 metirc 抽取到数据库中；
• 通过 Prometheus 和相干的 adapter 将数据抽取到数据库中：减少了一层中间件，组件多，但工作量少。

将 Prometheus 的数据导入到 PostgreSQL 中

TimescaleDB 作为一款基于 PostgreSQL 的开源时序数据库，自身和 Prometheus 是十分相似的。

相比于 Prometheus，有着更优的查问速度，高可用性及程度扩大行。SQL 语句相比于 PromSQL 来说对运维人员更敌对。Timescale 自身提供了插件 prometheus-postgresql-adapter，相比于其余的三方工具，稳固高效易保护。

更多 prometheus-postgresql-adapter 的装置步骤，能够参考 prometheus-postgresql-adapter installation

在 prometheus-postgresql-adapter 上更进一步

咱们曾经能够做到将 Prometheus 的元数据存储到 PostgreSQL 中，那么如何通过 Grafana 进行报表展现？咱们有两条路能够抉择：

• 间接应用 PostgreSQL 作为 Grafana 的数据源 – 架构简略，改变工作量微小；
• 在 PostgreSQL 上再接一层，应用 PromQL 来读取 PostgreSQL 中的数据 – 架构简单，根本没有什么改变工作量

目前，prometheus-postgresql-adapter 我的项目曾经被 Promscale 我的项目取代。相比于 prometheus-postgresql-adapter，Promscale 更不便于应用 TimescaleDB + PostgreSQL 作为 Prometheus 的近程存储。

Promscale 为咱们提供了以下个性：

• SQL 和 PromQL 双引擎查问剖析 metric
• PostgreSQL 提供了长久化的存储能力与性能，能够用于历史数据分析
• 数据的高可用性
• ACID 个性
• Timescale DB 提供了程度扩展性

Prometheus 的多租户与高可用解决方案

Thanos 与 Cortex 都是 Prometheus 的高可用及多租户的解决方案。并且双双进入 CNCF 孵化器我的项目。

Cortex 被构建为可扩大，且易于应用的计划，可用于 Prometheus 监控和长期存储，Cortex 多租户的个性，能够在单个集群将不同的 Prometheus 起源隔离，使不授信的各方共享一套集群。Thanos 是一种易于装置的解决方案，能够在用户的 Prometheus 上执行实例，过渡到具备长期存储性能的监控零碎中。

Thanos 与 Cortex 都是很好的 Prometheus 多租户与高可用解决方案，但本文选用了 Thanos 计划：

• Thanos 中所有的组件都是无状态的（stateless）
• 监控数据和集群状态被长久化到对象存储 OSS
• 反对 Prometheus 的高可用部署
• 文档健全，用户量绝对于其余计划更多

Thanos 性能与组件

Sidecar：

• 作为 Prometheus 运行 Pod 中的 Sidecar 容器
• 作为 Prometheus 的数据块（chunks）上传到对象存储（OSS）
• 反对多种对象存储（OSS），如 Aliyun、腾讯云、S3、Google 云存储、Azure 存储
• 可无缝集成在 Prometheus operator 中进行部署

Store：

• 从对象存储（OSS）中检索块（chunks），以便查问长周期的监控指标
• 基于工夫的分区查问
• 基于标签的分区查问

Compact：

• 为 OSS 中的监控数据创立降采样快（Downsampled chunks），以放慢长周期范畴内的数据查问

Query：

• 作为 PromQL 查问入口，代替 Prometheus 查问
• 打消来自于不同数据源（多个 Store）的反复数据
• 反对局部响应

Rule：

• 一个简化版本的 Prometheus（次要应用 rule 性能，不抓取数据，不做 PromQL 解析查问）
• 以 Prometheus 2.0 存储格局将后果写入 OSS
• 次要作为 Rule 的存储节点（通过 StoreAPI 将 TSDB 块上传到 OSS）

Bucket：

• 监事对象存储 Bucket 中存储的监控数据

Thanos 的 docker-compose 案例

以下我的项目为 TiDB 对接 Thanos 的 docker-compose 实现：tidb-thanos-quick-start

搭建 Thanos 的 docker-compose 环境须要以下的 image：

• prom/prometheus:v2.24.1
• quay.io/thanos/thanos:v0.18.0
• minio/minio:RELEASE.2020-05-01T22-19-14Z
• prom/node-exporter:v0.18.1
• prom/alertmanager:v0.21.0
• gcr.io/google_containers/cadvisor:v0.36.0
• grafana/grafana:7.3.7

在这个 docker compose 中，创立了两套 prometheus 监控，别离用来承接两套 tidb 零碎的监控。咱们能够独自的部署两无监控的 tidb 集群，通过 docker compose 中的 prometheus 来回收 metric 的信息。这样一来，咱们能够在 query 组件中同时查到两套集群的监控。甚至能够加以比照。