ELK 7.x 升级到 8.x 后 Kibana 插件兼容性问题如何解决？

Question

ELK 7.x 升级至 8.x 后，Kibana 插件普遍出现兼容性问题：插件因 API 变更（如弃用 `uiModules`、`Chrome` 服务）、React 18 升级导致生命周期不兼容、TypeScript 类型校验增强及插件签名强制要求而无法加载或报错。常见现象包括插件未出现在管理界面、控制台抛出 `Plugin initialization error` 或 `Invalid plugin manifest`。官方自 8.0 起已移除对旧版插件架构的支持，仅允许使用新版平台插件（Platform Plugin）开发范式，且必须通过 `kibana-plugin install` 签名验证。第三方插件（如 Sense 替代品、自定义可视化组件）若未适配 8.x，将直接失效。解决核心路径为：评估插件必要性 → 优先选用 Kibana 内置功能（如 Lens 替代自定义图表）→ 对关键自研插件进行重构：迁移至 `@kbn/plugin-helpers`、重写 UI 为 React 函数组件、适配 `core` 和 `plugins` 入口契约，并通过 `kibana-plugin verify` 校验。升级前务必在测试环境完成插件兼容性验证。

Answer 1

```html

一、现象层：典型兼容性故障表征

• Kibana 启动后插件未出现在 Stack Management → Plugins 界面
• 浏览器控制台持续报错：Plugin initialization error: Cannot find module 'ui/modules'
• 加载自定义可视化时白屏，React DevTools 显示 Invalid hook call（React 18 Strict Mode 下双重渲染触发）
• kibana-plugin install 失败并提示：Invalid plugin manifest: missing required field "kibana.version" 或 Plugin signature verification failed
• TypeScript 编译中断：error TS2339: Property 'chrome' does not exist on type 'CoreStart'

二、架构层：ELK 8.x 插件体系重构核心变更

维度	ELK 7.x（Legacy Plugin）	ELK 8.x（Platform Plugin）
插件生命周期	依赖 uiModules + Chrome + notify 等全局服务注入	基于 CoreSetup/CoreStart + PluginSetup/PluginStart 契约接口
UI 开发范式	AngularJS 模板 + Directive + Controller	React 18 函数组件 + React Query + Emotion CSS-in-JS
类型系统	弱类型声明，any 泛滥，无强制类型校验	全量 @types/elastic__kibana 支持，严格 strict: true 编译约束
安全机制	插件 ZIP 解压即运行，无签名验证	必须通过 kibana-plugin verify 签名认证，含 SHA-256+证书链校验

三、诊断层：四步插件兼容性评估法

1. 清单扫描：执行 GET /api/status 获取已加载插件列表，比对 kibana.yml 中 plugins.scanDirs 配置路径下实际存在但未注册的插件目录
2. Manifest 检查：验证 kibana.json 是否含 "kibana.version": "8.x"、"required_kibana_version" 及 "owner" 字段
3. 依赖图谱分析：使用 npx depcheck --ignores=@kbn/* 扫描残留的 ui/chrome、ui/notify 等废弃包引用
4. 运行时 Hook 追踪：在 src/plugin.ts 的 setup() 入口添加 console.trace('Plugin setup invoked') 定位初始化断点

四、解决层：平台插件迁移实施路线图

graph TD
  A[评估插件必要性] --> B{是否已被Lens/OSD/Alerting内置替代？}
  B -->|是| C[下线插件，配置迁移文档]
  B -->|否| D[启动平台化重构]
  D --> E[引入 @kbn/plugin-helpers v8.x 脚手架]
  E --> F[重写 UI 为 React 函数组件 + useKibana() Hook]
  F --> G[替换 chrome.getBasePath → core.http.basePath.get()]
  G --> H[将 uiSettings 注册迁移至 core.uiSettings.register() + plugins.settings.client]
  H --> I[kibana-plugin verify --signature=your-cert.pem]
  I --> J[CI 流水线集成：jest + storybook + cypress E2E]

五、工程层：关键代码迁移对照示例

// ❌ ELK 7.x 旧写法（已失效）
import chrome from 'ui/chrome';
import uiModules from 'ui/modules';
uiModules.get('app/myplugin').controller('MyCtrl', function ($scope) {
  $scope.basePath = chrome.getBasePath();
});

// ✅ ELK 8.x 平台插件标准写法
import { CoreSetup, CoreStart, Plugin, PluginInitializerContext } from '@kbn/core/public';
import { MyApp } from './components/app';

export class MyPlugin implements Plugin {
  public setup(core: CoreSetup, plugins: any) {
    core.application.register({
      id: 'myplugin',
      title: 'My Plugin',
      async mount(params) {
        const { renderApp } = await import('./application');
        return renderApp(params, core, plugins);
      }
    });
  }
  public start(core: CoreStart) {
    return {
      getBasePath: () => core.http.basePath.get(),
      getUiSettings: () => core.uiSettings
    };
  }
}

六、治理层：升级后长期运维建议

• 建立 .kibana-plugin-manifest.yml 元数据清单，记录每个插件的适配状态、负责人、SLA 响应等级
• 在 CI 中强制执行 kibana-plugin verify --signature + tsc --noEmit 双校验门禁
• 对第三方插件启用“沙箱隔离模式”：通过 kibana.yml 的 plugins.ignore 白名单机制动态管控
• 每季度执行 GET /api/plugins API 巡检，结合 Prometheus + Kibana Alerting 构建插件健康度看板

```