为什么需要渲染服务
Grafana 导出看板为 PNG、以及在告警通知里附带图片，都依赖独立的 grafana-image-renderer 服务：Grafana 负责生成看板定义并把渲染请求转发出去，真正的无头浏览器绘制由渲染服务完成。OSS 版本默认不带渲染能力，需要单独部署并在 grafana.ini 里指向它。
基本信息
| 部署方式 | 独立容器或二进制，官方镜像 grafana/grafana-image-renderer |
|---|---|
| 配置位置 | grafana.ini 的 [rendering] 段设置 server_url 与 callback_url |
| 运行依赖 | 无头浏览器（Chromium）与已安装的中文字体 |
| 使用位置 | 看板分享、报告导出、告警通知附带图片 |
渲染服务与配置
渲染服务与配置
docker run -d --name=renderer grafana/grafana-image-renderer:latest
# grafana.ini
[rendering]
server_url = http://renderer:8081/render
callback_url = http://grafana:3000/
# 验证：Share → Direct link rendered image常见问题
| 现象 | 常见原因 | 处理 |
|---|---|---|
| 请求超时 | 渲染容器无法回调访问 Grafana | 检查 callback_url 与网络策略 |
| 中文乱码或方框 | 渲染容器内字体缺失 | 挂载中文字体并重启渲染服务 |
| 图片空白 | 看板查询超时或变量未解析 | 延长超时、固定变量取值 |
| 内存不足 | Chromium 并发渲染占用高 | 限制并发数或提升容器内存上限 |
典型使用场景
- 值班群与工单里直接贴图，省去收件人打开链接的步骤
- 定时导出看板快照，做容量与趋势归档
- 告警通知里附带当前曲线，帮助快速判断严重程度
- 对外汇报用固定图片，避免依赖看板链接的访问权限
渲染服务与 Grafana 是两套进程，升级任一侧都要确认版本兼容，并确认回调地址在新部署里仍然可达。
渲染是资源消耗大户：并发导出会吃掉大量内存与 CPU，生产环境要限制单次导出数量并给渲染容器单独设资源上限。
排查顺序
- 先看 Grafana 日志里的渲染错误信息，确认请求是否发到了渲染服务
- 再从渲染容器侧验证能否访问 Grafana 的回调地址与端口
- 字体类问题直接进容器检查已安装字体，缺哪个补哪个
- 单块看板导出正常但批量失败时，优先怀疑并发与超时设置