TIDB 6.0新特性漫谈之Clinic

2022-11-30 15:50:08

1 个月前 TIDB 官方展开了一个 TiDB 6.0 Book Rush 活动，作为2年前参与过：TiDB in action 的我来说，还是比较熟悉的，之前电子书编写采用了比较极客的方式，有个 36 小时的实现，大家都编写自己领取的文章模块后，在 github 上提交自己的文章，本次 TiDB 6.0 Book Rush 则主要针对 6.0 新提出的 14 个新特性展开，这样大家试用+写文章时也能体现出重点，顺带帮官方测测BUG。哈哈。

本文主要涉及到 TiDB 6.0 的新特性 Clinic。

一、传统的故障排查

谈 Clinic 这个工具之前，不得不讲讲之前遇到故障时，找官方排查的血泪史。遇到bug时，官方技术支持一般要求提供：TiDB集群信息(版本，display )，grafana 监控、各个组件(TiDB/PD/TIKV/TiCDC/DM)日志、系统参数配置等。从 asktug 的帖子说明就可以看出需要用户提供的一些清单，主要包括 TiDB 集群节点信息、配置信息、集群监控、对应出问题组件的日志：

【 TiDB  使用环境】
【概述】 场景 + 问题概述
【背景】 做过哪些操作
【现象】 业务和数据库现象
【问题】 当前遇到的问题
【业务影响】 
【TiDB 版本】 
【应用软件及版本】
【附件】 相关日志及配置信息

* TiUP Cluster Display 信息
* TiUP CLuster Edit config 信息

监控（https://metricstool.pingcap.com/)
* TiDB-Overview Grafana监控
* TiDB Grafana 监控
* TiKV Grafana 监控
* PD Grafana 监控
* 对应模块日志（包含问题前后 1 小时日志）

1、提供监控

先聊 grafana 监控，下面的各个阶段都是我之前经历和使用过的提供监控的方式方法，大家用的过麻烦点赞。

（1）手动截图，刚开始技术支持会按照排除法给用户来定位问题。比如一个 oom 问题可能有几种导致的原因，技术支持同学会一个个让你截图来排除。这时的问题如下：

混乱繁杂（技术支持只能靠一点点猜想找你要截图，而且需要看看多个截图，光截图和问题判断的相互配合就需要大家的一上午或者下午的时间）
时间跨度不好定（比如：看详情需要 30 分钟内，如果要对比昨天的数据则需要看 2 天，同一个图可能需要截图不同时间段）
拿 tikv detail 这个dashboard来讲，上百个监控指标，光打开就分钟级别，再找就需要半分钟。
效率低下，刚开始还担心数据安全，截图后，自己还需要加“马赛克”，再加上排除法的来来回回的反馈，半天的时间很快就过去了，问题还没有及时的定位。

（2）后来 PingCAP 官方提供了一个“脚本”，脚本的好处就是避免手工截图，可以以 json 的方式导出 grafana 监控，然后发送给官方技术支持，他们收到这个 json 可以自己 load 到本地的 grafana 查看，避免了截图的效率低下，这个脚本也可以自己保存 json 数据。

脚本如下

