Начало работы с Прометеем

монитор

Введение

Prometheus — это система мониторинга и оповещения с открытым исходным кодом. Вдохновленный системой мониторинга Google borgmon, он был создан в 2012 году бывшими сотрудниками Google, работающими в SoundCloud, разработан как проект сообщества с открытым исходным кодом и официально выпущен в 2015 году.

Функции

Как система мониторинга нового поколения, Prometheus обладает следующими характеристиками:

  • Мощная многомерная модель данных:
  1. Данные временных рядов отличаются именами метрик и парами ключ-значение.
  2. Все показатели могут иметь произвольные многомерные метки.
  3. Модель данных является более произвольной, и ее не нужно задавать в виде строки, разделенной точками.
  4. С моделью данных можно выполнять операции агрегирования, вырезания и среза.
  5. Поддерживаются типы с плавающей запятой двойной точности, а для меток можно установить полный юникод.
  • Гибкий и мощный оператор запроса (PromQL): в одном операторе запроса вы можете выполнять такие операции, как умножение, сложение, соединение и дробное извлечение нескольких метрик.
  • Простота управления: сервер Prometheus представляет собой единый бинарник, который работает напрямую локально и не зависит от распределенного хранилища.
  • Эффективность: каждая точка выборки в среднем занимает всего 3,5 байта, а сервер Prometheus может обрабатывать миллионы метрик. Используйте режим извлечения для сбора данных временных рядов, который не только хорош для нативного тестирования, но и позволяет избежать проблемных серверов, отправляющих неверные метрики.
  • Данные временных рядов могут быть отправлены на сервер Prometheus с помощью push-шлюза.
  • Отслеживаемые цели можно получить с помощью обнаружения службы или статической конфигурации.
  • Существуют различные визуальные графические интерфейсы.
  • Легко растягивается.

Состав и структура

Экосистема Prometheus включает в себя несколько компонентов, многие из которых являются необязательными:

  • Prometheus Server:Используется для сбора и хранения данных временных рядов.
  • Client Library:Клиентская библиотека, которая генерирует соответствующие метрики для сервисов, которые необходимо отслеживать, и предоставляет их серверу Prometheus. Когда сервер Prometheus извлекает данные, он напрямую возвращает метрики статуса в реальном времени.
  • Push Gateway:В основном используется для краткосрочных работ. Поскольку такие рабочие места относительно недолговечны, они могут исчезнуть до того, как «Прометей» придет в движение. С этой целью на этот раз задания могут отправлять свои метрики непосредственно на сервер Prometheus. Этот метод в основном используется для метрик на уровне службы.Для метрик на уровне машины вам нужно использовать экспортер узлов.
  • Exporters:Используется для предоставления Prometheus метрик существующих сторонних сервисов.
  • Alertmanager:После получения оповещений с сервера Prometheus он дедуплицирует данные, группирует их и направляет в метод получения для выдачи аварийного сигнала. Распространенными способами получения являются: электронная почта, pagerduty, OpsGenie, веб-перехватчик и т. д.
  • некоторые другие инструменты.

На следующем рисунке показана схема архитектуры в официальной документации Prometheus:

Как видно из рисунка выше, к основным модулям Prometheus относятся: сервер Prometheus, экспортеры, Pushgateway, PromQL, Alertmanager и графический интерфейс.

Примерный рабочий процесс:

  1. Сервер Prometheus периодически извлекает метрики из настроенных заданий или экспортеров, либо получает метрики из Pushgateway, либо извлекает метрики из других серверов Prometheus.
  2. Сервер Prometheus хранит собранные метрики локально и запускает определенные alert.rules для регистрации новых временных рядов или отправки предупреждений в Alertmanager.
  3. Alertmanager обрабатывает полученные оповещения и выдает оповещения в соответствии с конфигурационным файлом. В графическом интерфейсе визуализируйте полученные данные.

Связанные концепции

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

модель данных

