作者： 张鱼小丸子 -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 官方以及第三方资料片

• Prometheus 官方资料

• Prometheus Dlownload
  

• Prometheus 查询运算操作
  

• Prometheus 查询函数
  

• Prometheus 配置文件模板
  

• Prometheus admin API
  

• 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 资料片

• Grafana 官方资料

• Grafana Repo
  

• Grafana Docs
  

• Grafana Download
  

• Grafana ChangeLog
  

• Grafana Plugins
  

四、其他

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 清理遗留数据

• 具体可见 Prometheus FAQ