# 系统日志 集群运行时CN、DN、GTM、CM以及集群安装部署时产生的日志统称为系统日志。如果集群在运行时发生故障，可以通过这些系统日志及时定位故障发生的原因，根据日志内容制定恢复集群的方法。 #### 日志文件存储路径 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时，会将当前日志文件重命名为历史日志文件，并以当前时间生成新的日志文件。 ![](https://support.huaweicloud.com/distributed-ref-v10-gaussdb/public_sys-resources/note_3.0-zh-cn.png) - 前缀为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+应用程序名称+日志级别+日志内容 表1CN、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+日期+时间+日志级别+日志内容 表2GTM日志参数 | 字段名称 | 字段含义 | |:---|:---| | 日志行数 | 当前生成日志可能会包含多行，日志行数表示日志内容处于本条日志的第几行。 | | 线程ID | 当前生成日志的线程ID号。 | | 日期 | 日志生成的日期，格式：yyyy-mm-dd。 | | 时间 | 日志生成的时间，格式：hh:mm:ss.ms。 | | 日志级别 | 日志的级别，不同级别表示的严重程度不一样，有FATAL、ERROR、LOG等级别。 | | 日志内容 | 日志内容。 | - CN、DN的system_alarm日志每一行内容的默认格式：告警ID+告警名称+告警级别+主机所属领域列表+告警来源标识+告警操作类型+告警描述+清除类型+开始时间戳+结束时间戳，日志参数详细请参见[表3]。 表3CN、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信息+磁盘读写情况。 表4cm_agent、cm_server、cm_ctl、om_monitor的运行日志参数 | 字段名称 | 字段含义 | |:---|:---| | 日期 | 日志生成的日期，格式：yyyy-mm-dd。 | | 时间 | 日志生成的时间，格式：hh:mm:ss.ms。 | | 线程ID | 生成当前日志的线程ID号。 | | 线程名 | 生成当前日志的线程名称。（cm_ctl、om_monitor运行日志无该参数。） | | 日志级别 | 日志的级别，不同级别表示不同的严重程度，包括LOG、WARNING、ERROR、FATAL等级别。 | | 日志内容 | 日志内容。 | 表5cm_server的key_event日志参数 | 字段名称 | 字段含义 | |:---|:---| | 日期 | 日志生成的日期，格式：yyyy-mm-dd。 | | 时间 | 日志生成的时间，格式：hh:mm:ss.ms。 | | 线程ID | 生成当前日志的线程ID号。 | | 线程名 | 生成当前日志的线程名称。 | | 关键事件类型 | 关键事件的类型，格式：\[KeyEvent: xxxx\]。 | | 关键事件对象实例ID | 关键事件的对象，格式：\[Instance: xxxx\]。 | | 关键事件细节 | 关键事件的细节，格式：\[Details: xxxx\]。 | 表6cm_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.