Grafana 8.0.6 用了大半年，一直很稳，结果有一次为了给某个项目补一个饼图扩展，手工从内网镜像站拉了一个第三方插件包，解压到插件目录，重启服务，面板里就多了一个红色感叹号：Missing signature。点击启用毫无反应，日志里只有一行plugin is unsigned。我当时以为是自己包解压错了，删了重来三遍，问题依旧。后来翻了官方配置文档、试了环境变量才把坑填平。今天把这台机器上从排查到解决的完整过程写下来，给所有还在用 8.0.6 或相似版本的朋友参考：缺签名不是软件坏了，而是安全策略把你挡在门外。
1. 报错现场还原：Missing signature 到底卡在哪一步
1.1 UI 上的表现与影响范围
先说说当时在页面上看到的情况。登录 Grafana 后，左侧菜单进入“Plugins”页面，插件卡片上原本应该显示“Enable”按钮，但我装的那个第三方图表插件直接显示一段黄色提示，大意是“This plugin is unsigned”，按钮点下去没有任何反馈，刷新页面又变回原来的状态。
如果你遇到类似情况，说明插件并没有真正加载成功。受影响的不仅仅是这一个插件本身，还包括所有依赖它的数据源、Dashboard 和 Panel。比如我那次装的饼图扩展，就算 Dashboard 里已经配置好了这个类型的面板，刷新后也会变成空白或提示“Panel plugin not found”。在多人协作的团队里，这类问题会直接拖慢交付节奏，所以在排查时要第一时间看日志，而不是反复重新上传插件包。
1.2 从日志里确认根因
我当时先去看 Grafana 服务日志。不同部署方式日志位置不一样，我用的是 systemd 管理的二进制包，所以直接执行：
journalctl -u grafana-server -n 100 --no-pager如果日志目录单独配置过，也可以看/var/log/grafana/grafana.log。日志里那一段大概长这样：
level=error logger=plugins msg="Failed to load plugin" pluginID=sample-panel error="plugin is unsigned"关键字就是plugin is unsigned，对应页面上的Missing signature。遇到这条日志基本可以确认，插件包本身没有问题，只是缺少 Grafana 认可的签名信息。此时不要继续在解压、上传环节里打转，优先检查签名校验机制。
1.3 容易混淆的两个报错：Missing signature 和 Signature invalid
我后来还见过一种更隐蔽的情况，插件其实带了签名文件，但提示却是invalid signature。这俩看着像，原因完全不同。我根据自己的经验整理了一张对比表：
| 报错关键字 | 页面提示 | 含义 | 最常见原因 |
|---|---|---|---|
plugin is unsigned | Missing signature | 插件包里根本没有签名信息 | 手动下载的第三方插件，未经过官方签名流程 |
error computing signature | Invalid signature | 插件有签名文件，但内容校验失败 | 插件包被篡改、文件被覆盖，或者签名文件损坏 |
排查时先区分这两个方向。标题里说的Missing signature属于第一类，处理重点是“允许加载未签名插件”或“换成已签名插件”；而invalid signature则需要重新获取原始插件包，必要时还要检查有没有杀毒软件或者同步工具动过文件。
2. 插件签名校验原理：为什么 Grafana 8.0.6 不肯接受未签名插件
2.1 签名校验到底校验了什么
Grafana 从早期版本开始就逐步收紧了插件安全策略，到 8.x 版本已经默认强制校验签名。它的工作原理并不复杂：官方发布插件时，会对插件包做一次数字签名，签名信息随包一起分发。Grafana 服务启动或扫描插件目录时，再拿着本地内置的公钥去验证签名是否完整、是否由官方签发。
你可以理解成给快递贴防伪标签。官方寄出来的包裹在封口处有防伪码，你收到后要扫一下确认没有被拆过；自己人手工做一个包裹，封口处没有防伪码，系统就会拒绝签收。Grafana 8.0.6 对插件就是这个逻辑：没有防伪码，也就是缺少签名，宁可功能不可用，也不承担插件被篡改后带来的风险。
这样做很重要，因为插件进程运行在 Grafana 服务账号下，有权限读取数据源配置、读取 Dashboard JSON、甚至执行部分系统调用。如果任何人都能塞一个未经验证的插件进去，等于给攻击者留了一扇后门。
2.2 为什么手动安装的第三方插件最容易触发
我那次踩坑的直接原因就是没有走官方插件市场。官方插件仓库里大部分插件都经过签名，直接从grafana-cli plugins install安装不会有问题。但我当时为了绕过外网限制，从内网镜像站下载了一个第三方插件包，自己解压、拷贝到插件目录，这个过程完全绕过了签名机制，自然就触发了Missing signature。
这个问题在离线环境里尤其常见。很多团队为了安全隔离，服务器不能直接访问外网，只能通过内网文件服务器传递插件包。从这些渠道拿到的包，除非发布者自己维护了签名流程，否则基本都会缺签名。所以不要怀疑是自己的操作失误，这是签名校验机制在按规则办事。
2.3 官方签名、私有插件和“无签名”插件的差别
对于用 Grafana 8.0.6 的团队来说，插件在签名层面大致分三类：
- 官方签名插件：从官方插件市场下载，带完整签名，默认可以直接加载。
- 自签名或企业内部分发的插件：理论上可以在内部搭建签名服务，但 8.0.6 这种版本配置起来比较复杂，大多数团队不会主动做。
- 完全未签名的插件：包括手工下载的免费插件、内部自研插件、网盘流传的修改版插件。这类插件在严格模式下会被直接拦截。
我见过不少运维同学把“缺签名”理解成插件包损坏，反复下载、反复解压，但问题依旧。实际上插件包是完整的，只是缺少那层被信任的“防伪标签”。这时候要想清楚：是放弃这个插件，还是主动把它加入白名单，允许未签名加载。
3. 三种解法与配置步骤：让未签名插件跑起来
3.1 方案A：换官方渠道安装，从根上消除缺签名问题
如果你的插件在官方插件市场里能找到，那最省事的做法就是用官方命令重新安装，不要手动解压。在 Grafana 8.0.6 环境下，一般这样操作：
grafana-cli plugins install grafana-piechart-panel注意，grafana-cli的版本要和 Grafana 服务版本一致，否则可能连不上服务。安装完成后重启 Grafana：
systemctl restart grafana-server这样装出来的插件自带头签名，不会再报Missing signature。如果插件需要指定版本，可以这样写：
grafana-cli plugins install grafana-piechart-panel 1.4.2官方命令会自动处理下载、校验、解压流程，目的就是避免手工操作造成签名缺失或目录结构错误。这是最推荐的一种姿势。
3.2 方案B：在 custom.ini 里放开未签名插件白名单
有些第三方插件确实不在官方市场，或者团队内部自研的数据源插件需要部署，那就要走“放开未签名插件”的路子。
Grafana 配置里提供了一个白名单参数：allow_loading_unsigned_plugins。在 8.0.6 中，最稳妥的方式是修改custom.ini，而不是直接改grafana.ini。因为 rpm/deb 包升级时可能会覆盖默认配置文件，custom.ini作为用户自定义配置，优先级更高，也更安全。
如果没有custom.ini，就手动创建一个。路径一般是/etc/grafana/custom.ini，内容写：
[plugins] allow_loading_unsigned_plugins = sample-panel, another-plugin这里填的是插件 ID，不是插件显示名，也不是目录名。插件 ID 要去插件包里的plugin.json文件里查，比如：
{ "id": "sample-panel", "name": "Sample Panel" }多个插件之间用英文逗号分隔，我建议不要加空格，避免有些版本解析出带空格的字符串导致匹配不上。改完配置后重启：
systemctl restart grafana-server重启后再去插件页面看，原来的红色提示应该消失，插件也可以正常启用了。
3.3 方案C：Docker 场景用环境变量覆盖
如果 Grafana 跑在 Docker 或 Kubernetes 里，直接改配置文件不是不行，但更常见的是用环境变量。Grafana 支持把配置文件里的任意参数映射成环境变量，规则是GF_开头，后面加配置段名和参数名，全部大写，用下划线分隔。
对于[plugins]下面的allow_loading_unsigned_plugins，环境变量就是：
GF_PLUGINS_ALLOW_LOADING_UNSIGNED_PLUGINS=sample-panel,another-plugin启动容器时可以这样写：
docker run -d \ -e GF_PLUGINS_ALLOW_LOADING_UNSIGNED_PLUGINS=sample-panel \ -v /data/plugins:/var/lib/grafana/plugins \ -p 3000:3000 \ --name grafana \ grafana/grafana:8.0.6这里要注意：环境变量会覆盖配置文件里的同名参数。如果容器里同时挂载了custom.ini，而custom.ini里也配置了白名单，最终生效的还是环境变量。所以排查问题时要先确认到底走的是配置文件还是环境变量。
3.4 手动安装插件时目录与 ID 的匹配细节
既然有三种解法，已经足够让插件跑起来，但手动安装插件时还有一个隐藏坑：插件目录名不一定等于插件 ID。Grafana 扫描/var/lib/grafana/plugins下的子目录时，会读取每个子目录里plugin.json的id字段来识别插件，最终白名单匹配的也是这个id。
所以手动安装时，我建议把解压目录名直接改成插件 ID，同时确保目录结构正确。比如查出来plugin.json里的 id 是sample-panel，就把插件目录放在：
/var/lib/grafana/plugins/sample-panel/下面直接能看到plugin.json和对应的module.js等文件，不要多套一层没有意义的嵌套目录。之前见过有人解压后多了一层同名目录，导致 Grafana 找不到plugin.json，报错信息也是杂七杂八，很难排查。
4. 完整实操记录：从报错日志到恢复正常加载
4.1 模拟环境与实际操作流程
下面用我实际处理过的一个内部场景做演示。假设 Grafana 8.0.6 跑在一台 CentOS 7 机器上，插件目录是默认的/var/lib/grafana/plugins，我拿到一个内网流传的扩展插件包，名字先叫internal-panel-v1.0.tar.gz。
第一步，解压到临时目录看结构：
tar -xzf internal-panel-v1.0.tar.gz -C /tmp/plugin-tmp find /tmp/plugin-tmp -name plugin.json找到plugin.json后，查看插件 ID：
cat /tmp/plugin-tmp/internal-panel/plugin.json | grep '"id"'我那次拿到的插件 ID 是internal-panel。确认之后，把插件复制到正式目录：
mkdir -p /var/lib/grafana/plugins/internal-panel cp -r /tmp/plugin-tmp/internal-panel/* /var/lib/grafana/plugins/internal-panel/然后重启 Grafana：
systemctl restart grafana-server systemctl status grafana-server此时自然出现了开头说的Missing signature。接着修改配置，新建或编辑/etc/grafana/custom.ini：
[plugins] allow_loading_unsigned_plugins = internal-panel再次重启：
systemctl restart grafana-server刷新浏览器页面，插件显示正常，启用按钮也能点击了。整个处理过程不到十分钟。
4.2 如何确认配置真正生效
配置改完后，不要只是点一下页面就完事，最好用日志和命令行双重确认。看日志的命令和前面一样：
journalctl -u grafana-server -n 50 --no-pager如果启动过程中没有出现plugin is unsigned，说明白名单配置生效了。如果想在页面上确认，也可以进入“Plugins”页面，看对应卡片的状态是否变成可启用，或者点进插件详情页，看右上角的状态标识是否已变为正常。
如果你的 Grafana 开启了 API，也可以用 curl 调用插件接口确认插件是否存在：
curl -s http://localhost:3000/api/plugins | grep internal-panel不过这个接口通常需要登录态或 API Key，临时验证还是优先看日志和页面最直接。
4.3 重启和验证过程中要注意的参数
重启 Grafana 前，一定要检查配置文件的段落名。常见错误是把allow_loading_unsigned_plugins写到了[server]段下面，或者写到了[plugins]段的上方但没注意缩进和方括号。配置解析是严格按照 INI 段名来的，段名不对，参数直接失效。
还有一点，如果 Grafana 是集群部署，每个节点的插件目录和配置都要保持一致。我在实际维护中遇到过只在某一台节点上配了白名单，结果其他节点依然报错的情况。节点之间不会自动同步配置和插件，必须通过部署工具批量推送。
最后，修改配置后不要用reload接口来验证，Grafana 的插件加载是启动时扫描的，很多场景下必须完整重启服务进程。
5. 排查 Missing signature 的常踩坑和速查表
5.1 改了配置但没生效：段名、文件名、重启缺一不可
这个坑出现的频率非常高。很多人改了/etc/grafana/grafana.ini，在[plugins]段下加了allow_loading_unsigned_plugins，但没生效。原因通常是官方包的默认配置文件在升级时被刷新，或者自定义配置没放到正确的文件里。
我的习惯是：优先改/etc/grafana/custom.ini。这个文件在安装包中不一定存在，需要自己创建。配置优先级是custom.ini高于grafana.ini，且不会被常规升级覆盖。段名必须写成[plugins]，参数用allow_loading_unsigned_plugins，然后重启服务。三点缺一不可：段名对、文件对、重启。
5.2 插件 ID 写错导致白名单失效
白名单匹配的是插件 ID，而不是插件名称和目录名。如果你从插件介绍页看到一个名字，就直接填进配置，大概率匹配不上。正确做法是查看插件包里的plugin.json，找到其中的"id"字段，把这个值原样复制到配置里。
这里还有个小细节，有些插件包解压后plugin.json里的 id 带了版本号或者命名空间，例如yourcompany-panel，填写时不要去掉中间的连字符，也不要改成驼峰。原样复制最稳妥。
5.3 文件权限和目录所有者问题
插件目录权限不对，也会让 Grafana 扫描失败，而且日志里不一定直接报签名问题。二进制的 Grafana 服务一般以grafana用户运行，如果插件目录是root用户解压的，且没有设置其他用户的读权限，进程可能连plugin.json都读不到，最终表现也是插件不可用。
我在复制插件后通常执行一条命令：
chown -R grafana:grafana /var/lib/grafana/plugins如果是 Docker 挂载卷，还需要确认宿主机目录权限映射到容器内用户后的可读性。权限问题隐蔽性很强，排查时可以先用ls -l看插件目录权限，再确认启动用户。
5.4 插件版本与 Grafana 版本不兼容的干扰
在 Grafana 8.0.6 上，即使插件签名通过了，也可能出现面板数据源无法加载的情况。这类问题常常不是签名导致，而是插件要求的 Grafana 版本高于当前版本，或者接口调用方式和 8.0.6 不兼容。
我在处理另一个插件时遇到过：插件本身是官方签名插件，但更新后要求 Grafana 8.2 以上，在 8.0.6 上直接显示加载失败，日志里却没有任何签名相关报错。所以遇到问题不要只盯着签名，还要去插件的plugin.json里看dependencies字段，确认兼容版本。
5.5 一个实用的排查速查表
为了方便记录和后续复用，我把排查过程整理成了下面这个表格：
| 检查项 | 操作方式 | 预期结果 |
|---|---|---|
| 确认插件 ID | cat /var/lib/grafana/plugins/<目录>/plugin.json | 拿到id字段 |
| 确认插件目录权限 | ls -ld /var/lib/grafana/plugins/<目录> | grafana 用户可读 |
| 确认配置段名 | 打开custom.ini，检查是否在[plugins]下 | 参数位置正确 |
| 确认白名单值 | 与plugin.json的 id 完全一致 | 无多余空格 |
| 确认环境变量 | 执行 `env | grep GF_PLUGINS_ALLOW` |
| 重启后查日志 | journalctl -u grafana-server -n 100 | 不再出现 unsigned |
| 页面确认 | Plugins 页面看状态 | 插件可启用 |
这套流程基本覆盖了我遇到的大部分Missing signature问题。按顺序走一遍，十分钟以内能定位。
6. 后续运维建议与个人心得
6.1 把插件安装流程固化到部署脚本
经过这次折腾后，我把插件安装从手工操作改成了脚本化处理。新环境部署 Grafana 时，先通过grafana-cli plugins install安装官方插件，内部自研插件则走单独的剧本，在拷贝插件后自动把插件 ID 写入custom.ini，再校验目录权限，最后重启服务。
这样做的收益很明显：团队里其他人不需要理解底层签名机制，只需要执行一个标准化脚本就能完成插件部署。后续即使有人手动往插件目录里扔了新插件，也会在配置检查阶段被拦住，不会出现上线后才发现缺签名。
6.2 安全性和便利性的平衡
允许未签名插件加载毕竟是一个安全妥协。8.0.6 之后的版本对插件的权限控制更加严格，甚至支持在 UI 上标记插件是否受信任。考虑到这一点，我平时处理时会先评估插件来源，再决定是否放进白名单：官方市场能装就装，第三方插件能在隔离环境先验证就验证，完全来路不明的插件尽量不用。
如果你的团队已经升级到更高版本的 Grafana，建议优先用官方市场或企业级签名机制，而不是长期依赖allow_loading_unsigned_plugins。但在 8.0.6 这个版本上，如果确实需要快速恢复业务，白名单是最直接有效的解法。我个人目前仍然维护着一套 Grafana 8.0.6 环境，插件白名单控制在个位数，每个插件都有明确的负责人和用途说明。这样既能解决问题，又不至于把安全底线完全放开。
