作者来自 Elastic Daniel Rubinstein一眼看清数千个用户群组的趋势无需离开你的工作流程。ES|QL 全新的 SPARKLINE 函数可以将聚合结果转换为趋势线。每行一个数组零操作成本。亲自体验 Elasticsearch深入了解我们在 Elasticsearch Labs 仓库 中提供的示例笔记本开始 免费云试用或者立即在你的 本地机器 上试用 Elastic。当你运行STATS ... BY查询并得到几十个或数百个结果时日志模式、主机、服务、状态码单纯的计数并不能告诉你这些数据在一段时间内发生了什么变化。错误数量或日志模式是在不断增加还是正在趋于稳定它是否处于通常的范围内要回答这些问题目前你要么构建一个单独的时间序列可视化要么凭肉眼观察数字然后祈祷结果是正确的。对于本应该一眼就能看清的事情来说这可能需要付出大量精力和时间还要不断切换上下文。在这篇博客中我们将介绍 Elasticsearch 查询语言ES|QL的 SPARKLINE 是如何工作的、它能做什么以及如何开始使用。工作原理SPARKLINE 是一个 ES|QL 聚合函数其签名非常简单SPARKLINE(aggregation, key, buckets, from, to)aggregation计算 y 轴值的表达式包括任何受支持的聚合COUNT(*)、SUM(bytes)、AVG(latency)或其他聚合。key用于生成分桶的日期表达式。buckets目标分桶数量。from/to时间范围的边界。在 Kibana 中它们通过查询参数与时间选择器绑定。在底层SPARKLINE 会对时间范围进行分桶计算每个分桶中的聚合值并将结果打包成一个有序数组。空分桶会填充为零因此每个用户群组都共享相同的 x 轴网格从而可以快速、轻松地进行可视化比较。该函数可以很自然地与STATS ... BY组合使用因此你可以将它与任意分组结合起来。Sparkline 大显身手的地方你首先会在 Discover 的日志模式分析中看到 SPARKLINE 发挥作用从 9.5 开始。当你运行CATEGORIZE查询时Discover 会在后台构建 SPARKLINE 查询并在每个模式旁边渲染趋势线。在这里你不需要自己编写SPARKLINE当你在 ES|QL 编辑器中使用 “identify patterns/识别模式” 选项时Discover 会自动处理这些操作。结果非常直观你可以扫描几十种日志模式并立即看到哪些模式此刻正在激增而哪些模式一整天都保持稳定。下面是后台实际使用的查询FROM app-logs-* | WHERE timestamp ?_tend AND timestamp ?_tstart | STATS count COUNT(*), sparkline SPARKLINE(COUNT(*), timestamp, 50, ?_tstart, ?_tend) BY pattern CATEGORIZE(message) | SORT count DESC设想一个平台团队正在调查如何降低日志成本。他们让 Discover 对数千万个文档进行分析并使用CATEGORIZE将这些文档聚类成不同的模式。其中有两种模式脱颖而出类似 “正在获取资源……” 和 “已完成资源……” 这样的详细生命周期消息每种消息都有数百万次命中。这些行旁边的 sparkline 则揭示了剩下的故事全天候持续、平稳的日志流。不是由故障事件驱动的。也不是突发性的。只是持续不断的噪声在悄无声息地消耗数百 TB 的存储空间。像这种情况解决方法通常很直接调整日志级别在摄取时丢弃该模式或者将其路由到成本更低的层级。一直以来真正困难的部分都是找到它。借助 ES|QL 中的日志模式分析和内联 sparkline这种发现过程只需要几秒钟而不是几个小时。Elastic 内部的网站可靠性工程SRE团队经常成功使用日志模式分析并充分利用 ES|QL 的各种增强功能。这些只是一些具体示例。按区域拆分请求数量看看哪些区域呈上升趋势。比较不同容器 ID 之间的延迟。按消费者群组监控队列深度。应用场景几乎无穷无尽。简单的设计我们有意让 SPARKLINE 保持专注它是一个聚合函数而不是一条新命令。它可以与现有的STATS ... BY语法组合使用因此在结构上没有什么新的东西需要学习。**它返回消费者可以在上下文中进行渲染的数据。**该函数生成一个值数组。这些值具体如何渲染可以是 Discover 中的迷你图表、notebook 中的折线或者 API 响应中的 JSON 数组这取决于消费者。**它会填充空桶。**每个分组都会获得数量相同的值并与相同的时间网格对齐。这是经过刻意设计的当你可以一眼比较各行之间的形状时sparkline 最有用而这需要保持一致的对齐方式。模式始终相同一条查询、多个趋势线、即时可视化排查。下一步SPARKLINE 在 Elasticsearch 9.5 中以技术预览形式提供。未来的工作包括在更多 ES|QL 使用界面中渲染 sparkline不再局限于最初与 Kibana 中CATEGORIZE上下文的集成。这包括仪表板也包括 Elastic Observability 中的以下应用场景在应用性能监控APM工作流中工程师经常分析速率、错误和持续时间RED指标以了解服务健康状况。挑战在于聚合后的数字会隐藏维度上的异常值。一个服务整体看起来可能很健康但某个区域、某个容器或者某个新部署的版本可能正在悄悄恶化。目前Elastic APM UI 允许你按事务名称拆分指标但根因分析需要按照任意维度进行切分可用区、服务版本、容器 ID、云区域。SPARKLINE 可以让这一过程变得切实可行。按service.version拆分错误率就可以立即看到哪个版本的趋势线偏离了其他版本。开始使用SPARKLINE 在 Elasticsearch 9.5 中以技术预览形式提供。你可以通过 ES|QL _query API 或 Kibana 的 Discover 进行尝试。完整的语法和支持的类型请参阅SPARKLINE 函数参考。本文所述任何功能或特性的发布时间和时间安排均由 Elastic 自行决定。目前尚未提供的任何功能或特性可能无法按时交付也可能根本不会交付。原文Introducing SPARKLINE in ES|QL: Spot trends at a glance | Elasticsearch Labs
在 ES|QL 中引入 SPARKLINE：一眼看清趋势
作者来自 Elastic Daniel Rubinstein一眼看清数千个用户群组的趋势无需离开你的工作流程。ES|QL 全新的 SPARKLINE 函数可以将聚合结果转换为趋势线。每行一个数组零操作成本。亲自体验 Elasticsearch深入了解我们在 Elasticsearch Labs 仓库 中提供的示例笔记本开始 免费云试用或者立即在你的 本地机器 上试用 Elastic。当你运行STATS ... BY查询并得到几十个或数百个结果时日志模式、主机、服务、状态码单纯的计数并不能告诉你这些数据在一段时间内发生了什么变化。错误数量或日志模式是在不断增加还是正在趋于稳定它是否处于通常的范围内要回答这些问题目前你要么构建一个单独的时间序列可视化要么凭肉眼观察数字然后祈祷结果是正确的。对于本应该一眼就能看清的事情来说这可能需要付出大量精力和时间还要不断切换上下文。在这篇博客中我们将介绍 Elasticsearch 查询语言ES|QL的 SPARKLINE 是如何工作的、它能做什么以及如何开始使用。工作原理SPARKLINE 是一个 ES|QL 聚合函数其签名非常简单SPARKLINE(aggregation, key, buckets, from, to)aggregation计算 y 轴值的表达式包括任何受支持的聚合COUNT(*)、SUM(bytes)、AVG(latency)或其他聚合。key用于生成分桶的日期表达式。buckets目标分桶数量。from/to时间范围的边界。在 Kibana 中它们通过查询参数与时间选择器绑定。在底层SPARKLINE 会对时间范围进行分桶计算每个分桶中的聚合值并将结果打包成一个有序数组。空分桶会填充为零因此每个用户群组都共享相同的 x 轴网格从而可以快速、轻松地进行可视化比较。该函数可以很自然地与STATS ... BY组合使用因此你可以将它与任意分组结合起来。Sparkline 大显身手的地方你首先会在 Discover 的日志模式分析中看到 SPARKLINE 发挥作用从 9.5 开始。当你运行CATEGORIZE查询时Discover 会在后台构建 SPARKLINE 查询并在每个模式旁边渲染趋势线。在这里你不需要自己编写SPARKLINE当你在 ES|QL 编辑器中使用 “identify patterns/识别模式” 选项时Discover 会自动处理这些操作。结果非常直观你可以扫描几十种日志模式并立即看到哪些模式此刻正在激增而哪些模式一整天都保持稳定。下面是后台实际使用的查询FROM app-logs-* | WHERE timestamp ?_tend AND timestamp ?_tstart | STATS count COUNT(*), sparkline SPARKLINE(COUNT(*), timestamp, 50, ?_tstart, ?_tend) BY pattern CATEGORIZE(message) | SORT count DESC设想一个平台团队正在调查如何降低日志成本。他们让 Discover 对数千万个文档进行分析并使用CATEGORIZE将这些文档聚类成不同的模式。其中有两种模式脱颖而出类似 “正在获取资源……” 和 “已完成资源……” 这样的详细生命周期消息每种消息都有数百万次命中。这些行旁边的 sparkline 则揭示了剩下的故事全天候持续、平稳的日志流。不是由故障事件驱动的。也不是突发性的。只是持续不断的噪声在悄无声息地消耗数百 TB 的存储空间。像这种情况解决方法通常很直接调整日志级别在摄取时丢弃该模式或者将其路由到成本更低的层级。一直以来真正困难的部分都是找到它。借助 ES|QL 中的日志模式分析和内联 sparkline这种发现过程只需要几秒钟而不是几个小时。Elastic 内部的网站可靠性工程SRE团队经常成功使用日志模式分析并充分利用 ES|QL 的各种增强功能。这些只是一些具体示例。按区域拆分请求数量看看哪些区域呈上升趋势。比较不同容器 ID 之间的延迟。按消费者群组监控队列深度。应用场景几乎无穷无尽。简单的设计我们有意让 SPARKLINE 保持专注它是一个聚合函数而不是一条新命令。它可以与现有的STATS ... BY语法组合使用因此在结构上没有什么新的东西需要学习。**它返回消费者可以在上下文中进行渲染的数据。**该函数生成一个值数组。这些值具体如何渲染可以是 Discover 中的迷你图表、notebook 中的折线或者 API 响应中的 JSON 数组这取决于消费者。**它会填充空桶。**每个分组都会获得数量相同的值并与相同的时间网格对齐。这是经过刻意设计的当你可以一眼比较各行之间的形状时sparkline 最有用而这需要保持一致的对齐方式。模式始终相同一条查询、多个趋势线、即时可视化排查。下一步SPARKLINE 在 Elasticsearch 9.5 中以技术预览形式提供。未来的工作包括在更多 ES|QL 使用界面中渲染 sparkline不再局限于最初与 Kibana 中CATEGORIZE上下文的集成。这包括仪表板也包括 Elastic Observability 中的以下应用场景在应用性能监控APM工作流中工程师经常分析速率、错误和持续时间RED指标以了解服务健康状况。挑战在于聚合后的数字会隐藏维度上的异常值。一个服务整体看起来可能很健康但某个区域、某个容器或者某个新部署的版本可能正在悄悄恶化。目前Elastic APM UI 允许你按事务名称拆分指标但根因分析需要按照任意维度进行切分可用区、服务版本、容器 ID、云区域。SPARKLINE 可以让这一过程变得切实可行。按service.version拆分错误率就可以立即看到哪个版本的趋势线偏离了其他版本。开始使用SPARKLINE 在 Elasticsearch 9.5 中以技术预览形式提供。你可以通过 ES|QL _query API 或 Kibana 的 Discover 进行尝试。完整的语法和支持的类型请参阅SPARKLINE 函数参考。本文所述任何功能或特性的发布时间和时间安排均由 Elastic 自行决定。目前尚未提供的任何功能或特性可能无法按时交付也可能根本不会交付。原文Introducing SPARKLINE in ES|QL: Spot trends at a glance | Elasticsearch Labs
