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

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

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

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

Чтобы следовать этому уроку, вам понадобится:

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

Сначала скачайте Прометей:

Извлеките тарбол:

Создайте минимальный файл конфигурации Prometheus в файловой системе хоста по адресу + ~ / prometheus.yml +:

Добавьте следующее содержимое в файл:

~ / Prometheus.yml

Сохранить и выйти из нано.

Этот пример конфигурации заставляет Prometheus очищать демонстрационные экземпляры. Prometheus работает с моделью извлечения, поэтому его необходимо настроить, чтобы он знал о конечных точках, из которых можно получить метрики. Демонстрационные экземпляры еще не запущены, но позже они будут работать на портах + 8080 +, + 8081 + и + 8082 +.

Запустите Prometheus, используя + nohup + и в качестве фонового процесса:

+ Nohup в начале команды отправляет вывод в файл` + ~ / nohup.out` вместо + stdout. + & + В конце команды позволит процессу продолжать работать в фоновом режиме, а вам будет предложено вернуться к дополнительным командам. Чтобы вернуть процесс на передний план (т. Е. Вернуться к работающему процессу терминала), используйте команду + fg + на том же терминале.

Если все идет хорошо, в файле + ~ / nohup.out вы должны увидеть вывод, подобный следующему:

Выход из стартового Прометея

В другом терминале вы можете отслеживать содержимое этого файла с помощью команды + tail -f ~ / nohup.out +. Когда содержимое записывается в файл, оно будет отображаться на терминале.

По умолчанию Prometheus загрузит свою конфигурацию из + prometheus.yml + (которую мы только что создали) и сохранит свои данные метрик в +. / Data + в текущем рабочем каталоге.

Флаг + -storage.local.memory-chunks + регулирует использование памяти Prometheus в соответствии с очень небольшим объемом ОЗУ хост-системы (всего 512 МБ) и небольшим количеством хранимых временных рядов в этом руководстве.

Теперь вы сможете получить доступ к серверу Prometheus по адресу + http: //: 9090 / +. Убедитесь, что он настроен на сбор метрик из трех демонстрационных экземпляров. Для этого перейдите в + http: //: 9090 / status + и найдите три конечные точки назначения для задания + demo + в разделе * Targets *. Столбец * State * для всех трех целей должен показывать состояние цели как * DOWN *, поскольку демонстрационные экземпляры еще не запущены и, следовательно, не могут быть удалены:

image: https: //assets.digitalocean.com/articles/prometheus_querying/demo.png [Демонстрационные экземпляры должны быть показаны как DOWN]

В этом разделе мы установим и запустим три экземпляра демонстрационного сервиса.

Загрузите демонстрационный сервис:

Извлеките это:

Запустите демонстрационную службу три раза на отдельных портах:

+ & + Запускает демонстрационные сервисы в фоновом режиме. Они ничего не будут регистрировать, но будут выставлять метрики Prometheus в конечной точке HTTP + / metrics + на своих соответствующих портах.

Эти демонстрационные сервисы экспортируют синтетические метрики о нескольких моделируемых подсистемах. Это:

Отдельные метрики представлены в примерах запросов в последующих разделах.

Сервер Prometheus теперь должен автоматически начать очистку ваших трех демонстрационных экземпляров. Перейдите на страницу состояния вашего сервера Prometheus по адресу + http: //: 9090 / status + и убедитесь, что цели для задания + demo + теперь показывают состояние * UP *:

image: https: //assets.digitalocean.com/articles/prometheus_querying/demo_up.png [Демо-цели должны отображаться как ВВЕРХ]

На этом этапе мы познакомимся со встроенным веб-интерфейсом Prometheus для запросов и построения графиков. Хотя этот интерфейс отлично подходит для специального исследования данных и изучения языка запросов Prometheus, он не подходит для создания постоянных панелей мониторинга и не поддерживает расширенные функции визуализации. Для создания панелей мониторинга см. Пример How Как добавить панель Prometheus в Grafana.

Перейдите к + http: //: 9090 / graph + на вашем сервере Prometheus. Это должно выглядеть так:

изображение: https: //assets.digitalocean.com/articles/prometheus_querying/interface.png [Интерфейс запросов и построения графиков Prometheus]

Как видите, есть две вкладки: * График * и * Консоль *. Прометей позволяет запрашивать данные в двух разных режимах:

Поскольку Prometheus может масштабироваться до миллионов временных рядов, можно создавать очень дорогие запросы (представьте, что это похоже на выбор всех строк из большой таблицы в базе данных SQL). Чтобы избежать превышения времени ожидания или перегрузки вашего сервера, рекомендуется сначала исследовать и создавать запросы в представлении * Console *, а не отображать их сразу. Оценка потенциально дорогостоящего запроса в один момент времени будет использовать гораздо меньше ресурсов, чем попытка построить тот же запрос за определенный промежуток времени.

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

