Linuxoid.pro

Сообщество разработчиков программного обеспечения и IT-специалистов

Мониторинг Prometheus: полное руководство

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

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

Ценность наличия Prometheus в вашей инфраструктуре бесспорна.

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

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

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

Подобно тому, что мы сделали с InfluxDB, это руководство разделено на три части.

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

1. Что такое Prometheus Monitoring?

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

Но Prometheus- это не только база данных временных рядов.

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

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

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

Что мы подразумеваем под целевым соскабливанием?

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

Если мы возьмем пример веб-приложения, расположенного, например, по адресу http: // localhost: 3000, ваше приложение будет предоставлять метрики в виде обычного текста по определенному URL-адресу, например http: // localhost: 3000 / metrics.

Оттуда в течение заданного интервала брака Prometheus будет извлекать данные из этой цели.

а — Как работает Prometheus?

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

Во-первых, вы хотите иметь возможность извлекать метрики из своих систем. Сделать это можно разными способами:

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

Как вы это поняли, и если мы игнорируем редкие случаи, когда вы можете использовать Pushgateway, Prometheus — это система мониторинга на основе pull.

Что это вообще значит?

Почему они так поступили?

б — Тяга против толчка

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

Это сильно отличается от InfluxDB, например, где вы, по сути, отправляете данные прямо в него.

Оба подхода имеют свои преимущества и неудобства. Из литературы, доступной по этому вопросу, вот список причин этого архитектурного выбора:

  • Централизованное управление : если Prometheus инициирует запросы к своим целям, вся ваша конфигурация выполняется на стороне сервера Prometheus, а не на отдельных целях.

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

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

  • Prometheus предназначен для хранения агрегированных показателей .

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

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

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

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

c — Prometheus мониторинг богатой экосистемы

Основная функция Prometheus, помимо мониторинга, — это база данных временных рядов.

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

Вот инструменты, из которых состоит экосистема Prometheus, чтобы расширить ее функциональные возможности:

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

Источники: публикация Oreilly

2. Объяснение концепций Prometheus Monitoring.

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

a — Модель данных ключевого значения

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

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

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

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

Но что, если вы хотите подробнее рассказать о своей метрике?

Что, если у моего процессора четыре ядра, и я хочу иметь для них четыре отдельных показателя?

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

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

б — Типы показателей

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

Прилавок

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

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

Как вы физически представляете, счетчик только увеличивается или сбрасывается .

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

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

А что, если вы хотите, например, измерить текущее использование памяти в определенный момент времени?

Использование памяти может снизиться, как это можно измерить с помощью Prometheus?

Манометры

Встречайте датчики!

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

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

Счетчики бесполезны?

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

Неправильно .

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

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

Почему? Вот ответ на этот вопрос / u / justinDavidow.

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

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

Конец ошибки!

Гистограмма

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

Значения объединяются в сегменты с настраиваемыми верхними границами. Это означает, что с помощью гистограмм вы можете:

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

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

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

Резюме

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

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

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

По сути, намерение другое.

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

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

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

c — Задания и экземпляры

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

Серверы тиражируются и распространяются по всему миру.

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

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

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

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

Удобно!

d — PromQL

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

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

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

Какие векторы?

Используя Prometheus и PromQL, вы будете иметь дело с двумя типами векторов:

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

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

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

е — КИПиА

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

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

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

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

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

f — Экспортеры

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

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

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

Примеры экспортеров включают:

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

Несколько слов о совместимости

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

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

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

g — Оповещения

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

Оповещения — очень распространенная вещь в Grafana, но они также включаются в Prometheus через диспетчер оповещений.

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

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

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

 

3. Примеры использования Prometheus Monitoring

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

Об этом мы и поговорим в этой главе.

а — Отрасль DevOps

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

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

Прометей — идеальный кандидат на DevOps.

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

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

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

б — Здравоохранение

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

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

Этот пример изначально обсуждался на сайте opensource.com в следующей статье:
https://opensource.com/article/18/9/prometheus-operational-advantage

c — Финансовые услуги

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

Речь была представлена ​​Джейми Кристианом и Аланом Стрейдером, которые продемонстрировали, как именно они используют Prometheus для мониторинга своей инфраструктуры в Northern Trust. Определенно поучительно и стоит посмотреть.

 

Модуль X — Дальнейшее развитие

Как мне нравится в это верить, есть время для теории и время для практики .

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

Оттуда у вас есть все инструменты для создания собственного решения для мониторинга.

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

Оттуда установите необходимые инструменты, создайте свою первую панель инструментов, и вы готовы к работе!

Если вам нужно вдохновение, я написал статью о мониторинге процессов Linux с помощью Prometheus и Grafana. Это помогает настроить инструменты, а также создать вашу первую панель инструментов.

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

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