Philipp Kahr

监控服务性能：Elastic Observability 的 SLA 计算概述

Elastic Stack 为不同的用户提供了许多有价值的见解，例如关于服务性能以及是否满足服务级别协议 (SLA) 的报告。在本文中，我们将概述如何为 Elastic Observability 计算 SLA。

阅读 12 分钟
日志分析
Monitoring service performance: An overview of SLA calculation for Elastic Observability

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 Client Helper。有两种方法可以解决这个问题。

Lens 公式

您可以使用 Lens 和公式（有关公式的深入了解，请查看此博客）。使用搜索栏来筛选您想要的数据。然后使用 Lens 中的公式选项。我们将状态为“正在运行”的所有记录的计数除以记录的总计数。当需要快速且即时地进行计算时，这是一个很好的解决方案。

count(kql='windows.service.state: "Running" ')/count()

使用上面发布的公式作为条形图的纵轴来计算正常运行时间的百分比。我们使用注释来标记为什么会出现下降以及为什么此服务低于阈值。该注释设置为重新启动，这表示正在发生重新启动，因此该服务暂时关闭。最后，我们添加一条参考线，并将其设置为我们定义的 98% 的阈值。这确保了快速查看可视化效果可以使我们的眼睛判断我们是高于还是低于阈值。

转换

如果我不只对一项服务感兴趣，而是有多项服务需要用于 SLA，该怎么办？这就是转换可以解决这个问题的地方。此外，第二个问题是此数据仅在 Lens 中可用。因此，我们无法对此创建任何警报。

转到“转换”并创建一个透视转换。

  1. 添加以下过滤器以将其缩小到仅限服务数据集：data_stream.dataset: "windows.service"。如果您对特定服务感兴趣，您可以随时将其添加到搜索栏中，如果您想知道整个舰队中是否有特定的远程管理服务启动！

  2. 选择数据直方图(@timestamp) 并将其设置为您选择的单位。默认情况下，Elastic Agent 仅每 60 秒收集一次服务状态。我选择 1 小时。

  3. 同时选择 agent.name 和 windows.service.name。

  1. 现在我们需要定义一个聚合类型。我们将使用 windows.service.state 的 value_count。这只是计算有多少记录具有此值。

  1. 将 value_count 重命名为 total_count。

  2. 第二次添加 windows.service.state 的 value_count，然后使用铅笔图标将其编辑为 terms，该术语用于聚合正在运行的服务。

  1. 这将打开一个子聚合。再次选择 value_count(windows.service.state) 并将其重命名为 values。

  2. 现在，预览显示了具有任何状态的记录计数和正在运行的计数。

  1. 这里是棘手的部分。我们需要编写一些自定义聚合来计算正常运行时间的百分比。单击编辑 JSON 配置旁边的复制图标。

  2. 在新选项卡中，转到 Dev Tools。粘贴您在剪贴板中的内容。

  3. 按“播放”按钮或使用键盘快捷键 ctrl+enter/cmd+enter 并运行它。这将创建一个数据外观的预览。它应该为您提供与表格预览中相同的信息。

  4. 现在，我们需要计算正常运行的百分比，这意味着执行一个 bucket 脚本，其中我们将 running.values 除以 total_count，就像我们在 Lens 可视化中所做的那样。如果您以不同的方式命名列或使用多个值，则需要进行相应的调整。

"availability": {
        "bucket_script": {
          "buckets_path": {
            "up": "running>values",
            "total": "total_count"
          },
          "script": "params.up/params.total"
        }
      }
  1. 这是我的完整转换
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"
        }
      }
    }
  }
}
  1. Dev Tools 中的预览应该可以工作并且完整。否则，您必须调试任何错误。大多数时候，它是 bucket 脚本和值的路径。您可能将其称为 up 而不是 running。这是我的预览的样子。
{
  "running": {
    "values": 1
  },
  "agent": {
    "name": "AnnalenasMac"
  },
  "@timestamp": "2021-12-07T19:00:00.000Z",
  "total_count": 1,
  "availability": 1,
  "windows": {
    "service": {
      "name": "InstallService"
    }
  }
},
  1. 现在，我们只在选择“编辑 JSON”后将 bucket 脚本粘贴到转换创建 UI 中。它看起来像这样

  1. 为您的转换指定一个名称，设置目标索引，然后连续运行它。选择此选项时，请确保不要使用 @timestamp。而是选择 event.ingested。 我们的文档详细解释了这一点。

  1. 单击“下一步”并创建并启动。这可能需要一段时间，所以不要担心。

总而言之，我们现在创建了一个透视转换，使用桶脚本聚合来计算服务运行时间的百分比。这里有一个需要注意的地方，因为 Elastic Agent 默认情况下每 60 秒才收集一次服务状态。可能出现的情况是，服务在收集时正好处于运行状态，但在几秒钟后就宕机了。如果这非常重要，并且没有其他监控的可能性，例如Elastic Synthetics，您可能需要减少 Agent 端的收集时间，以每 30 秒或 45 秒获取一次服务状态。根据您的阈值有多重要，您可以创建多个具有不同收集时间的策略。这确保了非常重要的服务器可能每 10 秒收集一次服务状态，因为您需要尽可能高的粒度和指标正确性的保证。对于只想知道远程访问解决方案是否大部分时间都运行的普通工作站，您可能不介意每 60 秒只有一个指标。

创建转换后，您获得的另一个附加功能是，数据存储在索引中，类似于 Elasticsearch。当您只进行可视化时，指标仅针对此可视化计算，并且在其他任何地方都不可用。由于这现在是数据，您可以为最喜欢的连接（Slack、Teams、Service Now、Mail 等，更多选择）创建阈值警报。

可视化转换后的数据

转换创建了一个名为 windows-service 的数据视图。我们要做的第一件事是将可用性字段的格式更改为百分比。这会自动告诉 Lens 需要将此字段格式化为百分比字段，因此您无需手动选择它并进行计算。此外，在 Discover 中，您将看到 50% 而不是 0.5。是不是很酷？如果您的持续时间以纳秒为单位，这也适用于持续时间，例如 event.duration！不再需要即时计算并思考是否需要除以 1,000 或 1,000,000。

我们通过使用一个简单的 Lens 可视化来获得此视图，该可视化在垂直轴上使用时间戳，最小间隔为 1 天，可用性的平均值。不用担心，一旦转换完成，其他数据将被填充。我们可以使用值 0.98 添加参考线，因为我们的目标是服务 98% 的正常运行时间。

总结

这篇博客文章介绍了在 Elastic Observability 中计算特定数据集的 SLA 所需的步骤，以及如何将其可视化。使用这种计算方法，可以打开许多有趣的用例的大门。您可以更改桶脚本并开始计算销售额和平均购物篮大小。有兴趣了解有关 Elastic Synthetics 的更多信息吗？请阅读我们的文档或查看我们的免费Synthetic Monitoring Quick Start training。

分享这篇文章

XFacebookLinkedInReddit