Elasticsearch 用于多种数据类型 —— 其中之一就是指标。 随着多年前 Metricbeat 的推出以及后来我们的 APM 代理的推出，指标用例变得更加流行。 多年来，Elasticsearch 在如何处理指标聚合和稀疏文档等方面做出了许多改进。 同时，引入了 TSVB 可视化，使指标可视化变得更加容易。 大多数其他指标解决方案都存在一个缺失的概念，即带维度的时间序列的概念。
2021 年年中，Elasticsearch 团队着手让 Elasticsearch 更适合指标。 该团队创建了时间序列数据流 (TSDS)，它在 8.7 中作为正式发布 (GA) 发布。
这篇博文深入探讨了 TSDS 的工作原理以及我们如何在 Elastic 可观察性中使用它，以及吧如何将它用于你自己的指标。
TSDS 快速介绍
时间序列数据流 (TSDS) 构建在 Elasticsearch 中针对时间序列优化的数据流之上。 要为指标创建数据流，需要对数据流进行额外设置。 当我们使用数据流时，首先必须创建一个索引模板：
PUT _index_template/metrics-laptop
{
"index_patterns": [
"metrics-laptop-*"
],
"data_stream": {},
"priority": 200,
"template": {
"settings": {
"index.mode": "time_series"
},
"mappings": {
"properties": {
"host.name": {
"type": "keyword",
"time_series_dimension": true
},
"packages.sent": {
"type": "integer",
"time_series_metric": "counter"
},
"memory.usage": {
"type": "double",
"time_series_metric": "gauge"
}
}
}
}
}让我们仔细看看这个模板。 在顶部，我们用 metrics-laptop-* 标记索引模式。 可以选择任何模式，但建议对所有指标使用数据流命名方案。 下一节设置 "index.mode": "time_series" 并确保它是一个 data_stream: "data_stream": {}。
维度
每个时间序列数据流至少需要一个维度。 在上面的示例中，host.name 被设置为维度字段，其中包含 "time_series_dimension": true。 默认情况下最多可以有 16 个维度。 并非每个维度都必须出现在每个文档中。 维度定义了时间序列。 一般规则是选择字段作为唯一标识你的时间序列的维度。 通常这是对主机/容器的唯一描述，但对于磁盘指标等某些指标，还需要磁盘 ID。 如果你对默认推荐的维度感到好奇，请查看此 ECS 贡献的维度属性。
减少存储并提高查询速度
此时，你已经拥有一个正常运行的时间序列数据流。 将索引模式设置为时间序列会自动打开合成源。 默认情况下，Elasticsearch 通常会复制数据三次：
- 面向行的存储（_source 字段）
- 面向列的存储（对于聚合 doc_values: true）
- 索引（对于过滤和搜索 index: true ）
对于合成（synthetic）源，_source 字段不会持久化； 相反，它是根据 doc values 重建的。 特别是在指标用例中，保留源代码几乎没有什么好处。
不存储它意味着存储量的显着减少。 时间序列数据流根据维度和时间戳对数据进行排序。 这意味着通常一起查询的数据存储在一起，从而加快了查询时间。 这也意味着单个时间序列的数据点并排存储在磁盘上。 由于计数器增加的速率通常相对恒定，因此可以进一步压缩数据。
指标类型
但要受益于 TSDS 的所有优势，指标字段的字段属性必须使用 time_series_metric: {type} 进行扩展。 支持多种类型 —— 例如，上面使用了 gauge 和 counter。 为 Elasticsearch 提供有关指标类型的知识允许 Elasticsearch 为不同类型提供更优化的查询并进一步减少存储使用。
当你在数据流命名方案下为数据流创建自己的模板时，设置 "priority": 200 或更高是很重要的，否则将应用内置的默认模板。
摄取文档
将文档提取到 TSDS 与将文档提取到 Elasticsearch 没有任何不同。 你可以在 Dev Tools 中使用以下命令添加文档，然后搜索它并检查映射。 注意：你必须将@timestamp 字段调整为接近你当前的日期和时间。
# Add a document with `host.name` as the dimension
POST metrics-laptop-default/_doc
{
# This timestamp neesd to be adjusted to be current
"@timestamp": "2023-03-30T12:26:23+00:00",
"host.name": "ruflin.com",
"packages.sent": 1000,
"memory.usage": 0.8
}
# Search for the added doc, _source will show up but is reconstructed
GET metrics-laptop-default/_search
# Check out the mappings
GET metrics-laptop-default如果你想为自己的文档添加一个当前机器运行的日期，你可以参考文章 “Elasticsearch：如何在写入文档时加上 now 时间标戳”。
如果你进行搜索，它仍会显示 _source 但这是根据 doc values 重建的。 上面添加的附加字段是 @timestamp。 这很重要，因为它是任何数据流的必填字段。
为什么这对可观察性很重要？
Elastic 可观察性解决方案的优势之一是在单个存储引擎中，所有信号都集中在一个地方。 用户可以一起查询日志、指标和跟踪，而无需从一个系统跳转到另一个系统。 正因为如此，拥有一个强大的存储和查询引擎不仅适用于日志而且适用于指标对我们来说很关键。
TSDS 在集成中的使用
通过集成（integrations），我们为用户提供了与他们的基础设施和服务集成的开箱即用体验。 如果你正在使用我们的集成，假设你使用的是 8.7 或更高版本，最终你将自动获得 TSDS 的所有指标优势。
目前我们正在处理我们的集成包列表，添加维度、指标类型字段，然后为指标数据流打开 TSDS。 这意味着一旦包启用了所有属性，你唯一要做的就是升级集成，其他一切都会在后台自动发生。
了解更多
如果你想详细了解 TSDS 的幕后工作原理和所有可用的配置选项，请查看 TSDS 文档。 Elasticsearch 在 8.7 中支持的只是 Elasticsearch 中指标时间序列的第一次迭代。 如果你切换到使用 TSDS，你将自动受益于 Elasticsearch 对指标时间序列所做的所有未来改进，无论是更高效的存储、查询性能还是新的聚合功能。
TSDS 从 8.7 开始就可以使用，并且会在集成升级时自动出现在我们越来越多的集成中。 你会注意到的是更低的存储使用量和更快的查询。 开心！