Skip to content

ahbpp/Prometheus_book

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

16 Commits
 
 
 
 

Repository files navigation

#Prometheus DB

Введение

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

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

Prometheus представляет собой комплексное решение, в состав которого входят и фреймворк для мониторинга, и собственная time-series база данных.

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

Базы данных временных рядов

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

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

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

История

Идея создания и разработка Prometheus DB принадлежит Matt T. Proud и Julius Volz, но большая часть первоначальной разработки была спонсирована сервисом SoundCloud. База данных была представлена в 2012 году в качестве внутренней системы мониторинга SoundCloud, но впоследствии получила широкое распространение. Первый публичный релиз состоялся в 2015 году, а в качестве подтверждения намерений стать open-source проектом присоеднился к Cloud Native Computing Foundation в 2016 году.

В ноябре 2017 был представлен Prometheus v.2.0, база данных стала быстрее в накоплении данных и скорости работы, а также повысилась эффективность использования ресурсов.

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

Установка

Для операционных систем mac os и Linux установка очень проста. Для начала переходим на страницу установки и скачиваем нужный tar.gz архив. Затем открываем терминал, преходим в папку с архивом и вводим команды:

  user$ tar xvfz prometheus-*.tar.gz
  cd prometheus-*

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

Также для дальнейшего прочтения попосбия стоит установить компиляторы для языка Go и Python (на macOS это можно сделать командой brew install go/python).

База данных написна на языке Go, но также имеет официальные клиентские библиотеки на языках Python, Java, Ruby и собственно Go.

Архитектура

В состав Prometheus входят следующие компоненты:

  • сервер, который считывает метрики и сохраняет их в time series базе данных;
  • клиентские библиотеки для различных языков программирования (Go, Java, Python, Ruby; сообществом также созданы библиотеки для Bash, Node.js, Haskell, .NET/C#);
  • PROMDASH — дашборд для метрик;
  • инструменты для экспорта данных из сторонних приложений (Statsd, Ganglia, HAProxy и других);
  • менеджер уведомлений AlertManager (на текущий момент находится на стадии бета-тестирования);
  • клиент командной строки для выполнения запросов к данным.

Архитектура

Главный компонент всей системы — сервер Prometheus. Он работает автономно и сохраняет все данные в локальной базе данных. Обнаружение сервисов происходит автоматически. Это упрощает процедуру развёртывания: для наблюдения за одним сервисом не нужно разворачивать распределённую систему мониторинга; достаточно установить только сервер и необходимые компоненты для сбора и экспорта метрик. Таких компонентов уже написано много под различные сервисы и ПО, весь список доступен на github.

Prometheus хранит данные в виде временных рядов — наборов значений, соотнесённых с временной меткой (timestamp). Элемент временного ряда (измерение) состоит из имени метрики, временной метки и пары «ключ — значение». Временные метки имеют точность до миллисекунд, значения представлены во float64.

В Prometheus используются следующие типы метрик:

  • счётчик (counter) — хранит значения, которые увеличиваются с течением времени (например, количество запросов к серверу);
  • шкала (gauge) — хранит значения, которые с течением времени могут как увеличиваться, так и уменьшаться (например, объём используемой оперативной памяти или количество операций ввода-вывода);
  • гистограмма (histogram) — хранит информацию об изменении некоторого параметра в течение определённого промежутка (например, общее количество запросов к серверу в период с 11 до 12 часов и количество запросов к этому же серверов в период с 11.30 до 11.40);
  • сводка результатов (summary) — как и гистограмма, хранит информацию об изменении значения некоторого параметра за временной интервал, но также позволяет рассчитывать квантили для скользящих временных интервалов.

Начало работы

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

Для начала в файле prometheus.yml задааются параметры с которыми запуститься база данных. Рассмотрим его подробнее:

global:
 scrape_interval:     15s #интервал сбора метрик (по умолчанию — 15 секунд);
 evaluation_interval: 15s #интервал сверки с правилами (по умолчанию — 15 секунд);

 external_labels:
   monitor: 'codelab-monitor'

rule_files:
 - 'prometheus.rules.yml' # файл правил

scrape_configs:
 - job_name: 'prometheus'

   scrape_interval: 5s #переопределение интервал сбора метрик для конкретной джобы

   static_configs: # сервисы и группы сервисов, для которых нужно собирать метрики.
     - targets: ['localhost:9090']

Также стоит отметить, что в секции static_configs могут быть параметры:

  • scrape_timeout — время ожидания данных;
  • metrics_path — HTTP-ресурс, на который будут передаваться метрики;
  • scheme — протокол, который будет использоваться для передачи метрик;
  • basic_auth — реквизиты для авторизации на сервере, с которого будут собираться метрики (username:, password:).

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

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

./prometheus --config.file=prometheus.yml

После запуска переходим на localhost:9090 и видим приятный стандартный веб-интерефейс prometheus. Можем выбрать одну из предложенных стандатрных программ prometheus и выполнить ее. Например, go_memstats_heap_alloc_bytes и посмотреть сколько выделелось байт на куче.

Также можно посмотреть на метрики и графики стандртных метрик по ссылкам localhost:9090/metrics и http://localhost:9090/graph.

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

Для начала клонируем исходники с git и собираем их go компилятором следующими командами:

git clone https://github.com/prometheus/client_golang.git
cd client_golang/examples/random
go get -d
go build

Далее запускаем в трех различных терминалах 3 следующие примеры (каждый в своем):

./random -listen-address=:8080
./random -listen-address=:8081
./random -listen-address=:8082

Соотвественно на каждом из трех портов мы можем посмотреть метрики: http://localhost:8080/metrics, http://localhost:8081/metrics, http://localhost:8082/metrics.

Выяглядит все это не очень понятно и интресно и понятно, поэтому давайте настроим конфигурацию prometheus для мониторинга этих метрик. Для этого добавим в наш prometheus.yml файл следующий scrape_configs:

scrape_configs:
 - job_name:       'example-random'

	scrape_interval: 5s

	static_configs:
		- targets: ['localhost:8080', 'localhost:8081']
			labels:
				group: 'production'

		- targets: ['localhost:8082']
			labels:
				group: 'canary'

После этого снова запускаем команду:

./prometheus --config.file=prometheus.yml

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

Можем убедиться, что у нас появилась в дашборд prometheus новая метрика rpc_durations_seconds.

Язык запросов

В Prometheus DB, удивительно, но язык запросов называется PromQL)

