Хабрахабр

[Перевод] Полное руководство по Prometheus в 2019 году

DevOps- и SRE-инженеры уже, наверное, не раз слышали о Prometheus.

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

Prometheus обладает очевидной ценностью и уже используется новаторами в отрасли, вроде DigitalOcean или Docker, как часть системы полного мониторинга.

Что такое Prometheus?
Зачем он нужен?
Чем он отличается от других систем?

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

Мы разделили это руководство на 3 части, как поступили с InfluxDB.

  • Сначала идет полный обзор Prometheus, его экосистемы и основных аспектов быстро развивающейся технологии.
  • Потом приводятся объяснения технических терминов Prometheus с иллюстрациями. Если вы не знаете, что такое метрики, ярлыки, экземпляры или экспортеры, вам сюда.
  • Наконец, мы опишем различные реальные сценарии использования Prometheus. Здесь вы вдохновитесь примерами успешных компаний.

Часть I. Что такое Prometheus?

Если вы не в курсе, что такое база данных временных рядов, почитайте первую часть руководства по InfluxDB. Prometheus — это база данных временных рядов.

Но Prometheus — не просто база данных временных рядов.

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

Prometheus мониторит самые разные системы: серверы, базы данных, отдельные виртуальные машины, да почти что угодно.

Для этого Prometheus периодически скрейпит свои целевые объекты.

Что такое скрейпинг?

Prometheus извлекает метрики через HTTP-вызовы к определенным конечным точкам, указанным в конфигурации Prometheus.

Приложение передает метрики в текстовом формате на некоторый URL. Возьмем, например, веб-приложение, расположенное по адресу http://localhost:3000. Допустим, http://localhost:3000/metrics.

По этому адресу Prometheus с определенными интервалами извлекает данные из целевого объекта.

1. Как работает Prometheus?

Как мы уже сказали, Prometheus состоит из самых разных компонентов.

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

  • Инструментирование приложения, то есть ваше приложение будет предоставлять совместимые с Prometheus метрики по заданному URL. Prometheus определит его как целевой объект и будет скрейпить с указанным интервалом.
  • Использование готовых экспортеров. В Prometheus есть целая коллекция экспортеров для существующих технологий. Например, готовые экспортеры для мониторинга машин Linux (Node Exporter), для распространенных баз данных (SQL Exporter или MongoDB Exporter) и даже для балансировщиков нагрузки HTTP (например, HAProxy Exporter).
  • Использование Pushgateway. Иногда приложения или задания не предоставляют метрики напрямую. Они могут быть не предназначены для этого (например, пакетные задания) или вы сами решили не предоставлять метрики напрямую через приложение.

Как вы уже поняли, Prometheus сам собирает данные (исключая редкие случаи, когда мы используем Pushgateway).

Что это значит?
Зачем это нужно?

2. Сбор vs. отправка

У Prometheus есть заметное отличие от других баз данных временных рядов: он активно сканирует целевые объекты, чтобы получить у них метрики.

InfluxDB, например, работает иначе: вы сами напрямую отправляете ему данные.

На основе доступной документации мы составили список причин, по которым создатели Prometheus выбрали такую архитектуру: Оба подхода имеют свои плюсы и минусы.

  • Централизованный контроль. Если Prometheus отправляет запросы целевым объектам, всю настройку мы выполняем на стороне Prometheus, а не отдельных систем.

Prometheus сам решает, где и как часто проводить скрейпинг.

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

  • Prometheus хранит агрегированные метрики.

Это дополнение к первой части, где мы обсуждали роль Prometheus.

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

Отправляется сообщение о факте, что сервис получил сообщение об ошибке 404 за последние пять минут. Если конкретно, веб-сервис не отправляет сообщение об ошибке 404 и сообщение с причиной ошибки.

Это главное различие между базами данных временных рядов, которые собирают агрегированные метрики, и теми, что собирают необработанные метрики.

3. Развитая экосистема Prometheus

По сути Prometheus — база данных временных рядов.

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

Prometheus поддерживает следующие инструменты, расширяющие его функционал:

  • Alertmanager. Prometheus отправляет оповещения в Alertmanager на основе кастомных правил, определенных в файлах конфигурации. Оттуда их можно экспортировать в разные конечные точки (например, Pagerduty или Slack).
  • Визуализация данных. Как и в Grafana, вы можете визуализировать временные ряды прямо в пользовательском веб-интерфейсе Prometheus. Вы можете фильтровать данные и составлять конкретные обзоры происходящего в разных целевых объектах.
  • Обнаружение сервисов. Prometheus динамически обнаруживает целевые объекты и автоматически скрейпит новые цели по запросу. Это особенно удобно, если вы работаете с контейнерами, которые динамически меняют адреса в зависимости от спроса.

