系统日志

日志文件存储路径

CN、DN、GTM的运行日志放在“$GAUSSLOG/gs_log”中各自对应的目录下。

CM（包括cm_agent、cm_server、cm_ctl、om_monitor、etcd）的日志放在“$GAUSSLOG/cm”中各自对应的目录下。

OM集群安装卸载时产生的日志放在“$GAUSSLOG/om”目录下。

日志文件命名格式

• CN和DN运行日志的命名规则：

  gaussdb-创建时间.log

  默认情况下，每日0点或者日志文件大于16MB或者集群（CN、DN）重新启动后，会生成新的日志文件。

  system_alarm-创建时间-current.log

• GTM运行日志的命名规则：

  gtm-创建时间.log

  默认情况下，日志文件大于16MB或者GTM实例重新启动后，会生成新的日志文件。

• CM的日志的命名规则：
  • cm_agent的日志：cm_agent-创建时间.log、cm_agent-创建时间-current.log；system_alarm-创建时间-current.log、system_call-current.log、system_stat-current.log、gaussdb-创建时间_000000.log。
  • cm_server的日志：cm_server-创建时间.log、cm_server-创建时间-current.log；key_event-创建时间-current.log、system_alarm-创建时间-current.log。
  • cm_ctl的日志：cm_ctl-创建时间-current.log。
  • om_monitor的日志：om_monitor-创建时间.log、om_monitor-创建时间-current.log；system_alarm-创建时间-current.log。
  其中，不带current标识符的文件是历史日志文件，带current标识符的文件是当前日志文件。最初调用进程时，进程会先创建一个带current标识符的日志文件，当该日志文件的大小超过16MB时，会将当前日志文件重命名为历史日志文件，并以当前时间生成新的日志文件。

  

  • 前缀为cm_agent、cm_server、cm_ctl、om_monitor的日志分别是cm_agent、cm_server、cm_ctl、om_monitor的运行日志。
  • 前缀为system_alarm的日志分别是cm_agent、cm_server、om_monitor的告警日志，记录集群运行时异常情况的告警上报与清除。
  • 前缀为key_event的日志是cm_server的关键事件日志，记录cm_server仲裁相关信息。
  • 前缀为system_call的日志是cm_agent在运行过程中调用工具命令的情况记录日志。
  • 前缀为system_stat的日志是cm_agent在运行过程中系统的性能监控日志，记录当前系统的磁盘I/O性能。
  • 前缀为gaussdb的日志是启动fenced模式的运行日志。
  • 日志命名依赖于系统时间戳，数据库会根据时间对旧的日志进行压缩，如果系统发生时间倒退，可能会把正在写入的日志文件提前压缩，导致日志文件无法继续写入，需要手动清理未来时间点日志进行恢复。

日志内容说明

• CN、DN每一行日志内容的默认格式：

  日期+时间+节点名称+用户名称+数据库名称+IP地址+会话ID+事务ID+应用程序名称+日志级别+日志内容

  表1 CN、DN日志参数

  字段名称	字段含义
  日期	日志生成的日期，格式：yyyy-mm-dd。
  时间	日志生成的时间，格式：hh:mm:ss.ms。
  节点名称	表示指定错误上报的节点。
  用户名称	当前触发生成日志的用户名。
  数据库名称	当前触发生成日志的数据库名。
  IP地址	当前触发生成日志的客户端的IP地址。
  线程ID	线程ID。
  会话ID	当前触发生成日志的session的session id。
  事务ID	事务ID（0表示没有分配事务ID）。
  线程名	线程名。
  查询ID	query_id，用户发起查询时，后台记录此查询的ID。
  模块名称	模块名称。
  日志级别	日志的级别，不同级别表示的严重程度不一样，有FATAL、ERROR、LOG等级别。
  日志内容	日志内容。

• GTM每一行日志内容的默认格式：

  日志行数+线程ID+日期+时间+日志级别+日志内容

  表2 GTM日志参数

  字段名称	字段含义
  日志行数	当前生成日志可能会包含多行，日志行数表示日志内容处于本条日志的第几行。
  线程ID	当前生成日志的线程ID号。
  日期	日志生成的日期，格式：yyyy-mm-dd。
  时间	日志生成的时间，格式：hh:mm:ss.ms。
  日志级别	日志的级别，不同级别表示的严重程度不一样，有FATAL、ERROR、LOG等级别。
  日志内容	日志内容。

