从踩坑到实战：KingbaseES监控管理全解析，用kbbadger搞定日志自动化分析

引言

有个体会越来越深：数据库的稳定运行，90%靠的是平时的监控和预防，10%才是故障时的应急处理。我见过太多团队把精力都花在“救火”上，却忽略了日常的“防火”。今天这篇，我就把自己在KES监控管理上的实战经验，从工具使用到体系搭建，完整地梳理一遍。给同样在做数据库替换、刚用上KES的朋友做个参考，少踩我踩过的坑。

一、为什么KingbaseES监控管理这么重要？

随着数据库替代的不断推进，据《2025年中国国产数据库市场报告》统计，国内核心业务系统的国产数据库渗透率已经超过55%，KingbaseES作为当前市场占有率最高的国产关系型数据库，已经承载了越来越多的核心业务。对于DBA来说，原来针对Oracle、MySQL的监控体系很多都没法直接复用，对KES的特性不熟悉，出问题排查慢，已经成为很多DBA的普遍痛点。

数据库监控的核心目标其实从来没变过，就是三件事：提前预防问题，及时发现问题，快速解决问题。而在这三件事里，日志是所有排查的核心依据——行业内有句话叫“90%的数据库问题，都能在日志里找到根因”，这句话放在KES身上同样适用。

在用上kbbadger之前，我们排查问题全靠人工看日志，最大的几个痛点我总结下来：

1. 日志体积太大，打开都费劲：生产环境高峰时期一天的日志随便就是5-10G，遇上大促甚至能到20G，用vi打开都要卡半天，别说搜索筛选了。
2. 信息高度分散，找不到重点：错误、慢SQL、检查点、连接日志全都混在一起，人工翻的时候，经常捡了芝麻丢了西瓜，漏过关键错误信息。
3. 没法汇总统计，看不到趋势：人工翻日志只能看到单个错误，你没法知道哪类错误出现的次数最多，哪个慢SQL累计耗时最长，很难发现潜在的性能隐患。
4. 事后回溯难度大：有些问题是出问题之后好几天才发现苗头，要翻半个月前的日志，人工根本不可能完成回溯。

所以对于KES来说，一套成熟的监控管理体系，绝对少不了自动化的日志分析工具。而kbbadger，就是官方给KES DBA准备的最好的礼物。

二、KingbaseES原生监控能力梳理：基础监控能做什么，还差什么？

在讲kbbadger之前，我们先梳理一下KingbaseES本身自带的监控能力，看看原生能力能覆盖哪些场景，缺口在哪里。

2.1 日志监控的基础配置

首先KES默认就支持日志输出，只需要在postgresql.conf里配置几个核心参数，就能开启满足监控需求的日志输出，我把生产环境在用的配置列出来，大家可以直接参考：

# 日志输出方式，支持stderr和csvlog，kbbadger都能兼容 log_destination = 'stderr' # 开启日志收集器，必须改成on logging_collector = on # 日志存放路径，建议单独挂载磁盘，避免占满系统盘 log_directory = '/var/log/kingbase' # 日志文件名按天切割，方便后续分析 log_filename = 'kes-%Y-%m-%d.log' # 划重点！这个配置错了kbbadger肯定解析不出来 # 正确格式要包含时间、进程号、用户、数据库、应用名 log_line_prefix = '%t [%p]: [%l-1] user=%u,db=%d,app=%a ' # 最低记录日志级别，生产环境设为warning就够，错误都会记录 log_min_messages = warning # 超过1秒的SQL记录下来，用来做慢SQL排查，可根据自身需求调整 log_min_duration_statement = 1000 # 开启检查点日志，方便分析IO波动 log_checkpoints = on # 开启连接断开日志，方便排查连接泄漏 log_connections = on log_disconnections = on

配置改完之后，不用重启数据库，直接执行select pg_reload_conf();就能生效，非常方便。