Поскольку наш тестовый сервер Prometheus не будет собирать много данных, мы не сможем сформулировать дорогостоящие запросы в этом руководстве. Любые примеры запросов можно просматривать как в * Graph *, так и в * Console * без риска.

Чтобы уменьшить или увеличить временной диапазон графика, нажмите кнопки * - * или * + *. Чтобы переместить время окончания графика, нажмите кнопки * << * или * >> *. Вы можете составить график, установив флажок * stacked *. Наконец, * Res. (s) * input позволяет вам указать собственное разрешение запроса (не требуется в этом руководстве).

Прежде чем мы начнем запрашивать, давайте кратко рассмотрим модель данных и терминологию Прометея. Прометей в основном хранит все данные как временные ряды. Каждый временной ряд идентифицируется именем метрики, а также набором пар ключ-значение, которые Прометей называет labels. Имя метрики указывает общий аспект измеряемой системы (например, число обработанных HTTP-запросов с момента запуска процесса, + http_requests_total +). Метки служат для различения подразмерных показателей, таких как метод HTTP (например, + method =" POST "+) или путь (например, '+ Путь = "/ API / Foo" + `). Наконец, последовательность образцов формирует фактические данные для серии. Каждый образец состоит из метки времени и значения, где метки времени имеют точность в миллисекундах, а значения всегда являются 64-битными значениями с плавающей запятой.

Самый простой запрос, который мы можем сформулировать, возвращает все серии, которые имеют заданное имя метрики. Например, демонстрационная служба экспортирует метрику + demo_api_request_duration_seconds_count +, которая представляет количество синтетических HTTP-запросов API, обработанных фиктивной службой. Вы можете задаться вопросом, почему имя метрики содержит строку + duration_seconds +. Это связано с тем, что этот счетчик является частью большой метрики гистограммы с именем + demo_api_request_duration_seconds +, которая в первую очередь отслеживает распределение длительностей запросов, но также предоставляет общее количество отслеживаемых запросов (с суффиксом + _count + здесь) в качестве полезного побочного продукта.

Убедитесь, что выбрана вкладка запроса * Console *, введите следующий запрос в текстовое поле вверху страницы и нажмите кнопку * Execute *, чтобы выполнить запрос:

Поскольку Prometheus отслеживает три экземпляра службы, вы должны увидеть табличный вывод, содержащий 27 результирующих временных рядов с этим именем метрики, по одному для каждого отслеживаемого экземпляра службы, пути, метода HTTP и кода состояния HTTP. Помимо меток, установленных самими экземплярами службы (+ method +, + path + и + status +), ряды будут иметь соответствующие метки + job + и + instance +, которые отличают разные экземпляры службы друг от друга. , Прометей автоматически прикрепляет эти метки при сохранении временных рядов от очищенных целей. Вывод должен выглядеть так:

image: https: //assets.digitalocean.com/articles/prometheus_querying/api_requests.png [Запрос API считается табличным выводом]

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

Теперь мы можем добавить метки соответствия, чтобы ограничить возвращаемые серии на основе их меток Соответствующие метки непосредственно следуют за именем метрики в фигурных скобках. В простейшей форме они фильтруют серии, которые имеют точное значение для данной метки. Например, этот запрос покажет только количество запросов для любых запросов + GET +:

Совпадения могут быть объединены с помощью запятых. Например, мы могли бы дополнительно фильтровать метрики только из экземпляра + localhost: 8080 + и задания + demo +:

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

изображение: https: //assets.digitalocean.com/articles/prometheus_querying/api_filtered.png [Отфильтрованный запрос API считается табличным выводом]

При объединении нескольких сопоставителей все они должны совпадать, чтобы выбрать серию. Выражение выше возвращает только количество запросов API для экземпляра службы, работающего на порте 8080 и в котором метод HTTP был + GET +. Мы также гарантируем, что мы выбираем только метрики, относящиеся к заданию + demo +.

Помимо сопоставления на равенство, Prometheus поддерживает сопоставление на неравенство (+! = +), Сопоставление регулярного выражения (+ = ~ +), а также отрицательное сопоставление регулярного выражения (+! ~ +). Также возможно полностью опустить имя метрики и выполнять запрос только с использованием меток. Например, чтобы перечислить все серии (независимо от того, какое имя метрики или задание), где метка + path + начинается с + / api +, вы можете выполнить этот запрос:

Приведенное выше регулярное выражение должно заканчиваться символом +. * +, Поскольку регулярные выражения всегда соответствуют полной строке в Prometheus.

Результирующий временной ряд будет представлять собой смесь серий с разными названиями метрик

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

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

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

Одна из наиболее часто используемых вами функций в Prometheus - + rate () +. Вместо того, чтобы вычислять частоту событий непосредственно в инструментальной службе, в Prometheus обычно отслеживают события, используя необработанные счетчики, и позволяют серверу Prometheus рассчитывать скорости в режиме реального времени во время запроса (это имеет ряд преимуществ, таких как отсутствие потери скачков скорости). между скрепами, а также возможностью выбирать динамические окна усреднения во время запроса). Счетчики начинаются с + 0 +, когда запускается отслеживаемая служба, и постоянно увеличиваются в течение срока службы процесса. Иногда, когда отслеживаемый процесс перезапускается, его счетчики сбрасываются на «+ 0 +» и снова начинают подниматься оттуда. Отображение необработанных счетчиков, как правило, не очень полезно, так как вы увидите только постоянно увеличивающуюся линию со случайными перезагрузками. Вы можете увидеть это, построив график количества запросов API демо-сервиса:

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