А если серьезно, то Prometheus предоставляет функциональный язык запросов PromQL (Prometheus Query Language), который позволяет пользователю выбирать и агрегировать данные временных рядов в режиме реального времени. Результат выражения может быть отображен в виде графика, отображен в виде табличных данных в браузере выражений Prometheus или использован внешними системами через HTTP API.

Типы данных языка выражений

В языке Прометея выражение или подвыражение может являться одним из четырех типов:

  • Мгновенный вектор - набор временных рядов, содержащий одну выборку для каждого временного ряда, все с одной и той же временной меткой
  • Диапазон вектора - набор временных рядов, содержащий диапазон точек данных во времени для каждого временного ряда
  • Скаляр - простое числовое значение с плавающей точкой
  • String - простое строковое значение(deprecated);

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

Селекторы временных рядов

Селекторы мгновенные векторов

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

В следующем примере выбираются все временные ряды содеражщие метрики с именем rpc_durations_seconds (из раздела #Начало работы) c определенной джобой и состоящей в определенной группе:

rpc_durations_seconds{group="production", job="example-random"}

Также можно перейти во вкладку Console и например посмотреть значения метрик за последнюю минуту с помощью следующей команды:

rpc_durations_seconds{group="production", job="example-random"}[1m]

Также поддерживается язык регулярных выражений RE2 syntax. Специально для них поддерживаются следующие операторы:

  • =: Выбирает метки, которые в точности равны указанной строке.
  • !=: Выбирает метки, которые не равны предоставленной строке.
  • =~: Выбирает метки, которые соответствуют регулярному выражению предоставленной строки.
  • !~: Выбирает метки, которые не соответствуют регулярному выражению указанной строки.

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

rpc_durations_seconds{instance=~"localhost:8080|localhost:8081"}

Селекторы векторов диапазона

Работать с векторами диапазона аналогично мгновенным векторов, за исключением того, что они выбирают диапазон выборок в прошлое начиная с текущего момента. Синтаксически, длительность диапазона добавляется в квадратных скобках ([]) в конце запроса, чтобы указать, как далеко назад во времени должны выбираться значения для каждого элемента вектора диапазона.

Продолжительность времени указывается в виде числа, за которым сразу следует одна из следующих единиц измерения:

  • s - секунды
  • h - часы
  • d - дни
  • w - недели
  • y - года

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

rpc_durations_seconds{instance=~"localhost:8080|localhost:8081"}[1m]

Модификатор сдвига

Модификатор сдвига(offset) позволяет изменять временной сдвиг для отдельных векторов мгновенных значений и диапазонов в запросе. Например, следующее выражение возвращает значение rpc_durations_seconds{instance=~"localhost:8080|localhost:8081"}, которое было 5 минут назад относительно текущего момента времнни:

rpc_durations_seconds{group="production", job="example-random"} offset 5m

Нужно иметь ввиду, что offset нужно указывать сразу после слектора, как например в таком запросе, возращающий сумму мтерик 5 минут назад:

sum(rpc_durations_seconds{group="production", job="example-random"} offset 5m)

Результаты предыдущего запроса посмотрите самостоятельно.

Операторы

Подробно про операторы можно почитать документации

Кратко: поддерживаются бинарные и арифметически между:

  • двумя числами
  • мгновенным вектором и числом
  • между двумя мгновенными векторами

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

rpc_durations_seconds{instance="localhost:8081"}  / ignoring(instance) rpc_durations_seconds{instance="localhost:8080"}

Alertmanager

Ни один инструмент мониторинга немыслим без компонента для рассылки уведомлений. В Prometheus для этой цели используется alertmanager. Настройки уведомлений хранятся в конфигурационном файле alertmanager.conf. Рассмотрим следующий фрагмент:

notification_config {
  name: "alertmanager_test"
  email_config {
    email: "[email protected]"
  }

aggregation_rule {
  notification_config_name: "alertmanager_test"
}

Его синтаксис вполне понятен: мы указали, что уведомления при наступлении определённого условия нужно отправлять по электронной почте на адрес [email protected].

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

В общем виде синтаксис правила выглядит так:

ALERT <имя проверки>
  IF <параметр и его значение>
  FOR <период времени>
  WITH <набор меток>>
  SUMMARY "<краткое описание>"
  DESCRIPTION "<образец уведомления>"

Рассмотрим функции правил на более конкретных примерах. Пример1:

ALERT InstanceDown
  IF up == 0
  FOR 5m
  WITH {
    severity="page"
  }
  SUMMARY "Instance {{$labels.instance}} down"
  DESCRIPTION "{{$labels.instance}} of job {{$labels.job}} has been down for more than 5 minutes."

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

Пример2:

ALERT ApiHighRequestLatency
  IF api_http_request_latencies_ms{quantile="0.5"} > 1000
  FOR 1m
  SUMMARY "High request latency on {{$labels.instance}}"
  DESCRIPTION "{{$labels.instance}} has a median request latency above 1s (current value: {{$value}})"

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

Чтобы прописанные в конфигурационном файле настройки вступили в силу, нужно сохранить его и выполнить команду:

$ alertmanager -config.file alertmanager.conf

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

Уведомления Prometheus отправляет в формате JSON. Выглядят они примерно так:

{
   "version": "1",
   "status": "firing",
   "alert": [
      {
         "summary": "summary",
         "description": "description",
         "labels": {
            "alertname": "TestAlert"
         },
         "payload": {
            "activeSince": "2015-06-01T12:55:47.356+01:00",
            "alertingRule": "ALERT TestAlert IF absent(metric_name) FOR 0y WITH ",
            "generatorURL": "http://localhost:9090/graph#%5B%7B%22expr%22%3A%22absent%28metric_name%29%22%2C%22tab%22%3A0%7D%5D",
            "value": "1"
         }
      }
   ]
}

Хранение данных

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

Локальная база данных

Локальная база данных временных рядов Прометея хранит данные временных рядов в произвольном формате на диске.

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

Блок для текущих поступающих сэмплов хранится в памяти и еще не полностью сохранен. Он защищен от сбоев с помощью журнала записи вперед (WAL), который можно воспроизвести при перезагрузке сервера Prometheus после сбоя. Файлы журнала с опережением записи хранятся в каталоге wal в сегментах 128 МБ. Эти файлы содержат необработанные данные, которые еще не были сжаты, поэтому они значительно больше обычных файлов блоков. Прометей будет хранить как минимум 3 файла журнала с опережением записи, однако серверы с высоким трафиком могут видеть более трех файлов WAL, поскольку ему необходимо хранить не менее двух часов необработанных данных.

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

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

Альтернативно, внешнее хранилище может использоваться через remote [read/write APIs](remote read/write APIs). Их надо очень тщательно подбирать, поскольку они сильно различаются по долговечности, производительности и эффективности.

Для получения больше дополнительной информации о можно перейти на TSDB format.

Сжатие

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

Интеграция с удаленным хранилищем

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

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

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

Протоколы чтения и записи используют сжатый буфер по HTTP. Протоколы еще не являются стабильными API и могут измениться на использование gRPC через HTTP / 2 в будущем, когда все переходы между Prometheus и удаленным хранилищем можно смело предположить для поддержки HTTP / 2.

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

Список поддерживаемых баз данных на сайте.

Клиентские библитеки

Prometheus предоставляет официальные клиентские библитеки на четырех языках:

  • Go
  • Java or Scala
  • Python
  • Ruby

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

В этом разделе будет рассмотрена библиотека на языке Python.

Prometheus Python Client

Установка

Все очень просто)))

