Только что понял это, и я верю, что это дает правильные результаты. Вы должны использовать правила записи, потому что вы не можете создать вектор диапазона из результата вектора экземпляра функции в одном запросе, как вы уже обнаружили (вы получаете ошибку разбора). Поэтому мы записываем результат функции (который будет вектором экземпляра) в качестве нового временного ряда и используем его в качестве имени метрики в другом запросе, где вы можете затем добавить [5d], чтобы выбрать диапазон.
Мы запускаем наши тесты несколько раз в минуту для всех наших сервисов, и каждый сервис («сервис» - это метка, имя каждого сервиса - это значение метки) имеет разное количество тестов, связанных с ним, но если какой-либо из Тесты для данного сервиса не пройдены, мы считаем это «моментом сбоя». (Количество неудачных тестов для данной службы фиксируется в метриках со значением метки status="failure".) Мы фиксируем количество неудачных попыток равным 1, поэтому у нас есть только нули и единицы для наших значений и, следовательно, мы можем преобразовать значения ошибок Временные ряды "в" успешные значения временных рядов "вместо этого, используя оператор неравенства и модификатор bool. (См. этот пост для обсуждения использования bool.) Таким образом, результат первой записанной метрики равен 1 для каждой службы, где все ее тесты были успешными в течение этого интервала очистки, и 0, где было по крайней мере один тестовый сбой для этой службы.
Если количество сбоев для службы> 0 для всех значений, возвращаемых за любую данную минуту, мы считаем, что эта служба «не работает» на эту минуту. (Таким образом, если у нас есть как сбой, так и успех в данную минуту, это не считается временем простоя.) Вот почему у нас есть вторая записанная метрика для получения фактических логических значений «для этой минуты». Вторая записанная метрика основана на первой, что нормально, поскольку в документации Prometheus говорится, что записанные метрики выполняются последовательно в каждой группе.
Таким образом, «время безотказной работы» для любой заданной длительности представляет собой сумму значений «для этой минуты» (т. Е. 1 для каждой минуты вверх), деленное на общее количество минут в продолжительности, независимо от того, какой бы длительностью она ни была.
Так как мы определили записанную метрику с именем "minute_up_bool", мы можем затем создать график времени безотказной работы в любом диапазоне, который мы хотим. (Кстати, записанные метрики генерируются только для времен после их первого определения, поэтому вы не получите вчерашние данные временных рядов, включенные в записанную метрику, которую вы определили сегодня.) Вот запрос, который вы можете поместить в Grafana, чтобы показать% времени безотказной работы над скользящее окно последних 5 дней:
sum_over_time(minute_up_bool[5d]) * 100 / (5 * 24 * 60)
Итак, это наша конфигурация правил записи:
groups:
- name: uptime
interval: 1m
# Each rule here builds on the previous one.
rules:
# Get test results as pass/fail => 1/0
# (label_replace() removes confusing status="failure" label value)
- record: test_success_bool
expr: label_replace(clamp_max(test_statuses_total{status="failure"}, 1), "status", "", "", "") != bool 1
# Get the uptime as 1 minute range where the sum of successes is not zero
- record: minute_up_bool
expr: clamp_max(sum_over_time(test_success_bool[1m]), 1)