• CN、DN的system_alarm日志每一行内容的默认格式：告警ID+告警名称+告警级别+主机所属领域列表+告警来源标识+告警操作类型+告警描述+清除类型+开始时间戳+结束时间戳，日志参数详细请参见表3。

  表3 CN、DN、cm_agent、cm_server、om_monitor的system_alarm日志参数

  字段名称-英文	字段名称-中文	字段含义
  id	告警ID	告警的ID。
  name	告警名称	告警的名称。
  level	告警级别	告警的级别，不同级别表示不同的严重程度，包括critical、major、minor、notice等级别。
  scope	主机所属领域列表	主机所属领域列表。指使用newsql的告警平台，固定取值newsql。
  source_tag	告警来源标识	告警的来源标识。
  op_type	告警操作类型	告警的操作类型。 firing表示告警上报。当为firing时，日志中包含告警描述和清除类型。 resolved表示告警清除。当为resolved时，日志中不包含告警描述和清除类型。
  details	告警描述	告警的具体信息。
  clear_type	清除类型	告警的清除类型。包括ADAC和ADMC。 ADAC：系统能够自动检测到该故障发生，也能自动检测到该故障被修复。 ADMC：系统能够自动检测到该故障发生，但无法检测到该故障的修复情况。
  start_timestamp	开始时间戳	告警开始的时间。 上报告警时，start_timestamp时间戳有值，end_timestamp值为0。 解除告警时，start_timestamp值为0，end_timestamp时间戳有值。
  end_timestamp	结束时间戳	告警结束的时间。

• cm_agent、cm_server、cm_ctl、om_monitor日志内容如下所示：
  • cm_agent、cm_server、cm_ctl、om_monitor的运行日志每一行内容的默认格式：日期+时间+线程ID+线程名+日志级别+日志内容。
  • cm_agent、cm_server、om_monitor的system_alarm日志每一行内容的默认格式：告警ID+告警名称+告警级别+主机所属领域列表+告警来源标识+告警操作类型+告警描述+清除类型+开始时间戳+结束时间戳。
  • cm_server的key_event日志每一行内容的默认格式：日期+时间+线程ID+线程名+关键事件类型+仲裁对象实例ID+仲裁细节。
  • cm_agent的system_call日志大部分内容的默认格式：日期+时间+节点名称+用户名称+数据库名称+IP地址+会话ID+事务ID+应用程序名称+日志级别+日志内容。日志参数详细请参见表1。
  • cm_agent的system_stat日志内容的默认格式：时间+操作系统+CPU信息+磁盘读写情况。

    表4 cm_agent、cm_server、cm_ctl、om_monitor的运行日志参数

    字段名称	字段含义
    日期	日志生成的日期，格式：yyyy-mm-dd。
    时间	日志生成的时间，格式：hh:mm:ss.ms。
    线程ID	生成当前日志的线程ID号。
    线程名	生成当前日志的线程名称。（cm_ctl、om_monitor运行日志无该参数。）
    日志级别	日志的级别，不同级别表示不同的严重程度，包括LOG、WARNING、ERROR、FATAL等级别。
    日志内容	日志内容。

    表5 cm_server的key_event日志参数

    字段名称	字段含义
    日期	日志生成的日期，格式：yyyy-mm-dd。
    时间	日志生成的时间，格式：hh:mm:ss.ms。
    线程ID	生成当前日志的线程ID号。
    线程名	生成当前日志的线程名称。
    关键事件类型	关键事件的类型，格式：[KeyEvent: xxxx]。
    关键事件对象实例ID	关键事件的对象，格式：[Instance: xxxx]。
    关键事件细节	关键事件的细节，格式：[Details: xxxx]。

    表6 cm_agent的system_stat日志参数

    字段名称	字段含义
    时间	日志生成的时间，使用中国标准时间（CST）表示。
    操作系统	主机的操作系统。
    CPU信息	CPU使用率。其中： %user：CPU处在用户模式下的时间百分比。 %nice：CPU处在带NICE值的用户模式下的时间百分比。 %system：CPU处在系统模式下的时间百分比。 %iowait：CPU等待输入输出完成时间的百分比。 %steal：管理程序维护另一个虚拟处理器时，虚拟CPU的无意识等待时间百分比。 %idle：CPU空闲时间百分比。
    磁盘读写	磁盘I/O信息。其中： rrqm/s：每秒合并的读请求次数，即读请求合并为更大的块的次数。 wrqm/s：每秒合并的写请求次数，即写请求合并为更大的块的次数。 r/s：每秒完成的读请求次数。 w/s：每秒完成的写请求次数。 rMB/s：每秒读取的数据量，单位为MB/s。 wMB/s：每秒写入的数据量，单位为MB/s。 r_await：平均每个读请求的等待时间，单位为毫秒。 w_await：平均每个写请求的等待时间，单位为毫秒。 %util：磁盘利用率，即磁盘I/O操作占用磁盘总时间的百分比。 %rrqm：读取请求在发送到设备之前合并的百分比。 %wrqm：写入请求在发送到设备之前合并的百分比。 rareq-sz：向设备发出的读请求的平均大小，单位为kB。 wareq-sz：向设备发出的写请求的平均大小，单位为kB。 d/s：设备每秒完成的丢弃请求数。 dMB/s：每秒设备丢弃的扇区数。 drqm/s：每秒合并到设备排队的丢弃请求数。 %drqm：丢弃请求在发送到设备之前合并的百分比。 d_await：向要服务的设备发出丢弃请求的平均时间。 dareq-sz：向设备发出的丢弃请求的平均大小，单位为kB。 f/s：设备每秒完成的刷新请求数（合并后）。 f_await：向要服务的设备发出的刷新请求的平均时间。 aqu-sz：向设备发出的请求的平均队列长度。

