Greenplum的日志管理

本篇文档首先介绍GP的日志架构，日志工具的使用说明，然后介绍一下日志的定期清理配置案例

[TOC]

日志架构

日志路径

下面的表格展示了各种Greenplum数据库日志文件的位置。在文件路径中，date是YYYYMMDD格式的日期，instance是当前的实例名称，而n是Segment编号。

服务器日志文件被写为逗号分隔值（CSV）格式。不是所有的日志项在所有的日志域中都有值。例如，只有与查询工作者进程相关的日志项才会有slice_id值。一个特定查询的相关日志项可以通过其会话标识符（gp_session_id）和命令标识符（gp_command_count）确定。

日志说明

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 进行查询
• 查看系统视图

1. List of relations    
   

2. Schema   |          Name          | Type |  Owner   | Storage     
   

3. ------------+------------------------+------+----------+---------    
   

4. gp_toolkit | gp_log_command_timings | view | digoal   | none  -- 统计    
   

5. gp_toolkit | gp_log_database        | view | digoal   | none  -- 这个包含当前数据库日志    
   

6. gp_toolkit | gp_log_master_concise  | view | digoal   | none  -- 统计    
   

7. gp_toolkit | gp_log_system          | view | digoal   | none  -- 这个包含所有日志    
   

8. (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目录下
命令方式：<script_name>_.log
日志记录的格式：
::::[INFO|WARN|FATAL]:

日志常用的参数和配置方案

下面是Greenplum与安全相关的审计（或者日志）服务器配置参数，它们可以在postgresql.conf配置文件中设置：

如下一共三个配置方案，可根据业务需求进行配置

日志过滤工作的使用

检查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命令。

• 检查日志文件

1. 检查 Master 日志文件 WARNING、 ERROR、 FATAL 或 PANIC 级别的日志信息：

$ gplogfilter -t

1. 使用 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 '<string>' | --find='<string>' 

 Finds the log entries containing the specified string. 

 
-F '<string>' | --nofind='<string>' 

 Rejects the log entries containing the specified string.
 
 -m <regex> | --match=<regex> 

 Finds log entries that match the specified Python regular expression. 
 See http://docs.python.org/library/re.html for Python regular expression 
 syntax. 


-M <regex> | --nomatch=<regex> 

 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 {} ;