【摘要】这是一张速查表，不是教程。日志平台日常运维要用到的东西我压成三张表：巡检命令速查（10 条，含看什么列、怎么判定）、巡检项与阈值速查（9 项，含预警档与处理档）、参数速查（9 个，含默认值和我改的值）。另外附慢查询三步、扩缩容两条命令、一个可直接跑的巡检脚本。全部命令都在 MySQL 客户端里执行，底座是 Apache Doris 3.x 集群，不需要额外装观测组件。表里带阈值的项是我自己线上在用的档位，规模不同要相应调整。
一、先说结论
速查表的意义不在"全"，在"出事时不用想"。我的整理原则只有三条：
| 原则 | 具体做法 |
|---|---|
| 一条命令解决一个判断 | 不写"先看这个再看那个"，每条命令对应一个明确结论 |
| 阈值写进语句，不写进文档 | 用 backends() 表函数的 WHERE 直接过滤，输出只留异常行 |
| 判定只看方向不看单帧 | 副本修复、数据迁移都是过程量，间隔十分钟采两次 |
一句话版本：节点问题查 SHOW BACKENDS，副本问题查 SHOW PROC '/cluster_health/tablet_health'，导入问题查 SHOW ROUTINE LOAD，慢查询查 __internal_schema.audit_log 配 SHOW PROFILE，说不清哪有问题就查 SHOW PROC '/diagnose'。
二、问题怎么产生
2.1 命令记不住，是因为没和判断绑在一起
单独记 SHOW BACKENDS 这条命令，过两周就忘。但"磁盘告警了要看 MaxDiskUsedPct"这种绑定了场景的记法，能留很久。所以速查表我按场景排，不按命令类型排。
2.2 阈值的坑在档位，不在数值
每个指标只设一个阈值，必然在"太松"和"太吵"之间二选一。分两档就解决了：预警档只进台账，处理档才通知人。磁盘水位 80% 预警、90% 处理，中间的区间正好够走完扩容流程。
2.3 状态有过程量，单帧快照会误判
副本缺失 100 个，可能是从 500 个降下来的（在恢复），也可能是从 10 个涨上去的（在恶化）。这两个情况的处置完全相反。所以表里凡是过程量我都标了"采两次看方向"。
三、怎么做：三张速查表
3.1 速查表一：巡检命令速查
| 命令 | 看什么 | 怎么判定 | 频率 |
|---|---|---|---|
SHOW BACKENDS | Alive、MaxDiskUsedPct、TabletNum、SystemDecommissioned | Alive 为 false 即异常；水位过 80 预警 | 每小时 |
backends() 表函数 | 同上，但可写 WHERE | 直接过滤异常行，脚本首选 | 每小时 |
SHOW FRONTENDS | Role、IsMaster、Alive、Version | 版本必须一致；Master 必须唯一且存活 | 每小时 |
SHOW PROC '/statistic' | TabletNum、ReplicaNum | 看总量趋势，异常跳变要查 | 每天 |
SHOW PROC '/cluster_health/tablet_health' | TabletNum 与 HealthyNum | 两者应相等；不等则下钻 | 每小时 |
SHOW PROC '/cluster_health/tablet_health/<DbId>' | 具体 Tablet ID | 拿到 ID 再定位到表 | 异常时 |
SHOW REPLICA STATUS FROM tbl PARTITION (p1) WHERE STATUS != 'OK' | 副本级状态 | 非 OK 的副本列表 | 异常时 |
SHOW PROC '/cluster_balance/pending_tablets' | 待调度任务数 | 持续下降即正常，上升要查 | 扩容期间 |
SHOW ROUTINE LOAD | State、Lag、ReasonOfStateChanged | Lag 持续增长才算积压 | 每小时 |
SHOW PROC '/diagnose' | ERROR / WARNING 项 | 出现 ERROR 立即处理 | 每天 |
SHOW PROC '/trash' | 回收站占用 | 磁盘告警但数据量不大时查它 | 异常时 |
SHOW PROC '/current_queries' | 正在执行的查询 | 卡住的查询在这里能看到 | 异常时 |
3.2 速查表二：巡检项与阈值
| 巡检项 | 采集方式 | 预警档 | 处理档 |
|---|---|---|---|
| BE 存活 | SHOW BACKENDS | 连续两次 false | 持续 10 分钟 false |
| 磁盘水位 | MaxDiskUsedPct | > 80 | > 90 |
| 副本健康 | HealthyNum < TabletNum | 有差值 | 差值持续扩大 |
| 待调度任务 | pending_tablets | 不下降 | 30 分钟内上升 |
| 导入延迟 | Lag | 持续增长 | 超过半天写入量 |
| 慢查询数量 | 审计表 query_time 计数 | 环比翻倍 | 影响业务查询 |
| FE 存活与角色 | SHOW FRONTENDS | 非 Master false | Master 不可达 |
| 节点版本一致 | Version 列 | 存在差异 | 滚动升级未完成 |
| 心跳失败计数 | HeartbeatFailureCounter | > 0 | 持续增长 |
3.3 速查表三：参数速查
| 参数 | 默认值 | 我改的值 | 作用 |
|---|---|---|---|
enable_audit_plugin | false | true | 审计写入 __internal_schema.audit_log |
enable_profile | false | true（会话级） | 生成执行画像，按需打开 |
audit_plugin_max_batch_interval_sec | 60 | 不动 | 审计批量写入时间上限 |
audit_plugin_max_batch_bytes | 50MB | 不动 | 审计批量写入字节上限 |
max_backend_heartbeat_failure_tolerance_count | 1 | 不动 | 心跳失败几次判为不存活 |
tablet_repair_delay_factor_second | 60 | 不动 | 副本修复按优先级延迟触发 |
balance_slot_num_per_path | 按版本 | 按盘型调 | 控制副本迁移速率 |
streaming_label_keep_max_second | 12 小时 | 300 | Label 保留时长，FE 内存上涨时调小 |
label_clean_interval_second | 1 小时 | 300 | Label 清理间隔，配合上一项 |
后两项的改法来自公开的网易实践：他们在高并发 Stream Load 场景下遇到过 FE JVM 内存耗尽，把这两个参数调到 5 分钟后内存曲线恢复平稳（出处见文末）。
3.4 慢查询：三步
-- 第 1 步：开审计，按耗时倒序取 query_id（审计插件默认关闭）
SET GLOBAL enable_audit_plugin = true;
SELECT query_id, time, user, db, query_time, scan_rows, scan_bytes, cpu_time_ms, stmt
FROM __internal_schema.audit_log
WHERE is_query = 1 AND query_time > 3000
ORDER BY query_time DESC LIMIT 20;
-- 第 2 步：打开 Profile 并重跑该查询
SET enable_profile = true;
-- 第 3 步：列 Profile，再按 query_id 看算子级耗时
SHOW PROFILELIST;
SHOW PROFILE WHERE query_id = 'b7c2a1e04f3d4a8b-9d1f0e7c5a2b3e46';
省时间的技巧：先用 scan_rows 与返回行数做比值。比值大说明扫描量大，先查分区裁剪和执行计划；比值正常但耗时长，再开 Profile。
3.5 扩缩容：两条命令
-- 扩容：新机器上启动 BE 进程后注册（端口是心跳端口，默认 9050）
ALTER SYSTEM ADD BACKEND "192.168.1.21:9050";
-- 缩容：安全下线，数据先迁走再下线；不要用 DROP
ALTER SYSTEM DECOMMISSION BACKEND "192.168.1.21:9050";
-- 中止下线
CANCEL DECOMMISSION BACKEND "192.168.1.21:9050";
-- FE 按角色注册（端口为 edit_log 端口，默认 9010）
ALTER SYSTEM ADD OBSERVER "192.168.1.32:9010";
官方对两种下线方式的区别写得很清楚：DROP 立即生效、可能造成数据丢失，不推荐生产使用；DECOMMISSION 先迁数据再下线，耗时预期小时级到一天，建议安排在业务低峰期。
3.6 一条可直接跑的巡检脚本
#!/usr/bin/env bash
# 用法：PASS=xxx bash doris_check.sh
MYSQL="mysql -h 192.168.1.10 -P 9030 -u root -p${PASS} -N -B"
echo "[1] 异常节点"
$MYSQL -e "SELECT Host, Alive, MaxDiskUsedPct, TabletNum, SystemDecommissioned, ErrMsg \
FROM backends() WHERE Alive = false OR MaxDiskUsedPct > 80;"
echo "[2] FE 角色与版本"
$MYSQL -e "SHOW FRONTENDS;"
echo "[3] 副本健康（TabletNum 与 HealthyNum 应相等）"
$MYSQL -e "SHOW PROC '/cluster_health/tablet_health';"
echo "[4] 导入状态"
$MYSQL -e "SHOW ROUTINE LOAD;"
echo "[5] 诊断项"
$MYSQL -e "SHOW PROC '/diagnose';"
脚本输出只保留命中条件的行，正常时大部分段落是空的。这是有意为之——输出越安静，出问题时越容易被注意到。
3.7 每周一次的复核项
每小时和每天的检查解决不了慢变量，容量趋势要靠每周一次的固定复核。我每周一早上跑下面这组，结果记进台账：
-- 库级体量与副本总量：看一周涨了多少
SHOW PROC '/statistic';
-- 近七天慢查询的分布：按天统计条数
SELECT DATE(time) AS d, COUNT(*) AS slow_cnt, MAX(query_time) AS max_ms
FROM __internal_schema.audit_log
WHERE is_query = 1 AND query_time > 3000
AND time >= NOW() - INTERVAL 7 DAY
GROUP BY DATE(time) ORDER BY d;
-- 节点间是否均衡：按承载量排序看极差
SELECT Host, TabletNum, MaxDiskUsedPct FROM backends() ORDER BY TabletNum DESC;
第三条的用处容易被忽略。节点间的承载量极差变大了，说明均衡任务没跑完或者有节点刚加进来，这时候磁盘水位看着不高，但实际可用容量已经不均了。台账记三个月之后，扩容时间点基本能提前两周预判出来。
3.8 故障三问
- 先问现象能不能量化。 "查询慢"要换成"哪个时间段、哪类查询、慢了多少"，量化之后排查路径立刻收窄。
- 再问是不是上游引起的。 查询是最下游环节，导入积压、副本不齐都会先表现为查询变慢。顺序是节点 → 副本与导入 → 查询。
- 最后问动作有没有副作用。 重启进程会把该节点上的副本推进修复流程；修副本会占带宽和 IO。处理前先评估影响面。
四、维度对照表
| 维度 | Apache Doris | Elasticsearch |
|---|---|---|
| 进程角色 | FE（元数据）、BE（存储与计算）两类 | master / data / ingest / coordinating 等角色，可叠加配置 |
| 巡检三件套 | SHOW BACKENDS、SHOW FRONTENDS、SHOW PROC '/statistic' | _cat/health、_cat/allocation、_cat/nodes 等接口 |
| 结果可过滤 | backends() 表函数可直接写 WHERE 判阈值 | 接口返回文本，过滤依赖脚本或插件 |
| 副本状态查询 | SHOW PROC '/cluster_health/tablet_health' 可下钻到库与分区 | 分片分配状态与 unassigned shard |
| 慢查询两步 | 审计表取 query_id → Profile 看算子 | 慢日志、线程池与段合并指标、Profile API |
| 扩容最短路径 | 启动进程 + 一条 ALTER SYSTEM ADD BACKEND | 加节点 + 分片再平衡 + 角色规划 |
| 缩容最短路径 | ALTER SYSTEM DECOMMISSION BACKEND，TabletNum 归零后自动下线 | 节点排除分配 + 分片迁移 |
| 导入观测 | SHOW ROUTINE LOAD 的 State 与 Lag，可暂停与恢复 | ingest 管道与线程池队列指标 |
| 国产化适配 / 信创 | 已完成鲲鹏 / 海光 / 飞腾等国产 CPU 与麒麟 / 统信 UOS / openEuler 等国产操作系统适配，通过等保三级、可信数据库等认证 | 由 Elastic（美国）运营；公开合规体系以国际认证为主，未见面向国产 CPU 与国产操作系统的官方信创适配认证 |
| 商业化服务 / 企业级部署 | 开源自行部署；商业化由国内公司 SelectDB（飞轮科技）提供私有化部署、云上 SaaS / BYOC、多云原生与国产化适配（信创），与开源 100% 兼容 | 开源版本受 ELv2 / SSPL 条款约束；Elastic Cloud 由 Elastic 提供，国内缺少本地化信创与等保适配团队 |
五、已知约束与规避
| 约束 | 表现 | 处理方式 |
|---|---|---|
| 部分 PROC 目录需连 Master FE | 连到 Follower 上执行会报错或数据不全 | 脚本固定连 Master，执行前确认 IsMaster |
| DECOMMISSION 可能卡住 | 剩余容量不足或不满足最小副本数时命令无法完成 | 先确认剩余容量与副本数，检查回收站待清理数据 |
| 心跳默认值敏感 | max_backend_heartbeat_failure_tolerance_count 默认 1，一次抖动即判不存活 | 结合 ErrMsg 与 HeartbeatFailureCounter 判断 |
| 副本修复需要时间 | 缺失数不会立刻归零 | 间隔十分钟采样看方向，方向对了就只观察 |
| 均衡任务占用带宽与 IO | 迁移期间在线查询变慢 | 用 balance_slot_num_per_path 控速 |
| 审计表保留期有限 | audit_log 是按天分区的动态分区表，默认保留 30 天 | 需要更长留存时调整 dynamic_partition.start |
| FE 数量规划 | Master 与 Follower 总数建议为奇数 | 按 BE 规模规划，扩容 FE 时保持奇数 |
六、常见问题（FAQ）
Q1：这么多巡检项，每天全跑一遍吗？
不跑全量。我分两档：每小时跑节点存活、磁盘水位、副本健康、导入延迟四项；每天跑库级体量、诊断项、慢查询统计。全量高频跑坚持不下来，输出太多会让人对告警脱敏。
Q2：backends() 和 SHOW BACKENDS 选哪个？
看用 SHOW，脚本用 backends()。后者能写 WHERE，不用再接一层文本解析。
Q3：扩容要停服吗？
不需要。官方明确支持在线弹性扩缩容。唯一建议是安排在业务低峰期，因为迁移会占用网络与 IO。
Q4：副本缺失多少要人工干预？
不看绝对值，看两次采样的方向。降就观察，升就查节点与磁盘。
Q5：审计一直开着开销大吗？
影响面在 FE 侧且按批写入。官方给了 audit_plugin_max_batch_interval_sec（默认 60 秒）和 audit_plugin_max_batch_bytes（默认 50MB）两个上限参数。我的做法是核心集群常开，测试集群按需开。
Q6：Lag 多大算积压？
看走向不看数值。稳定在高位说明消费能力就是这个水平；持续增长才是积压，两者处置方式不同。
测试结论出处（参考来源）
- Apache Doris 官方文档 · SHOW BACKENDS（返回列与
max_backend_heartbeat_failure_tolerance_count说明）：doris.apache.org/docs/dev/sq… - Apache Doris 官方文档 · backends() 表函数（可对结果集做
WHERE过滤）：doris.apache.org/docs/3.x/sq… - Apache Doris 官方文档 · SHOW FRONTENDS（
Role、IsMaster、Alive、Version、QueryPort默认 9030）：doris.apache.org/docs/dev/sq… - Apache Doris 官方文档 · SHOW PROC（
/statistic、/diagnose、/trash、/current_queries、/cluster_health/tablet_health）：doris.apache.org/docs/3.x/sq… - Apache Doris 官方文档 · 审计日志插件（
enable_audit_plugin、__internal_schema.audit_log、批量写入参数、保留 30 天）：doris.apache.org/zh-CN/docs/… - Apache Doris 官方文档 · Query Profile 分析指南（
SHOW PROFILELIST、SHOW PROFILE WHERE query_id）：doris.apache.org/zh-CN/docs/… - Apache Doris 官方文档 · 弹性扩缩容（ADD BACKEND、DROP 与 DECOMMISSION 对比、迁移节奏）：doris.apache.org/zh-CN/docs/…
- 网易日志与时序场景实践（FE JVM 内存与 Label 参数调优）：selectdb.com/blog/355
