1. 报警只有一行字排障时到底缺了什么监控系统跑了大半年告警通道一直挺稳邮件、钉钉、企微都能收到消息。但真正出事的时候你会发现一个很尴尬的问题手机弹出一条CPU 使用率超过 90%点进去只有干巴巴的一行文字没有图没有趋势没有上下文。你得先打开电脑登录 Grafana找到对应的 Dashboard再手动把时间范围调到报警发生的那几分钟才能看清楚到底发生了什么。这一套动作下来五分钟没了而故障可能还在持续。这个痛点在做高可用监控系统的时候特别明显。报警的本质不是通知你出事了而是让你在最短时间内判断出什么事、多严重、要不要立刻介入。纯文本报警把判断成本全部转嫁给了人而人恰恰是故障链路里最慢的一环。所以这次我要做的事情很明确让 Grafana 的 Alert 在通过 webhook 推送报警时顺带把报警时刻的 Panel 图片渲染出来并且把图片地址imageUrl作为参数一起带出去最终在报警消息里直接能看到图。关键词就三个Grafana Alert、Ceph S3 兼容接口、imageUrl 参数。听起来像是三个不搭界的东西但它们凑在一起解决的是一个非常具体的问题——图片渲染出来之后存哪儿、怎么让接收方拿到一个可访问的地址。Grafana 自己渲染图片不难难的是渲染完的图片需要一个稳定的、报警接收方比如钉钉机器人、自建告警网关能访问到的存储位置而 Ceph 提供的 S3 兼容接口正好可以扮演这个角色。这篇文章适合谁看如果你正在维护一套 Grafana 监控体系已经配好了基础的 Alert 规则和 webhook 通知但想让报警信息更有图有真相那这篇就是写给你的。如果你还没接触过 Grafana 的图片渲染也没关系我会把前置条件、配置细节、踩坑过程都讲清楚。需要说明的是下面涉及的路径、桶名、地址等都是示例实际部署时按你自己的环境替换。在正式开始之前先把整体链路理一遍这样后面每一步你都知道自己在干什么Grafana Alert 触发进入 Contact Point 的 webhook 通知流程Grafana 的 Image Renderer 插件根据报警规则里配置的 Panel 渲染出 PNG 图片渲染出的图片通过 Grafana 的 external image storage 上传到 Ceph 的 S3 兼容桶上传成功后返回一个可访问的 URL这个 URL 会以imageUrl的形式注入到 webhook 的 payload 里接收端钉钉、企微、自建网关解析 payload把图片展示出来。整条链路里最容易出问题的不是 Grafana 本身而是渲染和存储这两个环节的衔接。下面我按实际搭建顺序一块一块拆。2. 图片渲染这一步坑比想象中多2.1 为什么图片渲染要单独装插件很多人第一次配的时候会懵Grafana 界面上明明能看到 Panel 的图为什么报警的时候渲染不出来原因是 Grafana 主程序本身不具备服务端截图能力。你在浏览器里看到的图是前端 JavaScript 用 Canvas 画出来的服务端没有浏览器环境自然截不了图。所以需要单独部署一个Grafana Image Renderer。它是一个基于无头浏览器的服务接收 Grafana 发来的渲染请求把 Panel 渲染成 PNG 再返回。部署方式有两种一种是装成 Grafana 的插件grafana-image-renderer跟 Grafana 同进程或独立进程跑另一种是单独部署一个 renderer 服务Grafana 通过rendering_server配置指向它。我个人的建议是单独部署 renderer 服务理由有三个。第一渲染是 CPU 和内存密集型操作跟 Grafana 主进程混在一起会互相影响尤其报警风暴的时候渲染请求一多Grafana 界面都可能卡。第二独立部署方便水平扩展渲染压力大就多加一个实例。第三升级和维护互不干扰renderer 挂了不影响 Grafana 本身的查询和展示。配置上Grafana 侧需要在配置文件里加上[rendering] server_url http://renderer-host:8081/render callback_url http://grafana-host:3000/这里server_url指向 renderer 的渲染接口callback_url是 renderer 渲染完后回调 Grafana 的地址。callback_url 这个参数特别容易被忽略如果配错了renderer 渲染完图片回传不到 Grafana你会看到报警里图片位置是空的但日志里又没什么明显报错排查起来很费劲。2.2 渲染超时和并发报警风暴下的隐形杀手renderer 默认的超时时间不算长平时单张图渲染一两秒没问题但报警风暴的时候几十条规则同时触发渲染请求排队很容易超时。超时之后 Grafana 拿不到图片报警就退化成纯文本了。我的做法是把 renderer 的超时调大同时限制并发。在 renderer 侧可以配置[rendering] concurrent_render_limit 4这个值不要设太大设成 CPU 核数左右比较合适。设太大反而会因为资源争抢导致每张图都变慢。另外 Grafana 侧也有个rendering_timeout默认好像是 30 秒报警场景下可以适当调大但别无限大不然一条卡住的渲染会拖垮整个通知队列。还有一个细节渲染的 Panel 数量要克制。有些同学喜欢在报警规则里挂一整个 Dashboard 的多个 Panel觉得信息全。实际上渲染多个 Panel 会显著增加渲染时间和内存占用而且报警消息里图太多反而没人看。我的经验是一条报警规则最多渲染 1 到 2 个关键 Panel把最核心的趋势图放上去就够了。2.3 渲染出来的图片长什么样取决于你怎么配 Panel这里有个很多人不知道的点报警渲染的图片用的是 Panel 在报警触发时刻的数据但时间范围和图例这些展示细节取决于 Panel 本身的配置和报警规则里的设置。如果你希望报警图能清楚看到异常发生前后的趋势Panel 的时间范围最好设成相对时间比如最近 1 小时而不是固定时间。这样报警触发时渲染出来的图天然就带着异常发生前后的对比。如果设成固定时间范围渲染出来的图可能只显示一个点看不出趋势。另外Panel 的图例Legend建议打开并且显示当前值。这样图片上能直接看到哪个实例、当前值多少比纯看曲线直观得多。这些配置在平时看 Dashboard 的时候可能无所谓但在报警场景下图片是要独立传递信息的每一个细节都影响接收方的判断速度。3. 把图片塞进 Ceph 的 S3 桶为什么不用本地磁盘3.1 本地存储的问题在哪Grafana 默认的图片存储方式是本地磁盘渲染出来的图片存在 Grafana 服务器的某个目录下然后通过 Grafana 自己的 HTTP 服务对外提供访问。小规模用没问题但在高可用监控系统里这个方案有几个硬伤。第一多实例不一致。高可用意味着 Grafana 至少有两个实例报警可能在 A 实例触发图片存在 A 的本地磁盘但接收方拿到的 URL 如果指向 B 实例就 404 了。你可能说那我把 URL 固定指向 A但 A 挂了怎么办这就失去了高可用的意义。第二磁盘会满。报警图片是持续产生的一天几百上千张时间长了本地磁盘迟早被撑爆。你得额外写清理脚本还得担心清理的时候把正在被引用的图片删了。第三访问权限和生命周期管理麻烦。本地磁盘的图片没有统一的过期策略也没有细粒度的访问控制运维成本高。所以正确的做法是把图片存到一个所有 Grafana 实例都能访问、且接收方也能访问的共享存储上。对象存储是最自然的选择而 Ceph 的 S3 兼容接口RADOS Gateway简称 RGW正好提供了 S3 协议Grafana 原生就支持 S3 作为 external image storage。3.2 Ceph S3 兼容接口需要准备什么在 Ceph 这边你需要准备的东西不多但每一步都要确认清楚一个可用的 RGW 端点形如http://rgw-host:7480确保 Grafana 服务器能网络可达一个专门给 Grafana 用的桶比如grafana-alert-images不要跟其他业务混用一对访问密钥Access Key / Secret Key权限限定在这个桶上遵循最小权限原则桶的访问策略如果接收方需要直接访问图片 URL桶或对象需要允许匿名读取或者通过带签名的 URL 访问。这里有个关键决策图片 URL 是公开可读还是签名访问公开可读配置简单接收方拿到 URL 直接能打开但安全性差任何人拿到 URL 都能看。签名访问安全但 URL 有有效期且接收方比如钉钉拉取图片时可能因为签名过期而失败。我的建议是如果报警图片不包含敏感信息用公开可读 随机化的对象路径就够了路径里带足够的随机字符别人猜不到。如果图片敏感那就用签名 URL但要把有效期设得足够长比如 7 天确保接收方任何时候点开都能看到。3.3 Grafana 侧对接 S3 的配置细节Grafana 的 external image storage 配置在配置文件里长这样[external_image_storage] provider s3 [external_image_storage.s3] endpoint http://rgw-host:7480 bucket grafana-alert-images region us-east-1 access_key YOUR_ACCESS_KEY secret_key YOUR_SECRET_KEY path_style_access true这里有几个坑必须说清楚。第一个坑region不能乱填。Ceph RGW 虽然兼容 S3 协议但它对 region 的处理跟 AWS 不完全一样。有些 RGW 配置下region 必须填一个具体的值填错会报AuthorizationHeaderMalformed。一般填us-east-1能兼容大多数情况但如果你的 RGW 配了特定的 region得按实际的填。第二个坑path_style_access必须设为 true。AWS S3 默认用 virtual-hosted stylebucket.s3.amazonaws.com而 Ceph RGW 通常用 path stylergw-host:7480/bucket。如果不设这个参数Grafana 会用 virtual-hosted style 去访问直接连不上。这个坑我踩过报错信息很隐晦排查了半天才想到是 URL 风格的问题。第三个坑endpoint要不要带协议。有些版本的 Grafana 要求 endpoint 带http://或https://有些不带也能识别。保险起见带上协议避免歧义。配置改完重启 Grafana然后触发一次报警测试。如果配置对了你会在 Ceph 的桶里看到新上传的图片对象同时报警 payload 里会出现imageUrl字段。4. imageUrl 是怎么进到 webhook payload 里的4.1 先搞清楚 Grafana 的模板变量Grafana 的报警通知内容是通过**模板Template**渲染的模板里可以用一系列变量。图片相关的变量主要有两个.ImageURL渲染并上传成功后的图片完整 URL.ExternalURLGrafana 自身的访问地址。很多人配了 external image storage 之后发现 webhook payload 里没有 imageUrl原因通常是模板里没引用这个变量。Grafana 不会自动把 imageUrl 塞进 payload你必须在 Contact Point 的消息模板里显式写出来。一个典型的 webhook 消息模板大概长这样{ alertName: {{ .CommonLabels.alertname }}, status: {{ .Status }}, imageUrl: {{ .ImageURL }}, message: {{ .CommonAnnotations.summary }}, description: {{ .CommonAnnotations.description }} }注意.ImageURL只有在图片渲染并上传成功之后才有值。如果渲染失败或者存储配置有问题这个变量会是空字符串payload 里imageUrl就是空的。所以排查的时候第一步就是看这个字段有没有值有值说明渲染和存储都通了没值就往上游查。4.2 钉钉和企微对 imageUrl 的接受方式不一样这里要分接收端来说因为不同平台对图片的处理逻辑差别很大。钉钉机器人的 markdown 消息类型支持这种语法所以你可以直接在消息模板里拼钉钉收到之后会去拉取这个 URL 并展示图片。但钉钉对图片 URL 有要求必须是公网可访问的且响应要快。如果你的 Ceph RGW 在内网钉钉拉不到图就会显示一个裂图。这种情况要么把 RGW 暴露到公网注意安全要么在中间加一层图片代理。企业微信机器人的 markdown 也支持图片语法逻辑类似。但企微对图片大小有限制渲染出来的 PNG 如果太大比如超过 2MB可能会被拒。这时候可以在 renderer 侧调整图片质量或尺寸把单张图控制在合理范围内。自建告警网关就灵活多了payload 里拿到 imageUrl 之后想怎么处理都行可以下载下来转存、可以嵌入邮件、可以推到内部 IM。这也是我比较推荐的方式可控性最强。4.3 一个容易被忽略的细节URL 的可达性imageUrl 生成出来是一回事接收方能不能访问是另一回事。这里有个经典的坑Grafana 配置的 S3 endpoint 是内网地址生成的 imageUrl 自然也是内网地址但接收方钉钉服务器在公网访问不了。解决办法有两个思路。一是让 Grafana 生成 URL 时用一个对外可访问的域名这需要 Ceph RGW 前面挂一个反向代理并且 Grafana 配置的 endpoint 用这个对外域名。二是接收端做代理payload 里的 imageUrl 指向内网接收端拿到之后自己下载图片再转发。我倾向于第一种配置一次一劳永逸。具体做法是在 RGW 前面放一个 Nginx对外暴露一个域名Grafana 的endpoint配成这个域名。这样生成的 imageUrl 天然就是公网可达的。当然前提是这个域名和桶的访问策略配好别把整个桶暴露出去。5. 完整链路的联调与排查思路5.1 分阶段验证别一上来就端到端配这套东西最忌讳的就是全部配完再测一旦不通你根本不知道是哪一环的问题。正确的做法是分阶段验证每一环单独确认通了再往下走。第一阶段验证 renderer 能渲染。可以直接调 renderer 的接口传一个 Panel 的 URL 进去看能不能返回 PNG。这一步通了说明渲染环境没问题。第二阶段验证 Grafana 能拿到渲染结果。在 Grafana 里手动触发一次 Test 通知看通知内容里有没有图片。这一步通了说明 Grafana 和 renderer 的对接没问题。第三阶段验证图片能上传到 Ceph。触发报警后去 Ceph 桶里看有没有新对象。这一步通了说明 external image storage 配置正确。第四阶段验证 imageUrl 能访问。把生成的 URL 复制出来用 curl 或者浏览器访问看能不能拿到图片。这一步通了说明网络和权限没问题。第五阶段验证接收端能展示。发一条真实报警到钉钉或企微看图片有没有正常显示。这样分阶段走哪一步不通就集中查那一步效率高很多。5.2 常见报错和对应排查方向下面这张表是我实际遇到过的报错和排查方向供参考现象可能原因排查方向payload 里 imageUrl 为空渲染失败或存储未配置查 Grafana 日志中 rendering 相关报错图片位置显示裂图URL 不可达或权限不足用 curl 直接访问 URL 看返回码上传报 403密钥权限不足检查 Ceph 用户对桶的权限策略上传报 400region 或 path style 配置错核对 endpoint、region、path_style_access渲染超时renderer 并发或资源不足调大超时、限制并发、加资源图片模糊或截断Panel 尺寸或渲染参数问题调整 Panel 尺寸和渲染 deviceScaleFactor这里重点说两个。403 权限问题很多时候不是密钥错而是 Ceph 的桶策略没给这个用户写权限。Ceph 的权限模型跟 AWS 略有差异建议用radosgw-admin命令确认用户的 caps 配置。400 配置问题八成是 region 或 path style前面说过不再重复。5.3 报警风暴下的稳定性考量单条报警跑通不难难的是报警风暴下整条链路不崩。我做过一次压测同时触发 50 条报警结果 renderer 直接被打满后面的渲染全部超时图片全丢。后来做了几个优化。一是给 renderer 加队列和限流超过并发上限的请求排队等待而不是直接失败。二是给渲染加缓存相同 Panel 相同时间范围的渲染结果短时间内复用减少重复渲染。三是降级策略如果渲染确实失败报警消息里明确标注图片渲染失败而不是留个空白让人困惑。还有一点报警规则里渲染的 Panel 要精简。我见过有同学一条规则渲染 6 个 Panel平时没事风暴一来直接雪崩。精简到 1 到 2 个核心 Panel既够用又稳。6. 几个让这套方案更顺手的经验6.1 对象路径的命名策略Grafana 上传到 S3 的对象路径默认是它自己生成的通常带时间戳和随机串。这个路径你控制不了但可以通过桶的生命周期策略来管理。我一般会配一个规则30 天前的对象自动删除。报警图片的时效性很强一个月前的图基本没人看留着占空间。如果接收端需要按报警名称或者时间检索图片那默认路径就不够用了。这种情况可以考虑在接收端做二次处理把图片下载下来按自己的规则重新命名存储。Grafana 本身不提供自定义对象路径的配置这点要有预期。6.2 图片尺寸和清晰度的平衡renderer 渲染出来的图片默认尺寸和清晰度跟 Panel 的配置有关。如果图片太小看不清可以调大 Panel 的尺寸如果图片太大传输慢可以调小。还有一个参数deviceScaleFactor控制渲染的像素密度设成 2 会让图片更清晰但体积翻倍。报警场景下我一般设成 1 到 1.5够看就行别追求极致清晰。6.3 别忘了测试通知和真实报警的差异Grafana 的 Test 通知和真实报警走的是同一套模板但Test 通知不一定触发图片渲染。有些版本里Test 通知只验证模板渲染不实际渲染图片所以你会看到 Test 通知里 imageUrl 是空的但真实报警有图。别被这个误导以为配置错了。判断配置对不对还是要用真实报警来验证。6.4 监控这套监控系统本身最后一点也是做高可用监控系统最容易被忽略的监控系统自己也需要被监控。renderer 的渲染成功率、渲染耗时、S3 上传的成功率、图片 URL 的可达性这些指标都应该纳入监控。否则哪天 renderer 悄悄挂了报警还在发只是都没图了你可能很久都发现不了。我一般会给 renderer 加一个健康检查定期发一个测试渲染请求失败就报警。S3 上传也可以加一个探针定期上传一个测试对象。这些元监控看起来多余但真出事的时候能帮你快速定位。整套方案跑下来最直观的感受是报警从一行字变成了一张图加一行字排障的时候少了很多来回折腾。尤其是半夜被叫醒的时候手机上一眼就能看到趋势图判断是误报还是真故障几秒钟的事。这个体验的提升值得花时间把这条链路搭起来。