Часть II. Концепции Prometheus

Как и в руководстве по InfluxDB, мы подробно разъясним технические термины, связанные с Prometheus.

1. Модель данных «ключ-значение»

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

Ключ описывает, что мы измеряем, а значение хранит фактическую величину в виде числа. Prometheus работает с парами «ключ-значение».

Он хранит метрики, агрегированные за период времени. Помните: Prometheus не создан для хранения необработанной информации, вроде обычного текста.

Это, например, скорость процессора или занятый объем памяти. Ключом в данном случае называется метрика.

Но что если нужно больше деталей о метрике?
Например, у процессора 4 ядра, и нам нужно 4 отдельных метрики?

Ярлыки дают больше сведений о метриках, добавляя дополнительные поля. И здесь на помощь приходят ярлыки. Например, вы описываете не просто скорость процессора, а скорость одного ядра по определенному IP.

Потом вы сможете фильтровать метрики по ярлыкам и просматривать только нужную информацию.

2. Типы метрик

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

Счетчик

Счетчик, как понятно из названия, считает элементы за период времени. Это, наверное, самый простой тип метрик.

Если вы хотите посчитать, например, ошибки HTTP на серверах или посещения веб-сайта, используйте счетчик.

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

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

Как посчитать ее с Prometheus? А если нужно измерить, допустим, используемую память за определенный период?
Эта величина может уменьшаться.

Измерители

Знакомьтесь — измерители!

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

Но если измерители могут увеличиваться и уменьшаться и принимать положительные и отрицательные значения, то выходит, они лучше счетчиков?
Значит, счетчики — бесполезны?

Раз они могут все, давайте использовать их везде. Поначалу и я так думал. Логично?

А вот и нет.

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

Используя измерители, можно упустить нерегулярные изменения метрики со временем. Вот тут-то и кроются те самые подводные камни: измеритель не показывает развитие метрики за период времени.

Вот что говорит /u/justinDavidow: Почему?

«Измеритель показывает среднее значение дельты счетчика для единицы за период времени.

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

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

Если выполнять дополнительные вычисления с этими метриками, точность результатов окажется еще ниже. Если система отправляет метрики каждые 5 секунд, а Prometheus скрейпит целевой объект каждые 15, в процессе можно потерять некоторые метрики.

Когда Prometheus собирает его, он понимает, что значение было отправлено в определенный интервал. У счетчика каждое значение агрегировано.

Теперь не запутаетесь.

Гистограмма

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

Поэтому гистограмма может: Значения собираются в области с настраиваемой верхней границей.

  • Рассчитывать средние значения, то есть сумму значений, поделенную на количество значений.
  • Рассчитывать относительные измерения значений, и это очень удобно, если нужно узнать, сколько значений в определенной области соответствуют заданным критериям. Особенно это полезно, если нужно отслеживать пропорции или установить индикаторы качества.

В реальном мире я бы хотел получать оповещение, если у 20% моих серверов отклик больше 300 мс или отклик серверов больше 300 мс более 20% времени.

Если вы имеете дело с пропорциями, вам нужны гистограммы.

Сводки

Они тоже показывают сумму и количество измерений, а еще квантили за скользящий период. Сводки — это расширенные гистограммы.

Квантили, если что, — это деление плотности вероятности на отрезки равной вероятности.

Итак: гистограммы или сводки?

Все зависит от намерения.

Гистограммы объединяют значения за период времени, предоставляя сумму и количество, по которым можно отследить развитие определенной метрики.

е. Сводки, с другой стороны, показывают квантили за скользящий период (т. непрерывное развитие во времени).

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

3. Задания и экземпляры

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

Серверы реплицируются и распределяются по всему миру.

Чтобы это проиллюстрировать, давайте рассмотрим классическую архитектуру из двух серверов HAProxy, которые перераспределяют нагрузку по девяти бэкенд-веб-серверам (Нет-нет, никаких стеков Stackoverflow.)

В этом примере из реальной жизни мы отследим число ошибок HTTP, возвращенных веб-серверами.

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

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

Удобно же?

4. PromQL

