一般准则编辑

以下准则涵盖了集成中可以改进的通用方面,不应被视为每个包都应遵守的强制性要求列表。一些适用于一个集成的准则可能与另一个集成完全无关。将其视为尽力而为。

虽然这些准则侧重于指标,但它们同样适用于日志。

数据类型编辑

鉴于所有包都是基本的,开发人员应在适用时使用基本类型(例如 histogram. wildcard 等)。当然,对于 ECS(见下文),我们应该使用 ECS 指定的类型。

ECS 兼容性编辑

集成包应与最新版本的 ECS 兼容。这意味着集成将填充更多相关的 ECS 字段。

从 ECS 1.6 开始,ECS 将开始对某些字段使用基本类型。集成字段应在该过程中升级到新类型。

记录所有字段编辑

集成产生的所有字段必须由 fields.yml 映射。这保证了它们的索引映射是正确的,并且 Kibana 拥有处理所有字段的足够信息。

字段限制编辑

默认情况下,数据流将具有 total_fields.limit 设置为 1000。除了定义的自定义字段外,这还包括动态生成的 ECS 字段。如果预计您的数据流最终将容纳超过 1000 个字段,请在数据流的 manifest.yml 中设置显式限制

elasticsearch:
  index_template:
    settings:
      index:
        mapping:
          total_fields:
            limit: 5000

为了向后兼容,如果为数据流显式定义了超过 500 个字段,则该限制会自动提升到 10000 个字段,但是新创建的集成不应依赖于此行为,而是假定固定限制为 1000 个字段。

指定指标类型和单位编辑

作为字段定义的一部分,有两个设置添加了元数据,这将有助于 Kibana 绘制图表

  • unit 适用于所有数据类型,定义字段的单位。单位的示例包括 bytems。当对百分比使用 percent 时,惯例是将 1 用于 100%。您可以在 软件包规范 中找到支持的单位的完整列表。
  • metric_type 仅适用于指标事件,要添加到指标字段。它定义了它们的指标类型。它可以是 gaugecounter 类型。计数器用于始终随时间推移而增加的指标,例如页面访问次数。量规用于随时间推移可能增加或减少的金额,例如正在使用的内存量。

Elasticsearch 文档详细介绍了 这两个字段的预期值

其他应用程序(包括 Kibana)在访问这些字段时可以使用此元数据提供的信息。 unit 用于格式化字段的值,而 metric_type 可用于在查询数据时提供更好的默认值。

指定维度编辑

数据流的一组字段可以定义为维度。具有相同值的一组维度标识单个时间序列。

仔细选择字段集非常重要。它们应该是正确标识数据流中包含的任何时间序列所需的最小维度集。维度太少可能会将多个时间序列的数据混合到一个时间序列中,而维度太多可能会影响性能。

可以通过在其定义中设置 dimension: true 来将字段配置为维度。

只有某些数据类型的字段可以定义为维度。这些数据类型包括关键字、IP 和数字类型。

在选择维度时要考虑的一些准则

  • 它们会影响摄取性能,建议尽可能少地使用维度。在选择维度时,尽量避免冗余维度,例如引用相同对象的唯一标识符和名称。
  • 也要注意维度过少。对于给定的维度集,每个时间戳只能有一份文档。如果不同的对象产生相同的维度,这会导致数据丢失。
  • 更改维度可能是重大更改。不同的维度集会产生不同的时间序列,即使它们选择了相同的数据。

声明维度是使用 TSDB 索引的必要条件。这些索引针对时间序列用例进行了优化,带来了磁盘存储节省以及其他查询和聚合。

可以通过在数据流清单中设置 elasticsearch.index_mode: time_series 来启用数据流中的 TSDB 索引。

日志和指标 UI 兼容性编辑

在适用时,集成包应提供日志和指标应用程序的相关字段。这对于专注于计算资源(VM、容器等)的集成尤其重要。

减去指标编辑

集成包应为任何目标系统收集合理数量的指标。在某些情况下,这可能意味着删除 Filebeat 和 Metricbeat 目前正在收集的某些指标。收集太多指标会影响指标存储以及提供给用户的数据的相关性。

