Как запросить Прометея в Ubuntu 14.04, часть 2

Prometheus - это система мониторинга с открытым исходным кодом и база данных временных рядов. В ссылке: / community / tutorials / how-to-query-prometheus-on-ubuntu-14-04-part-1 [Как запросить Prometheus в Ubuntu 14.04, часть 1], мы настроили три экземпляра демо-сервиса, выставляющие синтетические метрики для сервер Прометей. Используя эти метрики, мы затем узнали, как использовать язык запросов Prometheus для выбора и фильтрации временных рядов, как агрегировать по измерениям, а также как вычислять ставки и производные.

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

Этот учебник основан на настройке, описанной в ссылке: / community / tutorials / how-to-query-prometheus-on-ubuntu-14-04-part-1 [Как запросить Prometheus в Ubuntu 14.04, часть 1]. Как минимум, вам нужно будет выполнить шаги 1 и 2 из этого руководства, чтобы настроить сервер Prometheus и три контролируемых экземпляра демонстрационной службы. Тем не менее, мы также будем опираться на методы языка запросов, описанные в первой части, и, таким образом, рекомендуем полностью их проработать.

В этом разделе мы узнаем, как фильтровать возвращенные временные ряды на основе их значения.

Наиболее распространенное использование для фильтрации на основе значений - для простых числовых пороговых значений предупреждений. Например, мы можем захотеть найти пути HTTP, которые имеют более высокую общую скорость запроса состояния + 500 , чем 0,2 в секунду, усредненную за последние 15 минут. Чтобы сделать это, мы просто запрашиваем все частоты запросов ` 500 ` -статуса и затем добавляем оператор фильтра `> 0.2 +` в конце выражения:

В представлении * Console * результат должен выглядеть следующим образом:

изображение: https: //assets.digitalocean.com/articles/prometheus_querying/filter_rates_scalar.png [Фильтрация частоты запросов по скалярному номеру]

Однако, как и в случае с двоичной арифметикой, Прометей поддерживает не только фильтрацию по одному скалярному числу. Вы также можете отфильтровать один набор временных рядов на основе другого набора рядов. Опять же, элементы сопоставляются своими наборами меток, и оператор сопоставления применяется между соответствующими элементами. Только элементы с левой стороны, которые соответствуют элементу с правой стороны and, которые проходят фильтр, становятся частью вывода. Предложения + on (<метки>) +, + group_left (<метки>) +, + group_right (<метки>) + работают так же, как и в арифметических операторах.

Например, мы могли бы выбрать частоту + 500 + -статуса для любых комбинаций + job +, + instance +, + method + и + path +, для которых частота + 200 + -status равна по крайней мере, в 50 раз выше, чем + 500 + -статус состояния, как это:

Это будет выглядеть следующим образом:

изображение: https: //assets.digitalocean.com/articles/prometheus_querying/series.png [Фильтрация частоты запросов по другому набору серий]

Помимо +> +, Прометей также поддерживает обычные операторы сравнения +> = +, + ⇐ +, + <+, +! = + И + == + в фильтрации.

Теперь мы знаем, как фильтровать набор временных рядов на основе одного числового значения или другого набора значений временных рядов с соответствующими метками.

В этом разделе вы узнаете, как использовать операторы множеств Прометея для корреляции наборов временных рядов друг с другом.

Часто вы хотите отфильтровать один набор временных рядов на основе другого набора. Для этого Прометей предоставляет оператор множеств + и +. Для каждой серии на левой стороне оператора он пытается найти серию на правой стороне с одинаковыми метками. Если совпадение найдено, левый ряд становится частью выходных данных. Если справа нет соответствующих рядов, ряд исключается из выходных данных.

Например, вы можете выбрать любые конечные точки HTTP, которые имеют задержку 90-го процентиля выше 50 мс (0,05 с), но только для комбинаций измерений, которые получают более одного запроса в секунду. Мы будем использовать функцию + histogram_quantile () + для вычисления процентиля здесь. Мы объясним в следующем разделе, как именно эта функция работает. На данный момент имеет значение только то, что он рассчитывает задержку 90-го процентиля для каждого подразмера. Чтобы отфильтровать возникающие плохие задержки и сохранить только те, которые получают более одного запроса в секунду, мы можем запросить:

изображение: https: //assets.digitalocean.com/articles/prometheus_querying/intersection.png [Фильтрация скорости запросов по пересечению]

Вместо пересечения иногда требуется создать объединение из двух наборов временных рядов. Для этого Прометей предоставляет оператор множеств + или +. Это приводит к серии левой стороны операции, а также к любой серии с правой стороны, у которой слева нет соответствующих наборов меток. Например, чтобы получить список всех запросов, которые меньше 10 или выше 30, запросите:

Результат будет выглядеть так на графике:

изображение: https: //assets.digitalocean.com/articles/prometheus_querying/union.png [Создание объединения из двух наборов запросов]

Как вы можете видеть, использование фильтров значений и операций задания на графиках может привести к появлению и исчезновению временных рядов в пределах одного и того же графика в зависимости от того, соответствуют ли они фильтру или нет на каком-либо временном шаге вдоль графика. Как правило, использование этого вида логики фильтра рекомендуется только для правил оповещения.

Теперь вы знаете, как строить пересечения и объединения из помеченных временных рядов.

В этом разделе мы узнаем, как интерпретировать метрики гистограммы и как рассчитывать квантили (обобщенную форму процентилей) из них.

Prometheus поддерживает метрики гистограммы, которые позволяют сервису регистрировать распределение ряда значений. Гистограммы обычно отслеживают измерения, такие как задержки запросов или размеры ответов, но могут в основном отслеживать любое значение, которое колеблется по величине в соответствии с некоторым распределением. Гистограммы Prometheus sample data на стороне клиента, означающие, что они подсчитывают наблюдаемые значения, используя ряд настраиваемых значений (например, задержки), а затем выставить эти сегменты как отдельные временные ряды.

Внутренне гистограммы реализованы как группа временных рядов, каждый из которых представляет счет для данного сегмента (например, «Запросы до 10 мс», «запросы до 25 мс», «запросы до 50 мс» и т. Д.). Счетчики сегментов являются накопительными, что означает, что сегменты для больших значений включают в себя значения для всех сегментов с меньшими значениями. На каждом временном ряду, который является частью гистограммы, соответствующий сегмент обозначается специальной меткой + le + (меньше или равно). Это добавляет дополнительное измерение к любым существующим измерениям, которые вы уже отслеживаете.

Например, наш демонстрационный сервис экспортирует гистограмму + demo_api_request_duration_seconds_bucket +, которая отслеживает распределение длительностей запросов API. Поскольку эта гистограмма экспортирует 26 сегментов в отслеживаемое подразмерение, этот показатель имеет много временных рядов. Давайте сначала посмотрим на необработанную гистограмму только для одного типа запроса из одного экземпляра:

Вы должны увидеть 26 серий, каждая из которых представляет одну область наблюдения, обозначенную меткой + le +:

изображение: https: //assets.digitalocean.com/articles/prometheus_querying/histogram.png [Необработанная серия гистограмм]

Гистограмма может помочь вам ответить на такие вопросы, как «Сколько из моих запросов занимает больше 100 мсек?» (При условии, что гистограмма имеет настроенную корзину с границей 100 мс). С другой стороны, вы часто хотели бы ответить на такой вопрос, как «Какова задержка, при которой 99% моих запросов завершаются?». Если ваши сегменты гистограммы достаточно тонкие, вы можете рассчитать это с помощью функции + histogram_quantile () +. Эта функция ожидает метрику гистограммы (группа рядов с метками сегмента + le +) в качестве входных данных и выводит соответствующие квантили. В отличие от процентилей, которые варьируются от 0-го до 100-го процентиля, целевая квантильная спецификация, которую функция + histogram_quantile () + ожидает в качестве входных данных, находится в диапазоне от + 0 + до + 1 + (таким образом, 90-й процентиль будет соответствовать квантилю "+ 0,9 +").

Например, мы могли бы попытаться вычислить задержку API 90-го процентиля за все время для всех измерений, как это:

