日志平台运维速查表：巡检命令、阈值、参数，一张贴墙

野生数据人2026-10-13 16:50

【摘要】这是一张速查表，不是教程。日志平台日常运维要用到的东西我压成三张表：巡检命令速查（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 慢查询：三步

sql 复制代码 
-- 第 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 扩缩容：两条命令

sql 复制代码 
-- 扩容：新机器上启动 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 一条可直接跑的巡检脚本

bash 复制代码 
#!/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 每周一次的复核项

每小时和每天的检查解决不了慢变量，容量趋势要靠每周一次的固定复核。我每周一早上跑下面这组，结果记进台账：

sql 复制代码 
-- 库级体量与副本总量：看一周涨了多少
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 故障三问

  1. 先问现象能不能量化。 "查询慢"要换成"哪个时间段、哪类查询、慢了多少"，量化之后排查路径立刻收窄。
  2. 再问是不是上游引起的。 查询是最下游环节，导入积压、副本不齐都会先表现为查询变慢。顺序是节点 → 副本与导入 → 查询。
  3. 最后问动作有没有副作用。 重启进程会把该节点上的副本推进修复流程；修副本会占带宽和 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 多大算积压？

看走向不看数值。稳定在高位说明消费能力就是这个水平；持续增长才是积压，两者处置方式不同。

测试结论出处（参考来源）

相关推荐
数据库小学妹1 小时前
向量检索最小可运行实现：HNSW索引参数与召回率/延迟权衡
数据库·后端
发量惊人的中年网工2 小时前
SD-WAN 组网方案怎么选？跨地域与多分支企业的选型指南（含成本对比）
服务器·网络·数据库
xiaogai_gai2 小时前
物料主数据从ERP同步到电商中台:基于轻易云的编码映射与增量全量双轨实践
大数据·数据库
SelectDB2 小时前
信创适配速查手册：国产 CPU / OS 对照表、认证许可速查与部署检查项清单
大数据·数据库·数据分析
亚川楼宇自控系统数据中心厂家2 小时前
机房 3D 可视化技术：从平面监控到立体化管理的升级
大数据·数据库·人工智能
LaughingZhu2 小时前
任务在飞书创建，开发在 Orca 继续：我把飞书项目接到了 Linear
大数据·人工智能·深度学习·神经网络·飞书
SelectDB2 小时前
部署形态与存算分离速查：形态对照、配置项清单与关键命令片段
大数据·数据结构·数据库
SelectDB2 小时前
Workload Group 参数速查：排队与并发配置、CPU 软硬限切换与常见配置问题清单
大数据·数据库·数据分析
智享 AI 科技2 小时前
2026年AI私域系统怎么选？从功能到服务的全维度对比
大数据·人工智能·经验分享
热门推荐
01国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）02历年考研数学一、数学二、数学三真题试卷及答案PDF03GitHub 镜像站点04「全语录+省流版」邵艾伦 × 孙宇晨：聊风口、聊个人IP、聊年轻人如何抓住 AI 时代的机会05如何新建文件夹？ 电脑新建文件夹的4种方法06蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接07Windows 10/11 如何退出微软账户并改用本地账户登录（含找不到选项的解决方法）08轻量化AI渗透武器库｜ARTEX自主攻防系统、资产梳理、漏洞挖掘、链路分析全流程智能化落地09Telegram APK 下载安装完整指南 — 2026年最新10微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新