写点什么

TiDB 监控架构解读

  • 2022 年 7 月 11 日
  • 本文字数:3307 字

    阅读完需:约 11 分钟

作者: 张鱼小丸子 -PingCAP 原文来源:https://tidb.net/blog/34ce2d64

TiDB 监控架构

通过本篇文档学习 TiDB 集群监控架构 (默认按照 TiDB-ansible 部署为准) 本篇文档按照 2019 年中 TiDB-ansible master branch 描述;区别在于是否有 pushgateway 组件 (端口 9091)

一、TiDB 监控架构介绍

TiDB 使用开源时许数据库 Prometheus 组件存放监控数据 使用开源数据图形可视化工具 Grafana 做数据展示 接下来让我们看下该套监控是如何运作得……



  • 监控数据工作流程

  • Node exporter 收集主机资源负载信息

  • Blackbox exporter 根据配置文件信息主动探测目标服务状态

  • 该服务比较特殊,只是在机器启动服务,被探测目标信息需要在 Prometheus 配置文件中配置

  • TiDB PD TiKV 通过主动将监控数据推送至 Push Gateway

  • Prometheus 通过配置文件指定 Push Gateway 、 Node exporter 服务地址,Prometheus 主动获取相关信息并存在 TSDB 数据库内

  • Grafana 添加 Prometheus 数据源,根据 dashboard metric 规则主动向 Prometheus 发起查询请求,然后绘图展示。

1.1 组件介绍

  • Grafana 监控、度量分析仪表板工具,从 Prometheus 获取数据

  • Prometheus 用于存放监控数据的时序数据库

  • Push Gateway push acceptor for ephemeral and batch jobs

  • Black-box 黑盒测试工具,支持 HTTP, HTTPS, DNS, TCP and ICMP

  • Node-export 主机资源 agent 组件

1.2 监控组件端口

  • 第三方监控组件端口


1.3 TiDB Metrics 组件端口

  • TiDB 服务监控数据端口


二、Prometheus 时序数据库


  • Prometheus 工作流程

  • Prometheus server 定期从静态配置的 targets 或者服务发现的 targets 拉取数据。

  • 当新拉取的数据大于配置内存缓存区的时候,Prometheus 会将数据持久化到磁盘(如果使用 remote storage 将持久化到网络存储)。

  • Prometheus 可以配置 rules,然后定时查询数据,当条件触发的时候,会将 alert 推送到配置的 Alertmanager。

  • Alertmanager 收到警告的时候,可以根据配置,聚合,去重,降噪,最后发送告警到目的地。

  • 可以使用 API, Prometheus Console 或者 Grafana 查询和聚合数据。

2.1 Prometheus 介绍

  • 多维数据模型(时序列数据由 metric 名和一组 key/value 组成)

  • 在多维度上灵活的查询语言 (PromQl)

  • 不依赖分布式存储,单主节点工作.

  • 通过基于 HTTP 的 Pull 方式采集时序数据

  • 可以通过 Push Gateway 进行时序列数据推送 (pushing)

  • 可以通过服务发现或者静态配置去获取要采集的目标服务器

  • 多种可视化图表及仪表盘支持

  • Pull 方式

  • Prometheus 采集数据是用的 Pull 也就是拉模型, 通过 HTTP 协议去采集指标,只要应用系统能够提供 HTTP 接口就可以接入监控系统,相比于私有协议或二进制协议来说开发简单。

  • Push 方式 / 目前暂不推荐使用该方案

  • 对于定时任务这种短周期的指标采集,如果采用 Pull 模式,可能造成任务结束了,Prometheus 还没有来得及采集,这个时候可以使用加一个中转层,客户端推数据到 Push Gateway 缓存一下,由 Prometheus 从 Push Gateway Pull 指标过来。(需要额外搭建 Push Gateway,同时需要在 Prometheus 配置文件新增 job 去 Gateway 采集数据)

  • Push Gateway 性能有限,目前 TiDB-ansible 不支持自动部署多套 Push Gateway

注意

  • Prometheus 客户端库主要提供 Counter、Gauge、Histogram 、 Summery 四种主要的 metric 类型

  • Prometheus 的数据是基于时序的 float64 的值,如果你的数据值有更多类型,无法满足

  • Prometheus 不适合做审计计费,因为它的数据是按一定时间采集的,关注的更多是系统的运行瞬时状态以及趋势,即使有少量数据没有采集也能容忍,但是审计计费需要记录每个请求,并且数据长期存储,这个和 Prometheus 无法满足,可能需要采用专门的审计系统

2.3 Prometheus 官方以及第三方资料片

三、Grafana 可视化工具

为 Graphite、OpenTSDB、InfluxDB、Prometheus、Elasticsearch、MySQL 等监控提供度量分析和仪表板可视化工具

3.1 工具基础功能

用户权限


grafana 用户权限与 dashboard 页面权限需要配合设置才能做到部分用户查看 a 页面,部署用户查看所有页面;设置时会比较繁琐