изображение: https: //assets.digitalocean.com/articles/prometheus_querying/raw_counters.png [Создание графических счетчиков]

Чтобы сделать счетчики полезными, мы можем использовать функцию + rate () + для вычисления скорости увеличения в секунду. Нам нужно указать + rate () +, по какому временному окну усреднять скорость, предоставив селектор диапазона после сопоставителя серии (например, + [5m] +). Например, чтобы вычислить увеличение вышеупомянутой встречной метрики в секунду, усредненное за последние пять минут, составьте график следующего запроса:

Результат теперь гораздо полезнее:

изображение: https: //assets.digitalocean.com/articles/prometheus_querying/graphing_rates.png [График показателей счетчиков]

+ rate () + является умным и автоматически настраивается для сброса счетчика, предполагая, что любое уменьшение значения счетчика является сбросом.

Вариант + rate () + это + irate () +. В то время как + rate () + усредняет скорость по всем выборкам в данном временном окне (в данном случае пять минут), + irate () + всегда просматривает только две выборки в прошлом. Тем не менее, вам необходимо указать временное окно (например, + [5m] +), чтобы узнать, как далеко можно максимально оглянуться назад во времени для этих двух выборок. + irate () + будет быстрее реагировать на изменения скорости и поэтому обычно рекомендуется для использования на графиках. Напротив, + rate () + обеспечит более плавные скорости и рекомендуется для использования в выражениях оповещения (так как короткие всплески скорости будут подавлены и не разбудят вас ночью).

С + irate () + приведенный выше график будет выглядеть следующим образом, обнаруживая короткие прерывистые провалы в скорости запросов:

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

+ rate () + и + irate () + всегда вычисляют коэффициент per-second. Иногда вам может понадобиться узнать сумму total, на которую счетчик увеличился за определенный промежуток времени, но все еще корректный для сброса счетчика. Вы можете добиться этого с помощью функции + increment () +. Например, чтобы вычислить общее количество запросов, обработанных за последний час, выполните запрос:

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

Например, чтобы увидеть, насколько быстро вымышленное использование диска, экспортируемое нашим демонстрационным сервисом, увеличивается или уменьшается (в миБ в секунду) на основе линейной регрессии последних 15 минут, мы можем запросить:

Результат должен выглядеть так:

изображение: https: //assets.digitalocean.com/articles/prometheus_querying/disk_usage.png [График производной от использования диска]

Чтобы узнать больше о расчете дельт и трендов в датчиках, см. Также http://prometheus.io/docs/querying/functions/#delta [+ delta () +] и http://prometheus.io/docs/ запрос / functions / # предиката_линейных [+ предикатов_линей () +] функций.

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

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

Прометей собирает данные с высокой степенью детализации, что может привести к множеству рядов для каждого имени метрики. Однако часто вас не интересуют все измерения, и у вас может быть даже слишком много рядов, чтобы разумно представить их все одновременно. Решение заключается в агрегировании по некоторым измерениям и сохранении только тех, которые вам нужны. Например, демонстрационный сервис отслеживает HTTP-запросы API по + method +, + path + и + status +. Прометей добавляет дополнительные измерения к этой метрике при извлечении ее из Node Exporter: метки + instance + и + job +, которые отслеживают, из какой обработки вышли метрики. Теперь, чтобы увидеть общую частоту запросов по всем измерениям, мы можем использовать оператор агрегации + sum () +:

Однако это агрегирует по всем _ измерениям и создает один выходной ряд:

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

