用TiTop在终端快速观察TiDB集群
TiDB 是一款兼容 MySQL 协议的开源分布式 SQL 数据库，采用计算与存储分离架构。TiDB Server 负责 SQL 解析与执行，TiKV 提供分布式事务型键值存储，PD 负责集群调度和元数据管理。它适合需要水平扩展、高可用和强一致事务的在线业务。
随着集群规模增大，排查问题时往往需要同时观察 SQL 吞吐、节点资源、TiKV 请求和活跃会话。TiTop 是一个面向 TiDB 的轻量级终端监控工具，可以直接查询 Prometheus，并按需连接 TiDB SQL 端口，把常用诊断信息集中在一个终端中，如果企业没有部署TiDB企业版TEM工具是比较缺一个能够同时观察到Prometheus和TiDB SQL层面的趁手方便工具，TiTop便是借鉴和参考Oracle的oratop工具来设计和开发完成的一款终端实时监控工具。
# 仅使用 Prometheus
./titop -m production@10.0.0.10:9090
# 启用 SQL 诊断功能
./titop -m production@10.0.0.10:9090 \
-u monitor -p 'password'
生产环境建议通过环境变量提供密码，并使用只读、最小权限的专用监控账号。
集群活动概览
首页集中展示 QPS、事务完成速率、P99 延迟、连接数、活跃度、错误率以及 TiDB、TiKV、PD 节点状态。它适合在故障发生时先快速判断问题属于吞吐变化、延迟升高、错误增加，还是组件掉线。
集群节点
节点面板展示各实例的角色、状态、版本、运行时间、CPU、内存和部分请求指标。节点默认按照异常状态优先、CPU 使用率降序排列，便于快速找到离线或负载较高的实例。
TiKV 线程池
TiKV 线程池面板展示 Unified Read、Raft Store、Async Apply、gRPC Poll、Storage Read 和 GC Worker 的 CPU 使用情况。某个线程池持续繁忙时，可以结合 TiKV 请求延迟进一步判断读取、Raft、Apply 或 GC 是否成为瓶颈。
TiKV 请求
请求面板按照请求类型展示 OPS、平均延迟、P99 延迟和时间负载。相比只看请求次数，时间负载更容易发现“请求量不高但单次耗时很长”的异常。
SQL 类型与活跃会话
SQL 面板将语句分为 DML/事务、DDL、管理操作和其他类型，并展示当前正在执行的会话。活跃会话按执行时间降序排列，可查看用户、来源、数据库、Digest、执行时间、内存、临时磁盘空间和 SQL 摘要。
当活跃会话超过终端高度时，TiTop 会优先保留运行时间较长的会话，并自动省略其余内容，不会不断向下堆积造成页面滚动错位。页面也会根据终端宽度切换完整、紧凑或极简布局。
Schema Load
Schema Load 面板通过相邻 Statement Summary 快照计算短周期负载，可以观察各 Schema 的 QPS、写入 QPS、平均延迟、错误率、执行时间负载、Keys、Coprocessor Task、Backoff 和事务重试等指标。
这个面板更适合比较“当前哪些默认 Schema 相对更活跃”，不应直接用于计费、审计或精确请求量统计。
错误与陈旧数据
Prometheus 指标采用独立查询。单个指标查询失败时，TiTop 会尽可能保留上一次成功结果，并在错误面板标记采集错误和陈旧时间，避免短暂故障让整个页面全部变成零值。
适用场景
TiTop 比较适合以下场景：
- 日常集群巡检；
- 压测期间实时观察负载；
- 故障现场快速定位异常组件；
- 通过 SSH 在远程终端中监控；
- 获取一次性文本或 JSON 快照供脚本使用。
TiTop 的定位是快速、轻量的现场观察工具，而不是替代 TiDB Dashboard、Grafana 和 Prometheus 告警体系。日常监控可以依靠 Dashboard 和告警平台，出现问题时再使用 TiTop 把关键指标集中到一个终端中，通过快捷键可以快速的在不同模式下灵活切换观察不同角度状态，两者可以形成很好的互补。
