最近要发D-SMART OB专版，所以对OB的关注会多一些，每天思考的问题大多数也和OB有关。昨天发现D-SMART在Oracle之外的数据库日志分析方面还存在不小的差距，因此组织同事开始弥补差距。当然也免不了重点照顾一下OB的日志。
日志是一个DBA开始运维一种新数据库中首先要接触的可观测性能力，在能看懂某种数据库的日志之前，这个数据库对DBA来说是个黑匣子，其实针对所有的IT基础设施甚至应用软件都是如此，当你学会看这种软件的日志的时候，你已经能够真正的“运维”这个软件系统了。作为复杂的分布式数据库系统，比起普通的软件或者集中式数据库来说，日志难免也要复杂一些。首先每个OBSERVER、rootserivce等组件都会有独立的日志文件，如果分布式数据库的节点多了，没有一个统一的日志中心还真不太好去做日志管理和分析。
其次是OB数据库在日志方面也不太友好，产生的日志数量也太庞大了。在我们实验室的测试环境中安装了一套Oceanbase 4.2.1，这是OB 4的第一个LTS版本。在某个observer节点上，20号下午13点多我清理过一次日志，到了22号14点的时候，这个observer已经产生了差不多20GB的日志文件了。再加上OB的日志格式没有Oracle那么赏心悦目（也许是看了三十年Oracle的日志，看其他日志都不大习惯），因此想在庞大的OB数据库里看日志是件十分麻烦的事情。
当然OB的同学也会强烈给你推荐OCP，在OCP里查看日志信息还是挺方便的。不过对于我这种sqlplus出身的DBA来说，还是有点不习惯GUI的管理界面。前阵子和几个已经在深度使用OB的朋友说起这事。这个也是O记DBA出身的朋友说自从开始用OB之后，再也没有通过命令去运维过OB，一直都是用OCP的。看样子我也要改变下自己的习惯，多用用OCP了。
OB的日志级别与其他数据库类似，一般来说，我们需要关注 ERROR 和 WARN 级别的告警日志，因为它们可能反映了系统的故障或异常，需要及时进行处理。另外，EDIAG 和 WDIAG 级别的日志也可以帮助我们诊断问题的原因和解决方案，但它们通常是 OceanBase 数据库开发者使用的，不一定适合数据库管理员。在目前4.2.1版本里，哪怕是把日志级别设置为WARN，还是会有大量的用于诊断的EDIAG/WDIAG信息会显示在observer.log中，这个小bug也导致了OB的日志量过大。OceanBase 数据库有多个日志文件，其中最重要的是在oceanbase/log目录下的四个：
lobserver.log：记录了 OceanBase 数据库的主要运行日志，包括 SQL 执行、事务处理、分区管理、存储引擎、网络通信等模块的日志信息。
lelection.log：记录了 OceanBase 数据库的选举日志，包括分区选举、租户选举、集群选举等模块的日志信息。
lrootservice.log：记录了 OceanBase 数据库的根服务日志，包括租户管理、表空间管理、表管理、分区管理、备份恢复、平衡等模块的日志信息。
ltrace.log：记录了在OceanBase中做数据库trace的信息。
这些日志文件都有一个对应的 .wf 后缀的文件，例如 observer.log.wf，它们是 WARNING 日志文件，只记录 WARN 及高于 WARN 级别的日志信息。我们可以通过这些文件快速定位系统的告警信息。可能是OB的同学也觉得自己的日志数量太庞大了，因此在一般情况下如果你手头无法访问OCP，需要手工查看OB的日志，不建议你去看*.log文件，而是去检查*.log.wf文件，否则你会被海量的日志文件搞崩溃的。
在查看OB的日志的时候，我们需要关注一下日志的格式。OB日志中最主要的内容包括（1）时间戳；（2）日志级别；（3）错误号（3-A）附加错误号，可能是内部错误号；（4）出错位置；（5）错误信息。
现在你可能已经知道OB的日志文件或者错误信息怎么看了，不过这只是万里长征走出了第一步。下面你还需要像了解Oracle 错误代码一样了解OB的错误号都代表了什么。OB的《参考手册》里有相关OB错误号的描述。
不过这些资料不一定是最新的，可能与OB最新的版本有些差异。幸亏OB是有开源版本的，你可以下载OB源码，打开src/share/ob_errno.def文件来查看最新的错误信息。
OB的-1~-999是预留的错误号，而-1000~-1999和-2001~-3000分别是兼容MySQL server和MySQL client的。大于4000的才是OB原生的错误代码。ob_errno.def的格式是这样的：
通过ob_errno.def我们可以了解OB错误代码的分段情况。日常把这些号段记下来，对于遇到错误的时候快速判断错误可能的原因还是很有帮助的。这里我整理了一张号段表，有兴趣的朋友可以把图截下来保存起来。在Oracle数据库中我也积累过类似的号段表，把号段表背下来，下回遇到在不方便查看电脑的时候，看一眼错误号，也能大致定位出数据库故障或者某个报错大致的定位。下表是针对OB4.X的告警号段，对于OB 3.X,告警信息的含义可能会有一些不同。不过从OB4开始，这些号段相对就比较稳定了。
除了这个文件外，deps/oblib/src/lib/ob_errno.h文件中也定义了一些重要的错误码，有兴趣去读读这个文件也是会有收获的。
学会简单地看OB的日志后，下一步就是要区分哪些告警是致命的，会影响到OB集群的健康，或者影响到业务系统，这些日志是需要产生告警的。其他的日志哪怕级别是ERROR或者WARN，也不需要立即处置，只需要在做巡检、优化的时候关注就可以了。
比如在D-SMART中，我们看到昨晚产生了大量的-4013，这些告警虽然不会引发OB集群故障，但是客户端应用会因为租户内存不足而出现报错。运维人员就需要给租户扩内存了。
而更多的日志告警在优化中心中可以查看，其处理的紧急程度没有产生告警的急迫，完全可以在每个月的巡检中做自动的分析。针对OB的日志自动分析工具还在开发中，所以大家看到的这些日志项的状态还是“未分析”，自动分析工具完成后，这些日志会被异步分析。在异步分析中发现某些日志的告警的危害性很高，也会补充发送日志告警。