pip install prometheus_client

Примеры

Копируем этот шикарный питновский код и запускаем.

from prometheus_client import start_http_server, Summary
import random
import time

# Создаем метрику
REQUEST_TIME = Summary('request_processing_seconds', 'Time spent processing request')

# Магический декоратор над функцией
@REQUEST_TIME.time()
def process_request(t):
    """A dummy function that takes some time."""
    time.sleep(t)

if __name__ == '__main__':
    # Выбираем где запускаем
    start_http_server(8000)
    # Генерируем данные
    while True:
        process_request(random.random())

Посещаем шикарный http://localhost:8000/.
Видим, что появились новые метрики:

  • request_processing_seconds_count: количество вызовов функции.
  • request_processing_seconds_sum: общее количество времени, которое выполнялась функция.

Полезные программы и утилиты

Grafana

В первую очередь стоит упомянуть о совместимости Prometheus и отличного графического визуализатора Gafana. Установить ее можно по инструкции

По умолчанию Grafana запускается на http://localhost:3000.

Создание источника данных для Prometheus:

355/5000

  • Нажмите на логотип Grafana, чтобы открыть меню боковой панели.
  • Нажмите «Data Sources» на боковой панели.
  • Нажмите «Add New».
  • Выберите Prometheus в качестве типа.
  • Установите соответствующий URL-адрес сервера Prometheus (например, http: // localhost: 9090 /)
  • При необходимости настройте другие параметры источника данных (например, отключите доступ к прокси-серверу). Нажмите «Add», чтобы сохранить новый источник данных.

Ниже приведен пример конфигурации:

Создание визуализации Prometheus:

  • Нажмите на название графика, затем нажмите «Edit».
  • На вкладке «Metrics» выберите источник данных Prometheus (справа внизу).
  • Введите любое выражение Прометея в поле «Query», используя поле «Metric» для поиска метрик с помощью автозаполнения.
  • Чтобы отформатировать имена легенды временных рядов, используйте вход «ФLegend format». Например, чтобы показать только метки метода и состояния возвращаемого результата запроса, разделенные чертой, можно использовать строку формата легенды {{method}} - {{status}}.
  • Настройте другие параметры графика, пока у вас не будет рабочего графика.

Посмотрим на пример как может выглядить визуализация:

Использование готовых дэшборд с Grafana.com:

Grafana.com поддерживает коллекцию общих панелей мониторинга, которые можно загружать и использовать с отдельными экземплярами Grafana. Используйте опцию «Filter» на Grafana.com, чтобы просматривать информационные панели только для источника данных «Prometheus».

В настоящее время вы должны вручную отредактировать загруженные файлы JSON и исправить записи источника данных:, чтобы они отражали имя источника данных Grafana, которое вы выбрали для своего сервера Prometheus. Используйте «Dashboards» → «Home» → «Import», чтобы импортировать отредактированный файл панели мониторинга в вашу установку Grafana.

Безопасность

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

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

Как и в случае любой сложной системы, невозможно гарантировать отсутствие ошибок. Если вы обнаружите ошибку безопасности, сообщите об этом в частном порядке сопровождающим, перечисленным в MAINTAINERS.md соответствующего репозитория и в CC [email protected].

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

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

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

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

Начиная с Prometheus 2.0, флаг --web.enable-admin-api контролирует доступ к административному HTTP API, который включает в себя такие функции, как удаление временных рядов. Это отключено по умолчанию. Если эта функция включена, административные и мутирующие функции будут доступны по пути /api/*/admin/. Флаг --web.enable-lifecycle управляет перезагрузками HTTP и отключениями Prometheus. Это также отключено по умолчанию. Если они включены, они будут доступны по путям /-/reload и /-/quit.

В Prometheus 1.x, / - / reload и использование DELETE для /api/v1/series доступны всем, у кого есть доступ к HTTP API. Конечная точка /-/quit отключена по умолчанию, но может быть включена с флагом -web.enable-remote-shutdown.

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

Использование

Больше о Prometheus DB

Сообщество

Социальные сети

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

  • prometheus-announce – для объявлений, о новых версиях.
  • prometheus-users - для обсуждения вопросов использования Прометея и поддержки сообщества.

Twitter: @PrometheusIO

Саммиты разработчиков:

Технические обсуждения происходят в списке разработчиков, наши личные встречи встречаются публично, и у нас есть публичные звонки. Ниже вы можете найти ссылки на наши саммиты разработчиков на PromCon 2017 и 2018 соответственно. Эти встречи на высшем уровне разработчиков открыты для присоединения по запросу, если у нас есть возможности. Предпочтение отдается дружественным проектам и компаниям, плюс разнообразие. Посетители могут свободно не быть указанными в записях публичных собраний.

Contributing

В файле CONTRIBUTING.md в соответствующем репозитории Prometheus для получения инструкций о том, как отправить изменения. Если вы планируете внести более сложные или потенциально противоречивые изменения, обсудите их в IRC-канале разработчиков или в списке рассылки перед отправкой запроса на удаление.

IRC: #prometheus-dev on irc.freenode.net
Мейлы разработчиков: prometheus-developers

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published