« 解析 CI 失败 开发期间的文档 »
Elastic 文档 ›Kibana 指南 [8.17] ›开发者指南 ›贡献

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 不应触发超限，但如果发生这种情况，请通过尝试以下操作来明确导致超限的原因

  1. 使用 --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
  2. 您可能还需要为 PR 的上游分支创建统计信息，然后在 Webpack 可视化工具中并排比较它们，以找出大小差异所在（使用两个浏览器标签）。
  3. 对于相对较小的更改，您可能可以通过将来自两个不同分支的 stats.json 文件粘贴到 Beyond Compare 中来更好地理解问题。

  4. 如果 Beyond Compare 中的更改数量过多，则可以使用 jq 将 stats.json 文件缩减为仅包含模块 ID 的排序列表。

    jq -r .modules[].id {pluginDir}/target/public/stats.json | sort - > moduleids.txt

    为您的分支和 master 生成一个 moduleids.txt 文件，然后将它们放入 Beyond Compare 中，以获得非常具体的新增内容视图。

  5. 作为最后的手段，您可能需要尝试直接比较包源。通常最好使用生产源进行此操作，以便您检查 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
  6. 如果所有其他方法都失败，请联系 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 失败 开发期间的文档 »