面板展示 (Dashbord)


  • Dashbord 组成如下:

  • 一个 Dashbord 由多个 row 组成。

  • 一个 row 由 1~n 个 panel 组成。

  • 一个 panel 可以是 Graph、Singlestat、Table、Text 或者插件自带 panel 。

  • Graph table text singlestat 等数据通过 查询编辑器(Query Editor)书写相应的规则得到数据;可以套用 dashboard 函数

报警(Alert)

Grafana 在 4.0 版本后增加了报警功能,不过 Grafana 的报警属于数据源的后置查询且只能出发一次告警,容易在大量告警时被淹没,实时性不大能满足需求。不过可以设置一些告警指标,用于在 dashboard 上可视化巡检使用。

误差

该部分引用 Grafana 的一些使用技巧


这里有一个常见的 Grafana 误区,因为经常有用数值类型的 count_ps(每秒的数量) 来顺便获取每秒打点数量的情况,注意在这种情况下,一段时间内的打点总量需要使用 count_ps(每秒的数量) 的 avg 平均值来乘以这段时间的秒数来计算,而不是通过界面上的 Total 直接读取。


这是因为,在界面上一条曲线能够展示的点的数量是有限的,Grafana 会根据你的窗口宽度来决定返回的点数,因为像一天这样的时间段肯定没办法在界面上展示每一秒的点,毕竟总量为 86400 个点就算带鱼屏也不可能挤得下。对于无法展示的点,Grafana 默认是使用 avg 平均值的行为来修正返回点的值,举个栗子,如下图:



上图时间范围是一天,上部分为曲线面板的值,下部分为 面饼图表的值,并且上部分图标的曲线为 count 类型(十秒聚一次),可以看到 avg 平均值为 683,那么总量应该为 682 乘以 6 (如果是 count_ps(每秒的数量) 这里则是 60) 乘以 60 (一小时 60 分钟)再乘以 24 (一天 24 小时)得到 589 万,与图片中下部分的 582 万相近,因此上部分 total 的 117 万是一个完完全全让人误解的值,可以认为它毫无意义进而直接无视掉。


我们计算出来的 589 万和界面上的 582 万其实也有一点误差,不过这是可以接受的,因为 statsd 一般情况下是 UDP 的形式(它其实有 TCP 的形式),所以如果想要完全正确的数据,那么最好把打点相关的数据也入库,从数据库里后置查询出来的才是完全可靠。

3.2 Grafana 资料片

四、其他

4.1 Grafana 忘记密码

4.1.1 重新部署一套 Grafana 服务

  • 删除 Grafana 目录下数据,dashboard 二次自定义将会丢失

  • 执行 ansible-playbook deploy.yml --tags=grafana 部署

  • 执行 ansible-playbook start.yml --tags=grafana 启动

4.1.2 使用 Grafana ctl 工具修改

  • 官方文档 链接,此方法仅适用于 4.1 以上版本

  • 首先找到 grafana db 文件

  • 直接修改 grafana db

  • grafana-cli admin reset-admin-password …

  • grafana-cli admin reset-admin-password –homepath “/usr/share/grafana” newpass

4.1.3 通过 sql lite 修改数据库

使用 sql lite 工具修改 Grafana.db ; 执行以下步骤会强制将 Grafana 管理员密码重置为 admin


  1. 停止 Grafana 服务

  2. 通过 grafana.ini 配置文件找到 grafana.db 实际目录


  • 通过 find / -name "grafana.db" 查找,需要确保是 grafana.ini 文件中引用的

  • ini 文件默认在 /opt/grafana/conf/grafana.ini

  • db 文件默认在 /data.grafana/grafana.db


  1. 通过 sqllite cliet 链接数据库修改密码

4.1.4 暴力重置 Grafana db

该方式与 4.1.1 结果相同,会丢失 dashboard 信息


  1. 停止 Grafana

  2. 找到 grafana.ini 文件,并将 grafana.ini 文件中 admin_password 修改为 admin

  3. 删除掉 grafana.db 文件;文件默认在 /data.grafana/grafana.db

  4. 重启 Grafana 服务

  5. 可选步骤 // 通过 tidb-ansible 脚本导入 dashboard


  • 只有当前 Grafana 是通过 tidb-ansible 部署时才可使用

  • 执行 ansible-playbook start.yml --tags=grafana 导入


  1. 可选步骤 // 手动导入 dashboard


  • 登陆 grafana ui ,添加监控数据源,如 Prometheus

  • 登陆 grafana ui ,选择 import dashboard

4.2 Prometheus 清理遗留数据


发布于: 刚刚阅读数: 3
用户头像

TiDB 社区官网:https://tidb.net/ 2021.12.15 加入

TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目,旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/

评论

发布
暂无评论
TiDB 监控架构解读_监控_TiDB 社区干货传送门_InfoQ写作社区