Запрос метрики
Почему последняя временная метка результата находится в будущем?
В Ключ-АСТРОМ точки данных метрик хранятся во временных интервалах с разным разрешением. Наилучшая степень детализации временного интервала составляет одну минуту. Временные метки, возвращаемые конечной точкой запроса метрик, являются временем окончания этих временных интервалов.
Например, если текущее время — 09:24, и вы запрашиваете последние 6 часов с разрешением в 1 час, отметка времени последней точки данных будет сегодня в 10:00. Подробнее см . в примечании о временных рамках .
Почему возвращаемые значения увеличиваются на большем таймфрейме?
Точки данных, возвращаемые конечной точкой запроса, агрегируются по времени. В зависимости от временных рамок запроса разрешение точек данных может составлять минуты, часы, дни или даже годы. Если вы запрашиваете больший период времени, разрешение ваших данных, вероятно, будет более грубым, что приведет к увеличению значений для агрегаций, таких как sumили count.
Если вы хотите получить сопоставимые результаты для разных разрешений, используйте преобразование скорости . Например, :rate(1m)предоставляет вам значение в минуту.
Почему значение процентной метрики больше 100 % при использовании кратности?
Например, следующий запрос может возвращать значения выше 100 %, даже если единицей измерения является Percent.
builtin:host.availability:splitBy():avg:fold
Основная причина этой проблемы заключается в том, что при применении статистического преобразования (путем вызова :avgв приведенном выше примере) семантика метрики теряется и становится недоступной для преобразований, которые происходят позже в цепочке преобразований. То есть, когда вызывается кратное преобразование , информация о том, что значения должны быть усреднены, больше недоступна, и sumвместо этого применяется агрегация.
Чтобы предотвратить эту проблему, не выполняйте агрегацию перед преобразованием fold.
builtin:host.availability:splitBy():fold
Почему значение измерения равно нулю?
Если верхний x применяется к измерению метрики, сохраняются только значения x измерения. Все остальные значения измерения записываются в remainderизмерение, имеющее значение null.
Как я могу получить красивые имена для отслеживаемых объектов?
По умолчанию ответ на запрос содержит только идентификаторы отслеживаемых объектов (например, HOST-E1784F5E3F9987CD).
Если вы хотите, чтобы имя объекта также было в ответе, вам нужно использовать преобразование имен . Красивое имя затем доступно в dimensionMapключе размера dt.entity.<entityType>.name, например, dt.entity.host.name).
Почему результат выражения моей метрики пуст?
Существует несколько причин, по которым выражение метрики может привести к пустому результату:
- Ключи параметров показателей, используемых в выражении, не совпадают. Если у вас есть метрики с разными ключами измерений, вам необходимо выровнять измерения метрик, чтобы сделать возможным расчет. Для этой цели можно использовать преобразование « Разделить» или « Объединить ». Рассмотрим этот запрос:
builtin:host.cpu.iowait
/
builtin:host.disk.throughput.read
Это приведет к Metric expression contains non-matching dimension-keys.ошибке, потому что метрика builtin:host.cpu.iowait имеет только одно измерение ( dt.entity.host ), а встроенная: host.disk.throughput.read имеет два ( dt.entity.host и dt.entity .диск ). Чтобы запрос заработал, нужно избавиться от дискового измерения (например, с помощью преобразования слияния ).
builtin:host.cpu.iowait
/
builtin:host.disk.throughput.read:merge(dt.entity.disk)
Значения размеров не совпадают.
Например, следующее выражение даст пустой результат, потому что разные значения измерения не могут быть объединены.
builtin:host.cpu.iowait:filter(eq(dt.entity.host,HOST-001))
/
builtin:host.cpu.iowait:filter(eq(dt.entity.host,HOST-002))
Решением в этом случае является полное отбрасывание измерений с помощью преобразования splitBy .
builtin:host.cpu.iowait:filter(eq(dt.entity.host,HOST-001)):splitBy()
/
builtin:host.cpu.iowait:filter(eq(dt.entity.host,HOST-002)):splitBy()
Еще одна причина отсутствия совпадающих кортежей: применение предельного преобразования к операнду выражения может привести к отфильтровыванию совпадающих измерений. Всегда применяйте преобразование предела к результату выражения, а не к его операндам.
Рассмотрим следующий запрос, который пытается добавить 10 самых популярных периодов использования ЦП к 10 основным периодам простоя ЦП.
builtin:host.cpu.usage:sort(value(avg,descending)):limit(10)
+
builtin:host.cpu.idle:sort(value(avg,descending)):limit(10)
Если у вас большая среда с сотнями хостов, маловероятно, что 10 хостов с максимальной загрузкой ЦП входят в число 10 хостов с наибольшим временем простоя ЦП. У операндов не будет совпадающих кортежей, поэтому результат выражения будет пустым. Решение состоит в том, чтобы вместо этого применить ограничение к результату выражения:
( builtin:host.cpu.usage + builtin:host.cpu.idle ) :sort(value(auto,descending)) :limit(10)
Нет данных для метрики.
Рассмотрим этот пример выражения соотношения, где мы вычисляем коэффициент ошибок для ключевых действий пользователя:
builtin:apps.other.keyUserActions.reportedErrorCount.os
/
builtin:apps.other.keyUserActions.requestCount.os
Если запросов много, но ни одной ошибки на вашем таймфрейме, результат будет пустым, хотя коэффициент ошибок 0был бы более значимым. Вы можете добиться этого с помощью default(0)преобразования:
builtin:apps.other.keyUserActions.reportedErrorCount.os:default(0)
/
builtin:apps.other.keyUserActions.requestCount.os
Почему я могу применить агрегацию, которую метрика не поддерживает?
После выполнения пространственной агрегации с помощью преобразования « Разделить по» или « Слияние » к результату можно применить произвольное агрегирование.
Например, вы можете выполнить следующий запрос, даже если метрика изначально не поддерживает процентили.
builtin:host.cpu.user:splitBy("dt.entity.host"):percentile(50)
Однако, поскольку метрика имеет только одно измерение ( dt.entity.host ), никакие значения фактически не агрегируются по пространству. Следовательно, percentile(50)агрегирование даст тот же результат percentile(99), что и , поскольку в этом случае оценка процентиля основана только на одной точке данных.
Прием метрик
Почему моя принятая точка данных недоступна?
Существует несколько причин, по которым точка данных может быть недоступна. Попробуйте следующие решения.
- Убедитесь, что вы получили ответ с
202кодом состояния HTTP для конечной точки загрузки. - Может пройти несколько минут, прежде чем полученная точка данных станет доступной через REST API метрик и в обозревателе данных . Решение - подождать.
- Ключ-АСТРОМ версии 1.239+Используйте информационную панель Metric & Dimension Usage + Rejections , чтобы проверить, была ли точка данных отклонена на более позднем этапе. Точка данных могла быть принята конечной точкой приема, но позже отклонена из-за нарушения инварианта.
- Проверьте фильтры, которые вы используете. Точка данных может быть отфильтрована зоной управления или фильтром временного интервала.
Почему мои метрические ключи имеют суффикс «.count» или «.gauge»?
Метрики с разными типами полезной нагрузки не могут использовать один и тот же ключ. Следовательно:
countк метрикам автоматически добавляется суффикс,.countесли их ключ метрики уже не заканчивается на.countили_countgaugeметрикам автоматически добавляется суффикс.gauge, если их ключ заканчивается на.countили_count
Почему метаданные моей метрики не обновляются?
Вы можете записать метаданные метрики через протокол приема только в том случае, если он не был установлен ранее . Для обновления метаданных метрик необходимо использовать браузер метрик .
Почему отсутствует добавленное измерение?
Если вы принимаете измерение с пустым значением, весь кортеж измерения удаляется во время приема. Например, если вы принимаете myMetric,dimEmpty="" 1, измерение dimEmptyудаляется.