HAWQ技術解析（十六） —— 運維監控
一、推薦的監控與維護任務
表1至表5是HAWQ向系統管理員推薦定期執行的活動，包括系統與資料庫監控、資料與資料庫的維護、補丁與升級等，目的是要確認系統的所有元件都可以正常工作。監控工作有助於在早期發現和診斷問題。維護任務幫助使用者保持系統是最新的，應用了所有錯誤修復和功能性改進，並且避免效能衰減。例如，解決由於臃腫的系統表或逐漸減少的剩餘磁碟空間引發的問題。最好但不是必須在每個叢集中實施所有的建議。可以根據自身的服務需求，參考執行頻率和嚴重性級別建議，將其作為實施運維監控的指南。
1. 資料庫狀態監控活動
表1為推薦的資料庫監控活動。活動 | 過程 | 改進措施 |
列出當前down的段。如果返回任何行，這應該生成一個警告。 推薦頻率：每5到10分鐘執行一次。 重要性：重要 | 在‘postgres’資料庫中執行下面的查詢： SELECT * FROM gp_segment_configuration WHERE status <> 'u'; | 如果查詢返回任何行，執行下面的步驟修正問題： 1. 驗證down段所在主機有響應。 2. 如果主機OK，為down段檢查pg_log檔案,尋找段down掉的根本原因。 |
執行一個分散式查詢檢測它在所有段上執行。每個段應該返回一行。 推薦頻率：每5到10分鐘執行一次。 重要性：極為重要 | 在‘postgres’資料庫中執行下面的查詢： SELECT gp_segment_id, count(*) FROM gp_dist_random('pg_class') GROUP BY 1; | 如果查詢失敗，說明對叢集中某些段的任務分發有問題。這是很少見的情況。檢查不能被分派任務的主機，確認沒有硬體或網路問題。 |
執行一個基本的檢查，看主節點是否啟動並工作。 推薦頻率：每5到10分鐘執行一次。 重要性：極為重要 | 在‘postgres’資料庫中執行下面的查詢： SELECT count(*) FROM gp_segment_configuration; | 如果此查詢失敗，主節點可能down了。重試幾次並手工檢查主節點的活動。如果主節點down，重啟或在主主節點沒有遺留程序時啟用從主節點。 |
表1
2. 硬體與作業系統監控
表2為推薦的硬體與系統監控活動。活動 | 過程 | 改進措施 |
底層平臺檢查，維護需求或硬體的系統停機。 推薦頻率：如果可能，實時，或者每15分鐘。 重要性：極為重要 | 設定硬體和OS錯誤檢查。 | 如果需要，從HAWQ叢集中移除存在硬體或OS問題的主機，解決後在添加回來。 |
檢查HAWQ資料儲存和OS的磁碟空間使用情況。 推薦頻率：5到30分鐘。 重要性：極為重要 | 設定磁碟空間檢查。 . 設定閾值，當磁碟達到使用的百分比產生警告。推薦閾值為全部空間的75%。 . 不推薦空間使用接近100%時執行系統。 | 刪除資料或檔案，釋放系統空間。 |
檢查網絡卡錯誤或刪除包 推薦頻率：每小時。 重要性：重要 | 設定網絡卡檢查。 | 與網路或系統團隊一起解決問題。 |
檢查RAID錯誤或RAID效能衰減。 推薦頻率：每5分鐘。 重要性：極為重要 | 設定RAID檢查。 | . 儘快替換失敗的磁碟。 . 與系統管理團隊一起儘快解決其它RAID或控制器問題。 |
檢查是否有足夠的I/O頻寬，或I/O傾斜。 推薦頻率：建立叢集或懷疑硬體問題時。 | 執行‘hawq checkperf’應用 | 如果資料傳輸率與以下不相似，叢集頻寬可能不足。 . 每秒2GB的磁碟讀 . 每秒1GB的磁碟寫 . 每秒10GB的網路讀寫 如果傳輸率慢於期望，考慮期望的效能諮詢你的架構顧問。 如果叢集的機器顯示出參差不齊的剖析，與系統管理團隊一起解決機器錯誤。 |
表2
3. 資料維護
表3為推薦的資料維護活動。活動 | 過程 | 改進措施 |
檢查缺少統計資訊的表。 | 檢查每個資料庫中的‘hawq_stats_missing’檢視： | 在缺少統計資訊的表上執行ANALYZE。 |
表3
4. 資料庫維護
表4為推薦的資料庫維護活動。活動 | 過程 | 改進措施 |
標記HAWQ系統目錄中被刪除的行（‘pg_catalog’表模式中的表）以重用它們佔用的空間。 | 清空每個系統目錄： | 定期清空系統目錄，避免膨脹。 |
清空所有接近vacuum_freeze_min_age值的系統目錄，（‘pg_catalog’模式中的表） | 清空單個系統目錄表： | 在到達vacuum_freeze_min_age值後，VACUUM掃描表時，不再用FrozenXID替換事務ID。對這些表到達限制之前上執行vacuum。 |
修改表的統計資訊。 | 分析使用者表： | 定期分析更新的表，使得查詢優化器能夠產生高效的執行計劃。 |
備份資料庫資料。 | 使用PXF | 最佳實踐是，當資料庫必須還原時，有一個當前資料庫的備份。 |
清空系統目錄（‘pg_catalog’模式中的表），維護高效目錄。 | VACUUM每個資料庫的系統表。 | 優化器從系統表查詢資訊建立查詢計劃。如果系統表和索引被允許隨著時間膨脹，掃描系統表會增加查詢時間。 |
5. 補丁與升級
表5為推薦的補丁與升級活動。活動 | 過程 | 改進措施 |
保證任何修復的bug和提升被應用到核心。 推薦頻率：至少每六個月 重要性：重要 | 按照廠商的指導更新Linux核心。 | 保持當前核心包含修復的bug和安全性問題，避免將來困難的升級。 |
安裝HAWQ次要版本 Recommended 推薦頻率：每季度 重要性：重要 | 總是升級到最新的系列。 | 保持當前的HAWQ軟體包含修復的bug，效能提升，以及HAWQ叢集的提升特性。 |
表5
為保持HAWQ系統高效執行，必須執行這些例行系統維護任務。如資料庫必須定期清理過期資料，並且更新表的統計，讓查詢優化器能夠獲得精確的資訊。HAWQ DBA可以使用標準的類UNIX工具，如cron指令碼，自動執行這些任務。指令碼至少應該能夠提供任務是否執行成功和執行時間等資訊，比如使用最簡單的輸出日誌方式實現。除了系統級的運維，還有一項重要的工作是維護HAWQ日誌檔案。HAWQ中的每個資料庫例項，包括master和segment，都會執行一個PostgreSQL資料庫伺服器，例如下面ps命令所示的master和segment資料庫伺服器程序：
gpadmin 655225 1 0 Apr24 ? 00:01:52 /usr/local/hawq_2_1_1_0/bin/postgres -D /data/hawq/master -i -M master -p 5432 --silent-mode=true
gpadmin 655753 1 0 Apr24 ? 00:04:28 /usr/local/hawq_2_1_1_0/bin/postgres -D /data/hawq/segment -i -M segment -p 40000 --silent-mode=true二、監控HAWQ系統
觀察HAWQ系統的日常效能幫助管理員理解系統行為，計劃工作流程，或排查系統問題。可以使用多種工具監控HAWQ，包括系統工具或附加元件。本節討論監控資料庫效能與行為的監控方法。可以指令碼化這些監控活動，快速檢查系統中存在的問題。1. hawq_toolkit模式
hawq_toolkit是HAWQ的一個管理模式，使用與下面類似的命令在模式的查詢路徑中增加hawq_toolkit模式：db1=# set role 'gpadmin' ;
SET
db1=# set search_path to public, hawq_toolkit ;
SET
db1=#db1=# \dv
List of relations
Schema | Name | Type | Owner | Storage
--------------+------------------------------------------+------+---------+---------
hawq_toolkit | __hawq_fullname | view | gpadmin | none
hawq_toolkit | __hawq_is_append_only | view | gpadmin | none
hawq_toolkit | __hawq_user_data_tables | view | gpadmin | none
hawq_toolkit | __hawq_user_data_tables_readable | view | gpadmin | none
hawq_toolkit | __hawq_user_namespaces | view | gpadmin | none
hawq_toolkit | __hawq_user_tables | view | gpadmin | none
hawq_toolkit | hawq_log_command_timings | view | gpadmin | none
hawq_toolkit | hawq_log_master_concise | view | gpadmin | none
hawq_toolkit | hawq_size_of_all_table_indexes | view | gpadmin | none
hawq_toolkit | hawq_size_of_database | view | gpadmin | none
hawq_toolkit | hawq_size_of_index | view | gpadmin | none
hawq_toolkit | hawq_size_of_partition_and_indexes_disk | view | gpadmin | none
hawq_toolkit | hawq_size_of_schema_disk | view | gpadmin | none
hawq_toolkit | hawq_size_of_table_and_indexes_disk | view | gpadmin | none
hawq_toolkit | hawq_size_of_table_and_indexes_licensing | view | gpadmin | none
hawq_toolkit | hawq_size_of_table_disk | view | gpadmin | none
hawq_toolkit | hawq_size_of_table_uncompressed | view | gpadmin | none
hawq_toolkit | hawq_stats_missing | view | gpadmin | none
hawq_toolkit | hawq_table_indexes | view | gpadmin | none
(19 rows)2. 監控系統狀態
HAWQ管理員必須監控系統事件，尤其是如段宕機或段主機磁碟空間不足等嚴重問題。下面描述如何監控HAWQ系統的健康狀況，並檢查HAWQ系統的狀態資訊。（1）檢查系統狀態
一個HAWQ系統由分佈於多臺機器的多個PostgreSQL例項（master和segment）構成。監控一個HAWQ系統，需要知道系統的整體資訊，也要知道單個例項的狀態資訊。hawq state應用程式提供HAWQ系統的狀態資訊。
檢視master和segment的狀態與配置：hawq state預設檢查segment例項，顯示可用segment的和失效segment的簡要狀態。例如，檢視HAWQ系統的狀態：
[[email protected] ~]$ hawq state -b
20170427:10:56:54:403768 hawq_state:hdp3:gpadmin-[INFO]:--HAWQ instance status summary
20170427:10:56:54:403768 hawq_state:hdp3:gpadmin-[INFO]:------------------------------------------------------
20170427:10:56:54:403768 hawq_state:hdp3:gpadmin-[INFO]:-- Master instance = Active
20170427:10:56:54:403768 hawq_state:hdp3:gpadmin-[INFO]:-- Master standby = hdp2
20170427:10:56:54:403768 hawq_state:hdp3:gpadmin-[INFO]:-- Standby master state = Standby host passive
20170427:10:56:54:403768 hawq_state:hdp3:gpadmin-[INFO]:-- Total segment instance count from config file = 4
20170427:10:56:54:403768 hawq_state:hdp3:gpadmin-[INFO]:------------------------------------------------------
20170427:10:56:54:403768 hawq_state:hdp3:gpadmin-[INFO]:-- Segment Status
20170427:10:56:54:403768 hawq_state:hdp3:gpadmin-[INFO]:------------------------------------------------------
20170427:10:56:54:403768 hawq_state:hdp3:gpadmin-[INFO]:-- Total segments count from catalog = 4
20170427:10:56:54:403768 hawq_state:hdp3:gpadmin-[INFO]:-- Total segment valid (at master) = 4
20170427:10:56:54:403768 hawq_state:hdp3:gpadmin-[INFO]:-- Total segment failures (at master) = 0
20170427:10:56:54:403768 hawq_state:hdp3:gpadmin-[INFO]:-- Total number of postmaster.pid files missing = 0
20170427:10:56:54:403768 hawq_state:hdp3:gpadmin-[INFO]:-- Total number of postmaster.pid files found = 4
[[email protected] ~]$[[email protected] ~]$ hawq state -d /data/hawq/master/（2）檢查磁碟空間使用
檢視分散式資料庫和表的大小：hawq_toolkit管理模式包含幾個分別用來確認的HAWQ資料庫、模式、表和索引的磁碟空間使用的檢視。
檢視資料庫的磁碟空間使用：為了檢視資料庫的總大小（以位元組表示），使用hawq_toolkit管理模式中的hawq_size_of_database檢視，例如：
db1=# select * from hawq_toolkit.hawq_size_of_database
db1-# order by sodddatname;
sodddatname | sodddatsize
-------------+-------------
db1 | 16129012
gpadmin | 10394524
(2 rows)db1=# select relname as name, sotdsize as size, sotdtoastsize as toast, sotdadditionalsize as other
db1-# from hawq_toolkit.hawq_size_of_table_disk as sotd, pg_class
db1-# where sotd.sotdoid=pg_class.oid order by relname;
name | size | toast | other
---------------------+------+-------+-------
sales | 0 | 0 | 32768
sales_1_prt_p201701 | 40 | 0 | 98304
sales_1_prt_p201702 | 0 | 0 | 32768
sales_1_prt_p201703 | 0 | 0 | 32768
sales_1_prt_p201704 | 0 | 0 | 32768
sales_1_prt_p201705 | 0 | 0 | 32768
sales_1_prt_p201706 | 0 | 0 | 32768
sales_1_prt_p201707 | 0 | 0 | 32768
sales_1_prt_p201708 | 0 | 0 | 32768
sales_1_prt_p201709 | 0 | 0 | 32768
sales_1_prt_p201710 | 0 | 0 | 32768
sales_1_prt_p201711 | 0 | 0 | 32768
sales_1_prt_p201712 | 0 | 0 | 32768
t | 48 | 0 | 98304
(14 rows)db1=# select soisize, relname as indexname
db1-# from pg_class, hawq_toolkit.hawq_size_of_index
db1-# where pg_class.oid=hawq_size_of_index.soioid
db1-# and pg_class.relkind='i';
soisize | indexname
---------+-----------
(0 rows)HAWQ使用它的系統目錄跟蹤資料庫中儲存的不同物件（表、檢視、索引等等）的元資料資訊，還包括角色、表空間等全域性物件。
檢視最後執行的操作：可以使用pg_stat_operations和pg_stat_partition_operations系統檢視查詢一個數據庫物件上執行的操作。例如，檢視t表何時建立，何時做的最後的分析：
db1=# select schemaname as schema, objname as table,
db1-# usename as role, actionname as action,
db1-# subtype as type, statime as time
db1-# from pg_stat_operations
db1-# where objname='t';
schema | table | role | action | type | time
--------+-------+---------+---------+-------+-------------------------------
public | t | gpadmin | CREATE | TABLE | 2017-04-18 15:39:38.858007+08
public | t | gpadmin | ANALYZE | | 2017-04-21 10:16:32.42202+08
(2 rows)db1=# \d t
Append-Only Table "public.t"
Column | Type | Modifiers
--------+---------+-----------
i | integer |
Compression Type: None
Compression Level: 0
Block Size: 32768
Checksum: f
Distributed randomlyHAWQ的hawq_toolkit管理模式包含有關HAWQ工作檔案資訊的檢視。當沒有足夠的記憶體在記憶體中執行查詢時，HAWQ在磁碟上建立工作檔案。工作檔案資訊常被用於查詢的調優和排錯。檢視中的資訊還可以用於為HAWQ配置引數hawq_workfile_limit_per_query和hawq_workfile_limit_per_segment賦值。
hawq_toolkit模式中的檢視包括：
- hawq_workfile_entries - 當前在段上每個在磁碟上建立工作檔案的運算子一行
- hawq_workfile_usage_per_query - 當前段上每個使用磁碟空間執行的查詢一行
- hawq_workfile_usage_per_segment - 每個段一行，顯示當前段上用於工作檔案的磁碟空間總計。
3. HAWQ錯誤程式碼
下面討論描述特定資料庫事件的SQL錯誤程式碼。（1）SQL標準錯誤程式碼
HAWQ Error Codes列出了所有錯誤碼的定義及其所屬的錯誤分類。有一些沒有使用，但是由SQL標準定義。對於每一類錯誤，有一個包含最後三位字元000的標準錯誤碼。該編碼表示錯誤情況應列入此分類，但沒有分配任何特定編碼的情況。
每個錯誤碼的PL/pgSQL條件名與表中描述的相同，只是用下劃線代替了空格。例如，錯誤碼22012，DIVISION BY ZERO，條件名是DIVISION_BY_ZERO。條件名可能是大寫或小寫。
注意：與錯誤不同，PL/pgSQL條件名不識別警告，這些分類是00、01和02。
三、HAWQ日誌檔案管理
日誌檔案中包含HAWQ資料庫和應用程式部署的相關資訊。HAWQ的管理性日誌檔案儲存在預定義或配置的HAWQ節點的本地檔案系統上。這些日誌檔案有各自的位置和格式，被分別配置和管理。前面提到，HAWQ中的每個資料庫例項（主master、從master、segment）執行一個PostgreSQL資料庫程序，該程序有它自己的伺服器日誌檔案。當用戶直接執行HAWQ管理應用程式時，或者通過Ambari間接進行管理操作時，會生成相應的日誌檔案。另外，HAWQ叢集中的其它元件（如PXF、HDFS等）也會生成它們自己的日誌檔案。
可配的日誌引數影響何時、在哪裡記錄什麼訊息。可以通過HAWQ伺服器配置引數或者命令列選項配置HAWQ管理性日誌。
日誌檔案能以預定義或配置的時間間隔建立或輪換。注意，管理性日誌檔案不會自動截斷或刪除。管理員應該實施定期執行的指令碼清除這些日誌檔案。
1. HAWQ伺服器日誌檔案
（1）HAWQ日誌檔案位置日常日誌檔案分別在master和segment節點資料目錄的pg_log子目錄中被建立。可以從$GPHOME/etc/hawq-site.xml配置檔案中的hawq_master_directory和hawq_segment_directory屬性值獲得master與segment資料目錄的位置。
HAWQ資料庫伺服器日誌檔案的命名習慣是hawq-<date>_<time>.[csv|log]。例如hawq-2017-01-02_061611.csv或hawq-2017-01-03_001704.log。目前，一個給定日期的日誌檔案的數量和大小，依賴於HAWQ伺服器相關配置引數的值。
（2）HAWQ日誌格式
HAWQ伺服器日誌檔案是文字或是逗號分隔值（CSV）格式，日誌條目可能包括表6中所示的欄位。
# | 欄位名 | 資料型別 | 描述 |
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) | 執行緒ID（以“th-”為字首） |
6 | remote_host | varchar(100) | 客戶端機器的主機名/IP（如果在主節點上）。或主節點的主機名/IP（如果在段節點上）。 |
7 | remote_port | varchar(10) | 段或主節點的埠號 |
8 | session_start_time | timestamp with time zone | 會話連線開啟的時間 |
9 | transaction_id | int | 主節點上的最上級的事務ID；是任何子事務的父ID。 |
10 | gp_session_id | text | 會話標識號（以“con”為字首） |
11 | gp_command_count | text | 一個會話中的命令數（以“cmd”為字首） |
12 | gp_segment | text | 段內容識別符號。主節點的內容識別符號恆為-1。 |
13 | slice_id | text | 片段ID（查詢計劃中被執行的部分） |
14 | distr_tranx_id | text | 分散式事務識別符號 |
15 | local_tranx_id | text | 本地事務識別符號 |
16 | sub_tranx_id | text | 子事務識別符號 |
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 | 用於debug的使用者提供的查詢字串。此字串在內部使用時可能會被修改。 |
26 | error_cursor_pos | int | 查詢字串的遊標索引 |
27 | func_name | text | 生成此訊息的函式 |
28 | file_name | text | 原始訊息所在的原始檔名稱 |
29 | file_line | int | 原始訊息所在原始檔中的行號 |
30 | stack_trace | Text | 訊息相關的堆疊跟蹤文字 |
注意：日誌條目可能不包括所有日誌欄位的值。例如，slice_id欄位只存在於查詢工作程序相關的日誌條目中。
（3）檢查HAWQ日誌檔案
在診斷問題或獲取HAWQ部署資訊時都可能需要檢查HAWQ日誌檔案。
使用transaction_id識別事務相關的日誌條目。通過查詢的會話識別符號gp_session_id和命令識別符號gp_command_count，可以識別特定查詢相關的日誌條目。或者，當gp_log_format伺服器配置引數值配置為csv格式的日誌檔案時，可以使用hawq_toolkit管理模式查詢HAWQ日誌檔案例如，下面的hawq_toolkit查詢顯示所有名為mytest資料庫的ERROE日誌相關的時間和訊息：
select logtime, logmessage from hawq_toolkit.hawq_log_master_concise
where logdatabase='mytest' and logseverity='error';（4）在HAWQ日誌檔案查詢
使用HAWQ的gplogfilter應用查詢一個HAWQ日誌檔案中與特性條件匹配的條目。預設時，這個應用查詢預設位置的HAWQ主節點日誌檔案。例如，顯示2017年3月1日14點之後的主節點日誌檔案條目：
[[email protected] ~]$ gplogfilter -b '2017-03-01 14:00'[[email protected] ~]$ echo -e "hdp1\nhdp2\nhdp3\nhdp4\n" > seg_hosts
[[email protected] ~]$ hawq ssh -f seg_hosts
=> source /usr/local/hawq/greenplum_path.sh
=> gplogfilter -n 3 /data/hawq/segment/pg_log/hawq*.csv（5）配置HAWQ日誌
可以使用HAWQ伺服器日誌引數配置HAWQ伺服器對日誌的操作。這些配置引數相互協調，一起決定何時哪些資訊被記錄的HAWQ的伺服器日誌檔案中。如果啟用了日誌輪轉，可以通過HAWQ伺服器配置引數控制輪轉操作。HAWQ還提供了一系列伺服器配置引數專門處理GPORCA查詢執行器和優化器日誌。
表7-9彙總了伺服器日誌、日誌輪轉、查詢執行器和查詢優化器日誌相關的配置引數。
伺服器配置引數 | 描述 |
client_min_messages | 標識客戶端訊息的日誌級別。 |
debug_pretty_print | Debug輸出的縮排格式，增強可讀性。 |
gp_log_format | 定義伺服器日誌檔案格式。 |
gp_max_csv_line_length | 設定csv檔案的最大行長。 |
log_autostats | 記錄自動統計生成資訊。 |
log_connections | 記錄客戶端連線。 |
log_disconnections | 記錄客戶端終止連線。 |
log_dispatch_stats | 與語句排程相關的日誌資訊。 |
log_duration | 記錄語句執行時間。 |
log_error_verbosity | 定義日誌細節程度。 |
log_hostname | 記錄連線的主機名。 |
log_min_duration_statement | 配置最小執行時間，小於該時間的語句不記日誌。 |
log_min_error_statement | 記錄引發錯誤的SQL語句。 |
log_min_messages | 日誌檔案的日誌級別。 |
log_statement | 控制日誌中記錄哪些SQL語句。 |
log_timezone | 設定日誌檔案時間戳的時區。 |
伺服器配置引數 | 描述 |
log_rotation_age | 配置日誌檔案生命週期。 |
log_rotation_size | 配置日誌檔案最大尺寸。 |
log_truncate_on_rotation | 表示日誌輪轉時是否清空。 |
表8 日誌輪轉引數
伺服器配置引數 | 描述 |
debug_print_parse | 記錄查詢解析樹。 |
debug_print_plan | 記錄查詢計劃。 |
debug_print_prelim_plan | 記錄初步查詢計劃。 |
debug_print_rewritten | 記錄查詢重寫輸出。 |
debug_print_slice_table | 記錄查詢計劃分片。 |
log_executor_stats | 記錄查詢執行器效能統計。 |
log_parser_stats | 記錄查詢編譯器效能統計。 |
log_planner_stats | 記錄遺留老優化器（planner）的效能統計。 |
log_statement_stats | 記錄編譯器、執行器、優化器總的效能統計。 |
表9 查詢執行器和查詢優化器日誌相關引數
（6）管理HAWQ日誌檔案
HAWQ日誌的輸出往往很龐大，尤其是debug級別高時。因此不應該無限期地儲存這些資訊。通常HAWQ管理員會配置HAWQ定期輪轉日誌檔案，建立新的日誌檔案。
日常的日誌檔案被建立在master和segment資料目錄下的pg_log子目錄中。儘管日誌檔案日常輪轉，但它們不會自動截斷或刪除。管理員必須實現並執行指令碼，定期清理主master、從master和每個segment例項上老的日誌檔案。例如以下命令刪除master節點30天前的日誌檔案。
find /data/hawq/master/pg_log/ -mtime +30 -name "*.csv" -exec rm -rf {} \;2. 應用程式的日誌檔案
從命令列或使用Ambari使用者介面執行叢集管理動作時，會呼叫HAWQ應用程式。無論從哪裡執行管理動作，這些應用都會記錄命令執行狀態及結果的日誌資訊。訊息輸出到標準輸出，同時被記錄到日誌檔案中。一個應用被呼叫時，建立並維護一個“每天”日誌檔案。特定應用的執行日誌，在應用每次執行時追加到它當天的日誌檔案中。
注意：某些應用呼叫其它一個或多個應用。例如，hawq restart呼叫hawq stop和hawq start。此時日誌被寫入到呼叫的兩個應用的日誌檔案中。
（1）應用程式日誌檔案的位置
HAWQ應用日誌檔案的預設位置是/home/gpadmin/hawqAdminLogs/。可以選擇指定一個其它的日誌檔案目錄。
HAWQ應用日誌檔案的命名習慣是<cmdname>_<date>.log。例如，hawq_state_20170102.log或hawq_start_20161228.log。
（2）應用程式日誌檔案的格式
HAWQ應用日誌檔案以文字格式寫入，日誌條目構成如下：<date>:<time>:<pid> <cmdname>:<host>:<user>-[<loglevel>]:-<message>
日誌條目欄位描述如表10所示。
日誌條目欄位 | 描述 |
date | 條目被記錄的日期（月、日、年） |
time | 條目被記錄的時間 |
pid | 與命令相關的程序號 |
cmdname | HAWQ管理應用名 |
host | 命令執行所在主機 |
user | 呼叫命令的使用者名稱 |
loglevel | 日誌級別，是DEBUG、INFO、WARN、FATAL之一。預設的日誌級別是INFO，有更多的重要訊息。 |
message | 日誌訊息 |
注意：某些特殊管理應用命令的日誌檔案，例如hawq init，格式與慣例不同。
（3）檢查應用程式日誌條目
可以從HAWQ應用日誌檔案獲得更多關於命令執行的細節資訊。另外，特定命令最近的日誌檔案提供了命令被最後呼叫的日期/時間及其狀態資訊。
（4）配置應用程式日誌
所有應用都支援詳細輸出和檔案目錄日誌選項：
- -l | –logdir <dir>：指定日誌所在目錄
- -v | –verbose：輸出中包括DEBUG日誌訊息。
（5）管理應用程式日誌檔案
與伺服器日誌一樣，儘管日誌檔案日常輪轉，但它們不會自動截斷或刪除。管理員必須實現並執行指令碼或程式，定期清理老的管理應用日誌檔案。
3. 查詢Minidump日誌檔案
可以配置HAWQ GPORCA查詢優化器生成minidump匯出檔案，描述給定查詢的優化上下文。（minidump裡的資訊不是一種能夠輕易理解的格式。它主要的使用場景是生成並提供minidump檔案給HAWQ開發或支援團隊。）GPORCA minidump包括以下與查詢相關的資訊：
- GPORCA所需要的包含資料型別、表、操作符和統計資訊的目錄物件。
- 一個查詢的內部表示。
- 一個GPORCA生成的查詢計劃的內部表示。
- 傳給GPORCA的系統配置資訊，包括伺服器配置引數，成本與統計配置，段的數量等。
- 查詢優化時生成的錯誤跟蹤堆疊。
使用HAWQ的optimizer_minidump伺服器配置引數配置生成minidump。預設只在產生錯誤時生成minidump檔案。