«История мониторинга» (GUI) и «Метры» (API и функция) связаны, но различаются.
Функция «Метры» является внутренней по отношению к серверу и собирает необработанные (обычно мелкие) данные, объединяет их ежечасно, ежедневно и ежемесячно «сворачивается», а также устаревает старые данные.ВСЕ данные хранятся в базе данных Meters в «простых» XML-файлах, но также индексируются уникальным способом с использованием индексации семантики.
Данные Meters предоставляются через прямой запрос к базе данных Meters или через набор открытых точек входа REST - реализация которых находится в простом источнике xquery в дереве установки, которое вы можете просмотреть.
Графический интерфейс «Monitorinig History» - это клиентское приложение, которое использует конечные точки общественного отдыха, а затем выполняет дальнейшую обработку на стороне клиента для представления различных представлений.Точные алгоритмы обработки не задокументированы, но код javascript также находится в «открытом тексте» для проверки.Не всегда очевидно, где на стороне клиента javascript выполняет дополнительную обработку данных по сравнению с вызовом конечных точек REST, а также точное отображение того, что вы видите, к запросам бэкэнда.
Если ваша цель - воспроизвести «необработанные» данные, я рекомендую обратиться к базе данных «Метры», которая является «источником правды» - насколько это возможно.Запрашиваемая конкретная проблема более тонкая.Не всегда возможно полностью воспроизвести поведение «сворачивания» из необработанных данных в базе данных измерителей в ежечасные, ежемесячные и т. Д. В основном это «прямое движение вперед», но внутренне существуют случаи, когда внутренние данные хранятся с большей точностью илис большим количеством переменных затем публикуются в БД, и этот внутренний набор данных используется для агрегаций / «сверток» - это означает, что математика не всегда работает точно так же.Кроме того, существуют внутренние «правила», применяемые к округлению до ближайшей минуты / часа / 5 минут и т. Д., Чтобы получить более согласованные результаты данных, но с побочным эффектом, что данные могут быть отброшены.Например, если сервер находится под большой нагрузкой, могут быть случаи, когда точное время выборок данных «округляется» до следующего периода и может неправильно представлять средние значения за этот период.Первый и последний неполный час непрерывной работы сервера могут не иметь воспроизводимых ежечасных сводок - т. Е. Если вы самостоятельно рассчитаете частичные периоды, вы можете не получить одинаковые ответы, поскольку временные метки были настроены таким образом, чтобы соответствовать четным периодам.Внутренние данные на сервере не выполняют такое «округление», их цель - облегчить написание кода клиентского приложения для получения разумных результатов.Есть дополнительные тонкости при попытке агрегировать на серверах в кластере (как это делает GUI).Не всегда очевидно, что метрики, такие как «IO Rate», означают при применении к кластеру - это SUM или Avarage для всего кластера?очень похоже на интерпретацию «Load Avarage» в многоядерной системе.
Из моего прочтения вашего вопроса я предлагаю вам использовать данные непосредственно из базы данных измерений в качестве «исходных» данных.Если вы начинаете с необработанных данных, то отбрасываете все «частичные данные» (данные, которые выходят за пределы начала и конца следующего более высокого свертывания) - т.е. если вы запускаете свой сервер в 5:53 - отбрасываете все необработанные данные до6:00, затем включите все необработанные данные с 6:00 до 7:00 - вы должны найти почти точное совпадение с почасовыми данными, записанными в 7:00 - при условии, что вы используете ВСЕ необработанные атрибуты в уравнении (мин., не более, сумма, ср, сУММЫ).В пределах точности округления они должны совпадать.
Использование API более высокого уровня может дать ответы, которые вы не ожидаете.Они не являются неправильными , но существует множество комбинаций параметров, которые имеют разные возможные значения - ошибки API не будут ошибаться только потому, что вы указали параметры, которые являются неоднозначными или противоречивыми.Вы можете сравнить эту стратегию с другими поставщиками сервисов метрик, такими как AWS CloudWatch - не все возможные комбинации параметров дают понятные результаты.Но необработанные данные, не подвергавшиеся насилию, от этого не страдают.
Кроме того, API REST интенсивно используют индексы для повышения эффективности.Индексы не имеют той же точности, что и данные XML, поэтому вы можете получить погрешности, связанные с точностью, в зависимости от точных значений - индексы используют 32-битные значения.В зависимости от версии сервера, данные XML могут использовать 32- или 64-битные значения, но индексы все еще усекаются до 32.
Если вам нужна точность, ИМХО, избегайте вывода JSON - из-за присущего JSONпроблема с числовой точностью.Это компенсировано в истории мониторинга, но это довольно утомительно.
Если вам нужна максимальная производительность запросов, DO использует конечную точку REST (либо XML, либо JSON) - она оптимизирована для выполнения запросов по различным типам запросов.Хотя это не приносит нам никакой «магии» - нелегко достичь той же производительности и точности непосредственно из данных счетчиков.Снова, посмотрите на код для конечных точек, все это в простом xquery для проверки, но это не «источник правды» для необработанных данных - его намерение предназначено для эффективных * агрегированных запросов временных рядов *, а не для максимальной точности.Почти для всех случаев это то, что вы хотите.