Данные, хранящиеся в Prometheus, представляют собой временной ряд, который однозначно идентифицируется именем метрики и набором меток (пары ключ-значение).Разные метки представляют разные временные ряды.

  • Имя метрики: имя должно иметь семантику и обычно используется для представления функции метрики, например: http_requests_total, которое представляет общее количество http-запросов. Имя метрики состоит из символов ASCII, цифр, знаков подчеркивания и двоеточий и должно соответствовать регулярному выражению [a-zA-Z_:][a-zA-Z0-9_:]*.
  • Ярлыки: сделайте так, чтобы одни и те же временные ряды имели разные измерения идентификации. Например, http_requests_total{method="Get"} означает Получить запрос среди всех http-запросов. Когда method="post", это новая метрика. Ключи в метке состоят из символов ASCII, цифр и знаков подчеркивания и должны соответствовать регулярному выражению [a-zA-Z_:][a-zA-Z0-9_:]*.
  • Образцы: фактический временной ряд, каждый ряд включает значение float64 и отметку времени в миллисекундах.
  • Формат: {=, …}, например: http_requests_total{method="POST",endpoint="/api/tracks"}.

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

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

Прилавок

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

Измерять

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

Гистограмма

  • Описание: Распределение статистической выборки по интервалам.
  • Сценарий: Статистика задержки запросов. Например, подсчитайте количество запросов в интервале 0–200 мс, 200–400 мс и 400–800 мс.

Резюме

  • Примечание. Процентиль рассчитывается на основе выборки.
  • Сценарий: Статистика задержки запросов. Например, задержка запроса 95%

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

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

  • job: api-server
    • instance 1: 1.2.3.4:5670
    • instance 2: 1.2.3.4:5671
    • instance 3: 5.6.7.8:5670
    • instance 4: 5.6.7.8:5671

Когда Prometheus очищает цель, он автоматически добавляет некоторые метки к временным рядам очистки, чтобы идентифицировать цель очистки.

  • job: сконфигурированное имя задания, которому принадлежит цель.
  • Экземпляр: часть целевого URL, которая была очищена.

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

  • up{job="", instance=""}: 1 доступно, если экземпляр исправен, или 0 сбой при очистке.
  • scrape_duration_seconds{job="", instance=""}: продолжительность очистки.
  • scrape_samples_post_metric_relabeling{job="", instance=""}: количество образцов, оставшихся после применения перемаркировки метрики.
  • scrape_samples_scraped{job="", instance=""}: количество образцов, предоставленных целью.
  • scrape_series_added{job="", instance=""}: приблизительное количество новых серий в этом цикле очистки. Новое в версии 2.10.

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

Установить и настроить

Установить

Вы можете найти его на официальном сайтеprometheus.io/download/Загрузите установочный пакет, распакуйте его и используйте. Для удобства я использую образ докера для запуска Prometheus.

docker run --name prometheus -d -p 9090:9090 prom/prometheus

Введите http://localhost:9090 в браузере, чтобы получить доступ к веб-интерфейсу Prometheus:

Нажмите «Цели» в разделе «Статус» в строке меню, интерфейс выглядит следующим образом:

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

настроить

Содержимое файла конфигурации Prometheus prometheus.yml выглядит следующим образом:

# 全局设置，可以被覆盖
global:
  scrape_interval:     15s
  evaluation_interval: 15s
  
rule_files:
  # - "first.rules"
  # - "second.rules"

scrape_configs:
  - job_name: prometheus
    static_configs:
    - targets: ['localhost:9090']

ДолженglobalБлоки управляют глобальной конфигурацией Prometheus. У нас есть два варианта. Первый,scrape_intervalОпределяет, как часто Прометей царапает цель. Вы можете переопределить это значение для отдельных целей. В этом случае глобальная настройка — очищать каждые 15 секунд. Долженevaluation_intervalПараметры определяют, как часто Prometheus оценивает правила. Prometheus использует правила для создания новых временных рядов и генерации предупреждений.

Долженrule_filesБлок указывает расположение любых правил, которые мы хотим загрузить в Prometheus. Теперь у нас нет правил.

