Greenplum的日志管理

最新推荐文章于 2022-03-12 11:08:01 发布

原创

最新推荐文章于 2022-03-12 11:08:01 发布 · 8.5k 阅读

29 ·

CC 4.0 BY-SA版权

本文详细介绍Greenplum数据库的日志架构，包括日志路径、日志文件的说明及配置参数，阐述如何使用gplogfilter和gpssh工具检查Segment日志，以及如何利用gp_toolkit.gp_log视图进行日志汇聚分析。

Greenplum的日志管理

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

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）