1. 日志分析不是沒有工具而是缺一份能直接拍板的報(bào)告先說(shuō)我遇到的實(shí)際場(chǎng)景。一套跑著 PostgreSQL 的業(yè)務(wù)系統(tǒng)某天下午接口延遲曲線突然抬頭后臺(tái)能看到的只有 postgresql.log 里幾萬(wàn)行“duration: xxx ms statement: ...”。用 grep 把 duration 超過(guò) 1 秒的行撈出來(lái)能得到一批候選慢查詢但也就到此為止了哪些語(yǔ)句出現(xiàn)頻率最高、哪些用戶和數(shù)據(jù)庫(kù)貢獻(xiàn)了最多的慢語(yǔ)句、慢查詢集中在哪個(gè)時(shí)間段、有沒有臨時(shí)文件落盤、有沒有鎖等待單靠 grep 很難拼出完整畫面。后來(lái)我把 pgbadger 引入排查流程情況就變了。它是個(gè)純 Perl 寫成的 PostgreSQL 日志分析工具不連接數(shù)據(jù)庫(kù)、不改線上參數(shù)、只吃日志文件輸出一份結(jié)構(gòu)完整的 HTML 報(bào)告。跑完一條命令慢查詢 TopN、按庫(kù)按用戶的分布、臨時(shí)文件、鎖事件、checkpoint、autovacuum 全部整理成圖表直接就能看出系統(tǒng)瓶頸在哪。對(duì)專職 DBA 來(lái)說(shuō)它可以當(dāng)日常巡檢的報(bào)表生成器對(duì)后端工程師來(lái)說(shuō)它是排查“為什么接口慢了”的第一手證據(jù)。1.1 原始排查手段的局限我最早排查慢查詢靠的是 grep 加 sort。比如把日志里所有 “duration:” 開頭的行撈出來(lái)按耗時(shí)排序看最頂上那幾條。這個(gè)方法不是沒用但問(wèn)題也很明顯grep 只能回答“哪條語(yǔ)句慢”回答不了“整個(gè)系統(tǒng)慢在哪里”。一次故障背后往往是一類語(yǔ)句的高頻出現(xiàn)單次耗時(shí)不算特別夸張但總耗時(shí)在服務(wù)端堆了一大截。這種數(shù)量級(jí)的特征靠人眼掃日志是發(fā)現(xiàn)不了的。我也寫過(guò)臨時(shí) awk 腳本按數(shù)據(jù)庫(kù)、用戶、小時(shí)維度統(tǒng)計(jì)慢查詢次數(shù)和平均耗時(shí)。腳本本身不難難在每次需求一變就要改一遍今天要統(tǒng)計(jì)鎖等待明天要統(tǒng)計(jì)臨時(shí)文件后天要按客戶端 IP 拆分改來(lái)改去最后變成一份只有自己能看懂的 sh 文件維護(hù)成本比收益還高。更麻煩的是這類臨時(shí)腳本沒有統(tǒng)一的輸出格式報(bào)告放在一起無(wú)法縱向?qū)Ρ茸匀灰矝]法形成長(zhǎng)期的性能趨勢(shì)記錄。1.2 pgbadger 的定位pgbadger 解決的就是這個(gè)“從日志到結(jié)論”的最后一公里。它把 PostgreSQL 日志當(dāng)作輸入自動(dòng)識(shí)別語(yǔ)句開始和結(jié)束的位置關(guān)聯(lián)上時(shí)間、數(shù)據(jù)庫(kù)、用戶、客戶端等上下文再聚合出各種維度的統(tǒng)計(jì)報(bào)告。你不需要在日志里反復(fù)跳來(lái)跳去也不需要維護(hù)一堆臨時(shí)腳本。這個(gè)工具的核心優(yōu)勢(shì)有幾個(gè)一是純?nèi)罩痉治鲞\(yùn)行時(shí)不和數(shù)據(jù)庫(kù)建立連接對(duì)生產(chǎn)實(shí)例零侵入二是輸出格式標(biāo)準(zhǔn)HTML 給人看json 給程序用text 給終端快速預(yù)覽三是它對(duì)日志格式的兼容面比較廣常見的 stderr、syslog、csvlog、jsonlog 都能處理。下面這套用法是我在實(shí)際運(yùn)維里反復(fù)試出來(lái)的包含安裝配置、命令參數(shù)、報(bào)告閱讀和避坑經(jīng)驗(yàn)照著做基本能覆蓋日常需求。2. 安裝選型與 PostgreSQL 日志配置報(bào)告質(zhì)量的源頭在數(shù)據(jù)庫(kù)側(cè)2.1 兩種安裝方式怎么選pgbadger 的安裝沒有太多門檻。最省事的是走系統(tǒng)自帶的包管理器裝一個(gè)叫 pgbadger 的軟件包裝完直接pgbadger --version就能看到版本號(hào)。這種方式勝在依賴被自動(dòng)處理好升級(jí)也方便缺點(diǎn)是倉(cāng)庫(kù)里的版本可能滯后一些遇到新版 PostgreSQL 的日志格式變化時(shí)會(huì)比較被動(dòng)。另一種方式是從官方發(fā)布渠道拿最新源碼。因?yàn)樗举|(zhì)是一個(gè) Perl 腳本不需要編譯解壓之后就可以直接運(yùn)行依賴的 Perl 模塊通常系統(tǒng)里都已經(jīng)具備。我一般把腳本放到 /usr/local/bin 下配一個(gè)軟鏈接使用。兩種方式本質(zhì)上不影響功能關(guān)鍵是版本別太舊。我的原則很簡(jiǎn)單需要解析的 PostgreSQL 版本如果比較新就盡量用最新版 pgbadger舊版本對(duì)新增日志字段的兼容性往往要等下一個(gè) release 才修復(fù)。2.2 日志參數(shù)設(shè)置決定分析粒度很多人第一次跑 pgbadger出來(lái)的報(bào)告數(shù)據(jù)稀稀落落問(wèn)題多半不在工具而在 PostgreSQL 本身的日志配置。日志里根本沒有的信息工具再聰明也分析不出來(lái)。所以先要把幾個(gè)核心參數(shù)擺正。log_min_duration_statement 是慢查詢分析的地基它控制哪些 SQL 會(huì)被記進(jìn)日志。設(shè)成 0 表示記錄所有語(yǔ)句日志量會(huì)大到很快撐滿磁盤設(shè)得太大比如 5 秒一批耗時(shí) 2 秒但頻繁觸發(fā)的查詢就徹底消失了。我的建議是從 1000毫秒起步先觀察一天日志體積如果一天只有幾十 MB再往下調(diào)到 500 或 250。反之如果日志已經(jīng)大到影響排查就把閾值調(diào)回去。log_line_prefix 直接決定 pgbadger 能不能把日志拆出“時(shí)間、進(jìn)程號(hào)、用戶、數(shù)據(jù)庫(kù)、客戶端 IP”這些維度。很多默認(rèn)配置只有時(shí)間戳和進(jìn)程號(hào)這樣報(bào)告里的用戶維度和數(shù)據(jù)庫(kù)維度會(huì)全部缺失。推薦改成下面這種格式既能看日志時(shí)一眼認(rèn)出語(yǔ)句來(lái)源也正好是 pgbadger 最容易解析的格式log_line_prefix %t [%p]: user%u,db%d,app%a,client%h 此外還有幾個(gè)默認(rèn)關(guān)閉但建議打開的開關(guān)log_checkpoints 記錄檢查點(diǎn)信息log_connections 和 log_disconnections 記錄連接建立與斷開log_lock_waits 記錄鎖等待超過(guò) deadlock_timeout 的事件log_temp_files 記錄臨時(shí)文件創(chuàng)建log_autovacuum_min_duration 記錄 autovacuum 執(zhí)行情況。這些參數(shù)并不直接影響業(yè)務(wù)卻能讓報(bào)告里的故障線索完整不少。2.3 一份可以直接抄的配置片段把上面這些組合起來(lái)我在 PostgreSQL 側(cè)的配置大概是這樣的logging_collector on log_destination stderr log_directory log log_filename postgresql-%Y%m%d.log log_min_duration_statement 1000 log_line_prefix %t [%p]: user%u,db%d,app%a,client%h log_checkpoints on log_connections on log_disconnections on log_lock_waits on log_temp_files 0 log_autovacuum_min_duration 0log_destination 用默認(rèn)的 stderr 即可pgbadger 對(duì)這種格式支持最成熟。按天切分的 log_filename 方便后續(xù)按日期做增量分析和歸檔。修改完成之后不需要重啟實(shí)例執(zhí)行一次SELECT pg_reload_conf();或者pg_ctl reload就能生效。這里提醒一下如果是在已有業(yè)務(wù)系統(tǒng)上臨時(shí)加這些參數(shù)先確認(rèn)磁盤空間是否足夠。我給過(guò)的經(jīng)驗(yàn)值是慢查詢閾值 1 秒時(shí)單實(shí)例一天日志大約占幾百 MB 到 2 GB具體取決于業(yè)務(wù)負(fù)載提前做好預(yù)估能避免把生產(chǎn)磁盤寫滿。3. 命令實(shí)操?gòu)膯未紊傻皆隽孔詣?dòng)化3.1 最基礎(chǔ)的一條命令假設(shè)日志文件在 /var/lib/postgresql/15/main/log/ 下生成一份 HTML 報(bào)告只需要pgbadger -o report.html /var/lib/postgresql/15/main/log/postgresql-20240101.log運(yùn)行結(jié)束后會(huì)在當(dāng)前目錄得到 report.html瀏覽器打開就能看到整份分析。如果日志文件是 gzip 壓縮過(guò)的比如 postgresql-20240101.log.gzpgbadger 也能直接讀不用先手動(dòng)解壓。多個(gè)日志文件直接并列傳進(jìn)去pgbadger -o weekly.html /var/lib/postgresql/15/main/log/postgresql-20240101.log /var/lib/postgresql/15/main/log/postgresql-20240102.log還可以用通配符把某個(gè)時(shí)間段的文件一次性傳進(jìn)去也很方便。要注意的是通配符展開后文件順序是 shell 按文件名排序的只要文件名里帶日期且格式統(tǒng)一順序就不會(huì)亂。3.2 指定日志前綴參數(shù)如果使用了我上面推薦的 log_line_prefixpgbadger 通常能自動(dòng)識(shí)別。但不是所有環(huán)境都由你控制有時(shí)接手別人維護(hù)的實(shí)例日志前綴是自定義的自動(dòng)識(shí)別就會(huì)失手報(bào)告里出現(xiàn)大量“無(wú)法解析的行”。這時(shí)需要把真實(shí)的前綴格式用 --prefix 告訴它pgbadger --prefix %t [%p]: user%u,db%d,app%a,client%h -o report.html postgresql.log注意 --prefix 里的占位符要和 postgresql.conf 中 log_line_prefix 完全一致。比如你配置里用的是 %m帶毫秒的時(shí)間戳--prefix 里也要用 %m用成 %t 就會(huì)導(dǎo)致時(shí)間解析錯(cuò)位。我接手新環(huán)境的第一件事就是先看配置文件確認(rèn)這個(gè)參數(shù)再?zèng)Q定要不要把 --prefix 寫死在腳本里。3.3 只分析故障時(shí)間窗生產(chǎn)系統(tǒng)排查問(wèn)題時(shí)全量日志里大部分信息都是噪音。pgbadger 支持按時(shí)間范圍過(guò)濾我只分析故障發(fā)生的那個(gè)小時(shí)pgbadger -b 2024-03-12 10:00:00 -e 2024-03-12 10:30:00 -o crash.html postgresql-2024031*.log-b 是開始時(shí)間-e 是結(jié)束時(shí)間日志里在這個(gè)范圍之外的行會(huì)被忽略。這個(gè)參數(shù)在排障場(chǎng)景里特別有用一是報(bào)告聚焦Top 慢查詢不再被其它時(shí)段的不相關(guān)語(yǔ)句干擾二是解析量小出結(jié)果快。建議時(shí)間字符串里帶上前導(dǎo) 0避免排序和匹配上的歧義。3.4 增量分析每天只解析新增日志日志按天滾動(dòng)后第二天再跑全量會(huì)越來(lái)越慢這時(shí)用增量模式。pgbadger 用 --last-parsed 參數(shù)指定一個(gè)狀態(tài)文件每次運(yùn)行會(huì)把已經(jīng)解析到的日志時(shí)間位置記錄下來(lái)下一次運(yùn)行從上次打斷的地方繼續(xù)pgbadger --last-parsed /var/lib/pgbadger/state.txt -o report_20240312.html postgresql-202403*.log第一次運(yùn)行時(shí)它會(huì)先把當(dāng)天已有日志都解析完并把最新時(shí)間寫入 state.txt之后每次運(yùn)行只處理新增部分。需要說(shuō)明的是--last-parsed 的工作方式依賴日志輪轉(zhuǎn)規(guī)律如果某天文件名順序亂了比如補(bǔ)跑了一天的舊日志增量結(jié)果可能會(huì)缺一段。所以文件夾里文件名規(guī)律要保持好補(bǔ)跑舊日志時(shí)最好單獨(dú)指定文件名不要混進(jìn)常規(guī)任務(wù)。3.5 并行解析與報(bào)告格式日志文件很大的時(shí)候單進(jìn)程解析會(huì)比較慢。pgbadger 支持用 -j 參數(shù)開啟并行pgbadger -j 4 -o report_weekly.html /var/lib/postgresql/15/main/log/postgresql-202403*.log這個(gè)數(shù)字一般和 CPU 核數(shù)對(duì)齊我常用 4 到 8。另外輸出格式除了默認(rèn)的 HTML還有 text、json、csv 可選pgbadger -f text /var/lib/postgresql/15/main/log/postgresql-20240301.logtext 格式適合在終端快速掃一眼整體情況json 格式則方便接入自建的監(jiān)控面板做二次展示。如果日志來(lái)自 csvlog 或 jsonlog 格式可以在命令里用 --log-format 明確指定 stderr、csvlog、jsonlog 之一避免自動(dòng)識(shí)別在特殊字符下抽風(fēng)。3.6 按庫(kù)或按用戶過(guò)濾共享實(shí)例上會(huì)有多個(gè)庫(kù)、多個(gè)應(yīng)用賬號(hào)混在一起看容易掩蓋問(wèn)題。pgbadger 提供了按數(shù)據(jù)庫(kù)和用戶過(guò)濾的參數(shù)可以單獨(dú)為某個(gè)庫(kù)出報(bào)告。比如某個(gè)業(yè)務(wù)庫(kù)最近抖得厲害其他庫(kù)正常我就只對(duì)它生成報(bào)告避免把無(wú)關(guān)查詢混進(jìn) Top 榜。具體參數(shù)名可以用pgbadger --help查詢長(zhǎng)選項(xiàng)是 --dbname 和 --user 這一組。這類過(guò)濾不改變?nèi)罩疚募?nèi)容只是在分析階段做裁剪非常適合多租戶實(shí)例的運(yùn)維場(chǎng)景。4. 報(bào)告閱讀把圖表數(shù)據(jù)翻譯成優(yōu)化動(dòng)作4.1 報(bào)告結(jié)構(gòu)速覽第一次打開 HTML 報(bào)告可能會(huì)有點(diǎn)懵區(qū)塊很多但核心是幾塊。我用表格整理一下大體用途報(bào)告區(qū)塊主要用途Global Statistics整體查詢量、慢查詢數(shù)量和占比、平均耗時(shí)先看這里判斷有沒有系統(tǒng)性惡化Top Slowest / Most Frequent Queries單條最慢、單條最高頻兩個(gè)維度相互印證Queries by Time / per Database / per User查詢耗時(shí)隨時(shí)間的分布按庫(kù)按用戶拆分定位范圍Temporary Files臨時(shí)文件數(shù)量和大小判斷是否存在大量排序落盤Locks / Deadlocks鎖等待與死鎖事件排查并發(fā)沖突Checkpoints / Autovacuum檢查點(diǎn)與自動(dòng)清理活動(dòng)解釋 IO 集中尖峰不同版本的 pgbadger 區(qū)塊名會(huì)有差異但觀察順序是一樣的先看整體是否有異常再看慢查詢具體是誰(shuí)然后用臨時(shí)文件、鎖、checkpoint 等維度解釋“為什么慢”。4.2 一次調(diào)優(yōu)的完整鏈路用一個(gè)我實(shí)際處理過(guò)的場(chǎng)景來(lái)說(shuō)明報(bào)告怎么讀。某系統(tǒng)每天上午 10 點(diǎn)到 10 點(diǎn)半接口超時(shí)告警業(yè)務(wù)方懷疑數(shù)據(jù)庫(kù)被打滿。我用 30 分鐘窗口生成了報(bào)告命令就是 3.3 節(jié)里的寫法。報(bào)告給出的關(guān)鍵信息很明確Global Statistics 顯示該時(shí)段內(nèi)平均查詢耗時(shí)從日常的 20 毫秒漲到 800 毫秒Top 慢查詢第一名是一條關(guān)聯(lián)了 8 張表的匯總查詢單次平均 980 毫秒Temporary Files 區(qū)塊出現(xiàn)了單次超 400MB 的排序落盤記錄Lock 區(qū)塊顯示這條查詢與高頻寫事務(wù)存在鎖等待關(guān)聯(lián)。這三個(gè)線索拼到一起基本可以判定不是數(shù)據(jù)庫(kù)整體資源不足而是某條查詢?nèi)焙线m的索引導(dǎo)致查詢計(jì)劃選擇順序掃描并觸發(fā)大排序同時(shí)與寫事務(wù)爭(zhēng)用鎖。我針對(duì)該查詢關(guān)聯(lián)最多的一張表的過(guò)濾字段加了復(fù)合索引并把實(shí)例的 work_mem 從 4MB 提到 16MB。第二天再看監(jiān)控接口超時(shí)消失同一時(shí)段的查詢平均耗時(shí)降到 120 毫秒左右。用同一天的日志重新生成報(bào)告這條查詢已經(jīng)從 Top 10 里消失Temporary Files 區(qū)塊也沒有大文件了。這次排查從接到告警到確認(rèn)目標(biāo)半天都沒用到。如果沒有 pgbadger我需要先在日志里撈慢查詢?cè)俳y(tǒng)計(jì)臨時(shí)文件再翻鎖等待日志三個(gè)動(dòng)作要分頭做還不能保證時(shí)間戳對(duì)得上。4.3 從報(bào)告到優(yōu)化清單的固定套路我習(xí)慣把報(bào)告閱讀變成一個(gè)固定流程避免漏項(xiàng)。第一輪只看 Global Statistics確認(rèn)慢查詢總量是持平、上升還是下降這是系統(tǒng)整體健康的體溫計(jì)。第二輪進(jìn) Top 慢查詢關(guān)注每條語(yǔ)句的平均耗時(shí)和總耗時(shí)。總耗時(shí)高往往比單次峰值更值得處理因?yàn)楦纳扑苤苯咏档拖到y(tǒng)整體壓力。第三輪看 Temporary Files 和 Locks這兩個(gè)指標(biāo)能解釋慢查詢背后的資源原因也決定優(yōu)化方向是加索引、調(diào) work_mem 還是處理事務(wù)沖突。最后一輪看 Checkpoints 和 Autovacuum確認(rèn)有沒有維護(hù)任務(wù)和業(yè)務(wù)高峰重疊。優(yōu)化動(dòng)作做完之后別忘了把優(yōu)化前后的報(bào)告放一起對(duì)比。我每周都會(huì)把當(dāng)天報(bào)告歸檔到一個(gè)固定目錄文件名帶日期復(fù)盤時(shí)就拿上一周同一天的報(bào)告做對(duì)照量化結(jié)果既直觀又能沉淀成團(tuán)隊(duì)的優(yōu)化記錄。5. 實(shí)操中的踩坑點(diǎn)前綴失配、時(shí)區(qū)錯(cuò)位、大文件與版本適配5.1 日志前綴不匹配報(bào)告里全是“未解析行”我第一次把 pgbadger 用到生產(chǎn)環(huán)境時(shí)就在這里栽過(guò)。之前的同事自定義過(guò) log_line_prefix但配置文件和實(shí)際日志時(shí)間戳對(duì)不上生成的報(bào)告大量行被跳過(guò)Global Statistics 顯示的總查詢數(shù)明顯少于真實(shí)值。后來(lái)我逐個(gè)比對(duì)后發(fā)現(xiàn)日志里前綴用的是 %m帶毫秒而我傳的 --prefix 里寫的是 %t毫秒部分導(dǎo)致整體匹配失敗。處理辦法很簡(jiǎn)單傳遞和配置完全一致的 --prefix并且在腳本里寫死之前先取一條真實(shí)日志行手工驗(yàn)證。也可以準(zhǔn)備一個(gè)只有幾行日志的測(cè)試文件先跑一次看輸出里還有沒有警告確認(rèn)無(wú)誤再對(duì)全量文件運(yùn)行。這一步檢查成本很低但能省掉很多無(wú)效等待。5.2 時(shí)區(qū)不一致導(dǎo)致時(shí)間窗口偏差PostgreSQL 日志時(shí)間默認(rèn)是實(shí)例所在機(jī)器的本地時(shí)間而 pgbadger 的 -b/-e 參數(shù)如果不帶時(shí)區(qū)會(huì)按運(yùn)行命令的那臺(tái)機(jī)器來(lái)理解。如果兩者時(shí)區(qū)不同比如分析機(jī)是 UTC數(shù)據(jù)庫(kù)機(jī)是東八區(qū)過(guò)濾出來(lái)的時(shí)間窗口就會(huì)整體偏移 8 個(gè)小時(shí)。我現(xiàn)在的做法是要么保證分析機(jī)和數(shù)據(jù)庫(kù)機(jī)時(shí)區(qū)一致要么在 -b/-e 里顯式寫帶時(shí)區(qū)的字符串例如 2024-03-12 10:00:0008。只要日志時(shí)間、過(guò)濾條件、報(bào)告閱讀三方面都能對(duì)上時(shí)間維度就不會(huì)出錯(cuò)。這個(gè)問(wèn)題在跨地域、跨機(jī)房維護(hù)場(chǎng)景里尤其容易碰到別想當(dāng)然。5.3 超大日志下的性能問(wèn)題日志文件單日好幾個(gè) GB 的情況并不少見。pgbadger 雖然高效但默認(rèn)單進(jìn)程解析大文件也要等一陣。遇到這種情況我優(yōu)先做三件事第一用 -j 并行參數(shù)把解析任務(wù)分給多核第二能縮小時(shí)間范圍就先縮小別讓無(wú)關(guān)日志拖慢分析第三拆文件。按天的文件名規(guī)則就是為了方便按需挑選如果某天文件特別大可以先按小時(shí)用 sed 切出片段單獨(dú)生成一個(gè)臨時(shí)日志文件再喂給 pgbadger。另外解析前粗看一眼日志里有沒有被應(yīng)用程序打印出來(lái)的超長(zhǎng) SQL極端長(zhǎng)的行會(huì)顯著拉高解析開銷必要時(shí)先在應(yīng)用側(cè)控制日志輸出長(zhǎng)度。5.4 慢查詢閾值的高低之爭(zhēng)log_min_duration_statement 設(shè)置不合理會(huì)導(dǎo)致報(bào)告看起來(lái)“正?！钡珜?shí)際系統(tǒng)已經(jīng)很難受。閾值太高時(shí)一些高頻次、平均 900 毫秒的查詢不會(huì)被記錄報(bào)告頂部全是幾條巨慢語(yǔ)句反而掩蓋了拖垮系統(tǒng)的主要負(fù)載閾值太低時(shí)日志文件膨脹速度驚人一晚上撐滿磁盤的教訓(xùn)我也見過(guò)。我的建議是分階段調(diào)試先按 1000ms 采集一周看日志增長(zhǎng)速度如果報(bào)告里 Top 慢查詢以秒級(jí)語(yǔ)句為主同時(shí)業(yè)務(wù)對(duì)響應(yīng)時(shí)間敏感就把閾值降到 500ms 甚至 250ms再觀察一周。整個(gè)過(guò)程要配合磁盤監(jiān)控不要讓日志先成為新的故障源。5.5 PostgreSQL 版本升級(jí)后的格式適配PostgreSQL 升級(jí)后日志格式可能微調(diào)舊版 pgbadger 會(huì)出現(xiàn)解析率驟降的情況尤其是啟用了新日志格式之后。我處理升級(jí)時(shí)的固定動(dòng)作是先在測(cè)試環(huán)境用新版本導(dǎo)出一份覆蓋各類日志事件的樣本用最新版 pgbadger 試跑確認(rèn)報(bào)告里各項(xiàng)統(tǒng)計(jì)正常再讓生產(chǎn)環(huán)境的日常巡檢切到新版本工具。寧可多花十分鐘驗(yàn)證也不要在故障當(dāng)天發(fā)現(xiàn)工具讀不懂日志。5.6 字符集與特殊字符的小提醒日志內(nèi)容里如果混入了非 UTF-8 編碼的 SQLHTML 報(bào)告展示時(shí)可能出現(xiàn)亂碼嚴(yán)重時(shí)還會(huì)讓個(gè)別解析結(jié)果錯(cuò)位。這個(gè)問(wèn)題不算高頻但碰到一次就很頭疼。我現(xiàn)在的約定是應(yīng)用側(cè)連接參數(shù)統(tǒng)一用 UTF-8從源頭避免如果已經(jīng)產(chǎn)生了歷史日志可以先用 iconv 做編碼轉(zhuǎn)換再交給 pgbadger雖然多一步但能保住報(bào)告的可讀性。這些坑單個(gè)看都不復(fù)雜但每一項(xiàng)都可能讓一份報(bào)告失去參考價(jià)值。我現(xiàn)在每次接入新環(huán)境都會(huì)走一遍同樣的檢查確認(rèn)日志前綴、確認(rèn)時(shí)區(qū)、確認(rèn)版本、跑一次小樣本驗(yàn)證。這套流程用熟了之后pgbadger 基本不會(huì)辜負(fù)期望。