Или используете SQL в TimescaleDB. Если вы используете базы данных на основе InfluxDB, вы, наверное, уже знакомы с InfluxQL.

У Prometheus тоже есть свой язык для запросов и извлечения данных с серверов: PromQL.

PromQL использует тот же синтаксис и возвращает результаты в виде векторов. Как мы уже знаем, данные представлены в виде пар «ключ-значение».

Что за векторы?

В Prometheus и PromQL есть два вида векторов:

  • Моментальные векторы, которые представляют все метрики по последней метке времени.
  • Векторы с диапазоном времени: если вам нужно посмотреть развитие метрики со временем, вы можете указать диапазон времени в запросе к Prometheus. В итоге получите вектор, объединяющий все значения, записанные за выбранный период.

PromQL API предоставляет набор функций для операций с данными в запросах.

Вы можете сортировать значения, применять к ним математические функции (например, рассчитывать производные или экспоненты) и даже строить прогнозы (например, по модели Хольта-Уинтерса).

5. Инструментирование

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

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

Инструментирование доступно для большинства распространенных языков программирования: например, Python, Java, Ruby, Go и даже Node или C#.

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

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

6. Экспортеры

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

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

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

Примеры экспортеров:

  • Экспортеры баз данных: для баз данных MongoDB, серверов SQL и MySQL.
  • Экспортеры HTTP: для серверов HAProxy, Apache или NGINX.
  • Экспортеры Unix: производительность системы можно отслеживать с помощью встроенных экспортеров узлов, которые предоставляют все системные метрики без дополнительной настройки.

Пара слов о взаимной совместимости

Большинство баз данных временных рядов поддерживают взаимную совместимость для своих систем.

Например, у InfluxDB (через Telegraf), CollectD, StatsD и Nagios тоже есть свои стандарты. Prometheus не единственная система мониторинга со своими требованиями к предоставлению метрик.

Даже если Telegraf отправляет метрики не в том формате, который принимает Prometheus, Telegraf может послать эти метрики в экспортер InfluxDB, откуда их потом заберет Prometheus. Поэтому для взаимодействия разных систем создаются экспортеры.

7. Оповещения

При работе с базами данных временных рядов вам нужна обратная связь от данных, и за это отвечают менеджеры оповещений.

В Grafana оповещения обычное дело, но они доступны и в Prometheus через менеджер оповещений.

Менеджер оповещений — это отдельный инструмент, который присоединяется к Prometheus и запускает кастомные оповещатели.

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

Как и в Grafana, в качестве получателя можно указать электронный адрес, вебхук Slack, PagerDuty и кастомные HTTP-объекты.

Часть III. Примеры использования Prometheus

Как я люблю говорить, технология — не самоцель и должна выполнять определенную задачу. И, конечно, в каждом руководстве должны быть практические примеры.

Об этом и поговорим.

1. DevOps

Со всеми этими экспортерами для разных систем, баз данных и серверов очевидно, что Prometheus предназначен, в основном, для сферы DevOps.

Мы знаем, что в этой сфере множество конкурирующих поставщиков и персонализированных решений.

Prometheus идеально подходит для DevOps.

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

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

В среде, где экземпляры то и дело создаются и удаляются, ни один стек DevOps не обойдется без обнаружения сервисов.

2. Здравоохранение

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

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

Этот пример обсуждался на opensource.com в следующей статье.

3. Финансовые услуги

Последний пример приводился на конференции InfoQ, где обсуждалось использование Prometheus в финансовых учреждениях.

Очень содержательно, советую посмотреть. Джейми Кристиан (Jamie Christian) и Алан Стрейдер (Alan Strader) показывали, как они используют Prometheus для мониторинга своей инфраструктуры в Northern Trust.

Часть X. Что дальше?

Пора переходить от теории к практике.

Сегодня вы познакомились с основами Prometheus, узнали, какие функции он выполняет, с какими инструментами и системами работает и какие термины использует.

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

Чтобы приступить к работе с Prometheus, изучите все доступные экспортеры.

Потом установите нужные инструменты, создайте свою первую панель мониторинга — и вперед!

Там есть инструкции по настройке инструментов и первой панели мониторинга. Если вам нужно вдохновение, почитайте мою статью о том, как мониторить машину Linux с Prometheus и Grafana.

Надеюсь, вы узнали что-то новое.

Если у вас есть тема для моей следующей статьи, поделитесь.

Счастливо оставаться!

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть