首批通过分布式安全可靠测评，为关键业务系统打造
日志概述
更新时间：2026-03-03 09:59:14
编辑
分享
系统日志（SysLog）指 OceanBase 数据库程序日志，OceanBase 数据库在运行过程中自动打印的日志，用于监控报警和诊断。系统日志是监控指标的有力补充，两者共同支撑起 OceanBase 数据库的可观测能力。
系统日志与事务日志在有些场景下都简称为“日志”，但两者是完全不同的事物：
系统日志（SysLog）：OceanBase 数据库进程运行过程中打印的日志，用于监控报警和诊断，是可观测性领域的内容。
事务日志（commit log，简称 clog）：OceanBase 数据库先于数据持久化的 WAL，用于保证事务性，是数据一致性领域的内容。
日志模块
程序日志分为不同的模块，且有父模块和子模块两个层级。
OceanBase 数据库的父模块包括
CLIENT、CLOG、COMMON、ELECT、LIB、PROXY、RPC、RS、SERVER、SHARE、SQL、STORAGE、TLOG等。如果父模块下含有子模块，则表示为
父模块.子模块。例如：SQL.PARSER表示 SQL 模块下的 PARSER 子模块；SQL.*表示 SQL 模块下的所有子模块。
日志文件
OceanBase 数据库日志模块所属的日志文件分为 observer.log、election.log、rootservice.log、trace.log 和 alert.log 五种类型，默认打印 INFO 级别以上的日志。
除 trace.log、alert.log 文件之外，每类日志文件自动生成一个带有 .wf 后缀的 WARNING 日志文件（observer.log.wf、election.log.wf、rootservice.log.wf），只打印 WARN 级别以上的日志。通过集群配置项 enable_syslog_wf 控制是否生成 WARNING 日志文件。
| 日志名称 | 日志路径 |
|---|---|
启动和运行日志（observer.log、observer.log.wf） |
OBServer 服务器的 $work_dir/log 目录下。 |
选举日志（election.log、election.log.wf） |
OBServer 服务器的 $work_dir/log 目录下。 |
Root Service 日志（rootservice.log、rootservice.log.wf） |
OBServer 服务器的 $work_dir/log 目录下。 |
| 全链路追踪日志（trace.log） | OBServer 服务器的 $work_dir/log 目录下。 |
| 警告日志（alert.log） | OBServer 服务器的 $work_dir/log/alert 目录下。 |
OceanBase 数据库的单个日志文件大小不超过 256MB，当日志文件大小达到 256 MB 时，系统会进行日志轮转。原日志文件追加时间为后缀（格式为 yyyyMMddHHmmss），时间为本日志文件中最后一条日志的生成时间，并生成新的日志文件。发生日志轮转时，.wf 日志文件即使没到 256MB 也会一起轮转。也就是说 xxx.log.wf 文件和 xxx.log 文件总是一一对应的，.wf 文件一般情况下远小于 256 MB。
典型日志文件目录如下：
log
├── election.log
├── election.log.wf
├── observer.log
├── observer.log.20220427154619
├── observer.log.wf
├── observer.log.wf.20220427154619
├── rootservice.log
├── rootservice.log.20220427165438
├── rootservice.log.wf
├── rootservice.log.wf.20220427165438
└── log
├── alert.log
└── alert.log.20220304102928236
OceanBase 数据库原生支持日志归档（通过集群配置项 enable_syslog_recycle 控制），当日志总文件数达到 max_syslog_file_count 时，日志轮转时删除最老的日志文件。日志文件最大空间使用可按如下方式评估: max_syslog_file_count * 256M * 3 * (enable_syslog_wf ? 2 : 1)。
OceanBase 数据库原生日志归档功能基于文件数进行日志归档，当 OceanBase 数据库与外部管控系统（例如 OCP）一起部署时，通常使用外部管控系统提供的基于磁盘空间使用率的日志归档功能。
日志格式
典型的一行日志，及其格式如下。
普通的一行日志：
[2022-04-29 16:39:55.186527] WARN [COMMON] get_file_id_range (ob_log_file_group.cpp:127) [103594] [0] [Y0-0000000000000000-0-0] [lt=17] [dc=0] max file does not exist(max_file_id=4, b_exist=false)
对日志进行拆解，得到日志格式：
- time：
[2022-04-29 16:39:55.186527] - log_level：
WARN - module：
[COMMON] - function：
get_file_id_range - file_name:line_number：
(ob_log_file_group.cpp:127) - thread_id：
[103594] - coroutine_id：
[0] - trace_id：
[Y0-0000000000000000-0-0] - log_used_time：
[lt=17] - dropped_msg_count：
[dc=0] - info：
max file does not exist - parameter：
(max_file_id=4, b_exist=false)
日志格式分为两部分：
- header：
[2022-04-29 16:39:55.186527] WARN [COMMON] get_file_id_range (ob_log_file_group.cpp:127) [103594] [0] [Y0-0000000000000000-0-0] [lt=17] [dc=0] - message：
max file does not exist(max_file_id=4, b_exist=false)
如上格式所示，一条日志由头部（header）及消息体（message ）组成：
header 部分：
- time：该条日志打印的时间。
- log_level：该条日志的级别，目前支持以下级别（由高到低）：ERROR、USER_ERR、WARN、INFO、TRACE、DEBUG。
- module：当前打印日志的模块名，由父模块和子模块组成，OceanBase 数据库支持按模块指定日志级别。
- function：当前打印日志的函数名。
- file_name:line_number：当前打印日志的代码源文件名以及行号。
- thread_id：当前打印日志的线程 ID。
- coroutine_id：当前打印日志的协程 ID。
- trace_id：用于跟踪一个任务的 trace_id，任务级唯一，该 trace_id 通过 RPC 在各个 OBServer 间传递，从而可以根据 trace_id 来获取一个任务的所有日志数据。对应
GV$OB_SQL_AUDIT视图中的TRACE_ID字段。 - log_used_time：指上一条日志的处理时间 (异步日志场景包含日志写入文件时间)。
- dropped_msg_count：
dc=xx，其中xx表示当前日志距离上一条日志期间丢弃的日志个数, 没有丢弃时为 0。
message 部分：消息体一般由消息描述信息（info）与参数（parameter）组成。
- info：具体的日志内容。
- parameter：以
name=value的 list 形式组成的 KV 列表。value 部分如果是简单类型直接展示，如果是复杂类型则展示为类似于 JSON 格式的文本（为提高可读性，去掉了 JSON 格式 KEY 上的"）。
