› › ›

CI 指标

编辑

CI 指标编辑

除了运行我们的测试之外，CI 还收集有关 Kibana 构建的指标。这些指标被发送到外部服务，以跟踪随时间推移的变化，并为 PR 作者提供有关其更改影响的见解。

指标类型编辑

包大小编辑

这些指标帮助贡献者了解他们如何影响 Kibana 创建的包的大小，并帮助确保 Kibana 加载速度尽可能快。

页面加载包大小

为每个包/插件生成的入口文件的大小。此文件始终在每次页面加载时加载，因此它应该尽可能小。为了减少此指标，您可以将任何不在每次页面加载时都需要的代码放在 async import() 后面。

与其他插件静态共享的代码将有助于该插件的 页面加载包大小。这包括来自 public/index.ts 文件的导出以及 extraPublicDirs 清单属性引用的任何文件。

异步块大小

每个 async import() 语句导入的文件都会创建一个“异步块”。此指标跟踪这些块的总大小（以字节为单位），按插件/包 ID 分解。您可以将其视为用户访问包中的所有组件/应用程序时需要下载的代码量。

杂项资产大小

“杂项资产”是指任何不是异步块或入口块的东西，通常是图像。此指标跟踪这些资产的总大小（以字节为单位），按插件/包 ID 分解。

@kbn/optimizer 包模块计数

每个包/插件中包含的单独模块数量。这是我们拥有的关于 @kbn/optimizer 构建特定包需要多长时间的最佳指标，因此我们报告它来帮助人们了解何时导入了一个可能包含令人惊讶数量的子模块的模块。

可分发大小编辑

Kibana 可分发的大小是一个重要的指标，因为它不仅影响下载所需的时间，而且还影响下载后解压缩存档所需的时间。

我们没有在 PR 上报告几个指标，因为 gzip 压缩即使提供相同的输入也会产生不同的文件大小，因此即使 PR 作者没有进行任何相关更改，此指标也会定期显示更改。

所有指标都从为 Linux 平台生成的 tar.gz 存档中收集。

可分发文件计数: 默认可分发中包含的文件数量。
可分发大小: 默认可分发的大小（以字节为单位）。（不在 PR 上报告）

保存的物体字段计数编辑

Elasticsearch 默认情况下将索引中的字段数量限制为 1000，我们希望避免提高该限制。

保存的物体 .kibana 字段计数: 按保存的物体类型分解的保存的物体字段数量。

添加新的指标编辑

您可以使用 @kbn/dev-utils 包提供的 CiStatsReporter 类来报告新的指标。此类在 CI 上自动配置，并且其方法在 CI 外部运行时会执行空操作。有关更多详细信息，请查看 CiStatsReporter 自述文件。

解决 `页面加载包大小` 超出编辑

为了防止页面加载包意外变大，我们限制了每个插件的 页面加载资产大小 指标。当 PR 将此指标增加到 limits.yml 中为该插件定义的限制之外时，将设置一个失败的提交状态，并且 PR 作者需要决定如何在 PR 合并之前解决此问题。

在大多数情况下，限制应该足够高，以至于 PR 不会触发超出限制，但是当它们确实触发时，请确保通过尝试以下操作来明确导致超出限制的原因

使用 --profile 标志在本地运行优化器，以生成 webpack stats.json 文件，这些文件可以使用许多不同的在线工具进行检查。重点关注名为 {pluginId}.plugin.js 的块；*.chunk.js 块构成了 异步块大小 指标，该指标目前不受限制，是我们减少页面加载块大小的主要方式。
```
node scripts/build_kibana_platform_plugins --focus {pluginid} --profile
# builds and creates {pluginDir}target/public/stats.json files for {pluginId} and any plugin it depends on
```
- 官方 Webpack 工具：http://webpack.github.io/analyse/
- Webpack 可视化器：https://chrisbateman.github.io/webpack-visualizer/
您可能还想为 PR 的上游分支创建统计信息，然后在 Webpack 可视化器中并排比较它们，以找出大小差异所在（使用两个浏览器选项卡）。
对于相对较小的更改，您可能可以通过将来自两个不同分支的 stats.json 文件粘贴到 Beyond Compare 中来更好地理解问题
如果 Beyond Compare 中的更改数量太大，您可以使用 jq 将 stats.json 文件缩减为仅包含排序的模块 ID 列表
```
jq -r .modules[].id {pluginDir}/target/public/stats.json | sort - > moduleids.txt
```
为您的分支和 master 生成一个 moduleids.txt 文件，然后将它们放到 Beyond Compare 中，以获得对新增内容的非常具体的视图。
作为最后的手段，您可能想尝试直接比较包源代码。通常最好使用生产源代码来执行此操作，以便您检查 CI 所看到的实际字节变化。在构建包的可分发版本后，将其运行到 prettier 中，然后将其与上游的块一起放到 Beyond Compare 中
```
node scripts/build_kibana_platform_plugins --focus {pluginId} --dist
npm install -g prettier
prettier -w {pluginDir}/target/public/{pluginId}.plugin.js
# repeat these steps for upstream and then compare the two {pluginId}.plugin.js files in Beyond Compare
```
如果所有方法都失败，请与 Operations 联系以寻求帮助。

一旦您确定了添加到构建中的文件，您可能只需要将它们放在异步导入后面，如插件性能中所述。

如果包大小没有被任何明显的东西膨胀，但它仍然大于限制，您可以在您的 PR 中提高限制。通过手动编辑 limits.yml 文件或运行以下命令来执行此操作，以将限制更新为当前大小 + 15kb

node scripts/build_kibana_platform_plugins --focus {pluginId} --update-limits

此命令必须以可分发模式运行优化器，因此它将花费更长的时间，并且会为您的机器上的每个 CPU 生成一个工作进程。

对 limits.yml 文件的更改将触发 Operations 团队的审查，他们将尝试验证大小增加是否合理。如果您有上述步骤中可以分享的发现，那将非常有帮助！

验证 `页面加载包大小` 限制编辑

在尝试跟踪将改进包大小的更改时，请尝试在本地运行以下命令

node scripts/build_kibana_platform_plugins --dist --watch --focus {pluginId}

这将为您的插件以及您的插件所依赖的插件构建前端包。每当您进行更改时，包都会重新构建，您可以在插件内的 target/public/metrics.json 文件中检查该构建的指标。此文件将在您保存对源代码的更改时更新，对于确定您的更改是否足够降低 页面加载资产大小 应该有所帮助。

如果您只想运行一次构建，可以运行

node scripts/build_kibana_platform_plugins --validate-limits --focus {pluginId}

此命令需要应用生产优化才能获得正确的大小，这意味着优化器将花费更长的时间运行，并且在大多数开发人员机器上将消耗您机器的所有资源 20 分钟或更长时间。如果您想在运行此命令时进行多任务处理，您可能需要使用 --max-workers 标志来限制工作进程的数量。

« 解释 CI 失败开发期间的文档 »