/* Copyright 2020 PingCAP, Inc. Licensed under MIT. */
"use strict"
var t={t:"Script failed to run. Please ensure it is running on the Grafana v6.x.x dashboard page.",
i:"Going to export snapshot of the current dashboard: ",s:"Note: Only metrics from visible panels can be exported",
o:"Number of panels",l:"Loading panels",h:"Expand all rows",p:"Export",u:"Export immediately",cancel:"Cancel"}
try{
var e=angular.element,i=document.styleSheets[0],a=[".__dexport_hint{z-index:2222;position:fixed;background:#fff;color:#000;padding:1em;font-size:18px;border-left:3px solid #faad14;right:0;top:5em;opacity:.8;min-width:30em}",".__dexport_hint:hover{opacity:1}",".__dexport_hint button{margin:0 1em}",".__dexport_hint button[disabled]{opacity:.5}",".__dexport_hint progress{margin-right:1em;vertical-align:middle;width:18em}"]
new(function(){function n(){var n=this,s=e(document).injector()
this.m=s.get("timeSrv")
var o=this.m.dashboard
a.forEach(t=>i.insertRule(t,0)),this.v=e("<span>"),this.g=e('<progress value="0">'),
this._=e('<button style="font-weight:bold">').text(t.p).one("click",()=>n.k()),
this.P=e("<button>").text(t.h).on("click",()=>{o.expandRows(),n.S(()=>{n.T()})})
var r=/^(Mac|iP)/.test(navigator.platform)?"flex-direction:row-reverse":"justify-content:center"
this.j=e('<div class="__dexport_hint">').append(e("<p>").text(t.i).append(e("<strong>").text(o.title)),e("<p>").text(t.s).append(this.P),e('<p style="font-size:.8em">').append(this.g,this.v),e('<p style="display:flex;'+r+'">').append(this._,e("<button>").text(t.cancel).on("click",()=>n.I()))),
this.L=0,e(document.body).append(this.j),this.N=setInterval(()=>n.T(),500)}return n.prototype.T=function(){
var i=this,a=e(".panel-container"),n=a.length
if(0===this.L)this.v.text(t.o+": "+n),this._.prop("disabled",0===n)
else{var s=n-a.find(".panel-loading:visible").length,o=(100*s/n||0).toFixed(1)
this.v.text(t.l+": "+o+"% ("+s+"/"+n+")"),this.g.prop({value:s,max:n}),n>s?2!==this.L&&(this.L=2,
this._.prop("disabled",!1).text(t.u).one("click",()=>i.O())):this.O()}},n.prototype.k=function(){
var t=this,i=this.m.dashboard
this.B=i.refresh,this.m.setAutoRefresh(),e(".panel-loading").removeClass("ng-hide"),this.S(()=>{t.L=1,
t._.prop("disabled",!0),i.snapshot={timestamp:new Date},i.startRefresh()})},n.prototype.S=function(t){var i=e(".layout")
i.hide(),this.m.dashboard.removePanel(null),setTimeout(()=>{t(),i.show()},100)},n.prototype.O=function(){
var t=this.m.dashboard,i=t.snapshot.timestamp.toISOString(),a=t.getSaveModelClone(),n=a.title
a.time=this.m.timeRange(),a.id=null,a.uid=null,a.title=n+" (exported at "+i+")"
var s={meta:{isSnapshot:!0,type:"snapshot",expires:"9999-12-31T23:59:59Z",created:i,
grafana:grafanaBootData.settings.buildInfo},dashboard:a,overwrite:!0}
this.I()
var o=new Blob([JSON.stringify(s)],{type:"application/json"}),r=URL.createObjectURL(o),l=e("<a>")
l.prop({href:r,download:n+"_"+i+".json",target:"_blank"}),e(document.body).append(l),l[0].click(),setTimeout(()=>{
URL.revokeObjectURL(r),l.remove()},0)},n.prototype.I=function(){var t=this.m.dashboard
delete t.snapshot,t.forEachPanel(t=>delete t.snapshotData),t.annotations.list.forEach(t=>delete t.snapshotData),
this.B&&this.m.setAutoRefresh(this.B),clearInterval(this.N),this.j.remove(),a.forEach(()=>i.deleteRule(0))},n}())
}catch(e){console.error(e),alert(t.t)}

PS：脚本的主要问题，像tikv detail存储的时间比较长，另外grafana版本的变更/chrome的升级也可能带来兼容性的问题，需要频繁的调整脚本。另外你可能还需要具备“前端工程师”的能力。

2、提供日志

有时监控不能完全确认问题，还需要有日志的辅助，这时就需要提供各个组件的日志，就拿一个慢日志造成的tikv oom 举例，需要提供的日志：

（1）TiDB server 的日志，找“Welcome”关键词(代表重启)的附近 [expensive_query] 相关日志。

（2）TiDB 的 slow log，找 query-time，total-keys，process-keys 等指标，来找出导致问题的 SQL。

（3）Tikv 的日志，看是否读写有热点。

（4）如果涉及到统计信息不更新导致慢查询的问题，可能也需要查看 PD Leader 相关的日志。

提供日志时问题如下：

（1）有时需要提供所有 TIKV 组件的日志，假如你的 TiKV 节点比较多，又没有 ELK 这种日志收集平台的话，一台台的远程登录，找对应时间段的日志（可能因为日志切分放到了不同的文件），折腾一遭非常的痛苦。

（2）有时需要提供较长时间的日志文件过大，发送给官方人员的还需要各种渠道。

3、涉及的安全问题

很多小伙伴把自己业务的 grafana 监控放到 asktug 这个公共平台，对于大量的监控截图虽说是可以抹除敏感信息，但是光加马赛克就各种折腾和大量时间消耗。另外日志等信息放 asktug 这个平台就不好弄了，因为 asktug 是注册就可以看到大家发的帖子，包括各种截图以及日志信息。所以不免导致上传者担心的自己 TIDB 集群信息安全。

二、PingCAP Clinic

我想告诉大家的是，救星终于来了，以后 asktug 提故障帖子，不需要各种截图还打马赛克，也不需要脚本导json，各种苦哈哈的提供各种组件的日志。Pingcap 公司的技术人员，根据多年来问题排查的经验，提供了 Clinic 这个诊断服务来统一收集集群的各个指标(下面会有详细的指标收集说明)、统一上传到 Pingcap 公司的Clinic Server上，在 asktug 上，你只需要提供给官方技术一个上传完毕的链接即可，不要担心，你上传的数据首先只能官方人员查看，并且在 case 解决并关闭后的 90 天内删除，所以再也不用担心 asktug自己公司集群信息暴露的安全问题。