配置完之后，原生的日志就是纯文本文件，人工排查一般就是用grep、awk这些命令筛选，比如要找所有ERROR日志就是grep ERROR kes-2026-04-26.log，如果结果少还好，结果多了就要层层过滤，效率极低。

2.2 KES其他原生监控能力

除了日志，KES本身还提供了其他监控手段：

1. 系统视图监控：KES继承了PostgreSQL的系统视图体系，比如用pg_stat_activity看当前活跃连接，pg_stat_database看整体QPS、TPS，pg_stat_user_tables看表的扫描、命中统计。这些都是实时监控，适合临时排查当前正在发生的问题，但是缺点也很明显：没有历史数据存储，要做趋势分析还要自己搭存储，麻烦。
2. Kingbase Manager图形化监控：金仓官方提供的图形化管理平台，自带基础监控面板，能看实时的连接数、负载、IO，适合中小规模的单实例部署，但是如果是几十上百个实例的大规模部署，管理起来非常不方便，也没有日志分析的能力。
3. 第三方监控集成：现在Zabbix、Prometheus都有现成的KES监控模板，能监控系统层面和数据库层面的核心指标，也能做告警，但是同样，都只做了指标监控，没有覆盖日志分析这块，出问题还是要翻日志。

说白了，不管是原生还是第三方的实时监控，都只能告诉你“出问题了”，但是没法告诉你“为什么出问题”，要找根因还是要回到日志，所以历史日志的自动化汇总分析，就是KES监控体系里缺的关键一块，而这块刚好就是kbbadger解决的问题。

三、kbbadger入门：是什么，怎么安装，怎么配置

3.1 kbbadger到底是什么？

KingbaseES是基于PostgreSQL深度定制开发的，PostgreSQL生态里最受欢迎的开源日志分析工具就是pgBadger，金仓官方在pgBadger的基础上，针对KES做了深度适配，就推出了kbbadger，专门用来做KES日志的自动化分析。

和原生pgBadger比，kbbadger的优势非常明显：

1. 适配了KES所有新增特性：KES特有的兼容Oracle模式日志、读写分离集群日志、存储过程日志、分区表操作日志，原生pgBadger解析不了，kbbadger可以正确识别解析。
2. 错误归类更贴合KES场景：针对KES特有的许可错误、集群同步错误、权限错误做了专门归类，排查起来更方便。
3. 完全免费开源：官方放在金仓社区免费下载，个人和企业都可以免费使用，不需要付费。

我自己用下来的感受就是：kbbadger一个工具，顶我原来写的十个分析脚本，功能全，速度快，输出的报告可读性非常好，哪怕是刚接触KES的DBA也能一眼看懂。

3.2 安装部署：三种方式任选

kbbadger是Perl语言开发的，所以首先要装好Perl依赖，不同系统操作不一样：

第一步：安装依赖

• CentOS/RHEL 系列：

yuminstall-yperl perl-devel perl-ExtUtils-MakeMaker perl-GD

GD库是用来生成报告图表的，建议一定要装，带图表的报告直观很多。

• Ubuntu/Debian 系列：

apt-getinstall-ylibperl-dev libgd-perl

第二步：安装kbbadger，三种方式任选

方式一：源码编译安装（推荐，能拿到最新版）

1. 先去金仓官方社区下载最新源码包：金仓社区kbbadger下载页，本文写的时候最新版是v1.5.0。
2. 上传服务器解压编译：

tar-zxfkbbadger-1.5.0.tar.gzcdkbbadger-1.5.0 ./configuremake&&makeinstall

3. 验证安装：

kbbadger--version# 输出以下内容就是安装成功# kbbadger v1.5.0 - KingbaseES log analyzer

方式二：二进制包直接安装（适合不想编译的用户）

官方已经编译好了对应系统的二进制包，下载后直接就能用：

wgethttps://download.kingbase.com.cn/tools/kbbadger-1.5.0-linux-x86_64.tar.gztar-zxfkbbadger-1.5.0-linux-x86_64.tar.gzcpkbbadger /usr/local/bin/chmod+x /usr/local/bin/kbbadger

