课程名称：课程版本（101/201/301）+ 3.7.1 Metrics that DBAs should notice（运维中的关键监控）
学习时长：
40min
课程收获：
熟悉运维过程中需要关注的性能相关的监控指标
课程内容：
系统相关指标
CPU:超过80%，可能会成为系统瓶颈
CPU load:应该小于CPU的总核数
内存使用:
TiKV内存不要超过60%，剩下的留给page cache和系统
TiDB节点内存不要超过80%
Network traffic（网络流量）:不要打满网卡
IO：util不要超过80%
TiDB相关指标
query summary：
.99延迟应该小于100ms
不应该有slow query
QPS中idel CPS:这个值的作用是看延迟出现在客户端还是数据库端
server：
get token duration：最好小于1ms，如果很高，需要调整下token-limit
Executor:
parser duration:sql解析延迟最好小于10ms
Compile duration：计算执行计划的延迟，最好小于30ms
KV Errors：
lock resolve ops：出现锁冲突时要解锁，说明不同的事务之间是有冲突的，最好小于500，锁冲突严重，建议使用悲观锁
kv backoff ops：最好小于500，如何很高可能是tikv端有异常，如region不可用
PD Client：
PD TSO .99 wait duration:最好小于5ms
TiKV相关指标
Cluster：
region：单个TiKV推荐5w以下，region间的心跳和raft状态机开销都会比较大
gRPC：
.99 gRPC message duration:最好小于100ms
Thread CPU：
raft store cpu：最好小于75%*raftstore.store-pool-size
async apply cpu:最好小于75%*raftstore.apply-pool-size
scheduler work cpu:最好小于80%*store.scheduler-work-pool-size
gRPC poll CPU:最好小于80%*server.grpc-concurrency
Unified read pool CPU:最好小于80%*readpool.unified.max-thread-count
Storage ReadPool CPU:最好小于80%*readpool.storage.normal-concurrency
Raft IO
append log duration:.99 latency < 10ms
apply log duration:.99 latency < 30ms 把raftlog里要操作的事情，写到数据库里面
commit log duration:.99 latency < 30ms raft复制过程中，从发起raft复制到结束的过程，如果网络延迟很高，可能会反应到这个监控里面
上面的 .999 latency指标
Raft propose
Propose wait duration:.99 latency < 20ms 请求发过来了，raft模块什么时候处理，这段等待的时间，如果这段时间特别长，说明raft模块繁忙，是不是刷盘很慢，cpu瓶颈等
aplly wait duration:.99 latency < 50ms 把commitlog 扔给apply模块，它什么时候进行apply，
上面的 .999 latency指标
Errors
Server is busy：最好是没有这个东西，监控里面标明原因
**PD相关指标**
etcd
99% wal fsync duration:最好小于5ms
Heartbeat
99% region heartbeat latency:最好小于5ms ,如果时间非常长，说明PD负载高
**Dashboard**
## 学习过程中遇到的问题或延伸思考：
- 问题 1：
- 问题 2：
- 延伸思考 1：
- 延伸思考 2：
## 学习过程中参考的其他资料
<!-- 注释：学习过程如果有参考其他文档或博客，可以把链接贴到下方 -->
<!-- 注释：参考格式-->
- [文档名称](文档链接)
- [文档名称](文档链接)
- [文档名称](文档链接)