所以通过上面的说明可以了解到，Clinic 这个解决方案提供了2个组件。

Clinic 数据采集端 Diag ，用来采集各种数据。
Clinic Server 用于接收用户上传的各种采样数据。

1、Diag 都采集什么数据

（1）集群信息

包括集群基本信息，集群节点的硬件配置、内核参数等。

tiup cluster audit/display/edit-config获取集群的信息。
tiup exec --command可以执行 Insight 等命令获取系统信息，包括内核日志、内核参数、系统和硬件的基础信息。

（2）TiDB 组件配置和日志

tidb/pd/tikv/tiflash/ticdc/dm 的配置和日志，底层使用 SCP 直接从目标组件的节点采集日志文件和配置文件

(3) 监控

通过 Prometheus 提供的 HTTP API，数据收集组件可获取 Alert 和 metric 监控指标
另外 TiDB 的各个组件本身就暴露了 HTTP 接口，数据收集组件可以实时收集采样信息和进行性能采样。

PS：这些不就是我们之前苦哈哈的手动需要提供的么？以后可以通过 Diag 数据收集工具几个命令搞定。

2、使用 Diag 采集集群数据

（1）安装 Diag 诊断客户端：部署在集群侧的工具，用于采集集群的诊断数据 (collect)、上传诊断数据到 Clinic Server、对集群进行本地快速健康检查 (check)。

在tiup中控机上使用下面的命令安装，看到安装应该是 v0.7.1 版本：

tiup install diag
download https://tiup-mirrors.pingcap.com/diag-v0.7.1-linux-amd64.tar.gz 17.57 MiB / 17.57 MiB 100.00% 10.74 MiB/s

（2）采集近2小时的诊断数据。

tiup diag collect ${cluster-name} 
#执行命令过程不会马上收集，会大概展示要收集的内容、数据的大小，数据的路径：以diag开头的文件夹，确认后开始收集，收集完毕，进入路径发现以下内容：
cluster_audit       #集群的audit信息，执行tiup cluster audit|grep 集群得到
cluster.json        #集群的display信息，执行tiup cluster display的结果
fTLypmPrm8j_diag_audit.log    #tiup diag的执行日志，通过该日志可以看出详细的收集流程
meta.yaml           #集群的meta信息，执行tiup cluster edit-config可以得到
monitor/            #集群的大量的详细的grafana监控dashboard的json文件
test1.xxxx.com/     #各个tidb组件的详细日志+系统配置
..........
test10.xxxx.com/   #进入该目录
    datax/        #TiDB集群组件配置和日志
    dmesg.log     #系统内核日志，记录了操作系统硬件故障/oom kill等信息
    insight.json  #系统和硬件的基础信息
    limits.conf   #系统limit.conf的信息
    ss.txt        #系统网络情况
    sysctl.conf   #操作系统内核参数配置sysctl.conf

PS：默认 diag 会采集近2小时数据，如果要采集更早的某个时间段，可以通过 --from/--to来指定，详见 tiup diag collect --help

(3) 上传数据到 Clinic Server 给PingCAP官方技术人员查看。

tiup diag upload ${filepath}

完成上传后，Diag 会提示诊断数据的下载路径 Download URL，以后只需要提供该 URL 给官方支持人员就OK了，然后就是等反馈了。

PS:早期我使用的时候，上传还是统一的用户名和密码，新的版本已经需要

3、Clinic 还能干啥？

（1）集群抖动现场保留

当集群出现问题，但无法马上进行问题分析时，你可以先使用 Diag 采集数据，并将其数据保存下来，用于自己后期进行问题分析。

（2）日常巡检：预测可出现的集群的配置问题

Clinic 设计之初应该就是以后做日常 TIDB 巡检的工具，不过当前的 Technical Preview 版本只提供对配置项检查，用于发现不合理的配置，并提供修改建议。

#执行收集当前集群配置
tiup diag collect ${cluster-name} --include="config"
# 执行完毕后会生成一个数据目录
tiup diag check ${subdir-in-output-data}
#查看结果发现提示了几个Rule name tidb-max-days/backups、pdconfig-max-days/backups的warning,每个报警都有个链接可以知道具体的报警原因，比如下面就是TiDB 的日志大保留的天数设置为0（保存）导致的警告
#### Rule Name: tidb-max-days
- RuleID: 100
- Variation: TidbConfig.log.file.max-days
- For more information, please visit: https://s.tidb.io/msmo6awg
- Check Result:
  TidbConfig_xxxx.com:4000   TidbConfig.log.file.max-days:0   warning
  TidbConfig_xxxx.com:4000   TidbConfig.log.file.max-days:0   warning

（3）收集DM集群的诊断数据

主要采集DM集群信息，dm-master/worker的日志和配置，以及DM的监控，DM集群各个节点的硬件信息。