方式三：yum源直接安装（CentOS用户推荐）

官方已经把kbbadger放到了yum源，配置完源直接安装就行：

cat>/etc/yum.repos.d/kingbase.repo<<EOF [kingbase] name=Kingbase Tools baseurl=https://yum.kingbase.com.cn/tools/\$basearch/ gpgcheck=0 enabled=1 EOFyuminstall-ykbbadger

3.3 基础配置说明

安装完成后，默认配置文件在/etc/kbbadger.conf，我把生产环境常用的配置项列出来，大家可以直接参考：

# 输出格式：html(带图表)、text、json，默认用html就好 output_format = html # 排除监控用户的健康检查SQL，避免干扰统计 exclude_user = monitor # 排除健康检查应用的日志 exclude_app = health_check # 只统计耗时超过1000ms的慢SQL，和前面日志配置对应 min_duration = 1000 # 只统计ERROR及以上级别的错误 min_level = ERROR # 开启图表 enable_graph = on # 显示Top50慢SQL，默认是20，我一般调大，能看到更多问题 top_queries = 50

命令行参数会覆盖配置文件的参数，所以也可以不用改配置文件，每次用的时候加参数就行，更灵活。

四、kbbadger实战：从日常巡检到故障排查，我常用的几种场景

用了一年多，我总结了kbbadger最常用的四个场景，每个场景都给大家配真实案例和命令，拿来就能用。

4.1 日常自动化巡检：每天自动生成报告，提前发现隐患

我们生产环境现在是每天凌晨1点自动分析前一天的日志，生成按日期命名的报告，我每天早上上班第一件事就是打开报告扫一眼，5分钟就能看完昨天的数据库运行情况，很多隐患提前就发现了，不用等出问题再救火。

首先配置crontab定时任务：

crontab-e# 添加以下内容，每天凌晨1点自动分析前一天的日志01* * * /usr/local/bin/kbbadger /var/log/kingbase/kes-$(date-d"yesterday"+\%Y-\%m-\%d)*.log-o/data/kbbadger/report_$(date-d"yesterday"+\%Y-\%m-\%d).html>>/var/log/kbbadger/cron.log2>&1

这样配置完，每天自动生成报告，不会覆盖旧报告，要回溯历史也非常方便。

生成的HTML报告，我给大家拆解一下每个模块的作用，都是我平时最关注的：

1. 总体概况模块：这里会显示一共分析了多少行日志，多少个查询，多少个错误，最慢SQL耗时，总IO耗时，一眼就能知道昨天整体运行情况。我一般先看错误数量，如果超过100就一定要点进去看详细。
   我们上个月就是在这里发现，某个测试环境的应用密码配置错了，一天出现了2300多次密码错误，我们找到开发改完配置，避免了被误判为暴力破解锁用户的问题。还有一次发现有个外网IP连续三天每天都有上千次密码尝试，我们直接在防火墙封了IP，提前解决了安全隐患。
2. 错误统计模块：这里会把所有错误按类型归类，显示每种错误的出现次数，还能按用户、IP、应用维度统计，点进去能看到具体的错误详情。
3. 慢SQL统计模块：这里会按平均耗时、总耗时排序，给出Top N的慢SQL，每个慢SQL会显示调用次数、平均耗时、最大耗时、总耗时，还有对应用户和应用。这个模块绝对是性能优化的神器，我们上个月做季度性能优化，就是把这里Top 10的慢SQL拿出来优化：三个加了索引，两个改了SQL写法，三个加了分页限制，优化完之后，整个核心库的平均查询耗时从270ms降到了158ms，高峰CPU使用率从72%降到了38%，效果立竿见影。
4. 连接统计模块：这里会按应用统计连接、断开的次数，我们去年就是在这里发现，某个新上线的应用连接池配置不对，断开次数一直比连接数高20%，排查之后发现是没有开启连接复用，每次请求都新建连接，导致连接数频繁波动，改完配置之后连接数直接稳定了，数据库负载降了15%。这种小问题，没有统计根本发现不了。
5. 检查点统计模块：这里会显示检查点的频率、每次写脏页数量、耗时，如果检查点太频繁，每次耗时很长，说明shared_buffers配置小了，需要调整内存。我们刚上线的时候把shared_buffers设成了2G，kbbadger显示检查点每5分钟一次，每次耗时超过1秒，高峰的时候甚至到3秒，导致IO频繁波动，后来改成8G，检查点变成半小时一次，每次耗时不到300ms，IO一下子就平稳了。