日志示例

• CN、DN
  • 运行日志的典型样例：

    2023-09-14 21:28:52.647 dn_6001 rdsAdmin postgres localhost 139983342597888 0[0:0#0] 0 dn_6001 0 [BACKEND] LOG:  will update control file (create checkpoint), shutdown:0

  • system_alarm日志的典型样例：

    {"id":"0000001078919222","name":"AbnormalDataInstConnAuthMethod","level":"critical","scope":["newsql"],"source_tag":"szvphis5033219-cn_5001","op_type":"firing","details":"Data instance cn_5001 remote connection trust method error","clear_type":"ADAC","start_timestamp":1694140757589,"end_timestamp":0}

• GTM运行日志的典型样例：

  1:140027660965632:2023-09-05 09:38:51.267 -LOG:  switched to running as GTM-primary.

• cm_agent
  • 运行日志的典型样例：

    2023-09-05 05:59:59.845 tid=13690 CheckSysStatus ASYN LOG: [MEMORY STAT] memory system usage: 91.60%, application usage: 97.42%.

  • system_alarm日志的典型样例：

    {"id":"0000001078919202","name":"DatanodeFailOver","level":"major","scope":["newsql"],"source_tag":"pekphis351066-dn_6001","op_type":"firing","details":"Datanode standby dn_6001 fail over","clear_type":"ADMC","start_timestamp":1693035351709,"end_timestamp":0}

  • system_call日志的典型样例：

    2023-09-04 15:37:07.509 dn_6001_6002_6003 [unknown] [unknown] localhost 140252967524864 0[0:0#0] 0 [unknown] 0 [BACKEND] LOG:  create gaussdb state file success: db state(STARTING_STATE), server mode(Pending), connection index(1)

  • system_stat日志的典型样例：

    Fri Aug 25 16:58:19 CST 2023
    Linux 3.10.0-862.14.1.5.h687.eulerosv2r7.x86_64 (pekphis351066)         08/25/2023      _x86_64_        (8 CPU)
    
    avg-cpu:  %user   %nice %system %iowait  %steal   %idle
              18.02    0.00   10.07    0.41    0.00   71.50
    
    Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
    vda               0.01     7.89    0.08    3.67     0.00     0.05    26.96     0.01    2.57    3.41    2.55   0.18   0.07
    vdb               0.04    51.39    0.53  103.88     0.09     0.65    14.63     0.09    0.84    4.85    0.82   0.39   4.06

  • gs_log目录下的gaussdb日志的典型样例：

    [UDF] LOG:  Fenced master process start OK.

• cm_server
  • 运行日志的典型样例：

    2023-09-04 16:03:50.693 tid=95109 MAIN LOG: process startup packet, remote_type 7, nodeid 1, node name pekphis351066, postmaster is false.

  • system_alarm日志的典型样例：

    {"id":"0000001078919258","name":"ServerSwitchOver","level":"minor","scope":["newsql"],"source_tag":"pekphis351066-server_1","op_type":"firing","details":"Server standby server_1 switch over","clear_type":"ADMC","start_timestamp":1693031871104,"end_timestamp":0}

  • key_event日志的典型样例：

    2023-09-04 15:45:10.468 tid=95440 AGENT_WORKER: [KeyEvent: KEY_EVENT_SWITCHOVER] [Instance: 6001] [Details: send switchover message, node=1, instance=6001]

• cm_ctl
  • 运行日志的典型样例：

    2023-08-28 16:39:54.113 tid=72942  LOG: set cm_server.conf success.

• om_monitor
  • 运行日志的典型样例如下所示，CM Agent启动检查完成，cluster_manual_start、agent_config_file_r和agent_binary_file_x文件存在，config_change_flag文件不存在，CM Agent之前状态为进程不在，拉起CM Agent次数为0：

    2023-09-05 10:50:41.044 tid=100802  LOG: The CM Agent startup check is complete: cluster_manual_start=1, agent_config_file_r=1, agent_binary_file_x=1, config_change_flag=0, previous_status=0, start_count=0.

  • system_alarm日志的典型样例：

    {"id":"0000001078919226","name":"AbnormalCMAProcess","level":"critical","scope":["newsql"],"source_tag":"pekphis351066-cma","op_type":"resolved","start_timestamp":0,"end_timestamp":1692953836127}

日志丢弃机制

当系统日志写入异常时（如日志盘故障、日志盘负载过高等），系统会先进行重试（默认重试超时60秒），若重试仍失败则执行日志丢弃，以避免因日志写入阻塞而影响业务。当日志发生丢弃时，会在操作系统日志中打印告警信息：WARNING: logger pipe write failed, dropped a log message.