作者介绍:王天宜
Prometheus + Grafana 作为一套普适的监控系统广泛应用于各种应用环境中。
本文主要介绍能否将 TiDB + Prometheus 新搭建的监控系统,迁移到已有的监控系统的方案。
对资源比较紧张,高可用需求不强烈的用户,我们建议直接通过 Prometheus Label 进行集群的划分,做到 All in One 的 Prometheus 监控环境。对资源宽裕,高可用需求比较强烈的用户,可以考虑使用 Prometheus 多租户的解决方案。
Grafana 作为一个无状态的应用,如果有高可用的需求,可以考虑通过 Keepalived + Haproxy 的结构部署成高可用的架构。
从本文中,你将将了解到:
本文的思路导读:
有一些话要提前说一下:
[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-c1-v409,tidb-c2-v409。
在一台独立的机器上,我通过 TiUP 部署了一套集群 tidb-monitor 系统后,只保留 Grafana 与 Prometheus 组件。删除了其他的 TiDB 组件。这套 tidb-monitor 集群是为了模拟我们已有的监控平台,将 tidb-c1-v409 与 tidb-c2-v409 的监控迁移到 tidb-monitor 上。
Prometheus 是一个拥有多维度数据模型的、灵活的查询语句的时序数据库。
Prometheus 作为热门的开源项目,拥有活跃的社区及众多的成功案例。
Prometheus 提供了多个组件供用户使用。目前,TiDB 使用了以下组件:
Grafana 是一个开源的 metric 分析及可视化系统。
TiDB 使用 Grafana 来展示 TiDB 集群各组件的相关监控,监控项分组如下图所示:
随着集群数量的增加,部分用户可能存在以下的需求:
于此,我们考虑是否可以整合不同集群的 Prometheus 和 Grafana,做到多集群共用一套建监控系统。
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 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 的信息。
在主机中可以添加不同的 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 监控体系中,标签 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> 可以包含以下的集中操作:
通过以上对 Prometheus Label 的介绍,我们可以考虑使用 Label 这种特性,来标记区分不同的 TiDB 集群。
以 tidb 这个 job 为例,我们来完成一个最基本的配置。修改 tidb job 主要有两种思路:
方案一:创建 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'
在上面的配置中:
方案二:创建不同的 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 数量,但是增加了 job 里面 label 的数量。第二种方案,减少了 job 里面 label 的数量,但是增加了 job 的数量。就好像计算 2 3 4,很难比较是 (2 3) 4 好一些还是 2 (3 4) 好一些。
使用第一种方案,通过 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。
因为在 Prometheus 已经把所有的 metric 整合到同一个 Prometheus 中,所以需要在 Grafana 中配置这个 Prometheus。
以 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 中:
可以参考脚本 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,所以改不改不是那么重要。
可以难过过脚本 import-dashboard.sh 批量的将 dashboard 通过 Grafana API 导入到 Grafana 中。
详细的过成与原理可以参考 【SOP 系列 14】如何多个 TiDB 集群共用一个 Grafana。
通过以上的操作,我们已经可以做到将不同集群的 Prometheus 和 Grafana 整合到同一 Prometheus + Grafana 监控平台。这样做有什么风险:
不仅仅是 TiDB 的监控,包括 Kubernetes 的监控再也,也采用了一套集群一套监控的方式进行 metric 的采集。由于Prometheus 本身只支持单机部署,并不支持集群部署方式,我们无法高可用或者水平扩容。Prometheus 的数据存储能力也受限于单机的磁盘容量。在 All in One 的场景中,Prometheus 采集的数据量太大,消耗了大量的资源,可能无法达到最佳的性能。拆分 Prometheus 势在必行。
但是实际环境中,为了节约资源,为了方便运维,很多企业是像上文的方式,将多个不同的集群监控整合到一个监控平台中。多快好省这种理念在监控平台上很难实现。多就不能快,好久不能省。
解决性能问题可以从以下的几个方面来考虑:
针对于那些使用率低,占用空间很高的指标来说,如果业务需求可以满足,那么应当尽早的删除他们。这样的低性价比指标,很有可能会造成 Prometheus 的 OOM。可以通过以下的报警规则找到占用大量空间的指标,如果使用率不高,可以在 relabel_config 中使用 drop 命令删除掉。
count by (\_\_name\_\_)({\_\_name\_\_=~".+"}) > 10000
我们刚才做了什么:把不同的集群信息整合到一个监控平台中。我们要做什么:把一个监控平台的数据拆分到多个 Prometheus 中。
进行 Prometheus 的拆分,可以从以下的几个维度进行考虑:
从业务维度进行拆分,这种方式刚好和我们的目标是相反的。如果这样拆分的话,那么我什么都不做就挺好的。
当业务及其复杂,或者历史数据要长时间保留的时候,可以考虑将业务进行分片,将一个大的业务拆分成多个 group。在这种情况下,我们拆都来不及,更没有必要进行数据整合。
整合的话,可能会带来性能的问题。为了解决性能问题,我们有将 Prometheus 拆分开。To be or not to be, it is a question。假设我们采取一种混合的模式进行妥协:
那么可能会引入新的问题,我们的查询可能来自于不同的 datasource。在一个 dashboard 中,我们无法对不能的 dashboard 中进行聚合查询。为了解决这个问题,大体上有两种方案:
- 每个业务线都有自己的 Prometheus 监控系统,这个 Prometheus 可能要监控多个子系统
- 由一个中心的 Prometheus server 聚合多个业务线的 Prometheus
- Prometheus 中的数据定期导入到数仓中,Prometheus 只保留短时间内的数据
- 把 Prometheus 只当做一个 adapter,不进行数据存储,采集后的数据直接汇总到数据库中
- Prometheus 本身就是一个时序数据库,可以使用其他的库替代,如 InfluxDB(开源版本不支持高可用)或者 TimescaleDB
Prometheus + Grafana 这一套监控系统,本质上和数仓的模式非常类似,都是数据库 + 报表展示的模式。
Grafana也是一个支持多种数据源的报表工具,除了 Prometheus,我们还可以将数据存储在 PostgreSQL 或 MySQL 这样的关系型数据库中。
我们有两种方案将 metric 导入到数据库中:
TimescaleDB 作为一款基于 PostgreSQL 的开源时序数据库,本身和 Prometheus 是非常类似的。
相比于 Prometheus,有着更优的查询速度,高可用性及水平扩展行。SQL 语句相比于 PromSQL 来说对运维人员更友好。Timescale 本身提供了插件 prometheus-postgresql-adapter,相比于其他的三方工具,稳定高效易维护。
更多 prometheus-postgresql-adapter 的安装步骤,可以参考 prometheus-postgresql-adapter installation
我们已经可以做到将 Prometheus 的元数据存储到 PostgreSQL 中,那么如何通过 Grafana 进行报表展示? 我们有两条路可以选择:
目前,prometheus-postgresql-adapter 项目已经被 Promscale 项目取代。 相比于 prometheus-postgresql-adapter,Promscale 更方便于使用 TimescaleDB + PostgreSQL 作为 Prometheus 的远程存储。
Promscale 为我们提供了以下特性:
Thanos 与 Cortex 都是 Prometheus 的高可用及多租户的解决方案。并且双双进入 CNCF 孵化器项目。
Cortex 被构建为可扩展,且易于使用的方案,可用于 Prometheus 监控和长期存储,Cortex 多租户的特性,可以在单个集群将不同的 Prometheus 来源隔离,使不授信的各方共享一套集群。Thanos 是一种易于安装的解决方案,可以在用户的 Prometheus 上执行实例,过渡到具有长期存储功能的监控系统中。
Thanos 与 Cortex 都是很好的 Prometheus 多租户与高可用解决方案,但本文选用了 Thanos 方案:
Sidecar:
Store:
Compact:
Query:
Rule:
Bucket:
以下项目为 TiDB 对接 Thanos 的 docker-compose 实现:tidb-thanos-quick-start
搭建 Thanos 的 docker-compose 环境需要以下的 image:
在这个 docker compose 中,创建了两套 prometheus 监控,分别用来承接两套 tidb 系统的监控。 我们可以单独的部署两无监控的 tidb 集群,通过 docker compose 中的 prometheus 来回收 metric 的信息。这样一来,我们可以在 query 组件中同时查到两套集群的监控。甚至可以加以对比。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。