日誌，日誌，日誌，無論你是IT 的那個LEVEL 都知道，沒有日誌的系統是有硬傷，POSTGRESQL 的日誌在數據庫界應該屬於上層的，一個錯誤的日誌，包含的事件類型是很全面的，當然這也帶出另一個問題，他不像MYSQL 那樣將日誌分的很細，慢查詢的是慢查詢，錯誤是錯誤，所以一個合適的分析的工具將變得非常重要。
通過 pgbadger 可以對postgresql 的日誌進行分析，並且以網頁的方式信息展示，還是先給展示一下大致的樣子。
可統計的信息很多所以這個pgbadger 的功能也是很豐富的，其中有一個功能要說，他可以彌補上一期監控軟件的一個缺失，就是慢查詢的問題。當然問題的一個個說。
首先pgbadger 是一個通過日誌來分析問題的和展示問題的軟件，那我們就的把問題的關鍵點回歸到日誌，在多種數據庫中，Postgresql的日誌可以說是很全面的，並且都在一個日誌體系裡面體現，這也就為分析日誌創造了方便。
那怎麼讓postgresql 記錄更多的日誌以便pgbadger 能進行更多的分析展示就是一個問題。
所以還得先說一下，日誌的配置
在基於 stderr 的日誌並打開了 logging_collector
然後需要對日誌的記錄進行微調
log_checkpoints = on
log_connections = on
log_disconnections = on
log_lock_waits = on
log_temp_files = 1
log_autovacuum_min_duration = 1
log_error_verbosity = default
Log_min_duration_statement = 1
log_line_prefix = '%t [%p]: [%l-1] user=%u,db=%d,app=%a,client=%h‘
在打開這些開關後，需要重啟動數據庫
然後直接執行命令生成數據
生成的過程和你的日誌的大小有關，所以這裡就又得說另外一件事，定期要進行日誌的rotate , 保證日誌不要太BIG ，導致分析的過程太慢，生成的INDEX.html 文件太大。
上面說過pgbadger 可以最大限度的彌補上一期的監控的分析的缺陷，
其中可以從中獲得， 關於connections 的信息
建立連接的中的最大，最小以及平均連接的時間， 每個數據庫連接以餅圖的方式來進行展示，以每個用戶的方式來進行連接展示。同時也可以對session進行同樣的分析。這樣如果是寫週報，就會彌補上一期的monitor software 的一些不足。
另外對checkpoint 的監控也是通過日誌中的記錄來進行事後分析，其中可以對checkpoint buffers checkpoint files checkpoint warings checkpoint distance 等進行數據的分析和展示
另外對真空/分析分佈:顯示真空和分析隨時間變化的線圖，以及消耗CPU處理能力最多的表上的信息給與顯示，尤其對目前的PG 來說是重要的，知道目前的vacuum 做的如何。
例如分析每張表，以及tuple 的刪除以及每張表的vacuum 和超時的情況。
最後就是鎖，與查詢的信息了，通過鎖與查詢的分析，可以找到目前日誌文件中這一段時間中最耗時的查詢
最後TOP頁，可以給出
查詢時間直方圖，最慢的單個查詢，耗時查詢:規範化查詢及其總持續時間的列表，最頻繁查詢:一列規範化查詢和執行次數，歸一化最慢查詢:歸一化查詢及其平均持續時間的列表，等信息。
events 頁面也對目前的分析的LOG 本身的信息歸屬做了一個分析。
PGBADGER 和 上一期的 PGCULL 可能目前的一個問題就是都是英文版本，這一點可能算是一個缺點，除此以外，這兩個軟件一期基本上可以解決80%以上的性能和突發事件的分析問題。
PGBADGER 的安裝會更方便，解壓及使用，所以這也是這期根本沒說怎麼安裝的問題。
有問題可以一期解決，歡迎加入
閱讀更多 Austin的數據庫 的文章
