Какой тип агрегирования метрик Azure возвращает десятичные значения?

Я использую метрики Azure для оценки работоспособности моего ресурса Azure, собирая его тип агрегирования по умолчанию для каждой метрики ресурса. Я вижу, что класс MetricValue в пространстве имен Microsoft.Azure.Management.Monitor.Fluent.Models SDK вернет значение типа double для всех типов агрегирования.

namespace Microsoft.Azure.Management.Monitor.Fluent.Models
{
    public class MetricValue
    {
        public MetricValue();
        public MetricValue(DateTime timeStamp, double? average = null, double? minimum = null, double? maximum = null, double? total = null, double? count = null);

        public DateTime TimeStamp { get; set; }
        public double? Average { get; set; }
        public double? Minimum { get; set; }
        public double? Maximum { get; set; }
        public double? Total { get; set; }
        public double? Count { get; set; }
        public virtual void Validate();
    }
}

У меня такой вопрос (учитывая двойной тип данных): есть ли на самом деле шансы, что все метрики Azure всех служб вернут десятичные значения? Я вижу, что количество сообщений в метрике служебной шины иногда возвращает десятичные значения. Я не нахожу конкретных документов, связанных с моим вопросом, которые можно было бы прояснить. Спасибо.


azure .net c# azure-monitoring azure-functions
person Deepak    schedule 21.10.2020    source источник
comment
Вы спрашиваете, почему Microsoft решила использовать десятичную дробь для счетчика? ?   -  person Caius Jard    schedule 21.10.2020
comment
У меня вопрос: действительно ли все метрики всех служб Azure возвращают десятичное значение? Я не думаю, что мы получаем десятичное значение для метрики запросов функции Azure. Но указанный тип данных двойной для всех типов агрегации.   -  person Deepak    schedule 21.10.2020

Ответы (1)


arrow_upward
1
arrow_downward

Поскольку метрика может быть чем угодно, а MetricValue - это общий общий тип / схема, которая должна обслуживать все виды метрик, некоторые из которых требуют максимально возможной точности, очень высоких или низких значений (+ ve или -ve), а также должны сохраняться в базовом общее хранилище данных (например, Azure Monitor). Теперь, хотя некоторые метрики могут быть целыми в зависимости от единицы в контексте (например, когда вы говорите, что мой запрос занял 300 миллисекунд), некоторые могут не быть (например, на диске доступно 20,57 ГБ свободного места). И помните, помимо встроенных метрик Azure, из вашего приложения могут быть пользовательские метрики, которые, возможно, могут быть чем угодно, о которых вы мечтаете. Итак, чтобы обеспечить достаточно высокую точность, double - это выбор. Это объясняет Среднее, Минимальное, Максимальное, Итоговое. Но тогда почему Count также double, я не совсем уверен, но, скорее всего, чтобы разместить сверхвысокое число на всякий случай, и мы не исчерпаны int или long. Или это может быть счет в пределах временного окна, которое может быть десятичным (10,6 запроса в минуту).

person krishg    schedule 22.10.2020
comment
Я получаю количество сообщений в виде десятичного числа, например 10,68. Итак, могу ли я рассмотреть возможность использования целочисленной метрики, которая, как мы ожидаем, может быть и десятичной? В вашем примере вы говорите, что запрос составляет 300 миллисекунд. Поскольку счетчик представляется в десятичном формате, есть ли способ, которым запрос также может быть возвращен в виде десятичного значения? - person Deepak; 23.10.2020
comment
это может быть счет в пределах временного окна, которое может быть десятичным (10,6 запроса в минуту). Какой у вас запрос журнала? - person krishg; 23.10.2020
comment
Вот справочная ссылка, которую я использовал для получения метрики: docs.microsoft.com/en-us/samples/azure-samples/ - person Deepak; 23.10.2020
comment
Хорошо, я думаю, это потому, что в запросе есть временное зерно, такое как «timeGrain eq duration'PT5M», что означает подсчет каждые 5 минут, который может быть десятичным (10,68 запросов за 5 минут) на основе расчета за больший период. - person krishg; 23.10.2020