TiDB-OPS

Prometheus + Grafana = TiDB 监控架构

TiDB 监控架构介绍

Prometheus 在 TiDB 的应用

monitor

监控组件端口

服务 端口 组件介绍
Grafana 3000 监控数据展示工具
Prometheus 9090 支持临时性 Job 主动推送指标的中间网关
Push Gatewagy 9091 监控数据 push 网关
node_exporter 9100 主机性能收集组件
blackbox_exporter 9104 黑盒主动探测组件
mysql_exporter 9107 MySQL 状态监测组件
kafka_exporter 9105 kafka 状态监测组件

Prometheus

Prometheus 资料片

Prometheus 介绍

Prometheus-Frame

  1. Prometheus server 定期从静态配置的 targets 或者服务发现的 targets 拉取数据。
  2. 当新拉取的数据大于配置内存缓存区的时候,Prometheus 会将数据持久化到磁盘(如果使用 remote storage 将持久化到云端)。
  3. Prometheus 可以配置 rules,然后定时查询数据,当条件触发的时候,会将 alert 推送到配置的 Alertmanager。
  4. Alertmanager 收到警告的时候,可以根据配置,聚合,去重,降噪,最后发送警告。
  5. 可以使用 API, Prometheus Console 或者 Grafana 查询和聚合数据。

注意

Prometheus 基础概念

Prometheus 基础概念


Grafana

为 Graphite,InfluxDB 和 Prometheus 等提供漂亮的监控和度量分析和仪表板工具

Grafana 资料片

工具介绍

用户权限

Grafana 的权限分为三个等级:Viewer、Editor 和 Admin,Viewer 只能查看 Grafana 已经存在的面板而不能编辑,Editor 可以编辑面板,Admin 则拥有全部权限例如添加数据源、添加插件、增加 API KEY。

数据源(DataSource)

面板展示 (Dashbord)

Grafna-dashboard 组成

报警(Alert)

Grafana 在 4.0 版本后增加了报警功能,不过 Grafana 的报警属于数据源的后置查询,实时性不大能满足需求。

其他

误差

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

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

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

Grafna

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

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