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.logSegment启动日志
/home/gpadmin/gpadminlogs/gpsegstop.py_idb*gpadmin_date.logSegment停止日志
/greenplum/gpdata/master/gpseg-1/pg_log/startup.log实例启动日志
/greenplum/gpdata/master/gpseg-1/gpperfmon/logs/gpmon.*.loggpperfmon日志
/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)确定。

#域名数据类型描述
1event_timetimestamp with time zone日志项被写到日志中的时间
2user_namevarchar(100)数据库用户名
3database_namevarchar(100)数据库名
4process_idvarchar(10)系统进程ID(带前缀“p”)
5thread_idvarchar(50)线程计数(带前缀“th”)
6remote_hostvarchar(100)在Master上,是客户端机器的主机名/地址。在Segment上,是Master的主机名/地址。
7remote_portvarchar(10)Segment或Master的端口号
8session_start_timetimestamp with time zone会话连接打开的时间
9transaction_idintMaster上的顶层事务ID。这个ID是任何子事务的父亲。
10gp_session_idtext会话标识符号(带前缀“con”)
11gp_command_counttext会话内部的命令编号(带前缀“cmd”)
12gp_segmenttextSegment内容标识符(对主Segment带前缀“seg”,镜像Segment带前缀“mir”)。Master的内容id总是-1。
13slice_idtext切片id(查询计划被执行的部分)
14distr_tranx_idtext分布式事务ID
15local_tranx_idtext本地事务ID
16sub_tranx_idtext子事务ID
17event_severityvarchar(10)值包括:LOG、ERROR、FATAL、PANIC、DEBUG1、DEBUG2
18sql_state_codevarchar(10)与日志消息相关的SQL状态代码
19event_messagetext日志或者错误消息文本
20event_detailtext与错误或者警告消息相关的详细消息文本
21event_hinttext与错误或者警告消息相关的提示消息文本
22internal_querytext内部产生的查询文本
23internal_query_posint指向内部产生的查询文本中的光标
24event_contexttext产生消息的上下文
25debug_query_stringtext带有完整细节的用户提供的查询字符串,用于调试。这个字符串可能会由于内部使用而修改。
26error_cursor_posint指向查询字符串中的光标
27func_nametext产生这个消息的函数
28file_nametext产生消息的内部代码文件
29file_lineint产生消息的内部代码文件的行号
30stack_tracetext与这个消息相关的栈跟踪文本

日志说明

 

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配置文件中设置:

域名值范围默认描述
log_connectionsBooleanoff这会对服务器日志输出一行详细描述每个成功的连接。某些客户端程序(如psql)在决定是否要求口令时会尝试连接两次,因此重复的“connection received”消息并非总是表示问题。
log_disconnectionsBooleanoff在一个客户端会话终止时,这会在服务器日志中输出一行,其中会包括该会话的持续时间。
log_statementNONEDDLMODALLALL控制那些SQL语句会被记录。DDL记录所有数据定义命令,如CREATE、ALTER和DROP命令。MOD记录所有DDL语句外加INSERT、UPDATE、DELETE、TRUNCATE以及COPY FROM。如果PREPARE和EXPLAIN ANALYZE语句中如果包含有适当类型的命令,它们也会被日志记录。
log_hostnameBooleanoff连接日志消息默认只显示连接主机的IP地址。把这个选项打开会导致主机名也被记录。注意这依赖于用户的主机名解析设置,而且这有可能会带来不可忽视的性能损失。
log_durationBooleanoff致使每一个满足log_statement的完成语句的持续时间被记录。
log_error_verbosityTERSEDEFAULTVERBOSEDEFAULT为被记录的每条消息控制写入到服务器日志的细节多少。
log_min_duration_statement毫秒数, 0, -1-1如果语句的持续时间大于等于指定的毫秒数,则在一个日志行中记录该语句和它的持续时间。将这个参数设置为0将打印出所有的语句及其持续时间。-1禁用这一特性。例如,如果用户将它设置为250,那么所有运行时间大于等于250ms的SQL语句将被记录。在跟踪应用中的未优化查询时,启用这一选项非常有用。
log_min_messagesDEBUG5 DEBUG4 DEBUG3 DEBUG2 DEBUG1 INFO NOTICE WARNING ERROR LOG FATAL PANICNOTICE控制哪些消息级别会被写入到服务器日志。每个级别包括其后的所有级别。级别越靠后,发送到日志的消息就越少。
log_rotation_age任意有效的时间表达式(数字和单位)1d决定个体日志文件的最大生存时间。在这个时间过去之后,一个新的日志文件将被创建。设置为零可禁用新日志文件基于时间创建。
log_statement_statsBooleanoff对每个查询,写入查询解析器、规划器和执行器的整体性能统计信息到服务器日志中。这是一种粗糙的画像手段。
og_truncate_on_rotationBooleanoff截断(重写)而不是追加到任何现存的同名日志文件。仅当一个新文件由于基于时间的轮转而被打开时,截断才会发生。例如,使用这个设置配合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命令

  • 检查日志文件

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

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值