последний блокscrape_configsКонтролирует ресурсы, за которыми следит Prometheus. Поскольку Prometheus также предоставляет свои собственные данные в качестве конечных точек HTTP, он может очищать и отслеживать свое собственное состояние. В конфигурации по умолчанию есть задание под названием prometheus, которое собирает данные временных рядов, предоставляемые сервером prometheus. Задание содержит статически настроенную цель, локальный хост на порту 9090. Возвращенные данные временных рядов будут содержать подробную информацию о состоянии и производительности сервера Prometheus.

эксперимент

Симулятор HTTP-метрик Prometheus

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

docker run -p 8080:8080 pierrevincent/prom-http-simulator:0.1

Он предоставляет следующие метрики Prometheus в конечной точке /metrics:

  • http_requests_total: счетчик запросов, конечная точка метки и статус
  • http_request_duration_milliseconds: гистограмма задержки запроса

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

# ON
curl -X POST http://127.0.0.1:8080/spike/on

# OFF
curl -X POST http://127.0.0.1:8080/spike/off

# RANDOM
curl -X POST http://127.0.0.1:8080/spike/random

Частота ошибок по умолчанию составляет 1%. Его можно изменить на число от 0 до 100:

# 例如将错误率设置为50%
curl -H 'Content-Type: application/json' -X PUT -d '{"error_rate": 50}' http://127.0.0.1:8080/error_rate

Изменить конфигурацию Прометея

Конечная точка метрик симулятора метрик HTTP должна быть настроена в файле конфигурации Prometheus prometheus.yml .

Создайте файл prometheus.yml со следующим содержимым:

global:
  scrape_interval: 5s
  evaluation_interval: 5s
  scrape_timeout: 5s

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
    - targets: ['localhost:9090']
  - job_name: 'http-simulator'
    metrics_path: /metrics
    static_configs:
    - targets: ['172.16.1.232:8080']

пройти черезdocker upКоманда заменяет файл конфигурации в контейнере:

docker cp prometheus.yml prometheus:/etc/prometheus/

Перезапустите контейнер:

docker restart prometheus

доступhttp://localhost:9090/targets, и обнаружил, что целевой "http-симулятор" появился и находится в состоянии UP.

Запрос

Запрос скорости запроса

Запросить количество http-запросов

http_requests_total{job="http-simulator"}

Запрос количества успешных запросов на вход

http_requests_total{job="http-simulator", status="200", endpoint="/login"}

Количество успешных запросов запросов с разбивкой по конечной точке

http_requests_total{job="http-simulator", status="200"}

Запросить общее количество успешных запросов

sum(http_requests_total{job="http-simulator", status="200"})

Частота успешных запросов запросов, различающаяся по конечной точке

rate(http_requests_total{job="http-simulator", status="200"}[5m])

Общий процент успешных запросов

sum(rate(http_requests_total{job="http-simulator", status="200"}[5m]))

Запрос распределения задержки

Запрос распределения задержки http-симулятора

http_request_duration_milliseconds_bucket{job="http-simulator"}

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

http_request_duration_milliseconds_bucket{job="http-simulator", status="200", endpoint="/login"}

Доля успешных запросов на вход с задержкой не более 200 мс

sum(http_request_duration_milliseconds_bucket{job="http-simulator", status="200", endpoint="/login", le="200"}) / sum(http_request_duration_milliseconds_count{job="http-simulator", status="200", endpoint="/login"})

99-й процентиль задержки для успешных запросов на вход

histogram_quantile(0.99, rate(http_request_duration_milliseconds_bucket{job="http-simulator", status="200", endpoint="/login"}[5m]))

Выражения запроса, приведенные выше, могут быть протестированы сами по себе в интерфейсе запросов prometheus, поэтому я не буду тестировать их здесь по одному.

Суммировать

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

Ссылаться на

Прометей.IO/docs/intro… Woohoo. IBM.com/developer Я…

Подписывайтесь на меня

Категории