【问题标题】:Spring Boot Actuator 'http.server.requests' metric MAX timeSpring Boot Actuator 'http.server.requests' 度量 MAX 时间
【发布时间】:2019-01-01 03:04:33
【问题描述】:

我有一个 Spring Boot 应用程序,我正在使用 Spring Boot Actuator 和 Micrometer 来跟踪有关我的应用程序的指标。我特别关注“http.server.requests”指标和 MAX 统计数据:

{
    "name": "http.server.requests",
    "measurements": [
        {
            "statistic": "COUNT",
            "value": 2
        },
        {
            "statistic": "TOTAL_TIME",
            "value": 0.079653001
        },
        {
            "statistic": "MAX",
            "value": 0.032696019
        }
    ],
    "availableTags": [
        {
            "tag": "exception",
            "values": [
                "None"
            ]
        },
        {
            "tag": "method",
            "values": [
                "GET"
            ]
        },
        {
            "tag": "status",
            "values": [
                "200", 
                "400"

            ]
        }
    ]
}

我认为 MAX 统计数据是执行请求的最长时间(因为我提出了两个请求,所以它是其中一个请求的较长处理时间)。

每当我按任何标签过滤指标时,例如localhost:9090/actuator/metrics?tag=status:200

{
        "name": "http.server.requests",
        "measurements": [
            {
                "statistic": "COUNT",
                "value": 1
            },
            {
                "statistic": "TOTAL_TIME",
                "value": 0.029653001
            },
            {
                "statistic": "MAX",
                "value": 0.0
            }
        ],
        "availableTags": [
            {
                "tag": "exception",
                "values": [
                    "None"
                ]
            },
            {
                "tag": "method",
                "values": [
                    "GET"
                ]
            }
        ]
    }

我总是得到 0.0 作为最大时间。这是什么原因?

【问题讨论】:

    标签: spring spring-boot metrics spring-boot-actuator micrometer


    【解决方案1】:

    MAX 表示执行端点所花费的最长时间。

    分析/user/asset/getAllAssets

    COUNT  TOTAL_TIME  MAX
    5      115         17
    6      122         17  (Execution Time = 122 - 115 = 17)
    7      131         17  (Execution Time = 131 - 122 = 17)
    8      187         56  (Execution Time = 187 - 131 = 56)  
    9      204         56  From Now MAX will be 56 (Execution Time = 204 - 187 = 17)  
    

    • 如果我们对特定端点的请求数量较少(或 1 个请求),MAX 是否会为 0?

    没有特定端点的请求数不会影响 MAX (请参阅 Spring Boot Admin 的图像)


    • 当 MAX 为 0 时

    Timer 将值设置为 0。当端点没有被调用或执行一段时间 Timer 将 MAX 设置为 0。这里 近似的计时器值是 2 到 2.30 分钟(120 到 150 秒)

    DistributionStatisticConfig 具有.expiry(Duration.ofMinutes(2)),如果在最后 2 分钟(120 秒)内没有请求,则将一些测量设置为 0

    public TimeWindowMax(Clock clock,...)private void rotate() 等方法 Clock 接口已为此编写。你可能会看到实现here


    • 如何确定计时器值?

    为此,我采集了 6 个样本(在同一端点执行了 6 次)。为此,我已经确定了调用端点时间之间的时间差 - MAX 设置回零的时间


    MAX 属性属于enum Statistic,由Measurement 使用 (在测量中我们得到 COUNT、TOTAL_TIME、MAX)

    公共静态最终统计MAX

    记录的最大数量。当这代表一个时间时,它是 以监控系统的基本时间单位报告。


    注意事项: 这是特定端点(此处为/actuator/metrics/http.server.requests?tag=uri:/user/asset/getAllAssets)的指标的情况。

    对于actuator/metrics/http.server.requests的泛化度量

    由于计时器,某些端点的 MAX 将设置为 0。在我看来,/http.server.requests 的 MAX 将与特定端点相同。


    更新

    The document 已针对 MAX 进行了更新。

    注意:基本DistributionSummary 实现的最大值,例如 CumulativeDistributionSummary, StepDistributionSummary 是一个时代 窗口最大值 (TimeWindowMax)。这意味着它的值是最大值 时间窗口内的值。如果时间窗口结束,它将被重置为 0 和一个新的时间窗口再次开始。时间窗口大小将是 仪表注册表的步长,除非到期 DistributionStatisticConfig 明确设置为其他值。

    【讨论】:

      【解决方案2】:

      您可以使用根/actuator/metrics/http.server.requests 调用响应中定义的?tag=url:{endpoint_tag} 查看各个指标。 measurements 值的详细信息是;

      • COUNT:每秒调用次数。
      • TOTAL_TIME:记录的时间总和。以监控系统的基本时间单位报告
      • MAX:记录的最大金额。当这表示一个时间时,它以监控系统的基本时间单位报告。

      如给定here,也是here


      您看到的差异是由于存在计时器造成的。这意味着在当前为任何标记指标定义的MAX 值一段时间后可以重置回0。您能否向端点添加一些新调用,然后立即调用 /actuator/metrics/http.server.requests 以查看给定标签的非零 MAX 值?

      这是由于为每个较小的时期获取 MAX 指标背后的想法。当您看到这些指标时,您将能够获得一组MAX 值,而不是很长一段时间内的单个值。

      您可以在 Micrometer 源代码中看到这一点。有一个 rotate() 方法专注于重置 MAX 值以创建上述行为。

      您可以看到每个poll() 调用都会调用它,每隔一段时间就会触发一次以收集指标。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2019-11-22
        • 2019-06-21
        • 1970-01-01
        • 1970-01-01
        • 2016-06-01
        • 1970-01-01
        • 2016-06-19
        • 1970-01-01
        相关资源
        最近更新 更多