Максимальное время метрики Spring Boot Actuator 'http.server.requests'

У меня есть приложение 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 в качестве максимального времени. В чем причина этого?


person Christina    schedule 24.07.2018    source источник


Ответы (2)


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)  

  • Будет ли MAX равным 0, если у нас будет меньше запросов (или 1 запрос) к конкретной конечной точке?

Никакое количество запросов для конкретной конечной точки не влияет на MAX (см. Изображение из Spring Boot Admin)


  • Когда MAX будет 0

Есть Timer, который устанавливает значение 0. Когда конечная точка не вызывается или не выполняется какое-то время, Timer устанавливает MAX в 0. Здесь приблизительное значение таймера составляет от 2 до 2.30 минут (от 120 до 150 секунд)

DistributionStatisticConfig имеет .expiry(Duration.ofMinutes(2)), который устанавливает для некоторого измерения значение 0, если запросы не выполнялись за последние 2 минуты (120 секунд )

Такие методы, как public TimeWindowMax(Clock clock,...), private void rotate() Clock был написан для того же. Вы можете увидеть реализацию здесь


  • Как я определил значение таймера?

Для этого я взял 6 образцов (выполнил одну и ту же конечную точку 6 раз). Для этого я определил разницу во времени между временем вызова конечной точки - время, когда MAX возвращается в ноль


MAX принадлежит enum Statistic, который используется Измерение (В измерении мы получаем COUNT, TOTAL_TIME, MAX)

общедоступная статическая окончательная статистика MAX

Максимальная записанная сумма. Когда это представляет собой время, оно указывается в базовой единице времени системы мониторинга.


Примечания. Это случаи из метрики для конкретной конечной точки (здесь /actuator/metrics/http.server.requests?tag=uri:/user/asset/getAllAssets).

Для обобщенной метрики actuator/metrics/http.server.requests

MAX для некоторой конечной точки будет сброшен на 0 из-за таймера. На мой взгляд, MAX для /http.server.requests будет таким же, как конкретная конечная точка.

введите здесь описание изображения


ОБНОВЛЕНИЕ

Документ обновлен для MAX.

ПРИМЕЧАНИЕ: Макс для базовых DistributionSummary реализаций, таких как CumulativeDistributionSummary, StepDistributionSummary - это максимальное время окна (TimeWindowMax). Это означает, что его значение является максимальным значением во временном окне. Если временное окно закончится, оно будет сброшено на 0, и снова начнется новое временное окно. Размер временного окна будет размером шага реестра счетчика, если для истечения срока в DistributionStatisticConfig явно не установлено другое значение.

person Patel Romil    schedule 29.07.2019

Вы можете увидеть отдельные показатели, используя ?tag=url:{endpoint_tag}, как определено в ответе на корневой вызов /actuator/metrics/http.server.requests. Подробная информация о значениях measurements:

  • COUNT: посекундная ставка для звонков.
  • TOTAL_TIME: сумма записанных времен. Сообщается в базовой единице времени системы мониторинга
  • MAX: максимальная зарегистрированная сумма. Когда это представляет собой время, оно указывается в базовой единице времени системы мониторинга.

Как указано здесь, также здесь.


Несоответствия, которые вы видите, связаны с наличием таймера. Это означает, что через некоторое время определенное в настоящее время MAX значение для любой помеченной метрики может быть сброшено обратно на 0. Можете ли вы добавить несколько новых вызовов к своей конечной точке, а затем немедленно выполнить вызов /actuator/metrics/http.server.requests, чтобы увидеть ненулевое MAX значение для данного тега?

Это связано с идеей получения метрики MAX для каждого меньшего периода. Когда вы видите эти показатели, вы сможете получить массив из MAX значений, а не одно значение в течение длительного периода времени.

Вы можете увидеть это в действии в исходном коде Micrometer. Существует _ 10_ метод, направленный на сброс значения MAX для создания описанного выше поведения.

Вы можете видеть, что это вызывается для каждого _ 12_, который запускается каждый определенный период для сбора метрики.

person buræquete    schedule 29.07.2019