Greenplum的日誌管理
本篇文檔首先介紹GP的日誌架構，日誌工具的使用說明，然後介紹一下日誌的定期清理配置案例
目錄
gplogfilter+gpssh工具組合在所有segment節點進行查找
日誌架構
日誌路徑
下面的表格展示了各種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目錄下 命令方式：<script_name>_.log 日誌記錄的格式： ::::[INFO|WARN|FATAL]:
日誌常用的參數和配置方案
下面是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 '<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 {} \;