1. 问题现象与根源初探最近在帮一个朋友排查他们监控系统的怪事他们的Zabbix仪表盘上所有图表里的中文标签和标题都变成了一个个“口口”方块字。这问题说大不大图表数据本身是准的但说小也不小运维和领导看报表的时候满屏的“口口”实在影响观感和专业性。这种乱码问题在部署了Zabbix的环境里其实挺常见的尤其是自己手动编译安装或者环境配置比较“个性化”的时候。问题的核心十有八九出在PHP和Web服务器比如Nginx的字符集配置没对上。为什么是PHP和NginxZabbix的Web前端是用PHP写的它负责从数据库里取出监控数据然后调用GD库或者别的图形库生成PNG格式的图片图表。这个过程中PHP脚本需要告诉图形库“我要画这几个中文字”。如果PHP自身或者它调用的库认为文本是UTF-8编码但实际处理时用的却是另一种编码比如Latin-1或者根本找不到能显示这些字符的字体那么生成图片时无法识别的字符就会被替换成“口口”这样的占位符。而Nginx作为Web服务器它负责把PHP生成的这张图片或者包含图片的HTML页面正确地传递给用户的浏览器。如果Nginx在传输过程中错误地修改了响应头也可能导致乱码不过对于图片内嵌的文字乱码Nginx的嫌疑通常比PHP小一些。所以我们的排查思路就很清晰了这是一个典型的字符编码一致性问题和字体缺失问题。我们需要确保从数据库存储、PHP处理、图形库渲染到最终输出整个链条都使用统一的UTF-8编码并且系统中有可用的中文字体。接下来我们就从最可能出问题的PHP配置文件开始一步步挖下去。2. 核心元凶PHP配置文件深度解析当Zabbix图表出现中文“口口”时第一个要怀疑的就是PHP的运行时配置。PHP通过php.ini文件控制其核心行为其中几个关键参数直接决定了它如何处理多字节字符串比如中文。2.1 关键参数排查与修正首先找到你的PHP正在使用的php.ini文件。可以通过在Zabbix服务器的Web目录下创建一个info.php文件内容为然后在浏览器中访问它。在打开的PHP信息页面里搜索“Loaded Configuration File”这一项就能找到确切的路径。找到文件后重点检查并修改以下参数default_charset这是最重要的一个参数。它定义了PHP默认使用的字符集。如果这里不是UTF-8那么PHP在处理字符串时包括从数据库读取、生成HTTP头等就可能使用错误的编码。错误示例default_charset “ISO-8859-1”正确修正default_charset “UTF-8”internal_encoding和input_encoding/output_encoding这些是mbstring扩展的配置项。mbstring扩展专门用于安全地处理多字节字符如中文、日文。确保它们也设置为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会尝试自动转换字符编码到internal_encoding。date.timezone虽然不直接导致乱码但Zabbix很多日志和时间显示依赖于此。未设置会导致PHP警告有时可能间接影响页面渲染。务必设置为你的服务器所在时区例如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环境下因为权限或路径解析问题导致找不到字体。最稳妥的办法就是在php.ini里直接指定一个绝对路径的字体或者确保Zabbix配置的路径是Web进程用户绝对可读的。3. Nginx环境下的协同排查指南在Nginx PHP-FPM这套经典组合里Nginx本身不负责解释PHP但它作为“交通警察”其配置会影响请求和响应的传递。虽然图表“口口”问题主因在PHP但错误的Nginx配置可能让之前的所有修正功亏一篑。3.1 Nginx字符集配置检查Nginx的charset指令用于在HTTP响应头中添加Content-Type字段的字符集信息。如果它错误地设置了字符集可能会覆盖或与PHP产生的字符集冲突。打开你的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; # 根据你的实际socket或端口修改 fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } }关键就是charset utf-8;这一行。它告诉浏览器服务器返回的内容默认是UTF-8编码。请确保它不是off或者别的编码。3.2 PHP-FPM传递参数与静态文件处理fastcgi_params文件Nginx通过include fastcgi_params;引入了一组传递给PHP-FPM的默认参数。你需要检查这个文件通常是/etc/nginx/fastcgi_params确保其中没有包含可能覆盖PHP字符集的参数。比较安全的方式是在location ~ \.php$块中在include fastcgi_params;之后显式地设置字符集参数fastcgi_param PHP_VALUE “default_charsetUTF-8”; fastcgi_param PHP_ADMIN_VALUE “default_charsetUTF-8”;这相当于在运行时给PHP设置了default_charset。但要注意如果php.ini里已经设置正确这里可能不是必须的有时甚至可能引发冲突。我个人的经验是优先保证php.ini正确Nginx配置保持干净简洁。静态资源如图表图片的MIME类型Nginx负责直接发送Zabbix生成的图表图片.png。图片本身是二进制数据没有“字符集”概念。但Nginx需要为其设置正确的Content-Type头image/png。通常Nginx的mime.types文件已经包含了对.png的映射所以这部分一般不会出问题。但如果你有非常自定义的配置可以检查一下。注意事项修改Nginx配置后一定要用sudo nginx -t命令测试配置文件语法是否正确然后再用sudo systemctl reload nginx重新加载配置。直接restart在配置错误时可能导致服务中断而reload是热加载更安全。4. 系统级与数据库层编码验证解决了PHP和Nginx的配置我们还需要向上游和下游看看确保整个数据流都是UTF-8的。4.1 操作系统语言环境服务器的系统语言环境Locale会影响命令行下脚本的输出和一些库函数的行为。虽然对Web服务直接影响较小但为了环境统一建议检查。 在终端执行locale命令。查看LANG、LC_CTYPE等变量是否包含UTF-8。如果不是可以通过编辑/etc/locale.confRHEL/CentOS或/etc/default/localeDebian/Ubuntu来设置然后重启服务器或重新登录。一个常见的设置是LANGen_US.UTF-8或LANGzh_CN.UTF-8。4.2 数据库MySQL/MariaDB编码检查Zabbix的所有配置、主机名、监控项名称等都存在数据库里。如果数据库的编码不是UTF-8那么即使PHP用UTF-8去读读出来的也是乱码。连接数据库mysql -u zabbix -p使用你的zabbix数据库用户。检查数据库和表的编码-- 查看zabbix数据库的创建语句 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官方安装脚本通常会创建为utf8_bin校对集的数据库。检查数据库连接编码在PHP连接数据库时Zabbix前端配置文件/usr/share/zabbix/conf/zabbix.conf.php中定义了连接也需要指定编码。Zabbix的db.inc.php等文件通常会在连接后执行SET NAMES ‘utf8’语句来确保连接层使用UTF-8。你可以通过打开数据库的通用查询日志来验证这一点但通常Zabbix会处理好。重要提示如果发现数据库或表不是UTF-8编码千万不要直接在生产环境使用ALTER命令修改修改大表的字符集是一个耗时极长、锁表风险极高的操作。对于Zabbix这种历史数据重要的系统正确的做法是备份全库用mysqldump导出时指定--default-character-setutf8mb4然后创建一个新的UTF-8编码的数据库再导入。这需要安排维护窗口。5. 问题诊断流程与实战排查命令当问题发生时一个系统化的排查流程能帮你快速定位。下面是我常用的步骤和命令你可以像对照检查清单一样执行第一步现象确认与隔离访问Zabbix前端确认是所有图表的中文都变“口口”还是个别图表如果是个别检查是否是那台主机的主机名或监控项键值本身含有异常字符。尝试创建一个新的“简单图形”标题和标签都用中文看是否正常。这可以排除是历史数据问题还是实时生成问题。第二步PHP信息收集在Zabbix的Web根目录创建info.php访问并搜索default_charset,mbstring,GD,FreeType。截图或记录下关键值。第三步命令行直接测试GD库字体渲染这是最直接的验证方法。在服务器上创建一个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()使用内置字体但内置字体不支持中文 // 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函数不可用或字体文件不存在使用内置字体。’ . PHP_EOL; } imagepng($im); imagedestroy($im); ?在命令行运行php test_gd_font.php test.png。然后用file test.png查看是否成功生成图片如果可以用scp下载到本地或用display命令如果服务器有GUI查看图片中文字是否正常。如果命令行生成图片中文也是“口口”问题锁定在字体路径错误或字体文件损坏/不支持中文。如果命令行生成正常但网页显示不正常问题锁定在Web环境配置php.ini、Nginx或Zabbix前端配置。第四步检查Zabbix前端日志与PHP错误日志Zabbix前端日志在Zabbix前端的“报表” - “系统信息”中查看“服务器”标签页下的日志过滤“警告”和“错误”看是否有与图形生成、字体相关的记录。PHP-FPM/Apache错误日志查看/var/log/php-fpm/error.log或/var/log/apache2/error.log寻找与GD、freetype、字体相关的错误或警告。第五步网络抓包验证响应头进阶如果以上都正常可以借助浏览器开发者工具。打开“网络”(Network)选项卡刷新Zabbix页面找到图表图片的请求通常是chart.php或chart2.php开头的请求。查看其响应头(Response Headers)中的Content-Type。它应该是image/png不应该有charsetxxx字段因为图片二进制流不需要字符集。如果出现了charset那说明Nginx或PHP的某个配置错误地为图片响应添加了字符集头这可能干扰浏览器虽然概率极小。6. 根治方案与配置加固建议经过一番排查和修复问题应该能解决。但为了以后部署不再踩坑我总结了一套“加固”配置建议可以一劳永逸地避免大部分中文乱码问题。6.1 标准化PHP环境配置创建一个/etc/php.d/99-zabbix-charset.ini文件路径可能因系统而异这是CentOS/RHEL的风格Debian/Ubuntu可能放在/etc/php/7.x/fpm/conf.d/专门存放Zabbix相关的PHP优化配置; 确保默认字符集为UTF-8 default_charset “UTF-8” ; 配置mbstring扩展处理多字节字符 [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库使用正确的字体路径可选如果系统字体稳定可不设 ; 但如果你指定了字体这里可以设置系统默认字体路径 ; gd.font_path /usr/share/fonts/truetype/这样做的好处是配置与主php.ini分离易于管理并且在升级PHP时不容易被覆盖。6.2 确保系统字体完备对于生产环境的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命令来列出系统中所有可用的中文字体确认安装成功。6.3 Zabbix前端配置固化在Zabbix前端图形设置中正确设置字体路径后这个配置会保存在Zabbix的数据库里。但为了在迁移或备份恢复时不出错你可以考虑一个小技巧使用系统字体目录的软链接。 假设你决定使用/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 # 创建软链接 sudo ln -sf /usr/share/fonts/wqy-microhei/wqy-microhei.ttc /usr/share/zabbix/assets/fonts/graphfont.ttf这样Zabbix前端配置里即使保持默认的“graphfont”字体名和相对路径实际也会指向你的中文字体。这是一种侵入性更小、更隐蔽的修改方式。6.4 构建部署检查清单将以下检查项融入你的Zabbix部署或维护脚本中实现自动化验证[ ] 数据库zabbix库的字符集为utf8mb4校对集为utf8mb4_bin。[ ] PHPdefault_charset设置为UTF-8。[ ] PHPmbstring扩展已安装并正确配置。[ ] PHP-GD扩展已安装且支持FreeType。[ ] 系统已安装至少一种中文字体如fonts-wqy-microhei。[ ] Zabbix前端“图形”设置中的字体路径指向一个真实存在且可读的中文字体文件。[ ] Nginx配置文件中的charset指令设置为utf-8。[ ] 重启PHP-FPM和Nginx服务使配置生效。这套组合拳下来Zabbix图表中文显示问题基本可以根除。记住这类问题的本质是“一致性”确保数据从产生、存储、处理到展示的每一个环节都统一在UTF-8的旗帜下并给图形渲染引擎提供它认识的中文字体问题自然迎刃而解。