Обычно, однако, вы хотите сохранить some измерений в выводе. Для этого + sum () + и другие агрегаторы поддерживают предложение + без (<имена меток>) +, которое задает измерения для агрегирования. Существует также альтернативное предложение + by (<label names>) +, которое позволяет вам указать, какие имена меток сохранить. Если мы хотим узнать общую частоту запросов, суммированную по всем трем экземплярам службы и всем путям, но разделить результат по методу и коду состояния, мы можем запросить:

Это эквивалентно:

Полученная сумма не группируется по + instance,` + path` и + job:

image: https: //assets.digitalocean.com/articles/prometheus_querying/preserving.png [Сохранение некоторых измерений при суммировании]

Прометей поддерживает следующие агрегирующие операторы, каждый из которых поддерживает предложение + by () + или + без () +, чтобы выбрать, какие измерения сохранить:

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

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

В качестве простейшего примера арифметики вы можете использовать Прометей в качестве числового калькулятора. Например, выполните следующий запрос в представлении * Console *:

Вы получите единственное скалярное выходное значение + 33 +:

изображение: https: //assets.digitalocean.com/articles/prometheus_querying/scalar.png [Скалярный арифметический результат]

Скалярное значение - это простое числовое значение без каких-либо меток. Чтобы сделать это более полезным, Prometheus позволяет применять общие арифметические операторы (+, + - +, + * +, + / +, +% +) ко всем векторам временных рядов , Например, следующий запрос преобразует количество обработанных байтов с помощью имитированного последнего запуска пакетного задания в MiB:

Результат будет отображаться в MiB:

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

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

Особенность Прометея (и где Прометей действительно сияет!) - двоичная арифметика между двумя наборами временных рядов. При использовании бинарного оператора между двумя наборами рядов Prometheus автоматически сопоставляет элементы с одинаковыми наборами меток слева и справа от операции и применяет оператор к каждой совпадающей паре для получения выходных рядов.

Например, метрика + demo_api_request_duration_seconds_sum + сообщает нам, сколько секунд было потрачено на ответы на HTTP-запросы, а + demo_api_request_duration_seconds_count + сообщает нам, как были many HTTP-запросы. Обе метрики имеют одинаковые измерения (+ method i,` + path + , + status`, + instance,` + job`). Чтобы рассчитать среднюю задержку запросов для каждого из этих измерений, мы можем просто запросить отношение общего времени, затраченного на запросы, к общему количеству запросов.

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

Результирующий график средней задержки запроса должен выглядеть следующим образом:

изображение: https: //assets.digitalocean.com/articles/prometheus_querying/average_latency.png [График средней задержки запроса]

Но что мы делаем, если метки не совпадают точно с обеих сторон? Это особенно актуально, когда у нас есть наборы временных рядов разных размеров с обеих сторон операции, потому что одна сторона имеет больше измерений, чем другая. Например, демонстрационная работа экспортирует вымышленное время ЦП, затраченное в различных режимах (+ idle,` + user`, + system) в качестве метрики` + demo_cpu_usage_seconds_total + с измерением метки + mode + . Он также экспортирует вымышленное общее количество процессоров как `+ demo_num_cpus + (без дополнительных измерений в этой метрике). Если вы попытаетесь разделить одно на другое, чтобы получить среднюю загрузку ЦП в процентах для каждого из трех режимов, запрос не выдаст:

В этих сопоставлениях «один ко многим» или «многие к одному» мы должны указать Прометею, какое подмножество меток использовать для сопоставления, а также нам нужно указать, как обращаться с дополнительной размерностью. Чтобы решить сопоставление, мы добавляем условие + on (<label name>) + к бинарному оператору, который задает метки для сопоставления. Чтобы развернуть и сгруппировать вычисления по отдельным значениям дополнительных измерений на большей стороне, мы добавляем предложение + group_left (<имена ярлыков>) + или + group_right (<имена ярлыков>) +, которое перечисляет дополнительные размеры слева или справа соответственно.

Правильный запрос в этом случае будет:

Результат должен выглядеть так:

изображение: https: //assets.digitalocean.com/articles/prometheus_querying/average_cpu.png [График средней загрузки ЦП для каждого режима]

+ On (job, instance) + указывает оператору сопоставлять только серии слева и справа на их метках + job + и + instance + (и, следовательно, не на метке + mode +, которая не существует справа), в то время как предложение + group_left (mode) + указывает оператору развернуться и отобразить среднюю загрузку ЦП для каждого режима. Это случай сопоставления «многие к одному». Чтобы выполнить обратное сопоставление (один ко многим), используйте предложение + group_right (<label names>) + таким же образом.

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

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

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