潜在的移除候选者

  • 低级垃圾收集器指标
  • 显示代码流的内部指标(例如, Got100Continue, Wait100Continue
  • 冗余指标(例如,MQ 主题的指标收集不需要收集汇总指标)

相关指标编辑

这可能是最重要的是最难满足的准则之一,因为它需要了解每个目标系统。识别相关指标应逐案考虑。

此练习没有明确的准则。它可以像在某个地方找到所有内容一样简单(例如, RabbitMQ 文档),或者像审查多个来源(包括文档、博文和其他集成)一样困难,并将发现的信息集中到一个地方以供修订。建议仅收集仪表板和可视化所需的指标。

保留原始消息字段编辑

日志集成应保留原始消息字段(建议的名称: event.original),以便它显示在日志 UI 中。在用户想要在更改管道后重新索引数据时,它也很有用。此外,消息字段可以作为将来某些运行时字段的来源。

原始字段应使用 Kibana UI 可配置,以更好地管理成本和存储,以及与其他集成保持一致。

记录存储效率编辑

每个集成都应努力尽可能高效地存储收集的数据,这意味着优化每个集成生成文档的方式。

默认数据集编辑

在适用时,集成包应提供一个默认数据集,该数据集汇总了其他数据流中最相关的指标的子集。将其视为在概述仪表板中可视化的指标或用于警报的指标。创建单独的默认数据集的准则可能是当包中的数据集数量超过三个时。

更新的版本编辑

集成包应支持目标系统的最相关版本。我们的一些集成支持目标服务/系统的旧版本,这些版本在实施时是相关的。随着时间的推移,它们可能会过时并需要修订,这可能与测试针对最新版本的集成并更新文档中的兼容性部分一样简单,也可能意味着重构代码以使其与最新版本一起使用。例如,Ceph 模块最近已更新以支持最新版本,该版本具有完全不同的指标收集方式。为了适应模块中的旧版本和新版本,在模块中专门为较新版本创建了度量集,并在文档中注明了要使用的度量集。

更新的配置默认值编辑

集成包应提供有意义的默认值,例如收集间隔(周期)、启用的度量集以及任何其他特定于集成的配置参数。在大多数情况下,用户选择使用默认值。因此,提供相关的默认值对于集成的实用性至关重要。此外,集成应通过提供可以涵盖 80% 的用例的默认值来努力提供一键式体验。

更新的文档编辑

集成包应提供一致且全面的文档。有关更多详细信息,请参阅 文档指南

更新的集成内容编辑

集成包应提供开箱即用的仪表板。有关更多详细信息,请参阅 仪表盘指南

elastic.co/integrations 的内容编辑

每个集成都将在公共网站 elastic.co/integrations 上列出,而软件包注册表将作为真相来源。因此,文档和屏幕截图应为高质量以展示集成。请确保使用 svg 作为徽标,并使用 png 作为所有其他图像。应仔细审查任何其他品牌材料,例如

  • 徽标格式和质量
  • 使用徽标和商标的权限

精选用户体验编辑

建议在 Fleet 中设置集成策略。每个集成和代理都应在 Fleet 中可见,用户应能够直接从集成列表中添加集成。这将带来更好的凝聚力,因为它提供了跨集成的统一体验,允许用户一次添加多个集成,并避免在多个应用程序之间来回切换。它还允许用户在列表中发现新的集成。

Elastic 产品还将可以选择为难以放入 Fleet 的设置提供精选的 UI。产品可以决定他们希望在直接从 Fleet 中更改配置时提供多少灵活性。这将取决于用例以及是否有意义。不过,建议进行一定程度的配置。

资产标记和元数据编辑

当通过 Fleet 安装资产时,默认情况下会添加一些元数据。

对于 Elasticsearch 资产(如索引模板和摄取管道),一个 _meta 属性将添加到资产中,如下所示

{
  "managed_by": "fleet",
  "managed": true,
  "package": {
    "name": "<package name>"
  }
}

对于 Kibana 资产,除了 _meta 属性之外,还会生成 标签

  • 一个名为 name 匹配软件包 title 属性的标签
  • The managed tag, which Kibana uses to recognize "system" assets, or those that are installed by Kibana itself instead of generated by an end user