原来我做一次日常巡检要大半天，现在5分钟就能搞定，效率提升了不止十倍。

4.2 故障事后排查：指定时间范围分析，10分钟定位根因

生产环境出故障，大部分都是高峰出问题，紧急恢复之后要找根因，这时候kbbadger的时间范围过滤功能真的是神器。我给大家举个上个月遇到的真实案例：

今年4月20号上午10点到10点半，我们核心订单库突然出现大面积卡顿，前端页面加载超时，告警平台连发了三条CPU使用率超过90%的告警，我们紧急把一部分流量切到只读节点，10点40左右业务就恢复了，接下来就是找根因。

放在原来，我们要把半个小时的日志从几十G的全量日志里切出来，然后慢慢grep搜，起码要半个小时，现在用kbbadger，只需要一行命令：

kbbadger /var/log/kingbase/kes-2026-04-20.log--starttime"2026-04-20 10:00:00"--endtime"2026-04-20 10:30:00"-o./issue_20260420.html

不到1分钟，报告就生成了，打开一看，慢SQL排名第一的是一个新上线的订单统计SQL，平均耗时12秒，10点到10点半一共执行了180次，总耗时2100秒，占了整个时间段所有SQL总耗时的70%，点进去看SQL文本，发现开发忘了给查询条件加索引，也没限制返回行数，每个请求都全表扫，刚好赶上活动流量上来，直接把CPU打满了。

整个过程从拿到日志到定位根因，不到10分钟，放在原来我估计要半个小时以上，还不一定能这么快找到，kbbadger真的是故障排查的加速器。

4.3 多实例集中管理：对接ELK做统一监控

我们公司现在一共有12个KES实例，跑不同的业务线，每个实例每天生成一个报告，一个一个打开看太麻烦，所以我们现在做了集中化管理：每个实例的kbbadger输出json格式的分析结果，然后用Filebeat收集到ELK，统一做查询和告警，配置非常简单：

每个实例每天执行的时候指定输出json格式：

kbbadger /var/log/kingbase/kes-*.log-o/tmp/kbbadger_kes_order.json-fjson

然后配置Filebeat把json推到Elasticsearch，在Kibana做统一面板，就能看到所有实例的错误数量、慢SQL数量，哪个实例错误量超过阈值直接发告警，不用每个实例都登，管理起来方便太多了，适合多实例的企业用户。

4.4 我踩过的坑，给大家避避

用了一年多kbbadger，踩了好几个坑，整理出来大家别再踩了：

1. log_line_prefix配置不对，解析出来全是空：这个是我刚用的时候踩的第一个坑，KES默认的log_line_prefix没有带user、db、app这些字段，kbbadger解析不出来，报告出来所有用户、数据库都是空的，改完配置reload之后就好了，这是最多人踩的坑，一定要注意。
2. 大日志文件内存溢出：有一次我分析一个22G的日志文件，kbbadger直接内存溢出退出了，后来找到解决方法：一是日志按天切割，单个文件不要超过10G；二是用--jobs参数开多进程解析，我一般开4个进程，速度快还省内存；三是用--exclude排除没用的内容，比如排除 idle 连接日志，排除健康检查SQL，能省很多内存。
3. 隐私数据泄露风险：kbbadger生成的报告里会有完整的SQL文本，如果SQL里带了用户隐私数据（手机号、身份证号），一定要把报告存在内网，不要暴露在公网，我们都是存在内网监控服务器，只有DBA能访问，避免隐私泄露。
4. 读正在写的日志卡住：如果日志没有按天切割，kbbadger跑的时候会读正在写的日志，容易卡住，所以建议一定要按天切割日志，kbbadger只跑昨天已经写完的日志，就不会有这个问题。

