Greenplum的日志管理
Greenplum的日志管理
本篇文档首先介绍GP的日志架构，日志工具的使用说明，然后介绍一下日志的定期清理配置案例
目录
Greenplum的日志管理
日志架构
日志路径
日志说明
日志常用的参数和配置方案
日志过滤工作的使用
检查segment日志
gplogfilter+gpssh工具组合在所有segment节点进行查找
查看时间段的
筛选
gp_toolkit.gp_log*
gp_toolkit.gp_log_* 视图
日志文件的定期清理
日志架构
日志路径
下面的表格展示了各种Greenplum数据库日志文件的位置。在文件路径中，date是YYYYMMDD格式的日期，instance是当前的实例名称，而n是Segment编号。
| 路径 | 描述 |
|---|---|
| /home/gpadmin/gpadminlogs/* | 很多不同种类的日志文件，每台服务器都有的目录 |
| /home/gpadmin/gpadminlogs/gpstart_date.log | 启动日志 |
| /home/gpadmin/gpadminlogs/gpstop_date.log | 停止日志 |
| /home/gpadmin/gpadminlogs/gpsegstart.py_idb*gpadmin_date.log | Segment启动日志 |
| /home/gpadmin/gpadminlogs/gpsegstop.py_idb*gpadmin_date.log | Segment停止日志 |
| /greenplum/gpdata/master/gpseg-1/pg_log/startup.log | 实例启动日志 |
| /greenplum/gpdata/master/gpseg-1/gpperfmon/logs/gpmon.*.log | gpperfmon日志 |
| /greenplum/gpdata/mirror1/gpseg4/pg_log/*.csv | 镜像Segment日志 |
| /greenplum/gpdata/primary1/gpseg0/pg_log/*.csv | 主Segment日志 |
| /home/log/messages | 全局Linux系统消息 |
服务器日志文件被写为逗号分隔值（CSV）格式。不是所有的日志项在所有的日志域中都有值。例如，只有与查询工作者进程相关的日志项才会有slice_id值。一个特定查询的相关日志项可以通过其会话标识符（gp_session_id）和命令标识符（gp_command_count）确定。
| # | 域名 | 数据类型 | 描述 |
|---|---|---|---|
| 1 | event_time | timestamp with time zone | 日志项被写到日志中的时间 |
| 2 | user_name | varchar(100) | 数据库用户名 |
| 3 | database_name | varchar(100) | 数据库名 |
| 4 | process_id | varchar(10) | 系统进程ID（带前缀“p”） |
| 5 | thread_id | varchar(50) | 线程计数（带前缀“th”） |
| 6 | remote_host | varchar(100) | 在Master上，是客户端机器的主机名/地址。在Segment上，是Master的主机名/地址。 |
| 7 | remote_port | varchar(10) | Segment或Master的端口号 |
| 8 | session_start_time | timestamp with time zone | 会话连接打开的时间 |
| 9 | transaction_id | int | Master上的顶层事务ID。这个ID是任何子事务的父亲。 |
| 10 | gp_session_id | text | 会话标识符号（带前缀“con”） |
| 11 | gp_command_count | text | 会话内部的命令编号（带前缀“cmd”） |
| 12 | gp_segment | text | Segment内容标识符（对主Segment带前缀“seg”，镜像Segment带前缀“mir”）。Master的内容id总是-1。 |
| 13 | slice_id | text | 切片id（查询计划被执行的部分） |
| 14 | distr_tranx_id | text | 分布式事务ID |
| 15 | local_tranx_id | text | 本地事务ID |
| 16 | sub_tranx_id | text | 子事务ID |
| 17 | event_severity | varchar(10) | 值包括：LOG、ERROR、FATAL、PANIC、DEBUG1、DEBUG2 |
| 18 | sql_state_code | varchar(10) | 与日志消息相关的SQL状态代码 |
| 19 | event_message | text | 日志或者错误消息文本 |
| 20 | event_detail | text | 与错误或者警告消息相关的详细消息文本 |
| 21 | event_hint | text | 与错误或者警告消息相关的提示消息文本 |
| 22 | internal_query | text | 内部产生的查询文本 |
| 23 | internal_query_pos | int | 指向内部产生的查询文本中的光标 |
| 24 | event_context | text | 产生消息的上下文 |
| 25 | debug_query_string | text | 带有完整细节的用户提供的查询字符串，用于调试。这个字符串可能会由于内部使用而修改。 |
| 26 | error_cursor_pos | int | 指向查询字符串中的光标 |
| 27 | func_name | text | 产生这个消息的函数 |
| 28 | file_name | text | 产生消息的内部代码文件 |
| 29 | file_line | int | 产生消息的内部代码文件的行号 |
| 30 | stack_trace | text | 与这个消息相关的栈跟踪文本 |
日志说明
1.3.1 pg_log
这个日志一般是记录服务器与DB的状态，比如各种Error信息，定位慢查询SQL，数据库的启动关闭信息，发生checkpoint过于频繁等的告警信息，诸如此类。linux自带的路径一般在/home/log/postgres下面。该日志有.csv格式和.log。个人建议用前一种，因为一般会按大小和时间自动切割，毕竟查看一个巨大的日志文件比查看不同时间段的多个日志要难得多。另外这种日志是可以被清理删除，压缩打包或者转移，同时并不影响DB的正常运行。当我们有遇到DB无法启动或者更改参数没有生效时，第一个想到的就是查看这个日志。
共有四类，FATAL-严重告警，ERROR-错误，WARNING-警告，LOG-操作日志。由于是文本文件所以查询检索很不方便，经过观察，发现这些文件是有固定格式的，可以采用外部表的方式进行查询，同时可以利用相关的工具进行过滤
1.3.2 pg_xlog
这个日志是记录的Postgresql的WAL信息，也就是一些事务日志信息(transaction log)，默认单个大小是16M，源码安装的时候可以更改其大小。这些信息通常名字是类似'000000010000000000000013'这样的文件，这些日志会在定时回滚恢复(PITR)，流复制(Replication Stream)以及归档时能被用到，这些日志是非常重要的，记录着数据库发生的各种事务信息，不得随意删除或者移动这类日志文件，不然你的数据库会有无法恢复的风险
当你的归档或者流复制发生异常的时候，事务日志会不断地生成，有可能会造成你的磁盘空间被塞满，最终导致DB挂掉或者起不来。遇到这种情况不用慌，可以先关闭归档或者流复制功能，备份pg_xlog日志到其他地方，但请不要删除。然后删除较早时间的的pg_xlog，有一定空间后再试着启动Postgres。
日志分析可用通过如下手段（这块内容我会单独整理一个blog）
-
文件查看和检索
-
利用外部表方式进行查询
-
通过logstash工具进行定制分析
-
通过在安装了gpperfmon组件的情况下，通过log_alert_history 进行查询
-
查看系统视图
-
List of relations
-
Schema | Name | Type | Owner | Storage
-
------------+------------------------+------+----------+---------
-
gp_toolkit | gp_log_command_timings | view | digoal | none -- 统计
-
gp_toolkit | gp_log_database | view | digoal | none -- 这个包含当前数据库日志
-
gp_toolkit | gp_log_master_concise | view | digoal | none -- 统计
-
gp_toolkit | gp_log_system | view | digoal | none -- 这个包含所有日志
-
(4 rows)
-
通过gplogfilter工具来查找匹配指定标准的日志数据（包含segment gpssh）
1.3.3 pg_clog
pg_clog这个文件也是事务日志文件，但与pg_xlog不同的是它记录的是事务的元数据(metadata)，这个日志告诉我们哪些事务完成了，哪些没有完成。这个日志文件一般非常小，但是重要性也是相当高，不得随意删除或者对其更改信息。
总结：
pg_log记录各种Error信息，以及服务器与DB的状态信息，可由用户随意更新删除
pg_xlog与pg_clog记录数据库的事务信息，不得随意删除更新，做物理备份时要记得备份着两个日志。
1.4 数据库的启动和关闭日志
程序日志文件:使用gpstart，gpstop 等相关命令的日志 缺省位于~/gpAdminLogs目录下 命令方式：
日志常用的参数和配置方案
下面是Greenplum与安全相关的审计（或者日志）服务器配置参数，它们可以在postgresql.conf配置文件中设置：
| 域名 | 值范围 | 默认 | 描述 |
|---|---|---|---|
| log_connections | Boolean | off | 这会对服务器日志输出一行详细描述每个成功的连接。某些客户端程序（如psql）在决定是否要求口令时会尝试连接两次，因此重复的“connection received”消息并非总是表示问题。 |
| log_disconnections | Boolean | off | 在一个客户端会话终止时，这会在服务器日志中输出一行，其中会包括该会话的持续时间。 |
| log_statement | NONEDDLMODALL | ALL | 控制那些SQL语句会被记录。DDL记录所有数据定义命令，如CREATE、ALTER和DROP命令。MOD记录所有DDL语句外加INSERT、UPDATE、DELETE、TRUNCATE以及COPY FROM。如果PREPARE和EXPLAIN ANALYZE语句中如果包含有适当类型的命令，它们也会被日志记录。 |
| log_hostname | Boolean | off | 连接日志消息默认只显示连接主机的IP地址。把这个选项打开会导致主机名也被记录。注意这依赖于用户的主机名解析设置，而且这有可能会带来不可忽视的性能损失。 |
| log_duration | Boolean | off | 致使每一个满足log_statement的完成语句的持续时间被记录。 |
| log_error_verbosity | TERSEDEFAULTVERBOSE | DEFAULT | 为被记录的每条消息控制写入到服务器日志的细节多少。 |
| log_min_duration_statement | 毫秒数, 0, -1 | -1 | 如果语句的持续时间大于等于指定的毫秒数，则在一个日志行中记录该语句和它的持续时间。将这个参数设置为0将打印出所有的语句及其持续时间。-1禁用这一特性。例如，如果用户将它设置为250，那么所有运行时间大于等于250ms的SQL语句将被记录。在跟踪应用中的未优化查询时，启用这一选项非常有用。 |
| log_min_messages | DEBUG5 DEBUG4 DEBUG3 DEBUG2 DEBUG1 INFO NOTICE WARNING ERROR LOG FATAL PANIC | NOTICE | 控制哪些消息级别会被写入到服务器日志。每个级别包括其后的所有级别。级别越靠后，发送到日志的消息就越少。 |
| log_rotation_age | 任意有效的时间表达式（数字和单位） | 1d | 决定个体日志文件的最大生存时间。在这个时间过去之后，一个新的日志文件将被创建。设置为零可禁用新日志文件基于时间创建。 |
| log_statement_stats | Boolean | off | 对每个查询，写入查询解析器、规划器和执行器的整体性能统计信息到服务器日志中。这是一种粗糙的画像手段。 |
| og_truncate_on_rotation | Boolean | off | 截断（重写）而不是追加到任何现存的同名日志文件。仅当一个新文件由于基于时间的轮转而被打开时，截断才会发生。例如，使用这个设置配合gpseg#-%H.log这样的log_filename会导致产生24个每小时的日志文件，然后循环地重写它们。关闭这一设置时，预先已经存在的文件在所有的情况下都会被追加内容。 |
如下一共三个配置方案，可根据业务需求进行配置
| 参数 | 说明 |
|---|---|
| logging_collector | 是否打印log |
| log_line_prefix | 日志格式 |
| log_directory | 日志保存目录 |
| log_statement | 打印sql 类型 |
| log_min_duration_statement | *记录超时sql，超时多少秒记录* |
| *log日志方案（1）每天生成一个日志文件* | |
| log_filename = ‘postgresql-%Y-%m-%d_%H%M%S.log | 文件名 |
| log_truncate_on_rotation = off | 文件存在是否覆盖 |
| log_rotation_age = 1d | 间隔多长时间更换新文件 |
| log_rotation_size = 0 | 超过大小则换一个文件 |
| log日志方案（2）每当日志写完一定大小，则换一个 | |
| log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log | |
| log_truncate_on_rotation = off | |
| log_rotation_age = 0 | |
| log_rotation_size = 10M | |
| *log日志方案（3）只保留7天的日志，循环替换* | |
| log_filename = 'postgresql-%a.log | 星期 |
| log_truncate_on_rotation = on | 开启覆盖 |
| log_rotation_age = 1d | |
| log_rotation_size = 0 |
日志过滤工作的使用
检查segment日志
gplogfilter -n 3 输出最后3行日志
如果想查看segment节点的日志，那么可以执行以下命令
gpssh -f seg_hosts #seg_hosts为segment节点的主机列表
=>source /usr/local/greenplum-db/greenplum_path.sh
=>gplogfilter -n 3 /greenplum/gpdata/primary1/gpseg*/pg_log/gpdb-*.csv #segment节
gplogfilter+gpssh工具组合在所有segment节点进行查找
可以通过gplogfilter+gpssh组合使用，集中查看log
日志文件对于确定出错的原因可以提供更多的信息。 Master和每个Segment Instance都有自己的日志文件，它位于数据目录下的 pg_log 中。 Master 的日志文件包含着最多的信息，应该总是首先检查Master日志文件。
可以使用 gplogfilter命令 检查GPDB日志文件。要检查 Segment 的日志文件，可以使用 gpssh 在 Segment 主机上运行 gplogfilter命令。
-
检查日志文件
-
检查 Master 日志文件 WARNING、 ERROR、 FATAL 或 PANIC 级别的日志信息：
$ gplogfilter -t-
使用 gpssh 检查 Segment Instance 日志文件的 WARNING、 ERROR、 FATAL 或 PANIC级别日志信息：
$ gpssh -f seg_hosts_file -e 'source /usr/local/greenplum db/greenplum_path.sh;gplogfilter -t /data1/primary/*/pg_log/gpdb*.log' > seglog.out
查看时间段的
gplogfilter -b '2013-05-23 14:33' -e '2013-05-23 14:33'
筛选
-f '' | --find=''
Finds the log entries containing the specified string.
-F '' | --nofind=''
Rejects the log entries containing the specified string.
-m | --match=
Finds log entries that match the specified Python regular expression.
See http://docs.python.org/library/re.html for Python regular expression
syntax.
-M | --nomatch=
Rejects log entries that match the specified Python regular expression.
See http://docs.python.org/library/re.html for Python regular expression
syntax. 
Greenplum提供了gp_toolkit.gp_log...视图，用来汇聚日志，方便查看。
gp_toolkit.gp_log*
由于GP为分布式数据库，当查看它的一些日志时，如果到服务器上查看，会非常的繁琐，而且不好排查问题。
Greenplum提供了gp_toolkit.gp_log...视图，用来汇聚日志，方便查看。
[gpadmin@mdw ~]$ psql
psql (8.3.23)
Type "help" for help.
archdata=# \dv gp_toolkit.gp_log*
List of relations
Schema | Name | Type | Owner | Storage
------------+------------------------+------+---------+---------
gp_toolkit | gp_log_command_timings | view | gpadmin | none
gp_toolkit | gp_log_database | view | gpadmin | none
gp_toolkit | gp_log_master_concise | view | gpadmin | none
gp_toolkit | gp_log_system | view | gpadmin | none
(4 rows)
archdata=# gp_toolkit.gp_log_* 视图
-
gp_log_command_timings (只输出会话，PID，时间，如果关注运行较长时间的详细信息，可根据会话，PID在gp_log_system中定位)
This view uses an external table to read the log files on the master and report the execution time of SQL commands executed in a database session.
The use of this view requires superuser permissions. -
gp_log_master_concise (只有master节点的日志)
This view uses an external table to read a subset of the log fields from the master log file.
The use of this view requires superuser permissions. -
gp_log_system (汇聚master,segment,mirror节点的日志，含所有数据库)
This view uses an external table to read the server log files of the entire Greenplum system (master, segments, and mirrors) and lists all log entries.
Associated log entries can be identified by the session id (logsession) and command id (logcmdcount).
The use of this view requires superuser permissions. -
gp_log_database (汇聚master,segment,mirror节点的日志，含当前数据库)
This view uses an external table to read the server log files of the entire Greenplum system (master, segments, and mirrors) and lists log entries associated with the current database.
Associated log entries can be identified by the session id (logsession) and command id (logcmdcount).
The use of this view requires superuser permissions.
archdata=# \x
Expanded display is on.
archdata=# select * from gp_toolkit.gp_log_database limit 1000;
-[ RECORD 1 ]--+----------------------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
------------------------------
logtime | 2020-04-21 14:37:45.293413+08
loguser | gpadmin
logdatabase | archdata
logpid | p21318
logthread | th1795716992
loghost | ::1
logport | 22062
logsessiontime | 2020-04-21 14:37:45+08
logtransaction | 0
logsession |
logcmdcount |
logsegment | seg-1
logslice |
logdistxact |
loglocalxact |
logsubxact |
logseverity | FATAL
logstate | 57P03
logmessage | the database system is starting up
logdetail |
loghint |
logquery |
logquerypos |
logcontext |
logdebug |
logcursorpos | 0
logfunction |
logfile | postmaster.c
logline | 2927
logstack |
-[ RECORD 2 ]--+----------------------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
------------------------------
logtime | 2020-04-21 14:37:46.311543+08
loguser | gpadmin
logdatabase | archdata
logpid | p21349
logthread | th1795716992
loghost | ::1
logport | 22074
logsessiontime | 2020-04-21 14:37:46+08
logtransaction | 0
logsession | con5
logcmdcount | cmd1
logsegment | seg-1
logslice |
logdistxact |
loglocalxact |
logsubxact | sx1
logseverity | LOG
logstate | 00000
logmessage | statement: BEGIN
logdetail |
loghint |
logquery |
logquerypos |
logcontext |
logdebug | BEGIN
logcursorpos | 0
logfunction |
logfile | postgres.c
logline | 1590
logstack |
-[ RECORD 3 ]--+----------------------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
------------------------------
logtime | 2020-04-21 14:37:46.311627+08
loguser | gpadmin
logdatabase | archdata
logpid | p21349
logthread | th1795716992
loghost | ::1
logport | 22074
logsessiontime | 2020-04-21 14:37:46+08
logtransaction | 0
logsession | con5
logcmdcount | cmd2
logsegment | seg-1
logslice |
logdistxact |
loglocalxact |
logsubxact | sx1
logseverity | LOG
logstate | 00000
logmessage | statement: SET CLIENT_MIN_MESSAGES='ERROR'
logdetail |
loghint |
logquery |
logquerypos |
logcontext |
logdebug | SET CLIENT_MIN_MESSAGES='ERROR'
logcursorpos | 0
logfunction |
logfile | postgres.c
logline | 1590
logstack |
-[ RECORD 4 ]--+----------------------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
------------------------------
logtime | 2020-04-21 14:37:46.311674+08
loguser | gpadmin
logdatabase | archdata
logpid | p21349
logthread | th1795716992
loghost | ::1
logport | 22074
logsessiontime | 2020-04-21 14:37:46+08
logtransaction | 0
logsession | con5
logcmdcount | cmd3
logsegment | seg-1
logslice |
logdistxact |
loglocalxact |
logsubxact | sx1
logseverity | LOG
logstate | 00000
logmessage | statement: COMMIT
logdetail |
loghint |
logquery |
logquerypos |
logcontext |
logdebug | COMMIT
logcursorpos | 0
logfunction |
logfile | postgres.c
logline | 1590
logstack |
select * from gp_toolkit.gp_log_command_timings order by logsession,logcmdcount limit 100;
archdata=# select * from gp_toolkit.gp_log_command_timings order by logsession,logcmdcount limit 100;
-[ RECORD 1 ]------------------------------
logsession | con10
logcmdcount | cmd1
logdatabase | gpperfmon
loguser | gpmon
logpid | p14674
logtimemin | 2020-04-25 07:03:54.693368+08
logtimemax | 2020-04-25 07:03:54.702078+08
logduration | 00:00:00.00871
-[ RECORD 2 ]------------------------------
logsession | con10
logcmdcount | cmd1
logdatabase | gpperfmon
loguser | gpmon
logpid | p24290
logtimemin | 2020-04-25 08:38:59.935377+08
logtimemax | 2020-04-25 08:38:59.943972+08
logduration | 00:00:00.008595
select * from gp_toolkit.gp_log_master_concise limit 1000;
archdata=# select * from gp_toolkit.gp_log_master_concise limit 1000;
-[ RECORD 1 ]-------------------------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------------
logtime | 2020-04-21 14:30:21.830595+08
logdatabase |
logsession |
logcmdcount |
logseverity | LOG
logmessage | TransitionToMasterOrMirrorless: initializing XLog startup
日志文件的定期清理
greenplum日志存放在pg_log下，master节点和每个segment节点都会有，格式为gpdb-YYYY-MM-DD_hhmmss.cs 需要我们定期清理
定期清理master节点的日志，保留最近8天的日志
find master日志目录 -type f -name "gpdb-*.csv" -ctime +8 -exec rm {} \;