1. 問題現(xiàn)象與根源初探最近在幫一個朋友排查他們監(jiān)控系統(tǒng)的怪事他們的Zabbix儀表盤上所有圖表里的中文標簽和標題都變成了一個個“口口”方塊字。這問題說大不大圖表數(shù)據(jù)本身是準的但說小也不小運維和領導看報表的時候滿屏的“口口”實在影響觀感和專業(yè)性。這種亂碼問題在部署了Zabbix的環(huán)境里其實挺常見的尤其是自己手動編譯安裝或者環(huán)境配置比較“個性化”的時候。問題的核心十有八九出在PHP和Web服務器比如Nginx的字符集配置沒對上。為什么是PHP和NginxZabbix的Web前端是用PHP寫的它負責從數(shù)據(jù)庫里取出監(jiān)控數(shù)據(jù)然后調(diào)用GD庫或者別的圖形庫生成PNG格式的圖片圖表。這個過程中PHP腳本需要告訴圖形庫“我要畫這幾個中文字”。如果PHP自身或者它調(diào)用的庫認為文本是UTF-8編碼但實際處理時用的卻是另一種編碼比如Latin-1或者根本找不到能顯示這些字符的字體那么生成圖片時無法識別的字符就會被替換成“口口”這樣的占位符。而Nginx作為Web服務器它負責把PHP生成的這張圖片或者包含圖片的HTML頁面正確地傳遞給用戶的瀏覽器。如果Nginx在傳輸過程中錯誤地修改了響應頭也可能導致亂碼不過對于圖片內(nèi)嵌的文字亂碼Nginx的嫌疑通常比PHP小一些。所以我們的排查思路就很清晰了這是一個典型的字符編碼一致性問題和字體缺失問題。我們需要確保從數(shù)據(jù)庫存儲、PHP處理、圖形庫渲染到最終輸出整個鏈條都使用統(tǒng)一的UTF-8編碼并且系統(tǒng)中有可用的中文字體。接下來我們就從最可能出問題的PHP配置文件開始一步步挖下去。2. 核心元兇PHP配置文件深度解析當Zabbix圖表出現(xiàn)中文“口口”時第一個要懷疑的就是PHP的運行時配置。PHP通過php.ini文件控制其核心行為其中幾個關鍵參數(shù)直接決定了它如何處理多字節(jié)字符串比如中文。2.1 關鍵參數(shù)排查與修正首先找到你的PHP正在使用的php.ini文件。可以通過在Zabbix服務器的Web目錄下創(chuàng)建一個info.php文件內(nèi)容為然后在瀏覽器中訪問它。在打開的PHP信息頁面里搜索“Loaded Configuration File”這一項就能找到確切的路徑。找到文件后重點檢查并修改以下參數(shù)default_charset這是最重要的一個參數(shù)。它定義了PHP默認使用的字符集。如果這里不是UTF-8那么PHP在處理字符串時包括從數(shù)據(jù)庫讀取、生成HTTP頭等就可能使用錯誤的編碼。錯誤示例default_charset “ISO-8859-1”正確修正default_charset “UTF-8”internal_encoding和input_encoding/output_encoding這些是mbstring擴展的配置項。mbstring擴展專門用于安全地處理多字節(jié)字符如中文、日文。確保它們也設置為UTF-8。查找并設置[mbstring] mbstring.internal_encoding UTF-8 mbstring.http_input UTF-8 mbstring.http_output UTF-8 mbstring.encoding_translation On如果配置文件中沒有這些行可以手動添加在[mbstring]部分。encoding_translation開啟后mbstring會嘗試自動轉(zhuǎn)換字符編碼到internal_encoding。date.timezone雖然不直接導致亂碼但Zabbix很多日志和時間顯示依賴于此。未設置會導致PHP警告有時可能間接影響頁面渲染。務必設置為你的服務器所在時區(qū)例如Asia/Shanghai。注意修改php.ini后必須重啟PHP-FPM進程如果你用的是PHP-FPM或者重啟Apache/Nginx如果PHP以模塊形式運行才能使更改生效。對于PHP-FPM通常命令是sudo systemctl restart php-fpm或sudo service php-fpm restart。2.2 PHP-GD擴展與字體支持Zabbix生成圖表依賴于PHP的GD庫或ImageMagick等圖形擴展。GD庫在繪制文字時需要指定一個字體文件.ttf或.otf。如果指定的字體不存在或者字體文件本身不支持中文那么繪制中文時自然就成了“口口”。確認GD庫已安裝并支持FreeType在phpinfo()頁面里搜索“GD”查看是否啟用并確認“FreeType Support”為“enabled”。FreeType是渲染TrueType字體的關鍵。檢查Zabbix前端配置中的字體路徑登錄Zabbix前端進入“管理” - “一般” - “圖形”。查看“字體名稱”和“字體文件路徑”這兩個選項。字體名稱通常是一個字體家族名如“DejaVu Sans”。字體文件路徑這是絕對路徑指向一個具體的.ttf字體文件。Zabbix默認可能使用像/usr/share/zabbix/assets/fonts/這樣的路徑下的字體。解決字體問題路徑驗證用SSH登錄服務器檢查上述“字體文件路徑”是否存在并且Zabbix的Web服務器用戶通常是www-data或nginx有讀取權限。ls -l /path/to/font.ttf。安裝中文字體如果默認字體不支持中文你需要安裝一個。將一個支持中文的TrueType字體例如文泉驛微米黑wqy-microhei.ttf、思源黑體等上傳到服務器字體目錄如/usr/share/fonts/truetype/或Zabbix的字體目錄然后運行fc-cache -fv刷新字體緩存。修改Zabbix配置在Zabbix前端的圖形設置里將“字體文件路徑”修改為你新上傳的中文字體文件的絕對路徑。例如/usr/share/fonts/truetype/wqy/wqy-microhei.ttf。實操心得我遇到過好幾次GD庫用的字體路徑是一個相對路徑或者軟鏈接在命令行下測試正常但在Web環(huán)境下因為權限或路徑解析問題導致找不到字體。最穩(wěn)妥的辦法就是在php.ini里直接指定一個絕對路徑的字體或者確保Zabbix配置的路徑是Web進程用戶絕對可讀的。3. Nginx環(huán)境下的協(xié)同排查指南在Nginx PHP-FPM這套經(jīng)典組合里Nginx本身不負責解釋PHP但它作為“交通警察”其配置會影響請求和響應的傳遞。雖然圖表“口口”問題主因在PHP但錯誤的Nginx配置可能讓之前的所有修正功虧一簣。3.1 Nginx字符集配置檢查Nginx的charset指令用于在HTTP響應頭中添加Content-Type字段的字符集信息。如果它錯誤地設置了字符集可能會覆蓋或與PHP產(chǎn)生的字符集沖突。打開你的Zabbix站點Nginx配置文件通常位于/etc/nginx/sites-available/或/etc/nginx/conf.d/下檢查server塊server { listen 80; server_name zabbix.yourdomain.com; root /usr/share/zabbix; index index.php; charset utf-8; # 確保這一行是 utf-8 而不是其他如 gbk, gb2312 location / { try_files $uri $uri/ /index.php?$args; } location ~ \.php$ { include fastcgi_params; fastcgi_pass unix:/run/php/php-fpm.sock; # 根據(jù)你的實際socket或端口修改 fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } }關鍵就是charset utf-8;這一行。它告訴瀏覽器服務器返回的內(nèi)容默認是UTF-8編碼。請確保它不是off或者別的編碼。3.2 PHP-FPM傳遞參數(shù)與靜態(tài)文件處理fastcgi_params文件Nginx通過include fastcgi_params;引入了一組傳遞給PHP-FPM的默認參數(shù)。你需要檢查這個文件通常是/etc/nginx/fastcgi_params確保其中沒有包含可能覆蓋PHP字符集的參數(shù)。比較安全的方式是在location ~ \.php$塊中在include fastcgi_params;之后顯式地設置字符集參數(shù)fastcgi_param PHP_VALUE “default_charsetUTF-8”; fastcgi_param PHP_ADMIN_VALUE “default_charsetUTF-8”;這相當于在運行時給PHP設置了default_charset。但要注意如果php.ini里已經(jīng)設置正確這里可能不是必須的有時甚至可能引發(fā)沖突。我個人的經(jīng)驗是優(yōu)先保證php.ini正確Nginx配置保持干凈簡潔。靜態(tài)資源如圖表圖片的MIME類型Nginx負責直接發(fā)送Zabbix生成的圖表圖片.png。圖片本身是二進制數(shù)據(jù)沒有“字符集”概念。但Nginx需要為其設置正確的Content-Type頭image/png。通常Nginx的mime.types文件已經(jīng)包含了對.png的映射所以這部分一般不會出問題。但如果你有非常自定義的配置可以檢查一下。注意事項修改Nginx配置后一定要用sudo nginx -t命令測試配置文件語法是否正確然后再用sudo systemctl reload nginx重新加載配置。直接restart在配置錯誤時可能導致服務中斷而reload是熱加載更安全。4. 系統(tǒng)級與數(shù)據(jù)庫層編碼驗證解決了PHP和Nginx的配置我們還需要向上游和下游看看確保整個數(shù)據(jù)流都是UTF-8的。4.1 操作系統(tǒng)語言環(huán)境服務器的系統(tǒng)語言環(huán)境Locale會影響命令行下腳本的輸出和一些庫函數(shù)的行為。雖然對Web服務直接影響較小但為了環(huán)境統(tǒng)一建議檢查。 在終端執(zhí)行l(wèi)ocale命令。查看LANG、LC_CTYPE等變量是否包含UTF-8。如果不是可以通過編輯/etc/locale.confRHEL/CentOS或/etc/default/localeDebian/Ubuntu來設置然后重啟服務器或重新登錄。一個常見的設置是LANGen_US.UTF-8或LANGzh_CN.UTF-8。4.2 數(shù)據(jù)庫MySQL/MariaDB編碼檢查Zabbix的所有配置、主機名、監(jiān)控項名稱等都存在數(shù)據(jù)庫里。如果數(shù)據(jù)庫的編碼不是UTF-8那么即使PHP用UTF-8去讀讀出來的也是亂碼。連接數(shù)據(jù)庫mysql -u zabbix -p使用你的zabbix數(shù)據(jù)庫用戶。檢查數(shù)據(jù)庫和表的編碼-- 查看zabbix數(shù)據(jù)庫的創(chuàng)建語句 SHOW CREATE DATABASE zabbix; -- 你應該看到類似 DEFAULT CHARACTER SET utf8 COLLATE utf8_bin -- 查看關鍵表的編碼例如hosts表 SHOW CREATE TABLE zabbix.hosts;重點關注DEFAULT CHARSET部分它必須是utf8或utf8mb4推薦utf8mb4因為它支持更全的Unicode字符包括一些emoji。Zabbix官方安裝腳本通常會創(chuàng)建為utf8_bin校對集的數(shù)據(jù)庫。檢查數(shù)據(jù)庫連接編碼在PHP連接數(shù)據(jù)庫時Zabbix前端配置文件/usr/share/zabbix/conf/zabbix.conf.php中定義了連接也需要指定編碼。Zabbix的db.inc.php等文件通常會在連接后執(zhí)行SET NAMES ‘utf8’語句來確保連接層使用UTF-8。你可以通過打開數(shù)據(jù)庫的通用查詢?nèi)罩緛眚炞C這一點但通常Zabbix會處理好。重要提示如果發(fā)現(xiàn)數(shù)據(jù)庫或表不是UTF-8編碼千萬不要直接在生產(chǎn)環(huán)境使用ALTER命令修改修改大表的字符集是一個耗時極長、鎖表風險極高的操作。對于Zabbix這種歷史數(shù)據(jù)重要的系統(tǒng)正確的做法是備份全庫用mysqldump導出時指定--default-character-setutf8mb4然后創(chuàng)建一個新的UTF-8編碼的數(shù)據(jù)庫再導入。這需要安排維護窗口。5. 問題診斷流程與實戰(zhàn)排查命令當問題發(fā)生時一個系統(tǒng)化的排查流程能幫你快速定位。下面是我常用的步驟和命令你可以像對照檢查清單一樣執(zhí)行第一步現(xiàn)象確認與隔離訪問Zabbix前端確認是所有圖表的中文都變“口口”還是個別圖表如果是個別檢查是否是那臺主機的主機名或監(jiān)控項鍵值本身含有異常字符。嘗試創(chuàng)建一個新的“簡單圖形”標題和標簽都用中文看是否正常。這可以排除是歷史數(shù)據(jù)問題還是實時生成問題。第二步PHP信息收集在Zabbix的Web根目錄創(chuàng)建info.php訪問并搜索default_charset,mbstring,GD,FreeType。截圖或記錄下關鍵值。第三步命令行直接測試GD庫字體渲染這是最直接的驗證方法。在服務器上創(chuàng)建一個PHP測試腳本?php // test_gd_font.php header(‘Content-Type: image/png’); $im imagecreatetruecolor(400, 100); $white imagecolorallocate($im, 255, 255, 255); $black imagecolorallocate($im, 0, 0, 0); imagefilledrectangle($im, 0, 0, 399, 99, $white); // 使用Zabbix配置里相同的字體路徑 $font ‘/usr/share/fonts/truetype/wqy/wqy-microhei.ttc’; // 或者使用imagestring()使用內(nèi)置字體但內(nèi)置字體不支持中文 // imagestring($im, 5, 10, 10, ‘測試中文’, $black); if (function_exists(‘imagettftext’) file_exists($font)) { imagettftext($im, 20, 0, 10, 50, $black, $font, ‘Zabbix圖表測試中文’); echo ‘字體文件存在嘗試使用TTF渲染?！?. PHP_EOL; } else { imagestring($im, 5, 10, 10, ‘GD Test (No TTF)’, $black); echo ‘TTF函數(shù)不可用或字體文件不存在使用內(nèi)置字體?！?. PHP_EOL; } imagepng($im); imagedestroy($im); ?在命令行運行php test_gd_font.php test.png。然后用file test.png查看是否成功生成圖片如果可以用scp下載到本地或用display命令如果服務器有GUI查看圖片中文字是否正常。如果命令行生成圖片中文也是“口口”問題鎖定在字體路徑錯誤或字體文件損壞/不支持中文。如果命令行生成正常但網(wǎng)頁顯示不正常問題鎖定在Web環(huán)境配置php.ini、Nginx或Zabbix前端配置。第四步檢查Zabbix前端日志與PHP錯誤日志Zabbix前端日志在Zabbix前端的“報表” - “系統(tǒng)信息”中查看“服務器”標簽頁下的日志過濾“警告”和“錯誤”看是否有與圖形生成、字體相關的記錄。PHP-FPM/Apache錯誤日志查看/var/log/php-fpm/error.log或/var/log/apache2/error.log尋找與GD、freetype、字體相關的錯誤或警告。第五步網(wǎng)絡抓包驗證響應頭進階如果以上都正常可以借助瀏覽器開發(fā)者工具。打開“網(wǎng)絡”(Network)選項卡刷新Zabbix頁面找到圖表圖片的請求通常是chart.php或chart2.php開頭的請求。查看其響應頭(Response Headers)中的Content-Type。它應該是image/png不應該有charsetxxx字段因為圖片二進制流不需要字符集。如果出現(xiàn)了charset那說明Nginx或PHP的某個配置錯誤地為圖片響應添加了字符集頭這可能干擾瀏覽器雖然概率極小。6. 根治方案與配置加固建議經(jīng)過一番排查和修復問題應該能解決。但為了以后部署不再踩坑我總結了一套“加固”配置建議可以一勞永逸地避免大部分中文亂碼問題。6.1 標準化PHP環(huán)境配置創(chuàng)建一個/etc/php.d/99-zabbix-charset.ini文件路徑可能因系統(tǒng)而異這是CentOS/RHEL的風格Debian/Ubuntu可能放在/etc/php/7.x/fpm/conf.d/專門存放Zabbix相關的PHP優(yōu)化配置; 確保默認字符集為UTF-8 default_charset “UTF-8” ; 配置mbstring擴展處理多字節(jié)字符 [mbstring] mbstring.language Neutral mbstring.internal_encoding UTF-8 mbstring.http_input UTF-8 mbstring.http_output UTF-8 mbstring.encoding_translation On mbstring.detect_order auto mbstring.substitute_character none ; 確保GD庫使用正確的字體路徑可選如果系統(tǒng)字體穩(wěn)定可不設 ; 但如果你指定了字體這里可以設置系統(tǒng)默認字體路徑 ; gd.font_path /usr/share/fonts/truetype/這樣做的好處是配置與主php.ini分離易于管理并且在升級PHP時不容易被覆蓋。6.2 確保系統(tǒng)字體完備對于生產(chǎn)環(huán)境的Zabbix服務器建議安裝一套完整且版權無憂的中文字體包。文泉驛系列是一個好選擇# 對于CentOS/RHEL: sudo yum install wqy-microhei-fonts -y # 對于Debian/Ubuntu: sudo apt-get install fonts-wqy-microhei -y安裝后字體會通常放在/usr/share/fonts/目錄下。你可以使用fc-list :langzh命令來列出系統(tǒng)中所有可用的中文字體確認安裝成功。6.3 Zabbix前端配置固化在Zabbix前端圖形設置中正確設置字體路徑后這個配置會保存在Zabbix的數(shù)據(jù)庫里。但為了在遷移或備份恢復時不出錯你可以考慮一個小技巧使用系統(tǒng)字體目錄的軟鏈接。 假設你決定使用/usr/share/fonts/wqy-microhei/wqy-microhei.ttc這個字體而Zabbix默認查找的路徑是/usr/share/zabbix/assets/fonts/graphfont.ttf。你可以# 備份原字體如果有 sudo mv /usr/share/zabbix/assets/fonts/graphfont.ttf /usr/share/zabbix/assets/fonts/graphfont.ttf.bak # 創(chuàng)建軟鏈接 sudo ln -sf /usr/share/fonts/wqy-microhei/wqy-microhei.ttc /usr/share/zabbix/assets/fonts/graphfont.ttf這樣Zabbix前端配置里即使保持默認的“graphfont”字體名和相對路徑實際也會指向你的中文字體。這是一種侵入性更小、更隱蔽的修改方式。6.4 構建部署檢查清單將以下檢查項融入你的Zabbix部署或維護腳本中實現(xiàn)自動化驗證[ ] 數(shù)據(jù)庫zabbix庫的字符集為utf8mb4校對集為utf8mb4_bin。[ ] PHPdefault_charset設置為UTF-8。[ ] PHPmbstring擴展已安裝并正確配置。[ ] PHP-GD擴展已安裝且支持FreeType。[ ] 系統(tǒng)已安裝至少一種中文字體如fonts-wqy-microhei。[ ] Zabbix前端“圖形”設置中的字體路徑指向一個真實存在且可讀的中文字體文件。[ ] Nginx配置文件中的charset指令設置為utf-8。[ ] 重啟PHP-FPM和Nginx服務使配置生效。這套組合拳下來Zabbix圖表中文顯示問題基本可以根除。記住這類問題的本質(zhì)是“一致性”確保數(shù)據(jù)從產(chǎn)生、存儲、處理到展示的每一個環(huán)節(jié)都統(tǒng)一在UTF-8的旗幟下并給圖形渲染引擎提供它認識的中文字體問題自然迎刃而解。