Elastic Stack 为不同的用户提供了许多宝贵的见解。开发人员对低级指标和调试信息感兴趣。 SRE 对同时查看所有内容并确定根本原因感兴趣。管理人员希望获得报告,告诉他们服务性能如何以及服务级别协议 (SLA) 是否得到满足。在这篇文章中,我们将重点关注服务方面,并概述如何计算 SLA。
从 8.8 版开始,我们内置了计算 SLO 的功能 — 查看我们的指南!
SLA 计算的基础
计算和衡量 SLA 的方法有很多。最重要的部分是 SLA 的定义,作为一名顾问,我见过许多不同的方法。一些例子包括
- HTTP 2xx 的数量必须高于所有 HTTP 状态的 98%
- 成功 HTTP 2xx 请求的响应时间必须低于 x 毫秒
- 合成监控器必须至少保持 99% 的正常运行时间
- 计费服务的所有批处理交易的 95% 需要在 4 秒内完成
根据数据的来源,计算 SLA 可能更容易或更难。对于正常运行时间(合成监控),我们自动提供 SLA 值并提供开箱即用的警报,以便在过去 1 小时内可用性低于 98% 时简单地定义警报。
我个人建议尽可能使用 Elastic 合成监控 来监控服务性能。运行 HTTP 请求并验证来自服务的响应,或者执行完整的浏览器监控并像真实用户一样点击网站,可以更好地了解服务的健康状况。
有时这是不可能的,因为您想计算不提供任何 TCP 端口或 HTTP 交互的特定 Windows 服务的正常运行时间。这里需要注意的是,仅仅因为服务正在运行,并不一定意味着服务运行良好。
转换来救援
我们已经确定了我们的重要服务。在我们的例子中,它是 Steam 客户端助手。有两种方法可以解决这个问题。
Lens 公式
您可以使用 Lens 和公式(有关公式的深入探讨,查看此博客)。使用搜索栏筛选您想要的数据。然后在 Lens 中使用公式选项。我们将所有状态为“运行”的记录数量除以记录的总数。当需要快速计算和动态计算时,这是一个不错的解决方案。
count(kql='windows.service.state: "Running" ')/count()
使用上面发布的公式作为条形图的纵轴计算正常运行时间百分比。我们使用注释来标记下降的原因以及此服务低于阈值的原因。注释设置为“重启”,表示发生了重启,因此服务暂时停止。最后,我们添加一条参考线并将其设置为我们定义的 98% 阈值。这确保了快速查看可视化效果可以让我们的眼睛判断我们是在阈值之上还是之下。
转换
如果我不只对一项服务感兴趣,而是 SLA 需要多项服务呢?这就是转换可以解决此问题的地方。此外,第二个问题是此数据仅在 Lens 中可用。因此,我们无法在此基础上创建任何警报。
转到转换并创建一个透视转换。
-
添加以下过滤器以将其缩小到仅服务数据集:data_stream.dataset: "windows.service"。如果您对特定服务感兴趣,您始终可以将其添加到搜索栏中,如果您想知道整个集群中特定远程管理服务是否已启动!
-
选择 data_histogram(@timestamp) 并将其设置为您选择的单位。默认情况下,Elastic Agent 每 60 秒仅收集一次服务状态。我将使用 1 小时。
-
选择 agent.name 和 windows.service.name。
- 现在我们需要定义一个聚合类型。我们将使用 windows.service.state 的 value_count。这只会计算有多少条记录具有此值。
-
将 value_count 重命名为 total_count。
-
再次添加 windows.service.state 的 value_count,并使用铅笔图标将其编辑为 terms,它会聚合为“运行”。
-
这将打开一个子聚合。再次选择 value_count(windows.service.state) 并将其重命名为 values。
-
现在,预览显示了具有任何状态的记录数量和“运行”状态的记录数量。
-
这里是最棘手的部分。我们需要编写一些自定义聚合来计算正常运行时间的百分比。单击编辑 JSON 配置旁边的复制图标。
-
在新标签页中,转到 Dev Tools。粘贴剪贴板中的内容。
-
按播放按钮或使用键盘快捷键 ctrl+enter/cmd+enter 并运行它。这将创建数据外观的预览。它应该会为您提供与表格预览中相同的信息。
-
现在,我们需要计算正常运行时间的百分比,这意味着执行一个桶脚本,我们将 running.values 除以 total_count,就像我们在 Lens 可视化中所做的那样。假设您将列命名为不同的名称或使用多个值。在这种情况下,您需要相应地进行调整。
"availability": {
"bucket_script": {
"buckets_path": {
"up": "running>values",
"total": "total_count"
},
"script": "params.up/params.total"
}
}
- 这是我的整个转换
POST _transform/_preview
{
"source": {
"index": [
"metrics-*"
]
},
"pivot": {
"group_by": {
"@timestamp": {
"date_histogram": {
"field": "@timestamp",
"calendar_interval": "1h"
}
},
"agent.name": {
"terms": {
"field": "agent.name"
}
},
"windows.service.name": {
"terms": {
"field": "windows.service.name"
}
}
},
"aggregations": {
"total_count": {
"value_count": {
"field": "windows.service.state"
}
},
"running": {
"filter": {
"term": {
"windows.service.state": "Running"
}
},
"aggs": {
"values": {
"value_count": {
"field": "windows.service.state"
}
}
}
},
"availability": {
"bucket_script": {
"buckets_path": {
"up": "running>values",
"total": "total_count"
},
"script": "params.up/params.total"
}
}
}
}
}
- Dev Tools 中的预览应该可以正常工作并完整。否则,您必须调试任何错误。大多数情况下,它是桶脚本和值的路径。您可能已将其称为“up”而不是“running”。这是我的预览。
{
"running": {
"values": 1
},
"agent": {
"name": "AnnalenasMac"
},
"@timestamp": "2021-12-07T19:00:00.000Z",
"total_count": 1,
"availability": 1,
"windows": {
"service": {
"name": "InstallService"
}
}
},
- 现在,我们只需在选择“编辑 JSON”后将桶脚本粘贴到转换创建 UI 中。它看起来像这样
- 为您的转换命名,设置目标索引,并持续运行它。选择此选项时,请确保不要使用 @timestamp。而是选择 event.ingested。我们的文档详细解释了这一点。
- 单击下一步并创建和启动。这可能需要一点时间,所以不用担心。
总而言之,我们现在已经创建了一个透视转换,使用桶脚本聚合来计算服务的运行时间百分比。有一个需要注意的地方,因为 Elastic Agent 默认情况下每 60 秒仅收集一次服务状态。服务可能恰好在收集时启动,并在几秒钟后停止。如果这一点非常重要且没有其他监控可能性,例如 Elastic Synthetics,您可能希望减少 Agent 端的收集时间,以便每 30 秒或 45 秒收集一次服务状态。根据您的阈值的重要性,您可以创建多个具有不同收集时间的策略。这确保了超重要的服务器可能每 10 秒收集一次服务状态,因为您需要尽可能多的粒度和保险来确保指标的正确性。对于您只想了解远程访问解决方案大部分时间是否已启动的普通工作站,您可能不介意每 60 秒收集一次指标。
创建转换后,您将获得一个额外的功能,即数据存储在索引中,类似于 Elasticsearch 中的方式。当您只进行可视化时,度量标准仅为此可视化计算,在其他任何地方都不可用。由于这现在是数据,因此您可以为喜爱的连接(Slack、Teams、Service Now、邮件等等众多选项供您选择)创建阈值警报。
可视化转换后的数据
创建的转换创建了一个名为 windows-service 的数据视图。我们首先要做的就是将 availability 字段的格式更改为百分比。这会自动告诉 Lens 需要将其格式化为百分比字段,因此您无需手动选择它以及进行计算。此外,在 Discover 中,您看到的不是 0.5,而是 50%。是不是很酷?对于持续时间(例如 event.duration,如果以纳秒为单位)也是如此!无需再进行动态计算,也无需考虑是否需要除以 1,000 或 1,000,000。
我们使用一个简单的 Lens 可视化视图来获取此视图,该视图在垂直轴上使用时间戳,最小间隔为 1 天,以及 availability 的平均值。不用担心,一旦转换完成,其他数据将被填充。我们可以使用值 0.98 添加参考线,因为我们的目标是服务的 98% 正常运行时间。
总结
这篇博文介绍了在 Elastic Observability 中计算特定数据集的 SLA 所需的步骤,以及如何将其可视化。使用这种计算方法为许多有趣的用例打开了大门。您可以更改桶脚本并开始计算销售数量和平均购物篮大小。有兴趣了解有关 Elastic Synthetics 的更多信息?请阅读我们的文档或查看我们的免费合成监控快速入门培训。