Это не очень полезно или надежно. Счетчики сегментов сбрасываются при перезапуске отдельных экземпляров службы, и вы обычно хотите увидеть, какова задержка «сейчас» (например, измеренная за последние 5 минут), а не за все время метрики. Этого можно добиться, применив функцию + rate () + к базовым счетчикам сегментов гистограммы, которая имеет дело со сбросом счетчиков, а также учитывает только скорость увеличения каждого сегмента за указанное временное окно.

Рассчитайте задержку API 90-го процентиля за последние 5 минут следующим образом:

Это намного лучше и будет выглядеть так:

image: https: //assets.digitalocean.com/articles/prometheus_querying/quantiles_all.png [Вычисленные квантили для всех измерений запроса]

Тем не менее, это показывает 90-й процентиль для eveeey субразмера (+ job +, + instance,` + path`, + method n и` + status + ). Опять же, нас могут не интересовать все эти измерения и мы хотим объединить некоторые из них. К счастью, оператор агрегации Prometheus `+ sum + может быть скомпонован вместе с функцией + histogram_quantile () +, чтобы позволить нам агрегировать по измерениям во время запроса!

Следующий запрос вычисляет задержку 90-го процентиля, но разбивает результат только по измерениям + job +, + instance + и + path +:

График теперь будет выглядеть так:

image: https: //assets.digitalocean.com/articles/prometheus_querying/quantiles_some.png [Вычисленные квантили для некоторых измерений запроса]

Вычисление квантилей по гистограммам всегда вносит некоторую статистическую ошибку. Эта ошибка зависит от размеров вашего сегмента, распределения наблюдаемых значений, а также целевых квантилей, которые вы хотите вычислить. Чтобы узнать больше об этом, прочитайте о Errors of quantile оценка в документации Prometheus.

Теперь вы знаете, как интерпретировать метрики гистограммы и как рассчитывать квантили из них для разных временных диапазонов, а также агрегировать по некоторым измерениям на лету.

В этом разделе мы узнаем, как использовать метрики, содержащие метки времени.

Компоненты в экосистеме Прометея часто выставляют временные метки. Например, это может быть последний раз, когда пакетное задание было успешно выполнено, последняя перезагрузка файла конфигурации или загрузка компьютера. По соглашению время представляется в виде Unix timestamps в секундах с 1 января 1970 года по UTC.

Например, демонстрационная служба предоставляет последний раз, когда имитируется пакетное задание:

Это пакетное задание моделируется для запуска один раз в минуту, но не выполняется в 25% всех попыток. В случае сбоя метрика + demo_batch_last_success_timestamp_seconds + сохраняет свое последнее значение до тех пор, пока не произойдет другой успешный запуск.

Если вы отобразите необработанную временную метку, она будет выглядеть примерно так:

изображение: https: //assets.digitalocean.com/articles/prometheus_querying/raw_timestamp_data.png [необработанный график меток времени]

Как видите, необработанное значение метки времени само по себе обычно не очень полезно. Вместо этого вы часто хотите узнать, сколько лет значению метки времени. Обычный шаблон - вычитать метку времени в метрике из текущего времени, как это предусмотрено функцией + time () +:

Это дает время в секундах с момента последнего успешного запуска пакетного задания:

изображение: https: //assets.digitalocean.com/articles/prometheus_querying/timestamp_age_graph.jpg [график возраста отметки времени]

Если вы хотите преобразовать этот возраст из секунд в часы, вы можете разделить результат на + 3600 +:

Такое выражение полезно как для построения графиков, так и для оповещения. При визуализации возраста метки времени, как указано выше, вы получите пилообразный график с линейно увеличивающимися линиями и регулярным сбросом до + 0 +, когда пакетное задание завершается успешно. Если пилообразный шип становится слишком большим, это означает, что пакетное задание не выполнялось долгое время. Вы также можете предупредить об этом, добавив пороговый фильтр +> + к выражению и предупреждая о результирующем временном ряду (хотя мы не будем рассматривать правила оповещения в этом руководстве).

Чтобы просто перечислить экземпляры, для которых пакетное задание не было выполнено за последние 1,5 минуты, вы можете выполнить следующий запрос:

изображение: https: //assets.digitalocean.com/articles/prometheus_querying/batch_jobs.png [Отображение пакетных заданий, которые находятся позади]

Теперь вы знаете, как преобразовать необработанные метки времени в относительные возрасты, что полезно как для построения графиков, так и для оповещения.

На этом этапе вы узнаете, как сортировать выходные данные запроса или выбирать только самые большие или самые маленькие значения из набора рядов.

В табличном представлении * Console * часто бывает полезно отсортировать выходные серии по их значению. Вы можете добиться этого, используя функции + sort () + (сортировка по возрастанию) и + sort_desc () + (сортировка по убыванию). Например, чтобы показать частоты запросов по каждому пути, отсортированные по их значению, от наивысшего к наименьшему, вы можете запросить:

Отсортированный вывод будет выглядеть так:

изображение: https: //assets.digitalocean.com/articles/prometheus_querying/sorted_request_rates.png [отсортированные запросы]

Или, может быть, вам даже не интересно показывать все серии вообще, а только K самых больших или самых маленьких серий. Для этого Прометей предоставляет функции + topk () + и + bottomk () +. Каждый из них принимает значение K (сколько рядов вы хотите выбрать) и произвольное выражение, которое возвращает набор временных рядов, которые должны быть отфильтрованы. Например, чтобы показать только три верхние частоты запросов для каждого пути и метода, вы можете запросить:

изображение: https: //assets.digitalocean.com/articles/prometheus_querying/top_3_request_rates.png [Лучшие три уровня запросов]

Хотя сортировка очень полезна в представлении * Console *, + topk () + и + bottomk () + также могут быть полезны в графах. Просто имейте в виду, что выходные данные не будут отображать верхнюю или нижнюю K-серию как усредненные по всему временному диапазону графика - вместо этого выходные данные будут пересчитывать K-верхнюю или нижнюю выходные серии для каждого шага разрешения вдоль графика. Таким образом, ваш верхний или нижний K-ряды могут на самом деле варьироваться в диапазоне графика, и ваш график может отображать в целом более K-рядов.

Теперь мы узнали, как сортировать или выбирать только K самых больших или самых маленьких серий.

На этом этапе мы узнаем, как проверять состояние здоровья наших экземпляров с течением времени.

Чтобы сделать этот раздел более интересным, давайте прервем первый из трех ваших экземпляров демонстрационной службы с фоновым подключением (тот, который прослушивает порт 8080):

Всякий раз, когда Прометей очищает цель, он сохраняет синтетический образец с именем метрики + up + и метками + job + и + instance + очищенного экземпляра. Если очистка прошла успешно, значение выборки устанавливается на «+ 1 ». Устанавливается в ` 0 +`, если очистка не удалась. Таким образом, мы можем легко запросить, какие экземпляры в настоящее время «вверх» или «вниз»:

Теперь это должно показать один экземпляр как вниз:

изображение: https: //assets.digitalocean.com/articles/prometheus_querying/instance_health.png [Показывает состояние экземпляра]

Чтобы показать только одни экземпляры, вы можете отфильтровать значение + 0 +:

Теперь вы должны видеть только экземпляр, который вы остановили:

изображение: https: //assets.digitalocean.com/articles/prometheus_querying/down_instances.png [Показывать экземпляры]

Или, чтобы получить общее количество неработающих экземпляров:

Это покажет вам счет + 1 +:

изображение: https: //assets.digitalocean.com/articles/prometheus_querying/down_instance_count.png [Отображение количества экземпляров]

Эти типы запросов полезны для базовых предупреждений о состоянии работ.

Теперь вы знаете, как запросить, например, состояние здоровья.

В этом учебном пособии мы опирались на ход выполнения ссылки: / community / tutorials / how-to-query-prometheus-on-ubuntu-14-04-part-1 [Как запросить Prometheus в Ubuntu 14.04 часть 1] и рассказали больше продвинутые методы и шаблоны запросов. Мы узнали, как фильтровать ряды по их значению, вычислять квантили по гистограммам, работать с метриками на основе временных меток и многое другое.

Хотя эти учебные пособия не могут охватить все возможные варианты использования запросов, мы надеемся, что примеры запросов будут вам полезны при создании реальных запросов, панелей мониторинга и предупреждений с помощью Prometheus. Дополнительные сведения о языке запросов Prometheus см. В документации по языку запросов Prometheus.