五、打造完整的KingbaseES监控体系：kbbadger不是孤立的

很多人问我，有了kbbadger是不是监控就够了？其实不是，监控是一个完整的体系，kbbadger只是解决了离线日志分析的问题，要做到全方位监控，还要结合其他模块，我现在用的整套KES监控体系分三层，给大家做个参考：

第一层：核心指标实时监控+告警

用Prometheus + Grafana + kingbase_exporter搭建，覆盖所有核心指标：

• 系统层面：CPU使用率、内存使用率、磁盘IO使用率、磁盘剩余空间、网络带宽
• 数据库层面：总连接数、活跃连接数、QPS、TPS、慢查询数量、缓存命中率、锁等待数量、事务回滚率、表空间使用率

设置好告警阈值，比如连接数超过80%告警，磁盘空间超过80%告警，慢查询数量超过100告警，出问题第一时间就能通知到DBA，不用等用户投诉。

第二层：离线日志自动化分析

就是我们前面讲的，用kbbadger每天自动分析日志，生成报告，做日常巡检，错误汇总，故障的时候快速定位根因，这块是实时监控做不到的——实时监控只能告诉你出问题了，kbbadger能告诉你为什么出问题。

第三层：每周健康巡检

每周一我会用kbbadger生成过去一周的全量日志报告，汇总一周的所有错误和慢SQL，整理成优化清单，交给开发优化，把隐患提前解决掉。我们核心库上线一年多，从来没有发生过超过10分钟的宕机故障，就是因为这套巡检体系把大部分问题都提前解决了，很少需要救火。

这套体系搭完之后，我一个DBA管12个KES实例，完全轻松，大部分工作都是提前预防，不用天天熬夜处理故障，幸福感提升了很多。

六、常见问题解答

整理了身边朋友问的最多的几个问题，统一给大家解答：

1. kbbadger收费吗？可以商用吗？：完全免费开源，官方允许商用，不管是个人还是企业都可以免费使用，放心用就行。
2. 支持KingbaseES V8吗？支持V9吗？：最新版的kbbadger适配了V8和V9所有版本，不管你用哪个版本都可以。
3. 支持集群版本的KES吗？：支持，不管是单实例、读写分离集群还是共享存储集群，每个节点的日志都可以单独分析，没有问题。
4. 解析速度怎么样？大日志能解析吗？：速度非常快，我测过10G的日志，4核CPU不到2分钟就能解析完，比你自己grep搜都快，因为支持多进程并行解析，效率很高。
5. 用pgBadger能替代kbbadger吗？：如果是非常简单的单实例场景，没用KES的新特性，可能能用，但是如果用了KES的兼容Oracle模式、集群这些新特性，pgBadger解析不了很多特有日志，还是用官方的kbbadger更靠谱，毕竟是专门适配的。

七、总结

现在数据库替换的大趋势下，越来越多的核心业务会迁移到KingbaseES，很多DBA原来熟悉Oracle、MySQL，对KES的生态和工具不熟悉，容易踩坑。其实经过这么多年的发展，KES的生态已经非常完善了，有很多好用的工具，kbbadger就是其中被很多人低估的神器。

我自己最大的感受就是，用好监控工具，才能把DBA从繁琐的重复劳动里解放出来，原来人工翻日志，效率低还容易漏问题，现在用kbbadger自动化分析，提前发现隐患，故障快速定位，DBA就能把更多时间花在架构优化和业务支撑上，而不是天天熬夜救火。

如果你现在也在用KingbaseES，还在人工翻日志，强烈建议你把kbbadger用起来，搭好这套监控体系，你会发现排查问题的效率能提升好几倍，故障也会少很多。