Прометей автомат 40: Автоматический котел ПРОМЕТЕЙ™ 40 - Прометей™

Содержание

Автоматический котел ПРОМЕТЕЙ™ 40 — Прометей™

Характеристики

Максимальная температура воды, °С	110
Теплопроизводительность (min-max), кВт	5/40 кВт
Средний расход топлива, кг/ч	8/15
Поверхность теплообменника, м2	4
КПД, в зависимости от качества топлива,%	75/90
Основное топливо котла	сухие бурые и каменные угли марки Д (5-70 мм) 3000-5500 ккал/кг
Объем загрузочного бункера, м3/кг	0,3/360
Объем увеличенного бункера, м3/кг	0,6/1,0/2,3
Макс. рабочее давление, кгс/см2	2,5
Температура дымовых газов, °С	100-210
Объем отапливаемого помещения, м3	800
Диаметр присоед. труб, мм	60
Диаметр выходного патрубка, мм	120
Вес нетто, кг	600
Потребляемая мощность/напряжение, Вт/В	275/220
Объем воды в котле, л	150
Диаметр дымовой трубы, мм	120
Высота, мм	1891
Ширина, мм	855
Длина, мм	1840

Автоматические котлы «Прометей-Автомат»

Твердотопливные котлы длительного горения ПРОМЕТЕЙ™ Автомат. Имеют автоматическую подачу угля из бункера вместительностью до 5 м? (под заказ производиться бункер с увеличенным объемом) Мощность котлов от 40 до 1500 кВт.

2
20
30
50
Показать все

Быстрый просмотр

Автоматический котел ПРОМЕТЕЙ™ 40 Автоматический котел ПРОМЕТЕЙ™ 40

192 995 ₽
org/Product» data-id=»1250″>
Быстрый просмотр

Автоматический котел ПРОМЕТЕЙ™ 80 Автоматический котел ПРОМЕТЕЙ™ 80

336 380 ₽
org/Product» data-id=»1249″>
Быстрый просмотр

Автоматический котел ПРОМЕТЕЙ™ 140М Автоматический котел ПРОМЕТЕЙ™ 140М

603 340 ₽
org/Product» data-id=»1231″>
Быстрый просмотр

Автоматический котел ПРОМЕТЕЙ™ 200М Автоматический котел ПРОМЕТЕЙ™ 200М

746 600 ₽
org/Product» data-id=»1232″>
Быстрый просмотр

Автоматический котел ПРОМЕТЕЙ™ 300М Автоматический котел ПРОМЕТЕЙ™ 300М

818 930 ₽
org/Product» data-id=»1233″>
Быстрый просмотр

Автоматический котел ПРОМЕТЕЙ™ 400М Автоматический котел ПРОМЕТЕЙ™ 400М

1 012 700 ₽
org/Product» data-id=»1234″>
Быстрый просмотр

Автоматический котел ПРОМЕТЕЙ™ 600М Автоматический котел ПРОМЕТЕЙ™ 600М

1 449 000 ₽
org/Product» data-id=»1235″>
Быстрый просмотр

Автоматический котел ПРОМЕТЕЙ™ 800М Автоматический котел ПРОМЕТЕЙ™ 800М

1 745 400 ₽
org/Product» data-id=»1236″>
Быстрый просмотр

Автоматический котел ПРОМЕТЕЙ™ 1000М Автоматический котел ПРОМЕТЕЙ™ 1000М

2 031 300 ₽
org/Product» data-id=»1237″>
Быстрый просмотр

Автоматический котел ПРОМЕТЕЙ™ 1500М Автоматический котел ПРОМЕТЕЙ™ 1500М

2 722 500 ₽

СанТехРесурс

У НАС СНОВА НОВИНОЧКИ!

08. 08.2019

Новая мини-котельная уже в продаже!

06.06.2019

Все новости

Лучшая цена Хиты продаж Новинки

Водонагреватель ZANUSSI ZWH/S …
18 390 Р
В корзину
125157
Водонагреватель ZANUSSI ZWH/S 50 Splendore Dry
./images/cache/no_image-38×38.jpg
125157
18390.00
1
Водонагреватель ZANUSSI ZWH/S …
22 790 Р
В корзину
125158
Водонагреватель ZANUSSI ZWH/S 80 Splendore Dry
./images/cache/no_image-38×38.jpg
125158
22790.00
1
Водонагреватель эмал. бак Aris…
8 370 Р
В корзину
99327
Водонагреватель эмал. бак Ariston ABS ANDRIS LUX 10 UR, 1,2кВт, верх. подкл.
. /images/cache/data/product/00000099327-38×38.jpg
99327
8370.00
1
Кран шаровой STC Solo ДУ-25 с …
508 Р
В корзину
6442
Кран шаровой STC Solo ДУ-25 с амер.
./images/cache/data/product/00000006442-38×38.jpg
6442
508.00
1
Фильтр на кран -09
899 Р
В корзину
100639
Фильтр на кран -09
./images/cache/data/product/00000100639-38×38.jpg
100639
899.00
1
Кран шаровой STC Solo ДУ-20 с …
337 Р
В корзину
6441
Кран шаровой STC Solo ДУ-20 с амер.
./images/cache/data/product/00000006441-38×38.jpg
6441
337.00
1
Кран шаровой латунный ДУ- 20 а. ..
375 Р
В корзину
3472
Кран шаровой латунный ДУ- 20 американка /Галлоп
./images/cache/data/product/00000003472-38×38.jpg
3472
375.00
1
Радиатор биметалл. S19 BM 500/…
540 Р
В корзину
120345
Радиатор биметалл. S19 BM 500/78 120Вт Benarmo
./images/cache/no_image-38×38.jpg
120345
540.00
1
Сифон для умыв/мойки Was33 бут…
46 Р
В корзину
4324
Сифон для умыв/мойки Was33 бут 1 1/2 вып б/гофр отв/стир нерж/сетка
./images/cache/no_image-38×38.jpg
4324
46.00
1
Кран шаровой » BUGATTI» вн./на…
467 Р
В корзину
1230
Кран шаровой » BUGATTI» вн. /нар. ДУ-20
./images/cache/data/product/00000001230-38×38.jpg
1230
467.00
1
Кран шаровой » BUGATTI» вн./вн…
592 Р
В корзину
1225
Кран шаровой » BUGATTI» вн./вн. ДУ-25
./images/cache/data/product/00000001225-38×38.jpg
1225
592.00
1
Сифон для умыв/мойки Was32 бут…
48 Р
В корзину
4323
Сифон для умыв/мойки Was32 бут 1 1/2 вып б/гофр нерж/сетка
./images/cache/no_image-38×38.jpg
4323
48.00
1
Насос скважинный центробежный …
11 350 Р
В корзину
113506
Насос скважинный центробежный PUMPMAN 4SM2-8F d100 0,37кВт H=48мQ=3,6м3 корп. и колеса нерж каб. 20м
./images/cache/data/product/00000113506-38×38.jpg
113506
11350.00
1
Радиатор биметалл. Ogint Ultra…
599 Р
В корзину
98316
Радиатор биметалл. Ogint Ultra Plus 500
./images/cache/data/product/00000098316-38×38.jpg
98316
599.00
1
Труба медная неотожженная SANC…
1 319 Р
В корзину
521
Труба медная неотожженная SANCO 22 ст.1 (пайка)
./images/cache/data/product/00000000521-38×38.jpg
521
1319.00
1
Кран шаровой » BUGATTI» с амер…
684 Р
В корзину
1232
Кран шаровой » BUGATTI» с американкой ДУ-20
./images/cache/data/product/00000001232-38×38. jpg
1232
684.00
1
Кран шаровой » BUGATTI» вн./вн…
304 Р
В корзину
1223
Кран шаровой » BUGATTI» вн./вн. ДУ-15
./images/cache/data/product/00000001223-38×38.jpg
1223
304.00
1
Кран шаровой » BUGATTI» вн./вн…
1 488 Р
В корзину
1227
Кран шаровой » BUGATTI» вн./вн. ДУ-40
./images/cache/data/product/00000001227-38×38.jpg
1227
1488.00
1
СИФОН для поддона WIRQUIN 11/2…
175 Р
В корзину
94633
СИФОН для поддона WIRQUIN 11/2*40
./images/cache/no_image-38×38.jpg
94633
175.00
1
Водосчетчик МЕТЕР СВ-15 монт. …
656 Р
В корзину
95071
Водосчетчик МЕТЕР СВ-15 монт. дл. 110мм , tmax=90C, поверка 6/6 лет г/х УЦЕНКА
./images/cache/data/product/00000095071-38×38.jpg
95071
656.00
1
Водосчетчик ЭКОМЕРА-15У монт….
689 Р
В корзину
97066
Водосчетчик ЭКОМЕРА-15У монт. дл. 110мм , tmax=90C, с кчм поверка 6/6 лет г/х
./images/cache/data/product/00000097066-38×38.jpg
97066
689.00
1
Насос скважинный центробежный …
20 305 Р
В корзину
113505
Насос скважинный центробежный PUMPMAN 4SM2-21F d100 1,5кВт H=126мQ=3,6м3 корп. и колеса нерж каб.40м
./images/cache/data/product/00000113505-38×38.jpg
113505
20305.00
1
Кран шаровой » BUGATTI» с амер. ..
422 Р
В корзину
1231
Кран шаровой » BUGATTI» с американкой ДУ-15
./images/cache/data/product/00000001231-38×38.jpg
1231
422.00
1
Сифон для умыв/мойки Was 32A б…
35 Р
В корзину
4316
Сифон для умыв/мойки Was 32A бут 1 1/2 б/вып б/гофр
./images/cache/no_image-38×38.jpg
4316
35.00
1
Шланг душевой метал. рус/имп 1…
93 Р
В корзину
93605
Шланг душевой метал. рус/имп 1,5м
./images/cache/data/product/00000093605-38×38.jpg
93605
93.00
1
Кран шаровой » BUGATTI» с амер…
по запросу
В корзину
117170
Кран шаровой » BUGATTI» с американкой ДУ-20 626 арт. ARIZONA
./images/cache/no_image-38×38.jpg
117170
1
Гофросифон Flexiplast
62 Р
В корзину
975
Гофросифон Flexiplast
./images/cache/no_image-38×38.jpg
975
62.00
1
Кран шаровой STC Solo ДУ-25 вн…
407 Р
В корзину
6433
Кран шаровой STC Solo ДУ-25 вн.-вн.
./images/cache/data/product/00000006433-38×38.jpg
6433
407.00
1

Понимание и использование шаблона многоцелевого экспортера

Шаблон многоцелевого экспортера?
Запуск многоцелевых экспортеров
Базовый запрос многоцелевых экспортеров
Настройка модулей
Запрос многоцелевых экспортеров с помощью Prometheus

Это руководство познакомит вас с шаблоном многоцелевого экспортера. Для этого мы:

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

Шаблон многоцелевого экспортера?

Под шаблоном многоцелевого экспортера мы подразумеваем определенный дизайн, в котором:

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

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

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

Запуск многоцелевых экспортеров

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

Теперь давайте попробуем сами!

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

 docker run -p 9115:9115 prom/blackbox-exporter

Вы должны увидеть несколько строк журнала, и если все прошло хорошо, последняя должна сообщить msg="Прослушивание адреса" , как показано здесь:

 level=info ts=2018-10-17T15:41:35.4997596Z caller=main.go:324 msg="Прослушивание адреса" address=:9115

Основные запросы многоцелевых экспортеров

Есть два способа запроса:

Запрос самого экспортера. У него есть свои метрики, обычно доступные по адресу /metrics .
Запрос экспортера на очистку другой цели. Обычно доступно в «описательной» конечной точке, например. /зонд . Вероятно, это то, что вас в первую очередь интересует при использовании многоцелевых экспортеров.

Вы можете вручную попробовать первый тип запроса с curl в другом терминале или использовать эту ссылку:

 curl 'localhost:9115/metrics'

Ответ должен быть примерно таким:

# ПОМОЩЬ blackbox_exporter_build_info Метрика с постоянным значением '1', помеченная версией, ревизией, ветвью и версией, на основе которой был собран blackbox_exporter.

# ТИП шкалы blackbox_exporter_build_info blackbox_exporter_build_info{branch="HEAD",goversion="go1.10",revision="4a22506cf0cf139"d9b2f9cde099f0012d9fcabde", версия = "0.12.0"} 1 # ПОМОЩЬ go_gc_duration_seconds Сводная информация о длительности вызовов сборщика мусора. # TYPE сводка go_gc_duration_seconds go_gc_duration_seconds{quantile="0"} 0 go_gc_duration_seconds{quantile="0,25"} 0 go_gc_duration_seconds{quantile="0,5"} 0 go_gc_duration_seconds{quantile="0,75"} 0 go_gc_duration_seconds{quantile="1"} 0 go_gc_duration_seconds_sum 0 go_gc_duration_seconds_count 0 # ПОМОЩЬ go_goroutines Количество существующих на данный момент горутин. # TYPE датчик go_goroutines go_goroutines 9[…] # ПОМОЩЬ process_cpu_seconds_total Общее время, затрачиваемое пользователем и системным процессором в секундах. # TYPE счетчик process_cpu_seconds_total process_cpu_seconds_total 0,05 # HELP process_max_fds Максимальное количество дескрипторов открытых файлов. # Датчик TYPE process_max_fds process_max_fds 1.048576e+06 # HELP process_open_fds Количество дескрипторов открытых файлов.

# Датчик TYPE process_open_fds process_open_fds 7 # ПОМОЩЬ process_resident_memory_bytes Размер резидентной памяти в байтах. # Индикатор TYPE process_resident_memory_bytes процесс_резидент_память_байт 7.8848e+06 # ПОМОЩЬ process_start_time_seconds Время начала процесса с эпохи unix в секундах. # Индикатор TYPE process_start_time_seconds process_start_time_seconds 1,541154

e+09 # ПОМОЩЬ process_virtual_memory_bytes Размер виртуальной памяти в байтах. # Индикатор TYPE process_virtual_memory_bytes process_virtual_memory_bytes 1.5609856e+07

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

Для второго типа запроса нам необходимо указать цель и модуль в качестве параметров в HTTP-запросе GET. Целью является URI или IP, а модуль должен быть определен в конфигурации экспортера. Контейнер экспортера черного ящика поставляется со значимой конфигурацией по умолчанию.
Мы будем использовать целевой prometheus.io и предопределенный модуль http_2xx . Он говорит экспортеру сделать запрос GET, как это сделал бы браузер, если бы вы перешли на prometheus.io и ожидать ответа 200 OK.

Теперь вы можете указать экспортеру черного ящика запросить prometheus.io в терминале с помощью curl:

 curl 'localhost:9115/probe?target=prometheus.io&module=http_2xx'

Это вернет множество показателей:

 # ПОМОЩЬ probe_dns_lookup_time_seconds Возвращает время, затраченное на поиск DNS зонда в секундах
# ТИП датчика probe_dns_lookup_time_seconds
probe_dns_lookup_time_seconds 0,061087943
# HELP probe_duration_seconds Возвращает время, которое потребовалось для завершения проверки в секундах.
# ТИП датчика probe_duration_seconds
probe_duration_seconds 0,065580871
# HELP probe_failed_due_to_regex Указывает, произошел ли сбой проверки из-за регулярного выражения
# ТИП датчика probe_failed_due_to_regex
probe_failed_due_to_regex 0
# HELP probe_http_content_length Длина ответа http-контента
# TYPE probe_http_content_length Gauge
probe_http_content_length 0
# HELP probe_http_duration_seconds Продолжительность http-запроса по фазам, суммированная по всем редиректам
# ТИП датчика probe_http_duration_seconds
probe_http_duration_seconds{фаза="подключение"} 0
probe_http_duration_seconds{phase="processing"} 0
probe_http_duration_seconds {фаза = "разрешить"} 0,061087943
probe_http_duration_seconds{phase="tls"} 0
probe_http_duration_seconds{phase="transfer"} 0
# ПОМОЩЬ probe_http_redirects Количество редиректов
# ТИП датчика probe_http_redirects
probe_http_redirects 0
# HELP probe_http_ssl Указывает, использовался ли SSL для окончательного перенаправления
# ТИП датчика probe_http_ssl
probe_http_ssl 0
# ПОМОЩЬ probe_http_status_code Код состояния ответа HTTP
# ТИП датчика probe_http_status_code
probe_http_status_code 0
# HELP probe_http_version Возвращает версию HTTP ответа зонда. 
# ТИП датчика probe_http_version
probe_http_version 0
# HELP probe_ip_protocol Указывает, является ли IP-протокол зонда IP4 или IP6.
# ТИП датчика probe_ip_protocol
probe_ip_protocol 6
# HELP probe_success Отображает успешность проверки.
# Датчик TYPE probe_success
probe_success 0

Обратите внимание, что почти все показатели имеют значение 0 . Последний читает probe_success 0 . Это означает, что зонд не смог успешно связаться с prometheus.io . Причина скрыта в метрике probe_ip_protocol со значением 6 . По умолчанию зонд использует IPv6, пока не указано иное. Но демон Docker блокирует IPv6, пока не будет указано обратное. Следовательно, наш экспортер черного ящика, работающий в контейнере Docker, не может подключиться через IPv6.

Теперь мы можем либо указать Docker разрешить IPv6, либо экспортеру черного ящика использовать IPv4. В реальном мире и то, и другое может иметь смысл, и, как часто бывает, ответ на вопрос «что делать?» это «это зависит». Поскольку это руководство по экспортеру, мы изменим экспортер и воспользуемся возможностью настроить собственный модуль.

Настройка модулей

Модули предварительно определены в файле внутри контейнера докеров с именем config.yml , который является копией blackbox.yml в репозитории github.

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

Сначала загрузите файл с помощью curl или браузера:

 curl -o blackbox.yml https://raw.githubusercontent.com/prometheus/blackbox_exporter/master/blackbox.yml

Откройте его в редакторе. Первые несколько строк выглядят так:

 модулей:
  http_2xx:
    зонд: http
  http_post_2xx:
    зонд: http
    http:
      метод: ПОСТ

YAML использует пробельные отступы для выражения иерархии, поэтому вы можете распознать, что определены два модуля с именами http_2xx и http_post_2xx , и что они оба имеют зонд http , и для одного значение метода специально установлено на ПОЧТ .
Теперь вы измените модуль http_2xx , установив предпочитаемый_ip_протокол зонда http явно на строку ip4 .

 модули:
  http_2xx:
    зонд: http
    http:
      предпочтительный_ip_протокол: "ip4"
  http_post_2xx:
    зонд: http
    http:
      метод: ПОСТ

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

Теперь нам нужно указать экспортеру черного ящика использовать наш только что измененный файл. Вы можете сделать это с флагом --config.file="blackbox.yml" . Но поскольку мы используем Docker, мы сначала должны сделать этот файл доступным внутри контейнера с помощью --mount команда.

ПРИМЕЧАНИЕ. Если вы используете macOS, сначала необходимо разрешить демону Docker доступ к каталогу, в котором находится ваш blackbox.yml . Вы можете сделать это, нажав на маленького кита Docker в строке меню, а затем на Настройки -> Общий доступ к файлам -> + . После этого нажмите Применить и перезапустить .

Сначала вы останавливаете старый контейнер, переходя в его терминал и нажимая ctrl+c . Убедитесь, что вы находитесь в каталоге, содержащем ваш blackbox.yml . Затем вы запускаете эту команду. Длинно, но объясним:

 docker\
  запустить -p 9115:9115 \
  --mount type=bind,source="$(pwd)"/blackbox.yml,target=/blackbox.yml,только для чтения \
  пром/черный ящик-экспортер \
  --config.file="/blackbox.yml"

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

запустить контейнер с портом 9115 вне контейнера, сопоставленным с портом 9115 внутри контейнера.
смонтируйте из вашего текущего каталога ( $(pwd) означает рабочий каталог для печати) файл blackbox.yml в /blackbox.yml в режиме только для чтения .
используйте образ prom/blackbox-exporter из Docker Hub.
запустить blackbox-exporter с флагом --config.file , указав использовать /blackbox.yml в качестве файла конфигурации.

Если все правильно, вы должны увидеть что-то вроде этого:

 level=info ts=2018-10-19T12:40:51.650462756Z caller=main.go:213 msg="Starting blackbox_exporter" version="(version=0.12 .0, ветка = ГОЛОВА, ревизия = 4a22506cf0cf139d9b2f9cde099f0012d9fcabde)"
level=info ts=2018-10-19T12:40:51.653357722Z caller=main.go:220 msg="Загружен файл конфигурации"
level=info ts=2018-10-19T12:40:51.65349635Z caller=main.go:324 msg="Прослушивание адреса" address=:9115

Теперь вы можете попробовать наш новый модуль с использованием IPv4 http_2xx в терминале:

 curl 'localhost:9115/probe?target=prometheus.io&module=http_2xx'

Что должно возвращать метрики Prometheus следующим образом:

 # HELP probe_dns_lookup_time_seconds Возвращает время, затраченное на поиск DNS зонда в секундах
# ТИП датчика probe_dns_lookup_time_seconds
probe_dns_lookup_time_seconds 0,02679421
# HELP probe_duration_seconds Возвращает время, которое потребовалось для завершения проверки в секундах. 
# ТИП датчика probe_duration_seconds
probe_duration_seconds 0,461619124
# HELP probe_failed_due_to_regex Указывает, произошел ли сбой проверки из-за регулярного выражения
# ТИП датчика probe_failed_due_to_regex
probe_failed_due_to_regex 0
# HELP probe_http_content_length Длина ответа http-контента
# TYPE probe_http_content_length Gauge
probe_http_content_length -1
# HELP probe_http_duration_seconds Продолжительность http-запроса по фазам, суммированная по всем редиректам
# ТИП датчика probe_http_duration_seconds
probe_http_duration_seconds{phase="connect"} 0,062076202999999996
probe_http_duration_seconds{phase="processing"} 0,23481845699999998
probe_http_duration_seconds{фаза="разрешить"} 0,0295probe_http_duration_seconds{фаза="tls"} 0,163420078
probe_http_duration_seconds{phase="transfer"} 0,002243199
# ПОМОЩЬ probe_http_redirects Количество редиректов
# ТИП датчика probe_http_redirects
probe_http_redirects 1
# HELP probe_http_ssl Указывает, использовался ли SSL для окончательного перенаправления
# ТИП датчика probe_http_ssl
probe_http_ssl 1
# ПОМОЩЬ probe_http_status_code Код состояния ответа HTTP
# ТИП датчика probe_http_status_code
probe_http_status_code 200
# HELP probe_http_uncompressed_body_length Длина несжатого тела ответа
# Датчик TYPE probe_http_uncompressed_body_length
probe_http_uncompressed_body_length 14516
# HELP probe_http_version Возвращает версию HTTP ответа зонда. 
# ТИП датчика probe_http_version
probe_http_version 1.1
# HELP probe_ip_protocol Указывает, является ли IP-протокол зонда IP4 или IP6.
# ТИП датчика probe_ip_protocol
probe_ip_protocol 4
# HELP probe_ssl_earliest_cert_expiry Возвращает самый ранний срок действия сертификата SSL в unixtime
# ТИП датчика probe_ssl_earliest_cert_expiry
probe_ssl_earliest_cert_expiry 1.581897599e+09
# HELP probe_success Отображает успешность проверки.
# Датчик TYPE probe_success
probe_success 1
# HELP probe_tls_version_info Содержит используемую версию TLS
# ТИП датчика probe_tls_version_info
probe_tls_version_info{версия="TLS 1.3"} 1
 
 Вы можете видеть, что проверка прошла успешно, и получить множество полезных показателей, таких как задержка по фазам, код состояния, статус ssl или срок действия сертификата в Unix-времени. 
 Экспортер черного ящика также предлагает крошечный веб-интерфейс на localhost:9115, чтобы вы могли проверить последние несколько зондов, загруженную конфигурацию и информацию об отладке. Он даже предлагает прямую ссылку на зонд  prometheus.io . Удобно, если вам интересно, почему что-то не работает.
 Запрос многоцелевых экспортеров с помощью Prometheus 
 Пока все хорошо. Поздравьте себя. Экспортер черного ящика работает, и вы можете вручную указать ему запрашивать удаленную цель. Вы почти там. Теперь вам нужно сказать Prometheus, чтобы он выполнял запросы за нас.
 Ниже вы найдете минимальную конфигурацию prometheus. Он говорит Prometheus очистить сам экспортер, как мы это делали до использования  curl 'localhost:9115/metrics'  :
  ПРИМЕЧАНИЕ.  Если вы используете Docker для Mac или Docker для Windows, вы не можете использовать  localhost:9115  в последней строке, но должны использовать  host.docker .внутренний:9115  . Это связано с виртуальными машинами, используемыми для реализации Docker в этих операционных системах. Вы не должны использовать это в производстве.
  prometheus.yml  для Linux:
 глобальный:
  скреб_интервал: 5 с
scrape_configs:
- job_name: blackbox # Чтобы получить метрики о самом экспортере
  путь_метрик: /метрики
  статические_конфигурации:
    - цели:
      - локальный: 9115
 
  prometheus.yml  для macOS и Windows:
 глобальный:
  скреб_интервал: 5 с
scrape_configs:
- job_name: blackbox # Чтобы получить метрики о самом экспортере
  путь_метрик: /метрики
  статические_конфигурации:
    - цели:
      - хост.докер.внутренний:9115
 
 Теперь запустите контейнер Prometheus и скажите ему смонтировать наш файл конфигурации сверху. Из-за того, что сеть на хосте адресуется из контейнера, вам нужно использовать немного другую команду в Linux, чем в MacOS и Windows:
 Запустите Prometheus в Linux (не используйте  --network="host"  в рабочей среде):
 docker \
  запустить --network="хост"\
  --mount type=bind,source="$(pwd)"/prometheus.yml,target=/prometheus. yml,только для чтения \
  выпускной / прометей \
  --config.file="/prometheus.yml"
 
 Запустить Prometheus на MacOS и Windows:
 docker \
  запустить -p 9090:9090 \
  --mount type=bind,source="$(pwd)"/prometheus.yml,target=/prometheus.yml,только для чтения \
  выпускной / прометей \
  --config.file="/prometheus.yml"
 
 Эта команда работает аналогично запуску экспортера черного ящика с использованием файла конфигурации.
 Если все работает, вы сможете перейти на localhost:9090/targets и увидеть под черным ящиком   конечную точку с состоянием  UP  зеленым цветом. Если вы получаете красный  DOWN , убедитесь, что экспортер черного ящика, который вы запустили выше, все еще работает. Если вы не видите ничего или желтого  UNKNOWN , значит, вы работаете очень быстро, и вам нужно подождать еще несколько секунд, прежде чем перезагрузить вкладку браузера.
 Чтобы сообщить Prometheus о запросе  "localhost:9115/probe?target=prometheus. io&module=http_2xx" , вы добавляете еще одно задание очистки  blackbox-http , где вы устанавливаете  metrics_path  на  /probe  и параметры ниже  params:  в конфигурационном файле Prometheus  prometheus.yml  :
 global:
  скреб_интервал: 5 с
scrape_configs:
- job_name: blackbox # Чтобы получить метрики о самом экспортере
  путь_метрик: /метрики
  статические_конфигурации:
    - цели:
      - локальный: 9115 # Для Windows и macOS замените на - host.docker.internal:9115
- job_name: blackbox-http # Чтобы получить метрики о целях экспортера
  путь_метрики: /зонд
  параметры:
    модуль: [http_2xx]
    цель: [prometheus.io]
  статические_конфигурации:
    - цели:
      - localhost:9115 # Для Windows и macOS замените на - host.docker.internal:9115
 
 После сохранения файла конфигурации переключитесь на терминал с док-контейнером Prometheus и остановите его, нажав  ctrl+C , и снова запустите его, чтобы перезагрузить конфигурацию с помощью существующей команды.
 Терминал должен вернуть сообщение  «Сервер готов принимать веб-запросы».  и через несколько секунд вы должны начать видеть красочные графики в своем Prometheus.
 Это работает, но имеет несколько недостатков:
 Фактические цели указываются в конфигурации параметров, что очень необычно и трудно для понимания позже.
 Метка  instance  имеет значение адреса экспортера черного ящика, что технически верно, но не то, что нас интересует.
 Мы не можем увидеть, какой URL мы исследовали. Это непрактично, а также приведет к смешению разных метрик в одну, если мы проверим несколько URL-адресов.
 Чтобы исправить это, мы будем использовать перемаркировку. Перемаркировка здесь полезна, потому что за кулисами многие вещи в Prometheus настраиваются с помощью внутренних меток. Детали сложны и выходят за рамки данного руководства. Поэтому ограничимся необходимым. Но если вы хотите узнать больше, посмотрите это выступление. Пока достаточно, если вы понимаете это:
 Все этикетки, начинающиеся с  __ , удаляются после очистки. Большинство внутренних меток начинаются с  __  .
 Вы можете установить внутренние метки, которые называются  __param_  . Те задают параметр URL с ключом  <имя>  для запроса очистки.
 Существует внутренняя метка  __address__ , которая устанавливается  целями  в  static_configs  и значением которой является имя хоста для запроса очистки. По умолчанию он позже используется для установки значения метки  instance  , который прикрепляется к каждой метрике и сообщает вам, откуда взялись метрики.
 Вот конфигурация, которую вы будете использовать для этого. Не волнуйтесь, если это слишком много сразу, мы рассмотрим это шаг за шагом:
 глобальный:
  скреб_интервал: 5 с
scrape_configs:
- job_name: blackbox # Чтобы получить метрики о самом экспортере
  путь_метрик: /метрики
  статические_конфигурации:
    - цели:
      - localhost:9115 # Для Windows и macOS замените на - host. docker.internal:9115
- job_name: blackbox-http # Чтобы получить метрики о целях экспортера
  путь_метрики: /зонд
  параметры:
    модуль: [http_2xx]
  статические_конфигурации:
    - цели:
      - http://prometheus.io # Цель для проверки с http
      - https://prometheus.io # Цель для проверки с помощью https
      - http://example.com:8080 # Цель для проверки с http на порту 8080
  relabel_configs:
    - source_labels: [__адрес__]
      target_label: __param_target
    - source_labels: [__param_target]
      target_label: экземпляр
    - target_label: __адрес__
      замена: локальный: 9115 # Настоящее имя хоста экспортера черного ящика: порт. Для Windows и macOS замените на - host.docker.internal:9115
 
 Так что нового по сравнению с последним конфигом?
  params  больше не включает цель  . Вместо этого мы добавляем фактические цели в статические конфигурации :   target  . Мы также используем несколько, потому что мы можем сделать это сейчас:
 params:
    модуль: [http_2xx]
  статические_конфигурации:
    - цели:
      - http://prometheus. io # Цель для проверки с http
      - https://prometheus.io # Цель для проверки с помощью https
      - http://example.com:8080 # Цель для проверки с http на порту 8080
 
  relabel_configs  содержит новые правила перемаркировки:
 relabel_configs:
    - source_labels: [__адрес__]
      target_label: __param_target
    - source_labels: [__param_target]
      target_label: экземпляр
    - target_label: __адрес__
      замена: localhost:9115 # Настоящее имя хоста экспортера черного ящика: порт. Для Windows и macOS замените на - host.docker.internal:9115
 
 До применения правил перемаркировки URI запроса Prometheus будет выглядеть следующим образом:  "http://prometheus.io/probe?module=http_2xx"  . После перемаркировки он будет выглядеть так:  "http://localhost:9115/probe?target=http://prometheus.io&module=http_2xx"  .
 Теперь давайте рассмотрим, как это делает каждое правило:
 Сначала мы берем значения из метки  __address__  (которые содержат значения из  целей  ) и записываем их в новую метку  __param_target , которая добавит параметр  цель  к запросам очистки Prometheus:
 переназначить_конфигурации:
    - source_labels: [__адрес__]
      target_label: __param_target
 
 После этого наш воображаемый URI запроса Prometheus теперь имеет целевой параметр:  "http://prometheus. io/probe?target=http://prometheus.io&module=http_2xx"  .
 Затем мы берем значения из метки  __param_target  и создаем экземпляр метки со значениями.
 relabel_configs:
    - source_labels: [__param_target]
      target_label: экземпляр
 
 Наш запрос не изменится, но метрики, которые возвращаются из нашего запроса, теперь будут иметь метку  instance="http://prometheus.io"  .
 После этого записываем значение  localhost:9115  (URI нашего экспортера) в метку  __address__  . Это будет использоваться в качестве имени хоста и порта для запросов очистки Prometheus. Так что он напрямую запрашивает экспортер, а не целевой URI.
 relabel_configs:
    - target_label: __адрес__
      замена: локальный: 9115 # Настоящее имя хоста экспортера черного ящика: порт. Для Windows и macOS замените на - host.docker.internal:9115
 
 Теперь наш запрос  "localhost:9115/probe?target=http://prometheus. io&module=http_2xx"  . Таким образом, мы можем получить фактические цели, получить их как значения меток  экземпляров , позволяя Prometheus сделать запрос к экспортеру черного ящика.
 Часто люди объединяют их с обнаружением конкретной службы. Дополнительные сведения см. в документации по конфигурации. Использование их не проблема, так как они записывают в  __address__  метка точно так же, как  цели , определенные в  static_configs  .
 Вот и все. Перезапустите док-контейнер Prometheus и посмотрите на свои показатели. Обратите внимание, что вы выбрали период времени, когда фактически собирались метрики.
 В этом руководстве вы узнали, как работает шаблон многоцелевого экспортера, как запустить экспортер черного ящика с настроенным модулем и настроить Prometheus с использованием перемаркировки для извлечения метрик с помощью меток зонда.
 Исходный код этой документации является открытым. Пожалуйста, помогите улучшить его, зарегистрировав проблемы или запросы на включение.
 Блог | Прометей 
 Опубликовано: 16 ноября 2021 г., Бартломей Плотка (@bwplotka) Бартек Плотка работает мейнтейнером Prometheus с 2019 года и главным инженером-программистом в Red Hat. Соавтор проекта CNCF Thanos. Посол CNCF и технический руководитель CNCF TAG Observability. В свободное время он вместе с О'Рейли пишет книгу под названием «Эффективный подход». Мнения мои собственные!
 Что мне лично нравится в проекте «Прометей» и одна из многих причин, по которым я присоединился к команде, так это четкий фокус на целях проекта. Prometheus всегда стремился раздвинуть границы, когда речь шла о предоставлении прагматичного, надежного, дешевого, но бесценного мониторинга на основе показателей. Сверхстабильные и надежные API-интерфейсы Prometheus, язык запросов и протоколы интеграции (например, Remote Write и OpenMetrics) позволили экосистеме метрик Cloud Native Computing Foundation (CNCF) расти на этих прочных основаниях. В результате произошли удивительные вещи:
 Мы видим, что экспортеры сообщества получают метрики практически обо всем, например. контейнеры, eBPF, статистика сервера Minecraft и даже здоровье растений при работе в саду.
 Большинство людей в настоящее время ожидают, что облачное программное обеспечение будет иметь конечную точку HTTP/HTTPS /metrics , которую Prometheus может очищать. Концепция, тайно разработанная в Google и впервые реализованная во всем мире в рамках проекта Prometheus.
 Парадигма наблюдаемости изменилась. Мы видим, что SRE и разработчики в значительной степени полагаются на метрики с первого дня, что повышает отказоустойчивость программного обеспечения, возможность отладки и принятие решений на основе данных!
 В конце концов, мы вряд ли увидим кластеры Kubernetes без работающего там Prometheus.
 Сильная направленность сообщества Prometheus позволила другим проектам с открытым исходным кодом также расти, чтобы расширить модель развертывания Prometheus за пределы отдельных узлов (например, Cortex, Thanos и другие). Не говоря уже о поставщиках облачных услуг, использующих API и модель данных Prometheus (например, Amazon Managed Prometheus, Google Cloud Managed Prometheus, Grafana Cloud и другие). Если вы ищете единственную причину успеха проекта «Прометей», то вот она:  Сосредоточение внимания сообщества наблюдателей на том, что важно  .
 В этом (длинном) сообщении блога я хотел бы представить новый режим работы Prometheus под названием «Агент». Он встроен непосредственно в бинарный файл Prometheus. Режим агента отключает некоторые обычные функции Prometheus и оптимизирует двоичный файл для очистки и удаленной записи в удаленные места. Внедрение режима, который сокращает количество функций, позволяет использовать новые модели использования. В этом сообщении в блоге я объясню, почему это меняет правила игры для некоторых развертываний в экосистеме CNCF. Я очень взволнован этим!
 История варианта использования переадресации 
 Основная конструкция Прометея не менялась на протяжении всей жизни проекта. Вдохновленный системой мониторинга Google Borgmon, вы можете развернуть сервер Prometheus вместе с приложениями, которые вы хотите отслеживать, сообщить Prometheus, как к ним добраться, и разрешить собирать текущие значения их показателей через регулярные промежутки времени. Такой метод сбора, который часто называют «моделью вытягивания», является основным принципом, который позволяет Prometheus быть легким и надежным. Кроме того, это позволяет максимально упростить инструментирование приложений и экспортеров, поскольку им нужно только предоставить простую удобочитаемую конечную точку HTTP с текущим значением всех отслеживаемых показателей (в формате OpenMetrics). И все это без сложной push-инфраструктуры и нетривиальных клиентских библиотек. В целом упрощенное типичное развертывание мониторинга Prometheus выглядит следующим образом:
 Это прекрасно работает, и мы видели миллионы успешных развертываний, подобных этому, которые обрабатывают десятки миллионов активных серий. Некоторые из них предназначены для более длительного хранения, например, два года или около того. Все они позволяют запрашивать, предупреждать и записывать метрики, полезные как для администраторов кластера, так и для разработчиков.
 Однако облачный мир постоянно растет и развивается. С ростом количества управляемых решений Kubernetes и кластеров, создаваемых по запросу за считанные секунды, мы наконец-то можем относиться к кластерам как к «скоту», а не как к «домашним животным» (другими словами, мы меньше заботимся об отдельных их экземплярах). В некоторых случаях решения даже не имеют понятия кластера, например. kcp, Fargate и другие платформы.
 Другим интересным вариантом использования является понятие кластеров или сетей  Edge . В таких отраслях, как телекоммуникации, автомобилестроение и устройства IoT, использующих облачные технологии, мы видим все больше и больше кластеров гораздо меньшего размера с ограниченным объемом ресурсов. Это вынуждает передавать все данные (включая наблюдаемость) удаленным, более крупным аналогам, поскольку на этих удаленных узлах почти ничего не может храниться.
 Что это значит? Это означает, что данные мониторинга должны быть каким-то образом агрегированы, представлены пользователям, а иногда даже сохранены в  глобальный уровень . Это часто называют функцией  Global-View .
 Наивно, мы могли подумать о реализации этого, либо поместив Prometheus на этот глобальный уровень и собирая метрики по удаленным сетям, либо отправляя метрики непосредственно из приложения в центральное расположение для целей мониторинга. Позвольте мне объяснить, почему обе идеи, как правило,  очень  плохие идеи:
 🔥 Очистка границ сети может быть сложной задачей, если она добавляет новые неизвестные в конвейер мониторинга. Модель локального вытягивания позволяет Prometheus узнать, почему именно у целевой метрики возникают проблемы и когда. Возможно, он не работает, неправильно настроен, перезапущен, слишком медленный, чтобы предоставить нам метрики (например, загруженность ЦП), не может быть обнаружен с помощью обнаружения служб, у нас нет учетных данных для доступа или просто DNS, сеть или весь кластер не работает. Помещая наш парсер за пределы сети, мы рискуем потерять часть этой информации, внося ненадежность в парсер, не связанный с отдельной целью. Кроме того, мы рискуем полностью потерять важную видимость, если сеть временно не работает. Пожалуйста, не делай этого. Это того не стоит. (:
 🔥 Передавать метрики напрямую из приложения в какое-то центральное место тоже плохо. Особенно когда вы контролируете большой парк, вы буквально ничего не знаете, когда не видите метрики из удаленных приложений. Приложение не работает? Мой ресивер не работает? Может приложение не авторизовалось? Может быть, ему не удалось получить IP-адрес моего удаленного кластера? Может быть, это слишком медленно? Может сеть глючит? Хуже того, вы можете даже не знать, что данные некоторых целевых приложений отсутствуют. И вы даже не получите многого, поскольку вам нужно отслеживать состояние и статус всего, что должно отправлять данные. Такой дизайн требует тщательного анализа, поскольку он может слишком легко привести к провалу.
  ПРИМЕЧАНИЕ.  Бессерверные функции и недолговечные контейнеры часто являются теми случаями, когда мы рассматриваем отправку из приложения как спасение. Однако на этом этапе мы говорим о событиях или фрагментах метрик, которые мы, возможно, захотим объединить в более долгосрочные временные ряды. Эта тема обсуждается здесь, не стесняйтесь вносить свой вклад и помогать нам лучше поддерживать эти дела!
 Prometheus представил три способа поддержки случая глобального просмотра, каждый со своими плюсами и минусами. Кратко пройдемся по ним. На схеме ниже они показаны оранжевым цветом:
  Федерация  была представлена как первая функция для целей агрегирования. Это позволяет серверу Prometheus глобального уровня очищать подмножество метрик от листа Prometheus. Такая «федеративная» очистка уменьшает количество неизвестных в сетях, поскольку метрики, предоставляемые конечными точками федерации, включают временные метки исходных образцов. Тем не менее, он обычно страдает от невозможности объединить все метрики и не потерять данные во время более длинных сетевых разделов (минут).
  Prometheus Remote Read  позволяет выбирать необработанные метрики из базы данных удаленного сервера Prometheus без прямого запроса PromQL. Вы можете развернуть Prometheus или другие решения (например, Thanos) на глобальном уровне, чтобы выполнять запросы PromQL к этим данным, получая необходимые метрики из нескольких удаленных мест. Это действительно мощно, поскольку позволяет хранить данные «локально» и получать к ним доступ только при необходимости. К сожалению, есть и минусы. Без таких функций, как Query Pushdown, мы в крайних случаях извлекаем ГБ сжатых данных метрик для ответа на один запрос. Кроме того, если у нас есть сетевой раздел, мы временно слепы. И последнее, но не менее важное: некоторые правила безопасности не разрешают входящий трафик, а разрешают только исходящий.
 Наконец, у нас есть  Prometheus Remote Write  , который кажется самым популярным выбором в настоящее время. Поскольку режим агента ориентирован на варианты использования удаленной записи, давайте объясним его более подробно.
 Удаленная запись 
 Протокол удаленной записи Prometheus позволяет нам пересылать (поток) все или часть метрик, собранных Prometheus, в удаленное место. Вы можете настроить Prometheus для пересылки некоторых метрик (если хотите, со всеми метаданными и экземплярами!) в одно или несколько мест, которые поддерживают API удаленной записи. Фактически, Prometheus поддерживает как получение, так и отправку удаленной записи, поэтому вы можете развернуть Prometheus на глобальном уровне для получения этого потока и агрегирования данных между кластерами.
 Хотя официальная спецификация Prometheus Remote Write API находится на стадии рассмотрения, экосистема приняла протокол удаленной записи в качестве протокола экспорта метрик по умолчанию. Например, Cortex, Thanos, OpenTelemetry и облачные сервисы, такие как Amazon, Google, Grafana, Logz.io и т. д., поддерживают прием данных через удаленную запись.
 Проект Prometheus также предлагает официальные тесты на соответствие для своих API, например. соответствие отправителю удаленной записи для решений, предлагающих возможности клиента удаленной записи. Это отличный способ быстро определить, правильно ли вы реализуете этот протокол.
 Потоковая передача данных из такого парсера позволяет использовать варианты использования Global View, позволяя хранить данные метрик в централизованном расположении. Это также позволяет разделить задачи, что полезно, когда приложения управляются другими командами, а не конвейерами наблюдения или мониторинга. Кроме того, именно поэтому Remote Write выбирают поставщики, которые хотят снять с клиентов как можно больше работы.
 Подожди секунду, Бартек. Вы только что упомянули, что загружать метрики напрямую из приложения — не лучшая идея!
 Конечно, но самое удивительное то, что даже с удаленной записью Prometheus по-прежнему использует модель извлечения для сбора метрик из приложений, что дает нам представление об этих различных режимах отказа. После этого мы группируем образцы и серии и экспортируем, реплицируем (проталкиваем) данные на конечные точки удаленной записи, ограничивая количество неизвестных данных мониторинга, которые есть в центральной точке!
 Важно отметить, что надежная и эффективная реализация удаленной записи — это нетривиальная задача. Сообщество Prometheus потратило около трех лет на разработку стабильной и масштабируемой реализации. Мы несколько раз повторно реализовали WAL (журнал с упреждающей записью), добавили внутренние очереди, сегментирование, интеллектуальные отсрочки и многое другое. Все это скрыто от пользователя, который может наслаждаться высокопроизводительной потоковой передачей или большим количеством метрик, хранящихся в централизованном месте.
 Практический пример удаленной записи: учебное пособие по Katacoda 
 Все это не ново для Прометея. Многие из нас уже используют Prometheus для очистки всех необходимых метрик и удаленной записи всех или некоторых из них в удаленные места.
 Предположим, вы хотите попробовать на практике возможности удаленного письма. В этом случае мы рекомендуем руководство Thanos Katacoda по удаленному написанию метрик из Prometheus, в котором объясняются все шаги, необходимые Prometheus для пересылки всех метрик в удаленное место. это  бесплатно  , просто зарегистрируйте учетную запись и наслаждайтесь уроком! 🤗
 Обратите внимание, что в этом примере в качестве удаленного хранилища используется Thanos в режиме приема. В настоящее время вы можете использовать множество других проектов, совместимых с API удаленной записи.
 Итак, если удаленная запись работает нормально, зачем мы добавили в Prometheus специальный режим Агента?
 Режим агента Прометея 
 Из Prometheus  v2.32.0  (следующий релиз) каждый сможет запустить бинарник Prometheus с экспериментальной  --enable-feature=флаг агента . Если вы хотите попробовать его до выпуска, не стесняйтесь использовать Prometheus v2.32.0-beta.0 или наш образ  quay.io/prometheus/prometheus:v2.32.0-beta.0 .
 Режим агента оптимизирует Prometheus для варианта использования удаленной записи. Он отключает запросы, оповещения и локальное хранилище и заменяет их настраиваемой TSDB WAL. Все остальное остается прежним: логика парсинга, обнаружение сервисов и соответствующая конфигурация. Его можно использовать в качестве замены Prometheus, если вы хотите просто переслать свои данные на удаленный сервер Prometheus или в любой другой проект, совместимый с Remote-Write. По сути это выглядит так:
 Лучшее в Prometheus Agent то, что он встроен в Prometheus. Те же API парсинга, та же семантика, та же конфигурация и механизм обнаружения.
 Каковы преимущества использования режима агента, если вы планируете не запрашивать данные и не оповещать о них локально, а передавать метрики извне? Есть несколько:
 В первую очередь эффективность. Наш настроенный агент TSDB WAL удаляет данные сразу после успешной записи. Если он не может связаться с удаленной конечной точкой, он временно сохраняет данные на диске до тех пор, пока удаленная конечная точка не вернется в оперативный режим. В настоящее время это ограничено только двухчасовым буфером, подобно Прометею без агента, который, надеюсь, скоро будет разблокирован. Это означает, что нам не нужно создавать блоки данных в памяти. Нам не нужно поддерживать полный индекс для запросов. По сути, режим агента использует часть ресурсов, которые обычный сервер Prometheus использовал бы в аналогичной ситуации.
 Имеет ли значение эта эффективность? Да! Как мы уже упоминали, каждый ГБ памяти и каждое ядро ЦП, используемое в пограничных кластерах, имеет значение для некоторых развертываний. С другой стороны, парадигма выполнения мониторинга с использованием метрик в наши дни достаточно зрелая. Это означает, что чем более релевантные метрики с большей кардинальностью вы можете отправить по той же цене, тем лучше.
  ПРИМЕЧАНИЕ.  С введением режима агента исходный режим сервера Prometheus по-прежнему остается рекомендуемым, стабильным и поддерживаемым режимом. Агентский режим с удаленным хранилищем создает дополнительную сложность. Используйте с осторожностью.
 Во-вторых, преимущество нового режима агента заключается в том, что он упрощает горизонтальную масштабируемость для приема данных. Это то, чем я взволнован больше всего. Позвольте мне объяснить, почему.
 Мечта: Автоматически масштабируемый прием метрик 
 Настоящее автоматически масштабируемое решение для парсинга должно основываться на количестве целевых метрик и количестве метрик, которые они предоставляют. Чем больше данных мы собираем, тем больше экземпляров Prometheus мы развертываем автоматически. Если количество целей или их метрик уменьшится, мы можем уменьшить масштаб и удалить пару экземпляров. Это устранит бремя ручной настройки размера Prometheus и избавит от необходимости чрезмерно выделять Prometheus для ситуаций, когда кластер временно мал.
 Когда Prometheus работал в режиме сервера, этого было трудно добиться. Это связано с тем, что Prometheus в режиме сервера сохраняет состояние. Все, что собрано, остается как есть в одном месте. Это означает, что перед прекращением процедуры масштабирования потребуется выполнить резервное копирование собранных данных в существующие экземпляры. Тогда у нас возникнет проблема перекрывающихся царапин, вводящих в заблуждение маркеров устаревания и т. д.
 Кроме того, нам понадобится какой-нибудь запрос глобального представления, способный агрегировать все выборки во всех экземплярах (например, Thanos Query или Promxy). И последнее, но не менее важное: использование ресурсов Prometheus в режиме сервера зависит не только от приема. Предупреждения, запись, запросы, уплотнение, удаленная запись и т. д. могут потребовать больше или меньше ресурсов, независимо от количества целевых показателей.
 Режим агента по существу перемещает обнаружение, очистку и удаленную запись в отдельную микрослужбу. Это позволяет сфокусировать операционную модель только на приеме пищи. В результате Prometheus в режиме агента более или менее не имеет состояния. Да, чтобы избежать потери метрик, нам нужно развернуть пару агентов HA и подключить к ним постоянный диск. Но с технической точки зрения, если у нас есть тысячи метрических целей (например, контейнеров), мы можем развернуть несколько агентов Prometheus и безопасно изменить, какая реплика очищает какие цели. Это связано с тем, что, в конце концов, все образцы будут помещены в одно и то же центральное хранилище.
 В целом, Prometheus в режиме агента обеспечивает простые горизонтальные возможности автоматического масштабирования парсинга на основе Prometheus, которые могут реагировать на динамические изменения целевых показателей. Это определенно то, на что мы будем обращать внимание в сообществе Prometheus Kubernetes Operator в будущем.
 Теперь давайте посмотрим на текущее состояние режима агента в Prometheus. Готов ли он к использованию?
 Режим агента был проверен в масштабе 
 Следующий выпуск Prometheus будет включать режим агента в качестве экспериментальной функции. Флаги, API и формат WAL на диске могут измениться. Но производительность реализации уже проверена в бою благодаря работе Grafana Labs с открытым исходным кодом.
 Первоначальная реализация пользовательского WAL нашего агента была вдохновлена текущим WAL TSDB сервера Prometheus и создана Робертом Фратто в 2019 году под руководством Тома Уилки, сопровождающего Prometheus. Затем он использовался в проекте Grafana Agent с открытым исходным кодом, который с тех пор использовался многими клиентами Grafana Cloud и членами сообщества. Учитывая зрелость решения, пришло время пожертвовать реализацию Prometheus для нативной интеграции и более широкого внедрения. Роберт (Grafana Labs) с помощью Шрикришны (Red Hat) и сообщества перенес код в кодовую базу Prometheus, которая была объединена с  главная  2 недели назад!
 Процесс пожертвования прошел довольно гладко. Поскольку некоторые сопровождающие Prometheus ранее вносили свой вклад в этот код в рамках агента Grafana, и поскольку новый WAL вдохновлен собственным WAL Prometheus, текущим сопровождающим Prometheus TSDB не составило труда взять его на полное обслуживание! Также очень помогает то, что Роберт присоединяется к команде Prometheus в качестве сопровождающего TSDB (поздравляем!).
 А теперь давайте объясним, как им пользоваться! (:
 Подробное описание использования режима агента 
 С этого момента, если вы покажете вывод справки Prometheus (флаг  --help ), вы должны увидеть примерно следующее:
 использование: прометей []
Сервер мониторинга Prometheus
Флаги:
  -h, --help Показать контекстно-зависимую справку (также попробуйте --help-long и --help-man). 
      (... другие флаги)
      --storage.tsdb.path="данные/"
                                 Базовый путь для хранения метрик. Используйте только в режиме сервера.
      --storage.agent.path="агент данных/"
                                 Базовый путь для хранения метрик. Использовать только в режиме агента.
      (... другие флаги)
      --enable-feature= ... Имена функций, разделенные запятыми, для включения. Допустимые параметры: агент, экземпляр-хранилище, расширение-внешние-метки, моментальный снимок-памяти-при-выключении, promql-at-modifier, promql-negative-offset, удаленный-запись-приемник,
                                 дополнительные метрики очистки, менеджер по обнаружению новых услуг. Подробнее см. https://prometheus.io/docs/prometheus/latest/feature_flags/.
 
 Поскольку режим агента находится за флагом функции, как упоминалось ранее, используйте флаг  --enable-feature=agent  для запуска Prometheus в режиме агента. Теперь остальные флаги либо для сервера, либо для агента, либо только для определенного режима. Вы можете увидеть, какой флаг для какого режима, проверив последнее предложение строки справки флага. «Использовать только в режиме сервера» означает, что это только для режима сервера. Если вы не видите подобного упоминания, это означает, что флаг используется совместно.
 Режим агента принимает ту же конфигурацию очистки с теми же параметрами обнаружения и удаленной записи.
 Он также предоставляет веб-интерфейс с отключенными возможностями запросов, но показывает информацию о сборке, конфигурации, целях и информации об обнаружении служб, как на обычном сервере Prometheus.
 Практический пример агента Prometheus: руководство по Katacoda 
 Аналогично учебному пособию по удаленной записи Prometheus, если вы хотите попробовать на практике возможности агента Prometheus, мы рекомендуем учебное пособие Thanos Katacoda для агента Prometheus, в котором объясняется, насколько просто запустить агент Prometheus.
 Резюме 
 Надеюсь, вам было интересно! В этом посте мы рассмотрели новые случаи, которые появились, например:
. пограничные кластеры
 сети с ограниченным доступом
 большое количество кластеров
 эфемерные и динамические кластеры
 Затем мы объяснили новый режим агента Prometheus, который позволяет эффективно пересылать очищенные метрики на удаленные конечные точки записи.
 Как всегда, если у вас есть какие-либо вопросы или отзывы, не стесняйтесь отправить заявку на GitHub или задать вопросы в списке рассылки.
 Этот пост в блоге является частью согласованного выпуска между CNCF, Grafana и Prometheus. Не стесняйтесь также читать объявление CNCF и взгляд на агента Grafana, который лежит в основе агента Prometheus.
 Опубликовано: 14 октября 2021 г. Ричардом «RichiH» Хартманном Сегодня мы запускаем программу соответствия Prometheus с целью обеспечения взаимодействия между различными проектами и поставщиками в пространстве мониторинга Prometheus. В то время как юридические документы все еще нуждаются в доработке, мы провели тесты и считаем, что ниже наш первый раунд результатов. В рамках этого запуска Юлиус Волц обновил результаты своего теста PromQL.
 В качестве краткого напоминания: программа называется Prometheus  Conformance  , программное обеспечение может быть  совместимым  для конкретных тестов, что приводит к рейтингу совместимости  . Номенклатура может показаться сложной, но она позволяет нам говорить на эту тему, не используя бесконечные словесные змеи.
 Новые категории
 Призыв к действию
 Зарегистрироваться для тестирования
 Полная совместимость с Прометеем
 Проекты
 ААС
 Агент/Сборщик
 Прохождение
 Не проходит
 новых категорий 
 Мы обнаружили, что довольно сложно рассуждать о том, что нужно применять к какому программному обеспечению. Чтобы помочь разобраться в моих мыслях, мы создали обзор, в котором представлены четыре новые категории, в которые мы можем поместить программное обеспечение:
. Показатели показателей
 Агенты/Коллекционеры
 Серверные части хранилища Prometheus
 Полная совместимость с Прометеем
 Призыв к действию 
 Обратная связь очень приветствуется. Возможно, вопреки интуиции, мы хотим, чтобы сообщество, а не только команда Prometheus, формировало эти усилия. Чтобы помочь с этим, мы запустим WG Conformance в Prometheus. Как и в случае с WG Docs и WG Storage, они будут общедоступными, и мы активно приглашаем к участию.
 Как мы недавно упоминали, соотношение тех, кто поддерживает Prometheus, и тех, кто принимает его, на удивление или шокирующе низкое. Другими словами, мы надеемся, что экономические стимулы, связанные с совместимостью Prometheus, побудят поставщиков выделять ресурсы для создания тестов вместе с нами. Если вы всегда хотели внести свой вклад в Prometheus в рабочее время, это может быть подходящим способом; и способ, который заставит вас коснуться многих очень важных аспектов Прометея. Связаться с нами можно разными способами.
 Зарегистрироваться для тестирования 
 Вы можете использовать те же каналы связи, чтобы связаться с нами, если хотите зарегистрироваться для прохождения тестирования. Как только документы будут готовы, мы передадим контактную информацию и договорные операции в CNCF.
 Полная совместимость с Prometheus 
 Мы знаем, какие тесты мы хотим построить, но мы еще не готовы. Как было объявлено ранее, было бы несправедливо обвинять в этом проекты или поставщиков. Таким образом, тестовые прокладки считаются пройденными. В настоящее время полуручной характер, например. Тесты PromQL, проведенные Julius на этой неделе, означают, что Julius тестировал отправку данных через Prometheus Remote Write в большинстве случаев как часть тестирования PromQL. Мы повторно используем его результаты более чем одним способом. Скоро это будет распутано, и больше тестов с разных точек зрения будет продолжать повышать требования и, следовательно, доверие конечного пользователя.
 Имеет смысл рассматривать проекты и предложения как услугу в двух наборах.
 проектов 
 Прохождение 
 Кортекс 1.10.0
 М3 1.3.0
 Промышленная шкала 0.6.2
 Танос 0.23.1
 Не проходит 
 VictoriaMetrics 1.67.0 не проходит и не собирается проходить. В духе доверия конечных пользователей мы решили отслеживать их результаты, пока они позиционируют себя как замену Prometheus.
 ААС 
 Прохождение 
 Хроносфера
 Графана Облако
 Не проходит 
 Управляемая служба Amazon для Prometheus
 Облачная управляемая служба Google для Prometheus
 Новая реликвия
 Системный монитор
 NB. Поскольку Amazon Managed Service для Prometheus основан на Cortex, как и Grafana Cloud, мы ожидаем, что они перейдут после следующего цикла обновления.
 Агент/Коллекционер 
 Прохождение 
 Агент Графана 0. 19.0
 Сборщик OpenTelemetry 0.37.0
 Прометей 2.30.3
 Не проходит 
 Телеграф 1.20.2
 Древесина Вектор 0.16.1
 Агент VictoriaMetrics 1.67.0
 NB: мы тестировали Vector 0.16.1 вместо 0.17.0, потому что для 0.17.0 нет бинарных загрузок, а наша тестовая цепочка инструментов в настоящее время ожидает бинарные файлы.
 Опубликовано: 10 июня 2021 г. Ричардом «RichiH» Хартманном Согласно Оскару Уайльду, подражание — самая искренняя форма лести.
 Имена «Прометей» и «Танос» недавно были присвоены группой вымогателей. Мы мало что можем с этим сделать, кроме как сообщить вам, что это происходит. Вы тоже мало что можете сделать, кроме как знать, что это происходит.
 Хотя у нас  НЕ  есть основания полагать, что эта группа попытается обманом заставить кого-либо загрузить поддельные двоичные файлы наших проектов, мы по-прежнему рекомендуем следовать общепринятым методам цепочки поставок и безопасности. При развертывании программного обеспечения делайте это с помощью одного из следующих механизмов:
 Бинарные загрузки с официальных страниц релизов Prometheus и Thanos с проверкой контрольных сумм.
 загрузки Docker из официальных репозиториев, контролируемых проектом: Прометей: https://quay.io/repository/prometheus/prometheus и https://hub.docker.com/r/prom/prometheus
 Танос: https://quay.io/repository/thanos/thanos и https://hub.docker.com/r/thanosio/thanos
 Двоичные файлы, образы или контейнеры из дистрибутивов, которым вы доверяете
 Двоичные файлы, образы или контейнеры из ваших собственных внутренних групп проверки и развертывания программного обеспечения
 Самостоятельная сборка из исходников
 Если вы не можете разумно доверять конкретному провидению и цепочке поставок, вам не следует использовать программное обеспечение.
 Поскольку существует ненулевая вероятность того, что группа вымогателей намеренно выбрала имена и, таким образом, может наткнуться на это сообщение в блоге: пожалуйста, остановитесь. Как с программой-вымогателем, так и с выбором имени.
 Опубликовано: 5 мая 2021 г. Ричардом «RichiH» Хартманном Как было объявлено CNCF и нами, мы запускаем программу соответствия Prometheus.
 Чтобы дать всем представление о состоянии экосистемы перед официальным запуском тестов, мы хотели продемонстрировать новейшее дополнение к нашему небольшому набору тестовых наборов: набор тестов Prometheus Remote Write на соответствие требованиям тестирует отправляющую часть протокола Remote Write против наша спецификация.
 Во время PromCon в понедельник Том Уилки представил результаты тестов с момента записи несколько недель назад. В живом разделе у него уже было обновление. Два дня спустя у нас есть еще два обновления: Добавлен инструмент конвейера наблюдаемости Vector, а также новые версии существующих систем.
 Итак, без лишних слов, текущие результаты в алфавитном порядке:
 Отправитель  Версия  Оценка
 Агент Графана  0. 13.1   100% 
 Прометей  2.26.0   100% 
 Сборщик OpenTelemetry  0.26.0   41% 
 Телеграф  1.18.2   65% 
 Древесина Вектор  0.13.1   35% 
 Агент VictoriaMetrics  1.59.0   76% 
 Необработанные результаты:
 --- ПРОЙДЕН: TestRemoteWrite/grafana (0,01 с)
    --- ПРОЙДЕНО: TestRemoteWrite/grafana/Counter (10,02 с)
    --- ПРОЙДЕНО: TestRemoteWrite/grafana/EmptyLabels (10,02 с)
    --- ПРОШЕЛ: TestRemoteWrite/grafana/Gauge (10,02 с)
    --- ПРОЙДЕНО: TestRemoteWrite/grafana/Headers (10.02 с)
    --- ПРОЙДЕНО: TestRemoteWrite/grafana/Histogram (10,02 с)
    --- ПРОЙДЕНО: TestRemoteWrite/grafana/HonorLabels (10,02 с)
    --- ПРОЙДЕНО: TestRemoteWrite/grafana/InstanceLabel (10,02 с)
    --- ПРОЙДЕНИЕ: TestRemoteWrite/grafana/Invalid (10. 02 с)
    --- ПРОЙДЕНО: TestRemoteWrite/grafana/JobLabel (10,02 с)
    --- ПРОЙДЕН: TestRemoteWrite/grafana/NameLabel (10.02 с)
    --- ПРОЙДЕНО: TestRemoteWrite/grafana/Ordering (26,12 с)
    --- ПРОЙДЕНО: TestRemoteWrite/grafana/RepeatedLabels (10,02 с)
    --- ПРОЙДЕНО: TestRemoteWrite/grafana/SortedLabels (10,02 с)
    --- ПРОЙДЕН: TestRemoteWrite/grafana/Staleness (10.01 с)
    --- ПРОЙДИТЕ: TestRemoteWrite/grafana/Summary (10.01 с)
    --- ПРОЙДЕНИЕ: TestRemoteWrite/grafana/Timestamp (10.01 с)
    --- ПРОЙДЕН: TestRemoteWrite/grafana/Up (10,02 с)
--- ПРОЙДЕН: TestRemoteWrite/prometheus (0,01 с)
    --- ПРОЙДЕН: TestRemoteWrite/prometheus/Counter (10,02 с)
    --- ПРОЙДЕН: TestRemoteWrite/prometheus/EmptyLabels (10.02 с)
    --- ПРОЙДЕН: TestRemoteWrite/prometheus/Gauge (10,02 с)
    --- ПРОЙДЕН: TestRemoteWrite/prometheus/Headers (10.02 с)
    --- ПРОЙДЕНО: TestRemoteWrite/prometheus/Histogram (10,02 с)
    --- ПРОЙДЕНО: TestRemoteWrite/prometheus/HonorLabels (10,02 с)
    --- ПРОЙДЕН: TestRemoteWrite/prometheus/InstanceLabel (10,02 с)
    --- ПРОЙДЕНИЕ: TestRemoteWrite/prometheus/Invalid (10. 02 с)
    --- ПРОЙДЕНО: TestRemoteWrite/prometheus/JobLabel (10,02 с)
    --- ПРОЙДЕН: TestRemoteWrite/prometheus/NameLabel (10.03 с)
    --- ПРОЙДИТЕ: TestRemoteWrite/prometheus/Ordering (24.99с)
    --- ПРОЙДЕН: TestRemoteWrite/prometheus/RepeatedLabels (10.02 с)
    --- ПРОЙДЕНО: TestRemoteWrite/prometheus/SortedLabels (10.02 с)
    --- ПРОЙДЕН: TestRemoteWrite/prometheus/Staleness (10.02 с)
    --- ПРОЙДЕНО: TestRemoteWrite/prometheus/Summary (10,02 с)
    --- ПРОЙДИТЕ: TestRemoteWrite/prometheus/Timestamp (10,02 с)
    --- ПРОЙДЕНО: TestRemoteWrite/prometheus/Up (10,02 с)
--- FAIL: TestRemoteWrite/otelcollector (0,00 с)
    --- FAIL: TestRemoteWrite/otelcollector/Counter (10.01 с)
    --- FAIL: TestRemoteWrite/otelcollector/Histogram (10,01 с)
    --- FAIL: TestRemoteWrite/otelcollector/InstanceLabel (10.01 с)
    --- FAIL: TestRemoteWrite/otelcollector/Invalid (10.01s)
    --- FAIL: TestRemoteWrite/otelcollector/JobLabel (10.01 с)
    --- FAIL: TestRemoteWrite/otelcollector/Ordering (13,54 с)
    --- FAIL: TestRemoteWrite/otelcollector/RepeatedLabels (10. 01 с)
    --- FAIL: TestRemoteWrite/otelcollector/Staleness (10.01 с)
    --- FAIL: TestRemoteWrite/otelcollector/Summary (10.01 с)
    --- FAIL: TestRemoteWrite/otelcollector/Up (10.01 с)
    --- ПРОЙДЕНО: TestRemoteWrite/otelcollector/EmptyLabels (10.01 с)
    --- ПРОЙДЕНО: TestRemoteWrite/otelcollector/Gauge (10,01 с)
    --- ПРОЙДЕНО: TestRemoteWrite/otelcollector/Headers (10.01 с)
    --- ПРОЙДЕНО: TestRemoteWrite/otelcollector/HonorLabels (10.01 с)
    --- ПРОЙДЕНО: TestRemoteWrite/otelcollector/NameLabel (10.01 с)
    --- ПРОЙДЕНО: TestRemoteWrite/otelcollector/SortedLabels (10.01 с)
    --- ПРОЙДЕН: TestRemoteWrite/otelcollector/Timestamp (10,01 с)
--- FAIL: TestRemoteWrite/telegraf (0,01 с)
    --- FAIL: TestRemoteWrite/telegraf/EmptyLabels (14,60 с)
    --- FAIL: TestRemoteWrite/telegraf/HonorLabels (14,61 с)
    --- FAIL: TestRemoteWrite/telegraf/Invalid (14,61 с)
    --- FAIL: TestRemoteWrite/telegraf/RepeatedLabels (14,61 с)
    --- FAIL: TestRemoteWrite/telegraf/Staleness (14. 59с)
    --- FAIL: TestRemoteWrite/telegraf/Up (14,60 с)
    --- ПРОЙДЕН: TestRemoteWrite/telegraf/Counter (14,61 с)
    --- ПРОЙДЕН: TestRemoteWrite/telegraf/Gauge (14,60 с)
    --- ПРОЙДЕН: TestRemoteWrite/telegraf/Headers (14,61 с)
    --- ПРОЙДЕНО: TestRemoteWrite/telegraf/Histogram (14,61 с)
    --- ПРОЙДЕНО: TestRemoteWrite/telegraf/InstanceLabel (14,61 с)
    --- ПРОЙДЕНО: TestRemoteWrite/telegraf/JobLabel (14,61 с)
    --- ПРОЙДЕН: TestRemoteWrite/telegraf/NameLabel (14,60 с)
    --- ПРОЙДИТЕ: TestRemoteWrite/telegraf/Ordering (14,61 с)
    --- ПРОЙДЕНО: TestRemoteWrite/telegraf/SortedLabels (14,61 с)
    --- ПРОЙДИТЕ: TestRemoteWrite/telegraf/Summary (14,60 с)
    --- ПРОЙДЕНИЕ: TestRemoteWrite/telegraf/Timestamp (14,61 с)
--- FAIL: TestRemoteWrite/vector (0,01 с)
    --- FAIL: TestRemoteWrite/vector/Counter (10,02 с)
    --- FAIL: TestRemoteWrite/vector/EmptyLabels (10.01 с)
    --- FAIL: TestRemoteWrite/vector/Headers (10.02 с)
    --- FAIL: TestRemoteWrite/vector/HonorLabels (10,02 с)
    --- FAIL: TestRemoteWrite/vector/InstanceLabel (10,02 с)
    --- FAIL: TestRemoteWrite/vector/Invalid (10. 02s)
    --- FAIL: TestRemoteWrite/vector/JobLabel (10.01 с)
    --- FAIL: TestRemoteWrite/vector/Ordering (13.01 с)
    --- FAIL: TestRemoteWrite/vector/RepeatedLabels (10,02 с)
    --- FAIL: TestRemoteWrite/vector/Staleness (10,02 с)
    --- FAIL: TestRemoteWrite/vector/Up (10,02 с)
    --- ПРОЙДЕНО: TestRemoteWrite/vector/Gauge (10,02 с)
    --- ПРОШЕЛ: TestRemoteWrite/вектор/гистограмма (10,02 с)
    --- ПРОЙДЕН: TestRemoteWrite/vector/NameLabel (10,02 с)
    --- ПРОЙДЕНО: TestRemoteWrite/vector/SortedLabels (10,02 с)
    --- ПРОЙДЕНО: TestRemoteWrite/vector/Summary (10,02 с)
    --- ПРОЙДЕН: TestRemoteWrite/vector/Timestamp (10,02 с)
--- НЕУДАЧА: TestRemoteWrite/vmagent (0,01 с)
    --- FAIL: TestRemoteWrite/vmagent/Invalid (20,66 с)
    --- FAIL: TestRemoteWrite/vmagent/Ordering (22,05 с)
    --- FAIL: TestRemoteWrite/vmagent/RepeatedLabels (20,67 с)
    --- FAIL: TestRemoteWrite/vmagent/Staleness (20,67 с)
    --- ПРОШЕЛ: TestRemoteWrite/vmagent/Counter (20,67 с)
    --- ПРОШЕЛ: TestRemoteWrite/vmagent/EmptyLabels (20,64 с)
    --- ПРОШЕЛ: TestRemoteWrite/vmagent/Gauge (20,66 с)
    --- ПРОШЕЛ: TestRemoteWrite/vmagent/Headers (20,64 с)
    --- ПРОШЕЛ: TestRemoteWrite/vmagent/Histogram (20,66 с)
    --- ПРОЙДЕНО: TestRemoteWrite/vmagent/HonorLabels (20,66 с)
    --- ПРОЙДЕНО: TestRemoteWrite/vmagent/InstanceLabel (20,66 с)
    --- ПРОШЕЛ: TestRemoteWrite/vmagent/JobLabel (20,66 с)
    --- ПРОЙДЕНО: TestRemoteWrite/vmagent/NameLabel (20,66 с)
    --- ПРОШЕЛ: TestRemoteWrite/vmagent/SortedLabels (20,66 с)
    --- ПРОШЕЛ: TestRemoteWrite/vmagent/Summary (20,66 с)
    --- ПРОЙДЕН: TestRemoteWrite/vmagent/Timestamp (20,67 с)
    --- ПРОШЕЛ: TestRemoteWrite/vmagent/Up (20,66 с)
 
 Мы будем больше работать над улучшением наших наборов тестов, добавляя больше тестов и добавляя новые целевые тесты. Если вы хотите помочь нам, подумайте о том, чтобы добавить больше в наш список интеграций удаленной записи.
 Опубликовано: 3 мая 2021 г., Ричард «RichiH» Хартманн Prometheus — это стандарт мониторинга метрик в облачной среде и за ее пределами. Чтобы обеспечить совместимость, защитить пользователей от неожиданностей и обеспечить больше параллельных инноваций, проект Prometheus представляет программу соответствия Prometheus с помощью CNCF для сертификации соответствия компонентов и совместимости Prometheus.
 Ожидается, что Совет управляющих CNCF официально рассмотрит и утвердит программу на своем следующем заседании. Мы приглашаем более широкое сообщество помочь улучшить наши тесты на этом этапе ввода в эксплуатацию.
 С помощью нашего обширного и расширяющегося набора тестов проекты и поставщики могут определить соответствие нашим спецификациям и совместимость с экосистемой Prometheus.
 При запуске мы предлагаем тесты на соответствие для трех компонентов:
 PromQL (требуется ручная интерпретация, несколько завершено)
 Удаленное чтение-запись (полностью автоматизированное, WIP)
 OpenMetrics (частично автоматический, частично полный, потребуется анкета)
 Мы планируем добавить больше компонентов. Тесты для удаленного чтения Prometheus или нашего хранилища данных / TSDB, вероятно, станут следующими дополнениями. Мы открыто приглашаем всех расширять и улучшать существующие тесты, а также отправлять новые.
 Программа соответствия Prometheus работает следующим образом:
 Для каждого компонента будет пометка "foo YYYY-MM compatible", т.е. «Совместимость с OpenMetrics 2021-05», «Совместимость с PromQL 2021-05» и «Совместимость с Prometheus Remote Write 2021-05». Любой проект или поставщик может представить свою документацию по соответствию. При достижении 100% оценка будет предоставлена.
 Для любого полного программного обеспечения будет пометка «Prometheus x.y совместимый», например. «Прометей 2.26 совместим». Соответствующие оценки соответствия компонентов умножаются. При достижении 100% оценка будет предоставлена.
 Например, агент Prometheus поддерживает как OpenMetrics, так и удаленную запись Prometheus, но не PromQL. Таким образом, умножаются только оценки соответствия для OpenMetrics и Prometheus Remote Write.
 Знаки соответствия и совместимости действительны в течение 2 дополнительных выпусков или 12 недель, в зависимости от того, что дольше.
 Опубликовано: 18 февраля 2021 г., Ганеш Вернекар Вы когда-нибудь выбирали 10 лучших временных рядов для чего-то, но вместо 10 получали 100? Если да, то это для вас. Позвольте мне рассказать вам, в чем основная проблема и как я ее исправил.
 В настоящее время запрос  topk()  имеет смысл только как мгновенный запрос, который дает ровно  тыс.  результатов, но когда вы запускаете его как запрос диапазона, вы можете получить гораздо больше, чем  тыс.  результатов, поскольку каждый шаг оценивается независимо. это 9Модификатор 0055 @  позволяет исправить ранжирование для всех шагов в запросе диапазона.
 В Prometheus v2.25.0 мы представили новый модификатор PromQL  @ . Подобно тому, как модификатор  offset  позволяет сместить оценку селектора вектора, селектора вектора диапазона и подзапросов на фиксированную продолжительность относительно времени оценки, модификатор  @  позволяет исправить оценку для этих селекторов независимо от оценки запроса. время. Кредиты для этого синтаксиса принадлежат Бьёрну Рабенштейну.
 <селектор-вектора> @ <отметка времени>
<диапазон-вектор-селектор> @ <отметка времени>
<подзапрос> @ <отметка времени>
 
    является временной меткой unix и описывается литералом с плавающей запятой.
 Например, запрос  http_requests_total @ 1609746000  возвращает значение  http_requests_total  по адресу  2021-01-04T07:40:00+00:00  . Запрос  rate(http_requests_total[5m] @ 1609746000)  возвращает 5-минутную скорость  http_requests_total  одновременно.
 Кроме того,  start()  и  end()  также могут использоваться как значения для модификатора  @  в качестве специальных значений. Для запроса диапазона они разрешаются в начало и конец запроса диапазона соответственно и остаются одинаковыми для всех шагов. Для мгновенного запроса  start()  и  end()  разрешаются во время оценки.
 Возвращаясь к исправлению  topk() , следующий запрос отображает  1m  rate of  http_requests_total  тех рядов, чей последний  1h  rate был среди первых 5. Таким образом, теперь вы можете понять  topk()  даже как запрос диапазона, где он отображает точно  k  результатов.
 rate(http_requests_total[1m]) # Действует как настоящий селектор.
  а также
topk(5, rate(http_requests_total[1h] @ end())) # Это действует как функция ранжирования, которая фильтрует селектор.
 
 Аналогично, ранжирование  topk()  можно заменить другими функциями, такими как  histogram_quantile() , что сейчас имеет смысл только как мгновенный запрос.  rate()  можно заменить на  _over_time()  и т. д. Дайте нам знать, как вы используете этот новый модификатор!
 Модификатор  @  отключен по умолчанию и может быть включен с помощью флага  --enable-feature=promql-at-modifier  . Узнайте больше о флагах функций в этом сообщении в блоге и найдите документы для модификатора  @  здесь.
 Опубликовано: 17 февраля 2021 г. Ганеш Вернекар Мы всегда давали жесткие обещания в отношении стабильности и критических изменений в соответствии с моделью SemVer. Так и останется.
 Поскольку мы хотим быть более смелыми в экспериментах, мы планируем больше использовать флаги функций.
 Начиная с версии 2.25.0, мы представили новый раздел под названием отключенные функции, в котором функции скрыты за флагом  --enable-feature . Вы можете ожидать, что в будущих выпусках в этот раздел будет добавляться все больше и больше функций.
 Функции в этом списке считаются экспериментальными и учитывают следующие соображения, если они все еще отстают  --enable-feature  :
 Спецификации API могут измениться, если функция имеет какой-либо API (веб-API, интерфейсы кода и т. д.).
 Поведение функции может измениться.
 Они могут разрушить некоторые ваши предположения о Прометее. Например, предположение, что запрос не опережает время оценки образцов, которое будет разбито на  @ модификатор  и отрицательное смещение.
 Они могут быть нестабильными, но мы, конечно, постараемся, чтобы они были стабильными.
 Эти соображения позволяют нам более смело экспериментировать и быстрее внедрять инновации. Как только какая-либо функция получает широкое распространение и считается стабильной в отношении своего API, поведения и реализации, она может быть перемещена из списка отключенных функций и включена по умолчанию. Если мы обнаружим, что какая-либо функция не стоит того или не работает, мы можем полностью удалить ее. Если включение какой-либо функции считается серьезным изменением для Prometheus, она останется отключенной до следующего основного выпуска.
 Следите за этим списком в каждом выпуске и пробуйте!
 Опубликовано: 10 октября 2019 г. , автор Bartlomiej Plotka (@bwplotka) Доступна новая версия Prometheus 2.13.0, которая, как всегда, включает в себя множество исправлений и улучшений. Вы можете прочитать, что изменилось здесь. Тем не менее, есть одна функция, которую ждали некоторые проекты и пользователи: блочная, потоковая версия API удаленного чтения.
 В этой статье я хотел бы подробно рассказать о том, что мы изменили в удаленном протоколе, почему это было изменено и как его эффективно использовать.
 удаленных API 
 Начиная с версии 1.x Prometheus имеет возможность напрямую взаимодействовать со своим хранилищем с помощью удаленного API.
 Этот API позволяет сторонним системам взаимодействовать с данными метрик двумя способами:
  Написать  - получить образцы, отправленные Prometheus
  Прочитать  - извлечь образцы из Прометея
 Оба метода используют HTTP с сообщениями, закодированными с помощью protobuf. Запрос и ответ для обоих методов сжимаются с помощью snappy.
 Удаленная запись 
 Это самый популярный способ репликации данных Prometheus в стороннюю систему. В этом режиме Prometheus транслирует сэмплы, путем периодической отправки пакета образцов в заданную конечную точку.
 Удаленная запись была недавно значительно улучшена в марте с помощью удаленной записи на основе WAL, которая повышена надежность и потребление ресурсов. Также стоит отметить, что удаленная запись поддерживается почти всеми 3-мя партийные интеграции, упомянутые здесь.
 Удаленное чтение 
 Метод чтения встречается реже. Он был добавлен в марте 2017 года (на стороне сервера) и с тех пор не получил значительного развития.
 Выпуск Prometheus 2.13.0 включает исправление известных узких мест ресурсов в API чтения. В этой статье мы сосредоточимся на этих улучшениях.
 Основная идея удаленного чтения состоит в том, чтобы разрешить запросы к хранилищу Prometheus (TSDB) напрямую без оценки PromQL. Он аналогичен интерфейсу  Querier . который движок PromQL использует для извлечения данных из хранилища.
 По сути, это позволяет получить доступ для чтения временных рядов в TSDB, собранных Prometheus. Основные варианты использования удаленного чтения:
 Бесшовное обновление Prometheus между различными форматами данных Prometheus, поэтому Prometheus читает данные из другого Prometheus.
 Prometheus может читать из сторонних систем долгосрочного хранения, например InfluxDB.
 Сторонняя система запрашивает данные у Прометея, например у Таноса.
 API удаленного чтения предоставляет простую конечную точку HTTP, которая ожидает следующую полезную нагрузку protobuf:
 сообщение ReadRequest {
  повторные запросы Query = 1;
}
сообщение запрос {
  int64 start_timestamp_ms = 1;
  int64 end_timestamp_ms = 2;
  повторяющиеся совпадения prometheus.LabelMatcher = 3;
  подсказки prometheus.ReadHints = 4;
}
 
 С помощью этой полезной нагрузки клиент может запросить сопоставление определенной серии с учетом  сопоставителей  и временного диапазона с  в конце  и  в начале  .
 Ответ такой же простой:
 сообщение ReadResponse {
  // В том же порядке, что и запросы запроса.
  повторные результаты QueryResult = 1;
}
образец сообщения {
  двойное значение = 1;
  метка времени int64 = 2;
}
сообщение TimeSeries {
  повторяющиеся метки Label = 1;
  повторные выборки образцов = 2;
}
сообщение Результат запроса {
  повторяющиеся временные ряды prometheus.TimeSeries = 1;
}
 
 Удаленное чтение возвращает совпадающие временные ряды с  необработанными  выборками значения и метки времени.
 У такого простого удаленного чтения было две ключевые проблемы. Он был прост в использовании и понимании, но не было возможности потоковой передачи в рамках одного HTTP-запроса для формата protobuf, который мы определили. Во-вторых, ответ был включая необработанные образцы (значение  float64  и отметка времени  int64 ) вместо закодированный, сжатый пакет выборок, называемый «фрагментами», которые используются для хранения метрик внутри TSDB.
 Алгоритм сервера для удаленного чтения без потоковой передачи:
 Разобрать запрос.
 Выберите показатели из TSDB.
 Для всех расшифрованных серий: Для всех образцов: Добавить в ответ protobuf
 Ответ маршала.
 Мгновенный компресс.
 Отправьте ответ HTTP.
 Весь ответ удаленного чтения должен быть буферизирован в необработанном, несжатом формате, чтобы упорядочить его в потенциально огромное сообщение protobuf перед его отправкой клиенту. Затем весь ответ должен быть полностью буферизован в клиенте, чтобы иметь возможность размаршалить его из полученного протобуфа. Только после этого клиент смог использовать необработанные образцы.
 Что это значит? Это означает, что запросы, скажем, только на 8 часов, которые соответствуют 10 000 серий, могут занимать до  2,5 ГБ  памяти, выделенной как клиентом, так и сервером!
 Ниже приведена метрика использования памяти для Prometheus и Thanos Sidecar (клиент удаленного чтения) во время запроса удаленного чтения:
 Стоит отметить, что запрос 10 000 рядов — не лучшая идея, даже для родного HTTP Prometheus  query_range  конечная точка, поскольку ваш браузер просто не будет счастлив получать, хранить и отображать сотни мегабайт данных. Кроме того, для информационных панелей и целей рендеринга нецелесообразно иметь столько данных, поскольку люди не могут их прочитать. Поэтому обычно мы формируем запросы, имеющие не более 20 серий.
 Это замечательно, но очень распространенным методом является составление запросов таким образом, что запрос возвращает  агрегированных  20 рядов, однако внутри механизм запросов должен потенциально касаться тысяч серий для оценки ответа (например, при использовании агрегаторов). Вот почему такие системы, как Thanos, которые среди прочих данных используют данные TSDB из удаленного чтения, очень часто имеют дело с тяжелым запросом.
 Решение 
 Чтобы объяснить решение этой проблемы, полезно понять, как Prometheus перебирает данные при запросе. Основная концепция может быть показана в  Querier's .  Выберите тип возвращаемого метода  с именем  SeriesSet  . Интерфейс представлен ниже:
 // SeriesSet содержит набор серий. 
тип интерфейса SeriesSet {
    Следующий () логический
    Серия At()
    Ошибка ()
}
// Серия представляет один временной ряд.
тип Серийный интерфейс {
    // Labels возвращает полный набор меток, идентифицирующих серию.
    Ярлыки () метки. Ярлыки
    // Итератор возвращает новый итератор данных ряда.
    Итератор() SeriesIterator
}
// SeriesIterator перебирает данные временного ряда.
тип интерфейса SeriesIterator {
    // At возвращает текущую пару метка времени/значение.
    At() (t int64, v float64)
    // Next продвигает итератор на единицу.
    Следующий () логический
    Ошибка ()
}
 
 Эти наборы интерфейсов обеспечивают "потоковое" выполнение потока внутри процесса. Нам больше не нужно иметь предварительно вычисленный список рядов, содержащих образцы. С помощью этого интерфейса каждая реализация  SeriesSet.Next()  может получать серии по запросу. Аналогичным образом внутри каждой серии. мы также можем динамически получать каждый образец соответственно через  SeriesIterator. Next  .
 С помощью этого контракта Prometheus может минимизировать выделенную память, потому что механизм PromQL может оптимально перебирать образцы для оценки запроса. Таким же образом TSDB реализует  SeriesSet  таким образом, чтобы оптимально извлекать серию из блоков, хранящихся в файловой системе, один за другим, сводя к минимуму выделение.
 Это важно для API удаленного чтения, так как мы можем повторно использовать тот же шаблон потоковой передачи с помощью итераторов, отправляя в клиенту часть ответа в виде нескольких кусков для одной серии. Поскольку protobuf не имеет родной логики разграничения, мы  расширили . определение proto, позволяющее отправлять  набор небольших буферных сообщений протокола  вместо одного огромного. Мы звали этот режим  STREAMED_XOR_CHUNKS  удаленное чтение, в то время как старый называется  SAMPLES  . Расширенный протокол означает, что Prometheus больше не нужно буферизовать весь ответ. Вместо этого он может работать с каждой серией последовательно и отправлять по одному кадру за раз. каждый  SeriesSet.Next  или пакет  SeriesIterator.Next  итераций, возможно повторное использование одних и тех же страниц памяти для следующих серий!
 Теперь ответ  STREAMED_XOR_CHUNKS  удаленное чтение представляет собой набор сообщений (кадров) Protobuf, представленных ниже:
 // ChunkedReadResponse — это ответ, когда response_type равен STREAMED_XOR_CHUNKS.
// Мы строго транслируем полные серии за сериями, необязательно разделенные по времени. Это означает, что один кадр может содержать
// раздел одной серии, но как только новая серия будет запущена для потоковой передачи, это означает, что больше не будет фрагментов
// отправить за предыдущим.
сообщение ChunkedReadResponse {
  повторный prometheus.ChunkedSeries chunked_series = 1;
}
// ChunkedSeries представляет один закодированный временной ряд.
сообщение ChunkedSeries {
  // Метки должны быть отсортированы. 
  повторяющиеся метки Label = 1 [(gogoproto.nullable) = false];
  // Фрагменты будут располагаться в порядке начального времени и могут перекрываться.
  повторяющиеся фрагменты фрагментов = 2 [(gogoproto.nullable) = false];
}
 
 Как видите, кадр больше не содержит исходных сэмплов. Это второе улучшение, которое мы сделали: мы отправляем сообщение сэмплы, объединенные в куски (посмотрите это видео, чтобы узнать больше о кусках), которые являются точно такими же фрагментами, которые мы храним в TSDB.
 Мы получили следующий алгоритм сервера:
 Разобрать запрос.
 Выберите показатели из TSDB.
 Для всех серий: Для всех образцов: Кодировать фрагментами, если размер кадра >= 1 МБ; перерыв
 Сообщение Marshal  ChunkedReadResponse .
 Мгновенный компресс
 Отправить сообщение
 Полный дизайн можно найти здесь.
 эталонов 
 Какова производительность этого нового подхода по сравнению со старым решением?
 Сравним характеристики удаленного чтения между Prometheus  2. 12.0  и  2.13.0  . Что касается первоначальных результатов, представленных в начале этой статьи я использовал Prometheus в качестве сервера и сайдкар Thanos в качестве клиента удаленного чтения. Я вызывал тестируемый запрос на удаленное чтение, запуская вызов gRPC для боковой машины Thanos, используя  grpcurl  . Тест выполнялся на моем ноутбуке (Lenovo X1 16GB, i7 8th) с Kubernetes в докере (с использованием kind).
 Данные были созданы искусственно и представляют собой высокодинамичные серии из 10 000 (наихудший сценарий).
 Полный тестовый стенд доступен в репозитории thanosbench.
 Память 
 Без потоковой передачи 
 С потоковой передачей 
 Уменьшение памяти было ключевым моментом, к которому мы стремились в нашем решении. Вместо выделения ГБ памяти Prometheus буферизует примерно 50 МБ во время всего запроса, тогда как для Таноса используется лишь незначительное использование памяти. Благодаря трансляции Thanos gRPC StoreAPI, sidecar теперь является очень простым прокси.
 Кроме того, я пробовал разные временные диапазоны и количество серий, но, как и ожидалось, я продолжал видеть максимум 50 МБ в выделении для Прометея и ничего не видно для Таноса. Это доказывает, что наше удаленное чтение использует постоянную память  на запрос, независимо от того, сколько сэмплов вы запрашиваете для  . Выделенная память на запрос также значительно меньше зависит от мощности данных, поэтому количество серий извлекается, как и раньше.
 Это позволяет упростить планирование пропускной способности в зависимости от пользовательского трафика с помощью ограничения параллелизма.
 процессор 
 Без потоковой передачи 
 С потоковой передачей 
 Во время моих тестов также улучшилась загрузка ЦП, при этом процессорное время использовалось в 2 раза меньше.
 Задержка 
 Нам также удалось сократить задержку запроса удаленного чтения благодаря потоковой передаче и меньшему кодированию.
 Задержка удаленного запроса на чтение для 8-часового диапазона с серией 10 000:
 2.12.0: среднее время  2.13.0: среднее время
 реальный  0м34.701с  0м8.164с
 пользователь  0м7.324с  0м8.181с
 сис  0м1.172с  0м0.749с
 И с 2-часовым диапазоном времени:
 2.12.0: среднее время  2.13.0: среднее время
 реальный  0м10.904с  0м4.145с
 пользователь  0м6.236с  0м4.322с
 сис  0м0.973с  0м0.536с
 В дополнение к уменьшению задержки примерно в 2,5 раза, ответ передается в потоковом режиме немедленно по сравнению с непотоковым версия, в которой задержка клиента составляла 27 с ( реальных  минус  пользовательских  времени) только при обработке и маршалировании на стороне Prometheus и Thanos.
 Совместимость 
 Удаленное чтение было расширено с обратной и прямой совместимостью. Это благодаря protobuf и  поле accept_response_types , которое игнорируется для старых серверов. В то же время сервер работает просто отлично, если  accept_response_types  не присутствует у старых клиентов, предполагающих удаленное чтение  SAMPLES .
 Протокол удаленного чтения был расширен для обратной и прямой совместимости:
 Prometheus до версии 2.13.0 будет безопасно игнорировать поле  accept_response_types  , предоставленное более новыми клиентами, и примет режим  SAMPLES .
 Prometheus после версии 2.13.0 будет по умолчанию использовать режим  SAMPLES  для старых клиентов, которые не предоставляют параметр  accept_response_types .
 Использование 
 Чтобы использовать новое потоковое удаленное чтение в Prometheus v2.13.0, сторонняя система должна добавить к запросу  accept_response_types = [STREAMED_XOR_CHUNKS] .
 Тогда Prometheus будет передавать  ChunkedReadResponse  вместо старого сообщения. Каждый  ChunkedReadResponse  сообщение следующий размер varint и фиксированный размер bigendian uint32 для контрольной суммы CRC32 Castagnoli.
 Для Go рекомендуется использовать ChunkedReader читать прямо из потока.
 Обратите внимание, что флаг  storage.remote.read-sample-limit  больше не работает для  STREAMED_XOR_CHUNKS  .  storage.remote.read-concurrent-limit  работает как и раньше.
 Существует также новая опция  storage.remote.read-max-bytes-in-frame , которая управляет максимальным размером каждого сообщения. рекомендуется оставить его размером 1 МБ по умолчанию, поскольку Google рекомендует хранить сообщение protobuf не более 1 МБ.
 Как упоминалось ранее, это улучшение дает Таносу много преимуществ. Потоковое удаленное чтение добавлено в  v0.7.0 , так что эта или любая последующая версия, будет использовать потоковое удаленное чтение автоматически всякий раз, когда Prometheus 2. 13.0 или новее используется с коляской Thanos.
 Следующие шаги 
 Выпуск 2.13.0 представляет расширенное удаленное чтение и реализацию на стороне сервера Prometheus, однако на момент написания осталось сделать еще несколько вещей, чтобы в полной мере воспользоваться преимуществами расширенного протокола удаленного чтения:
 Поддержка клиентской стороны удаленного чтения Prometheus: в процессе
 Избегайте повторного кодирования фрагментов для блоков во время удаленного чтения: в процессе
 Резюме 
 Подводя итог, можно сказать, что основными преимуществами группового потокового удаленного чтения являются:
 И клиент, и сервер могут использовать  практически постоянный объем памяти на запрос  . Это связано с тем, что Prometheus отправляет только отдельные небольшие кадры один за другим, а не весь ответ во время удаленного чтения. Это здорово помогает с планирование емкости, особенно для несжимаемого ресурса, такого как память.
 Серверу Prometheus больше не нужно декодировать куски в необработанные образцы во время удаленного чтения. То же самое для клиентской части для кодирование, , если  система повторно использует собственное сжатие TSDB XOR (как это делает Танос).
 Как всегда, если у вас есть какие-либо вопросы или отзывы, не стесняйтесь отправить заявку на GitHub или задать вопросы в списке рассылки.
 Опубликовано: 18 июня 2019 г. Симоном Паскье  Продолжая серию интервью с пользователями Prometheus, Людовик Пуату из ForgeRock рассказывает о своем путешествии по мониторингу. 
 Расскажите о себе и о том, чем занимается ForgeRock? 
 Я Людовик Пуату, директор по управлению продуктами в ForgeRock, базирующаяся недалеко от Гренобля, Франция. ForgeRock является международной компанией по разработке программного обеспечения для управления идентификацией и доступом с более чем более 500 сотрудников, основанная в Норвегии в 2010 году, теперь со штаб-квартирой в Сан Франциско, США. Мы предоставляем решения для защиты каждого онлайн-взаимодействия с клиенты, сотрудники, устройства и вещи. У нас более 800 клиентов из финансовые компании для государственных услуг.
 Каков был ваш опыт мониторинга до Prometheus? 
 Платформа ForgeRock Identity всегда предлагала интерфейсы мониторинга. Но платформа состоит из 4 основных продуктов, каждый из которых имеет разные опции. Например, продукт Directory Services предлагает мониторинг информацию через SNMP, JMX или LDAP или даже RESTful API через HTTP в самые последние версии. Другие продукты имели только REST или JMX. Как результат, Мониторинг всей платформы был сложным и требовал инструментов, способных интегрировать эти протоколы.
 Почему ты решил посмотреть на Прометея? 
 Нам нужен был единый и общий интерфейс для мониторинга всех наших продукты, но сохраняя существующие для обратной совместимости.
 Мы начали использовать DropWizard для сбора метрик по всем продуктам. В в то же время мы начали перемещать эти продукты в облако и запускать их в Докер и Кубернет. Итак, Прометей стал очевиден благодаря своей интеграции с Kubernetes, его простотой развертывания и интеграцией Графана. Мы также посмотрели на Graphite и добавили его поддержку в наши продукты, он почти не используется нашими клиентами.
 Как вы перешли? 
 Некоторые из наших продуктов уже использовали библиотеку DropWizard, и мы решили использовать общую библиотеку во всех продуктах, поэтому DropWizard был очевидным выбором для закодировать приборку. Но очень быстро мы столкнулись с проблемой с данными модель. Интерфейс Prometheus использует измерения, в то время как мы, как правило, иерархическая модель показателей. Мы также начали использовать Micrometer и быстро наткнуться на некоторые ограничения. Таким образом, мы закончили создание пользовательской реализации для сбора наши показатели с помощью интерфейса Micrometer. Мы адаптировали DropWizard Metrics к соответствуют нашим требованиям и внесли коррективы в DropWizard Prometheus экспортер. Теперь с помощью одного инструментария мы можем выставлять метрики с помощью измерения или иерархически. Затем мы начали создавать образец Grafana. информационные панели, которые наш клиент может установить и настроить, чтобы иметь свои собственные мониторинг просмотров и предупреждений.
 Мы продолжаем предлагать прежние интерфейсы, но настоятельно рекомендуем клиентам использовать Prometheus и Grafana.
 Какие улучшения вы заметили после перехода? 
 Первые преимущества появились благодаря нашей команде инженеров по качеству. Когда они начали проверить нашу поддержку Prometheus и различные показатели, они начали включать он используется по умолчанию во всех стресс-тестах и тестах производительности. Они начали настраивать информационные панели Grafana для конкретных тестов. Вскоре после этого они начали выделять и указывать на различные показатели, чтобы объяснить некоторые проблемы с производительностью.
 При воспроизведении проблем с целью их понимания и устранения наши команда инженеров также использовала Prometheus и расширила некоторые информационные панели. весь процесс дал нам лучший продукт и гораздо лучшее понимание какие метрики важно отслеживать и визуализировать для клиентов.
 Как вы думаете, какое будущее ждет ForgeRock и Prometheus? 
 Компания ForgeRock начала предлагать свои продукты и решения в качестве оказание услуг. С этим шагом мониторинг и оповещение становятся еще более критично, и, конечно же, наша инфраструктура мониторинга основана на Prometheus. В настоящее время у нас есть два уровня мониторинга, по одному на каждого арендатора, где мы используем Prometheus для сбора данных об одной клиентской среде, а мы можем выставить набор показателей для этого клиента. Но мы также построили центральный Прометей служба, куда передаются метрики всех развернутых арендаторов, чтобы наша команда SRE может иметь действительно хорошее понимание того, что и как все среды клиентов бегут. В целом я бы сказал, что Prometheus стал нашим основным мониторингом. сервис, и он обслуживает как наших локальных клиентов, так и нас самих, управляющих нашим решения как услуга.
 Опубликовано: 6 февраля 2019 г. Брайаном Бразилом  Продолжая серию интервью с пользователями Prometheus, Донатас Абрайтис из Hostinger рассказывает о своем путешествии по мониторингу. 
 Можете ли вы рассказать нам о себе и о том, чем занимается Hostinger? 
 Я Донатас Абрайтис, системный инженер в Хостингер. Hostinger — хостинговая компания, название подразумевает. У нас около 30 миллионов клиентов с 2004 года, включая проект 000webhost.com - бесплатный хостинг-провайдер.
 Каков был ваш опыт мониторинга до Prometheus? 
 Когда Hostinger был совсем небольшой компанией, только Nagios, Cacti и Ganglia существовали в то время на рынке как инструменты мониторинга с открытым исходным кодом. Это как рассказывать молодежи, что такое флоппи-дисковод, но Nagios и Cacti все еще в цикле разработки сегодня.
 Несмотря на то, что инструментов автоматизации не существовало. Bash + Perl сделали свое дело. Если хочешь Чтобы масштабировать свою команду и себя, никогда нельзя игнорировать автоматизацию. Нет автоматизация - задействовано больше человеческого труда.
 В то время было около 150 физических серверов. Для сравнения, по сей день у нас около 2000 серверов, включая виртуальные машины и физические блоки.
 Для сетевого оборудования по-прежнему широко используется SNMP. С появлением «белого ящика» коммутаторы SNMP становится менее необходимым, так как можно установить обычные инструменты.
 Вместо SNMP можно запустить  node_exporter  или любой другой экспортер внутри переключитесь, чтобы предоставить любые метрики, которые вам нужны, в удобочитаемом формате. Красивое лучше некрасивого, верно?
 Мы используем CumulusOS, которая в нашем случае в основном x86, поэтому абсолютно нет проблема запуска любого вида Linux.
 Почему ты решил посмотреть на Прометея? 
 В 2015 году, когда мы начали автоматизировать все, что можно было автоматизировать, мы ввели Prometheus в экосистему. Сначала у нас был сингл окно мониторинга, где Alertmanager, Pushgateway, Grafana, Graylog и rsyslogd были запущены.
 Мы также оценили стек TICK (Telegraf/InfluxDB/Chronograf/Kapacitor), но нас они не устраивали из-за ограниченного функционала на тот момент а Prometheus выглядел во многих отношениях проще и зрелее для реализации.
 Как вы перешли? 
 В течение периода перехода от старого стека мониторинга (NCG - Nagios/Cacti/Ganglia) мы использовали обе системы и, наконец, полагаемся только на Прометей.
 У нас есть около 25 экспортеров метрик сообщества + некоторые пользовательские записи вроде  lxc_exporter  в нашем автопарке. В основном мы предоставляем пользовательские метрики, связанные с бизнесом. с помощью сборщика текстовых файлов.
 Какие улучшения вы заметили после перехода? 
 Новая установка улучшила временное разрешение с 5 минут до 15 секунд, что позволяет провести детальный и достаточно глубокий анализ. Даже среднее время до Обнаружение (MTTD) было уменьшено в 4,9 раза.0015
 Как вы думаете, какое будущее ждет Hostinger и Prometheus? 
 Поскольку с 2015 года мы увеличили нашу инфраструктуру в N раз, основной узким местом стали Prometheus и Alertmanager. Наш Прометей ест около ~2 ТБ дискового пространства. Следовательно, если мы перезапустим или изменим узел на обслуживании, мы пропустите данные мониторинга на некоторое время. В настоящее время мы используем Prometheus версии 2.4.2, но в ближайшее время у нас в планах перейти на 2.6. Особенно мы увлекающийся производительность и функции, связанные с WAL. Перезапуск Prometheus занимает около 10-15 минут. Неприемлимо. Другая проблема заключается в том, что если одна локация не работает, мы пропускаем также данные мониторинга. Таким образом, мы решили внедрить высокодоступный инфраструктура мониторинга: два узла Prometheus, два Alertmanager в отдельных континенты.
 Наш основной инструмент визуализации — Grafana. Крайне важно, чтобы Grafana может запросить резервный узел Prometheus, если основной не работает. Это легко, как что - поставить HAProxy впереди и принимать соединения локально.
 Еще одна проблема: как мы можем запретить пользователям (разработчикам и прочему внутреннему персоналу) от злоупотребления информационными панелями, перегружающими узлы Prometheus.
 Или резервный узел, если основной не работает - проблема с громоподобными стадами.
 Для достижения желаемого состояния мы дали шанс на Трикстер. Эта ускоряющая приборная панель время загрузки невероятное. Он кэширует временные ряды. В нашем случае кеш находится в память, но есть больше вариантов, где хранить. Даже когда основной идет вниз и вы обновляете информационную панель, Trickster не будет запрашивать второй узел для временной ряд, который он имеет в кэше памяти. Трикстер сидит между Графаной и Прометей. Он просто общается с Prometheus API.
 Узлы Prometheus независимы, а узлы Alertmanager образуют кластер. Если оба Alertmanager видят одно и то же оповещение, которое они дедуплицируют и запускают один раз а не несколько раз.
 У нас есть планы запустить множество  blackbox_exporters  и отслеживать каждого Hostinger веб-сайт клиента, потому что все, что не может быть отслежено, не может быть оценено.
 Мы с нетерпением ждем реализации большего количества узлов Prometheus в будущем, поэтому сегментирование узлов между несколькими экземплярами Prometheus. Это позволило бы нам не иметь узких мест, если один экземпляр в регионе не работает.
 Опубликовано: 28 января 2019 г. Ганеш Вернекар Введение 
 Как следует из названия, подзапрос является частью запроса и позволяет выполнять запрос диапазона внутри запроса, что раньше было невозможно. Это был давний запрос: prometheus/prometheus/1227.
 Запрос на вытягивание для поддержки подзапросов недавно был объединен с Prometheus и будет доступен в Prometheus 2.7. Давайте узнаем больше об этом ниже.
 Мотивация 
 Иногда бывают случаи, когда вы хотите обнаружить проблему, используя  скорость  с более низким разрешением/диапазоном (например,  5 м  ), агрегируя эти данные для более высокого диапазона (например,  max_over_time  для  1 ч  ).
 Ранее описанное выше было невозможно для одного запроса  PromQL . Если вы хотите иметь выбор диапазона в запросе для ваших правил оповещения или построения графика, вам потребуется правило записи, основанное на этом запросе, и выполнение выбора диапазона на метриках, созданных правилами записи. Пример:  max_over_time(rate(my_counter_total[5m])[1h])  .
 Если вам нужны быстрые результаты для данных, охватывающих дни или недели, может потребоваться некоторое время, пока в ваших правилах записи будет достаточно данных, прежде чем их можно будет использовать. Забыть добавить правила записи может быть неприятно. И было бы утомительно создавать правило записи для каждого шага запроса.
 Благодаря поддержке подзапросов обо всех ожиданиях и разочарованиях можно забыть.
 подзапросов 
 Подзапрос аналогичен вызову API /api/v1/query_range, но встроен в мгновенный запрос. Результатом подзапроса является вектор диапазона.
 Команда Prometheus пришла к единому мнению относительно синтаксиса подзапросов на саммите Prometheus Dev Summit 2018 в Мюнхене. Это примечания саммита по поддержке подзапросов и краткий проектный документ по синтаксису, используемому для реализации поддержки подзапросов.
 <мгновенный_запрос> '[' <диапазон> ':' [ <разрешение> ] ']' [смещение <длительность> ]
 
    эквивалентно полю запроса   в  /query_range  API.
  <диапазон>  и  смещение <длительность>  похоже на селектор диапазона.
  <разрешение>  является необязательным, что эквивалентно  шагу  в  /query_range  API.
 Если разрешение не указано, в качестве разрешения по умолчанию для подзапроса используется глобальный интервал оценки. Кроме того, шаг подзапроса выравнивается независимо и не зависит от времени выполнения родительского запроса.
 Примеры 
 Подзапрос внутри функции  min_over_time  возвращает 5-минутную скорость метрики  http_requests_total  за последние 30 минут с разрешением 1 минута. Это будет эквивалентно вызову API  /query_range  с запросом  query=rate(http_requests_total[5m]), end=, start=-30m, step=1m  и получением минимального количества всех полученных ценности.
 min_over_time(скорость(http_requests_total[5m])[30m:1m])
 
 Поломка:
  rate(http_requests_total[5m])[30m:1m]  — подзапрос, где  rate(http_requests_total[5m])  — запрос, который необходимо выполнить.
  rate(http_requests_total[5m])  выполняется с  start=-30m  до  end=  с разрешением  1m  . Обратите внимание, что время начала   выравнивается независимо с шагом  1 м  (выровненные шаги  0 м 1 м 2 м 3 м ... ).
 Наконец, результат всех вышеуказанных вычислений передается в  min_over_time()  .
 Ниже приведен пример вложенного подзапроса и использования разрешения по умолчанию. Самый внутренний подзапрос получает скорость  Distance_covered_meters_total  за диапазон времени. Мы используем это, чтобы получить  deriv()  ставок, опять же для диапазона времени. И, наконец, возьмите максимум всех производных. Обратите внимание, что время  <сейчас>  для самого внутреннего подзапроса относится к времени оценки внешнего подзапроса на  производное()  .
 max_over_time( производное( rate(distance_covered_meters_total[1m])[5m:1m] )[10m:] )
 
 В большинстве случаев вам потребуется интервал оценки по умолчанию, то есть интервал, с которым правила оцениваются по умолчанию. Пользовательские разрешения будут полезны в тех случаях, когда вы хотите выполнять вычисления реже/чаще, например. дорогие запросы, которые вы, возможно, захотите выполнять реже.
 Эпилог 
 Хотя подзапросы очень удобно использовать вместо правил записи, их использование излишне влияет на производительность. Тяжелые подзапросы в конечном итоге должны быть преобразованы в правила записи для повышения эффективности.
 Также не рекомендуется иметь подзапросы внутри правила записи. Вместо этого создайте больше правил записи, если вам нужно использовать подзапросы в правиле записи.
 Опубликовано: 23 августа 2018 г. Брайаном Бразилом  Продолжая серию интервью с пользователями Prometheus, Майл Росу из Presslabs рассказывает о своем путешествии по мониторингу. 
 Расскажите о себе и о том, чем занимается Presslabs? 
 Presslabs — высокопроизводительный управляемый WordPress хостинговая платформа, ориентированная на издателей, корпоративные бренды и цифровые агентства которые стремятся предложить беспрепятственный опыт посетителям своего веб-сайта, 100% время.
 Недавно мы разработали инновационный компонент для нашего ядра продукт — бизнес-аналитика WordPress. Теперь пользователи могут получать в режиме реального времени, полезные данные на комплексной информационной панели для поддержки краткосрочного процесс от выпуска до развертывания и постоянное совершенствование своих сайтов.
 Мы поддерживаем бесперебойную доставку до 2 миллиардов просмотров страниц в месяц на парк из 100 машин, полностью предназначенных для управляемого хостинга WordPress для требовательные клиенты.
 В настоящее время мы стремимся сделать WordPress максимально удобным. издательства по всему миру. В этом путешествии Kubernetes облегчает наш маршрут к предстоящему стандарту высокодоступной инфраструктуры хостинга WordPress.
 Каков был ваш опыт мониторинга до Prometheus? 
 Мы начали создавать нашу хостинговую платформу WordPress еще в 2009 году. мы использовали Munin, систему с открытым исходным кодом, сеть и инфраструктуру мониторинг, который выполнил все необходимые нам операции: выявление, сбор, агрегирование, оповещение и визуализация метрик. Хотя он показал себя хорошо, сбор раз в минуту и сбор раз в 5 минут был слишком медленным для нас, поэтому полученного результата было недостаточно для правильного анализа событий. на нашей платформе.
 Графит был нашим вторым выбором в списке, который решил проблему времени. обратился Мунин. Мы добавили collectd в смесь для предоставления метрик и использовали Графит для сбора и агрегатирования.
 Затем мы сделали Viz, инструмент для визуализации, который мы написали на JavaScript и Python. и оповещение. Однако мы прекратили активно пользоваться этим сервисом, т.к. поддерживать его было много работы, которую Grafana очень хорошо заменяла, так как его первая версия.
 Со второй половины 2017 года наша платформа Presslabs вышла на масштабный переходная фаза. Одним из основных изменений стал наш переход на Kubernetes. что подразумевало необходимость в высокопроизводительной системе мониторинга. Вот когда мы сосредоточились на Prometheus, который мы используем с тех пор, и планируем интегрировать его во все наши сервисы на новой платформе в качестве центрального элемента для извлечение и раскрытие метрик.
 Почему ты решил посмотреть на Прометея? 
 Мы начали рассматривать Prometheus в 2014 году на Velocity Europe Barcelona после разговаривая с командой инженеров Soundcloud. Преимущества, которые они выявили, были достаточно убедительным для нас, чтобы попробовать Prometheus.
 Как вы перешли? 
 Мы все еще находимся в процессе перехода, поэтому мы запускаем параллельно два системы — Prometheus и сборка Graphite. Для клиентской панели и наши основные сервисы мы используем Prometheus, но для клиентских сайтов мы все еще используем Графит-собран. Поверх обоих есть Grafana для визуализации.
 Документы Prometheus, вопросы Github и исходный код были основными ресурсами для интеграции Прометея; конечно, StackOverflow добавил немного остроты процесс, который удовлетворил многие наши любопытства.
 Единственная проблема с Prometheus заключается в том, что мы не можем получить долговременное хранилище для определенные показатели. Наша платформа инфраструктуры хостинга должна хранить данные об использовании метрики, такие как просмотры страниц, по крайней мере за год. Тем не менее, Прометей Ландшафт значительно улучшился с тех пор, как мы его используем, и нам еще предстоит его протестировать. возможные решения.
 Какие улучшения вы заметили после перехода? 
 С момента перехода на Prometheus мы заметили значительное снижение ресурса использования, по сравнению с любой другой альтернативой, которую мы использовали раньше. Кроме того, легко установить, так как автоматическая интеграция с Kubernetes экономит много времени.
 Как вы думаете, какое будущее ждет Presslabs и Prometheus? 
 У нас большие планы с Прометеем, так как мы работаем над заменой Прометея Диаграмма Helm, которую мы сейчас используем с Prometheus Operator на нашем новом инфраструктура. Реализация обеспечит разделение платформы клиентов, так как мы собираемся выделить выделенный сервер Prometheus для ограниченное количество веб-сайтов. Мы уже работаем над этим в рамках наших усилий Кубернетизация WordPress.
 Мы также работаем над экспортом метрик WordPress в формат Prometheus. Grafana никуда не денется, поскольку она идет рука об руку с Prometheus, чтобы решить потребность в визуализации.
 Опубликовано: 9 августа 2018 г. Ричардом Хартманном Мы рады сообщить, что с сегодняшнего дня Прометей получает диплом в рамках CNCF.
 «Прометей» — второй проект, достигший этого уровня. Выпустив Prometheus, CNCF показывает, что она уверена в скорости нашего кода и функций, в нашей зрелости и стабильности, а также в наших процессах управления и сообщества. Это также действует как внешняя проверка качества для всех, кто участвует во внутренних дискуссиях по поводу выбора инструмента мониторинга.
 С момента достижения инкубационного уровня произошло много всего; некоторые из которых выделяются:
 Мы полностью переписали серверную часть нашего хранилища для поддержки высокой текучести сервисов
 У нас был большой толчок к стабильности, особенно в версии 2.3.2
 Мы начали сбор документации, уделяя особое внимание упрощению внедрения Prometheus и присоединению к сообществу
 Особенно важен последний пункт, так как сейчас мы входим в четвертую фазу усыновления. Эти этапы были приняты
 Пользователи, ориентированные на мониторинг, активно ищут самое лучшее в мониторинге
 Пользователи гипермасштабирования сталкиваются с ландшафтом мониторинга, который не может соответствовать их масштабу
 Компании от малых до Fortune 50 переделывают свою инфраструктуру мониторинга
 Пользователи, которым не хватает финансирования и/или ресурсов, чтобы сосредоточиться на мониторинге, но они слышат о преимуществах Prometheus из разных источников
 Глядя в будущее, мы ожидаем еще более широкого распространения и по-прежнему стремимся работать с масштабами завтрашнего дня уже сегодня.
 Опубликовано: 5 июля 2018 г., автор Callum Styan Реализация обнаружения пользовательских сервисов 
 Prometheus содержит встроенные интеграции для многих систем обнаружения служб (SD), таких как Consul, Kubernetes и общедоступных облачных провайдеров, таких как Azure. Однако мы не можем обеспечить интеграцию реализации для каждого варианта обнаружения службы. Команда Прометея уже растянута тонкий поддерживает текущий набор интеграций SD, поэтому поддерживает интеграцию для каждой возможной SD вариант не реализуем. Во многих случаях текущие реализации SD были внесены людьми вне команды, а затем плохо поддерживается или тестируется. Мы хотим предоставить только прямые интеграция с механизмами обнаружения сервисов, которые, как мы знаем, мы можем поддерживать и которые работают так, как предполагалось. По этой причине в настоящее время действует мораторий на новые интеграции SD.
 Однако мы знаем, что все еще есть желание иметь возможность интеграции с другими механизмами SD, такими как Докер Рой. Недавно в документацию было внесено небольшое изменение кода плюс пример. каталог в репозитории Prometheus для реализации пользовательской интеграции обнаружения служб без чтобы объединить его с основным двоичным файлом Prometheus. Изменение кода позволяет нам использовать внутреннюю Код Discovery Manager для написания другого исполняемого файла, который взаимодействует с новым механизмом SD и выводит файл, совместимый с файлом Prometheus file_sd. Путем совместного размещения Prometheus и нашего нового исполняемого файла мы можем настроить Prometheus для чтения вывода нашего исполняемого файла, совместимого с file_sd, и, следовательно, очищать цели от этого механизма обнаружения службы. В будущем это позволит нам перемещать SD интеграции из основного бинарного файла Prometheus, а также для переноса стабильных SD-интеграций, которые делают использование адаптера в Prometheus пакет обнаружения.
 Перечислены интеграции с использованием file_sd, например те, которые реализованы с помощью кода адаптера. здесь.
 Давайте посмотрим на пример кода.
 Адаптер 
 Сначала у нас есть файл адаптер.иди. Вы можете просто скопировать этот файл для своей пользовательской реализации SD, но полезно понять, что происходит здесь.
 // Адаптер запускает реализацию обнаружения неизвестной службы и преобразует ее целевые группы
// в JSON и записывает в файл для file_sd.
структура адаптера типа {
    ctx контекст. Контекст
    открытие диска.Discoverer
    карта групп[string]*customSD
    менеджер *discovery.Manager
    выходная строка
    строка имени
    регистратор log.Logger
}
// Run запускает диспетчер обнаружения и реализацию обнаружения пользовательских служб.
func (*адаптер) Run() {
    перейти к.manager.Run()
    a.manager.StartCustomProvider(a.ctx, a.name, a.disc)
    перейти a.runCustomSD(a.ctx)
}
 
 Адаптер использует  discovery.Manager , чтобы фактически запустить функцию запуска нашего пользовательского поставщика SD в горутина. У менеджера есть канал, на который наш пользовательский SD будет отправлять обновления. Эти обновления содержат Цели СД. Поле groups содержит все цели и метки, о которых знает наш пользовательский исполняемый файл SD. от нашего механизма SD.
 введите структуру customSD {
    Цели []string `json:"targets"`
    Карта меток[string]string `json:"labels"`
}
 
 Это 9Структура 0055 customSD  существует в основном для того, чтобы помочь нам преобразовать внутреннюю целевую группу Prometheus . Группа  struct в JSON для формата file_sd.
 Во время работы адаптер будет прослушивать канал на наличие обновлений из нашей пользовательской реализации SD. После получения обновления он проанализирует targetgroup.Groups в другую карту [string]*customSD  , и сравните его с тем, что хранится в поле  групп  адаптера. Если они разные, мы присваиваем новые группы в структуру адаптера и запишите их в формате JSON в выходной файл. Обратите внимание, что это реализация предполагает, что каждое обновление, отправляемое реализацией SD по каналу, содержит полный список всех целевых групп, о которых известно СД.
 Пользовательская реализация SD 
 Теперь мы хотим использовать адаптер для реализации нашей собственной SD-карты. Полный рабочий пример находится в тот же каталог примеров здесь.
 Здесь вы можете видеть, что мы импортируем код адаптера  "github.com/prometheus/prometheus/documentation/examples/custom-sd/adapter"  а также некоторые другие Библиотеки Прометея. Чтобы написать собственную SD, нам нужна реализация интерфейса Discoverer.
 // Discoverer предоставляет информацию о целевых группах. Он поддерживает набор
// источников, из которых могут происходить TargetGroups. Всякий раз, когда провайдер обнаружения
// обнаруживает потенциальное изменение, отправляет TargetGroup через свой канал.
//
// Discoverer не знает, произошло ли фактическое изменение.
// Это гарантирует, что он отправляет новую целевую группу всякий раз, когда происходит изменение.
//
// Исследователи должны сначала отправить полный набор всех обнаруживаемых целевых групп.
тип интерфейса Discoverer {
    // Запускаем канал к провайдеру обнаружения (consul, dns и т. д.), через который он может отправлять
    // обновленные целевые группы.
    // Должен вернуться, если контекст отменяется. Не должно закрывать обновление
    // канал при возврате.
    Run(ctx context.Context, up chan<- []*targetgroup.Group)
}
 
 Нам просто нужно реализовать одну функцию,  Run(ctx context. Context, up chan<- []*targetgroup.Group)  . Это функция, которую менеджер в коде адаптера будет вызывать в горутине. Функция «Выполнить» использует контекст, чтобы знать, когда выйти, и передает канал для отправки обновлений целевых групп.
 Глядя на бег функции в приведенном примере, мы можем увидеть несколько ключевых вещей, которые нам нужно будет сделать. в реализации для другой SD. Периодически делаем звонки, в данном случае Консулу (ради этого примера, предположим, что встроенной реализации Consul SD еще нет), и преобразовать ответ на набор из  targetgroup.Group  структур. Из-за того, как работает Консул, мы должны сначала сделать вызов для получения всех известных услуг, а затем еще один вызов для каждой услуги, чтобы получить информацию обо всех резервные экземпляры.
 Обратите внимание на комментарий над циклом, который обращается к Consul для каждой службы:
 // Обратите внимание, что мы рассматриваем ошибки при запросе определенных консул-сервисов как фатальные для этого
// итерация цикла time. Tick. Лучше иметь несколько устаревших целей, чем незавершенные.
// список целей просто потому, что мог быть тайм-аут. Если услуга действительно
// что касается консула, то он будет подхвачен во время следующей итерации
// внешний цикл.
 
 Этим мы говорим, что если мы не можем получить информацию обо всех целях, лучше не отправить какое-либо обновление вообще, чем отправить неполное обновление. Мы бы предпочли список устаревших целей в течение небольшого периода времени и защититься от ложных срабатываний из-за таких вещей, как мгновенная сеть проблемы, перезапуски процессов или тайм-ауты HTTP. Если мы получим ответ от Консула о каждом target, мы отправляем все эти цели на канал. Также есть вспомогательная функция  parseServiceNodes  который принимает ответ Consul для отдельной службы и создает целевую группу из резервной копии узлы с метками.
 Использование текущего примера 
 Перед тем, как приступить к написанию собственной реализации SD, возможно, стоит запустить текущую пример после просмотра кода. Для простоты я обычно запускаю и Консул, и Prometheus как контейнеры Docker через docker-compose при работе с кодом примера.
  docker-compose.yml 
 версия: «2»
Сервисы:
консул:
    изображение: консул: последний
    имя_контейнера: консул
    порты:
    - 8300:8300
    - 8500:8500
    тома:
    - ${PWD}/consul.json:/consul/config/consul.json
Прометей:
    изображение: выпускной/прометей:последний
    имя_контейнера: прометей
    тома:
    - ./прометей.yml:/etc/прометей/прометей.yml
    порты:
    - 9090:9090
 
  консул.джсон 
 {
"оказание услуг": {
    "имя": "прометей",
    "порт": 9090,
    "чеки": [
    {
        "id": "показатели",
        "name": "Метрики сервера Prometheus",
        "http": "http://прометей:9090/метрика",
        "интервал": "10 с"
    }
    ]
}
}
 
 Если мы запустим оба контейнера через docker-compose, а затем запустим пример main.go, мы запросим Consul HTTP API на локальном хосте: 8500, а файл , совместимый с SD, будет записан как пользовательский  sd. json. Мы могли бы настроить Prometheus для подхвата этого файла через конфиг file_sd:
 scrape_configs:
  - job_name: "custom-sd"
    scrape_interval: "15 сек."
    файл_sd_configs:
    - файлы:
      - /путь/к/custom_sd.json
 
Опубликовано: 16 марта 2018 г. Автор: Brian Brazil  Продолжая серию интервью с пользователями Prometheus, Ричард Ли из Datawire рассказывает о том, как они перешли на Prometheus. 
 Расскажите о себе и о том, чем занимается Datawire? 
 В Datawire мы создаем инструменты с открытым исходным кодом, которые помогают разработчикам быстрее писать код на Кубернетес. Наши проекты включают телеприсутствие, для локальной разработки сервисов Kubernetes; Ambassador, собственный API-шлюз Kubernetes построен на Envoy Proxy; а также Forge, система сборки/развертывания.
 Мы запускаем ряд критически важных облачных сервисов в Kubernetes в AWS, чтобы поддержите наши усилия с открытым исходным кодом. Эти сервисы поддерживают такие варианты использования, как динамическое предоставление десятков кластеров Kubernetes в день, которые затем используется нашей автоматизированной тестовой инфраструктурой.
 Каков был ваш опыт мониторинга до Prometheus? 
 Мы использовали AWS CloudWatch. Это было легко настроить, но мы обнаружили, что, когда мы приняли более распределенную модель разработки (микросервисы), мы хотели большего гибкость и контроль. Например, мы хотели, чтобы каждая команда могла настраивать свой мониторинг по мере необходимости, не требуя помощь.
 Почему ты решил посмотреть на Прометея? 
 У нас было два основных требования. Во-первых, мы хотели, чтобы каждый инженер был здесь чтобы иметь возможность иметь оперативный контроль и видимость своих услуг. Наша модель разработки сильно децентрализована по замыслу, и мы стараемся избегать ситуации, когда инженер должен ждать другого инженера, чтобы сделать что-нибудь. Для мониторинга мы хотели, чтобы наши инженеры могли иметь большая гибкость и контроль над своей инфраструктурой метрик. Наш второй требованием была сильная экосистема. Сильная экосистема обычно означает установленные (и задокументированные) лучшие практики, постоянное развитие и множество люди, которые могут помочь, если вы застряли.
 Прометей и, в частности, Прометей Оператор, подходит под наши требования. С Prometheus Operator каждый разработчик может создать свой собственный Prometheus. экземпляр по мере необходимости, без помощи операций (нет узкого места!). Мы тоже члены CNCF с большим опытом работы с Сообщества Kubernetes и Envoy, поэтому, глядя на другое сообщество CNCF в Прометей был естественным подходящим персонажем.
 Как вы перешли? 
 Мы знали, что хотим начать с интеграции Prometheus с нашим шлюзом API. Наш API Gateway использует Envoy для проксирования, а Envoy автоматически создает метрики используя протокол statsd. Мы установили Prometheus Operator (несколько подробных заметки здесь) и настроил его, чтобы начать сбор статистики от посланника. Мы также настроили панель инструментов Grafana на основе некоторых работа от другого участника-посла.
 Какие улучшения вы заметили после перехода? 
 Теперь наши инженеры видят трафик L7. Мы также можем использовать Prometheus, чтобы сравнить задержку и пропускную способность для наших канареечных развертываний, чтобы дать нам больше уверенности в том, что новые версии наших сервисов не снижают производительность регрессии.
 Как вы думаете, какое будущее ждет Datawire и Prometheus? 
 Использование оператора Prometheus по-прежнему немного сложно. Нам нужно выяснить рекомендации по эксплуатации для наших сервисных групп (когда вы развертываете Прометей?). Затем нам нужно будет обучить наших инженеров этим передовым методам. и обучите их тому, как настроить Оператора в соответствии с их потребностями. Мы ожидаем это будет областью некоторых экспериментов, поскольку мы выясним, что работает и что не работает.
 Опубликовано: 8 февраля 2018 г. Автор: Brian Brazil  Продолжая серию интервью с пользователями Prometheus, Кевин Бертон из Scalefastr рассказывает о том, как они используют Prometheus. 
 Расскажите о себе и о том, чем занимается Scalefastr? 
 Меня зовут Кевин Бертон, я генеральный директор Scalefaststr. Мой фон в распределенном систем, и я ранее управлял Datastreamer, компанией, которая создала петабайт масштабировать распределенный сканер социальных сетей и поисковую систему.
 В Datastreamer мы столкнулись с проблемами масштабируемости в отношении нашей инфраструктуры и построил высокопроизводительный кластер на базе Debian, Elasticsearch, Cassandra, и Кубернет.
 Мы обнаружили, что многие из наших клиентов также боролись со своими инфраструктуры, и я был поражен тем, сколько они платят за хостинг больших количество контента в AWS и Google Cloud.
 Мы постоянно оценивали, сколько стоит запуск в облаке, и для нас стоимость хостинга была бы примерно в 5-10 раз больше, чем мы платим сейчас.
 Мы приняли решение о запуске новой облачной платформы на базе Open Source и облачные технологии, такие как Kubernetes, Prometheus, Elasticsearch, Cassandra, Grafana, Etcd и т. д.
 В настоящее время у нас есть несколько клиентов в петабайтном масштабе, и мы запуск нашей новой платформы в этом месяце.
 Каков был ваш опыт мониторинга до Prometheus? 
 В Datastreamer мы обнаружили, что метрики являются ключом к нашей способности повторять быстро. Наблюдаемость в нашей платформе стала тем, что мы приняли и мы интегрировали такие инструменты, как Dropwizard Метрики, облегчающие разработку аналитика для нашей платформы.
 Мы построили платформу на основе KairosDB, Grafana и собственного (простого) движок визуализации, который работал очень хорошо в течение довольно долгого времени.
 Ключевой проблемой KairosDB, с которой мы столкнулись, была скорость принятия и спрос на Прометея.
 Кроме того, что хорошо в Prometheus, так это поддержка экспортеров реализуются либо самими проектами, либо сообществом.
 С KairosDB нам часто было трудно создавать собственные экспортеры. вероятность того, что уже существующий экспортер для KairosDB, была довольно низкой по сравнению с к Прометею.
 Например, существует поддержка CollectD для KairosDB, но она не поддерживается очень хорошо в Debian, и в CollectD есть практические ошибки, которые мешают ему надежность работы в производстве.
 С Prometheus вы можете довольно быстро приступить к работе (система довольно проста в установке), и шанс, что у вас есть готовый экспортер для вашего платформа довольно высокая.
 Кроме того, мы ожидаем, что клиентские приложения начнут стандартизироваться на Показатели Prometheus, как только появятся размещенные платформы, такие как Scalefastr, которые интегрировать его как стандартизированный и поддерживаемый продукт.
 Иметь представление о производительности вашего приложения очень важно, и для этого необходима масштабируемость Prometheus.
 Почему ты решил посмотреть на Прометея? 
 Сначала нам было любопытно, как другие люди отслеживают свои Kubernetes и контейнерные приложения.
 Одной из основных проблем контейнеров является то, что они могут приходить и уходить. быстро оставляя после себя данные журналов и метрик, которые необходимо проанализировать.
 Стало ясно, что мы должны исследовать Prometheus как наш аналитический сервер однажды мы увидели, что люди успешно используют Prometheus в продакшене вместе с с архитектурой, ориентированной на контейнеры, а также поддержкой экспортеров и приборные панели.
 Как вы перешли? 
 Переход прошел для нас несколько безболезненно, так как Scalefastr — новое поле Окружающая среда.
 Архитектура по большей части новая с очень небольшим количеством ограничивающих факторов.
 Наша главная цель — развертывание на «голом железе», но создание облачных функций поверх существующее и стандартизированное оборудование.
 Идея состоит в том, чтобы вся аналитика в нашем кластере поддерживалась Prometheus.
 Мы предоставляем клиентам их собственную инфраструктуру «управления», которая включает Prometheus, Grafana, Elasticsearch и Kibana, а также элемент управления Kubernetes. самолет. Мы организуем эту систему с помощью Ansible, который обрабатывает начальную машину. установка (ssh, основные пакеты Debian и т. д.) и базовая конфигурация.
 Затем мы развертываем Prometheus, все необходимые экспортеры для клиента конфигурация и дополнительно дашборды для Grafana.
 Одна вещь, которую мы обнаружили несколько проблематичной, это то, что несколько информационных панелей на Grafana. com были написаны для Prometheus 1.x и не переносились на 2.x. Оказывается, есть всего несколько функций, которых нет в серии 2.x. и многие из них просто нуждаются в небольшой настройке здесь и там. Кроме того, некоторые дэшбордов были написаны для более ранней версии Grafana.
 Чтобы решить эту проблему, на этой неделе мы объявили о проекте по стандартизации и улучшению панели для Прометей для таких инструментов, как Cassandra, Elasticsearch, ОС, а также самого Prometheus. Мы открыли исходный код и опубликовали его на Гитхаб прошлая неделя.
 Мы надеемся, что это облегчит переход на Prometheus другим людям.
 Мы хотим улучшить автоматическую синхронизацию с нашей Grafana. backend, но и для загрузки этих информационных панелей на Grafana.com.
 Мы также опубликовали нашу конфигурацию Prometheus, чтобы ярлыки работали правильно с нашими шаблонами Grafana. Это позволяет вам иметь выпадающее меню для выбора более конкретных показателей, таких как имя кластера, имя экземпляра и т. д.
 Какие улучшения вы заметили после перехода? 
 Простота развертывания, высокая производительность и стандартизированные экспортеры сделали его нам легко переключаться. Кроме того, тот факт, что серверная часть довольно проста настроить (в основном, только сам демон) и не так много движущихся части сделали это легкое решение.
 Как вы думаете, какое будущее ждет Scalefastr и Prometheus? 
 Прямо сейчас мы развертываем Elasticsearch и Cassandra непосредственно на «голом железе». Мы работаем над тем, чтобы запускать их в контейнерах непосредственно поверх Kubernetes и работает над использованием интерфейса хранения контейнеров (CSI), чтобы сделать это возможный.
 Прежде чем мы сможем это сделать, нам нужно, чтобы служба обнаружения Prometheus работала и работала. это то, с чем мы еще не играли. В настоящее время мы развертываем и настроить Prometheus через Ansible, но явно это не масштабируется (или даже не работает) с Kubernetes, поскольку контейнеры могут появляться и исчезать по мере изменения нашей рабочей нагрузки.
 Мы также работаем над улучшением стандартных информационных панелей и предупреждений. Один из функции, которые мы хотели бы добавить (возможно, в виде контейнера), — это поддержка оповещение на основе прогнозирования зимних холодов.
 По сути, это позволило бы нам предсказать серьезные проблемы с производительностью, прежде чем они случаются. Вместо того, чтобы ждать, пока что-то выйдет из строя (например, дискового пространства) до тех пор, пока мы не примем меры для ее исправления.
 В некоторой степени Kubernetes помогает решить эту проблему, поскольку мы можем просто добавить узлов в кластер на основе водяного знака. Как только использование ресурсов слишком high мы можем просто автоматически масштабировать.
 Мы очень взволнованы будущим Прометея, особенно сейчас, когда мы продвижение серии 2.x и тот факт, что сотрудничество с CNCF кажется двигаться вперед красиво.
 Опубликовано: 29 ноября 2017 г. Томом Уилки от имени команды Prometheus Prometheus на CloudNativeCon 2017 
 Среда, 6 декабря, — День Прометея на CloudNativeCon Austin, и у нас есть фантастический список докладов и мероприятий для вас. Посетите салон «Прометей» практические советы о том, как лучше всего контролировать Kubernetes, посетить серию докладов на различные аспекты Prometheus, а затем пообщаться с некоторыми разработчиками Prometheus на CNCF стенд, за которым последовал «Счастливый час Прометея». Подробнее читайте...
 Продолжить чтение »
 Опубликовано: 8 ноября 2017 г. Фабианом Рейнарцем от имени команды Prometheus Анонс Prometheus 2.0 
 Почти полтора года назад мы выпустили Prometheus 1.0 в дикую природу. Релиз стал важной вехой для проекта. Мы достигли широкого набора функций, которые составляют простую, но чрезвычайно мощную философию мониторинга Prometheus.
 С тех пор мы добавили и улучшили различные интеграции обнаружения служб, расширили PromQL и провели эксперименты с первой итерацией удаленных API, чтобы включить подключаемые решения для долгосрочного хранения.
 Но что еще изменилось, чтобы заслужить новый основной релиз?
 Продолжить чтение »
 Опубликовано: 4 сентября 2017 г. Юлиусом Волцем Что произошло 
 Две недели назад пользователи и разработчики Prometheus со всего мира собрались в Мюнхене на PromCon 2017, второй конференции, посвященной системе мониторинга Prometheus. Целью этого мероприятия был обмен знаниями и передовым опытом, а также установление профессиональных связей в области мониторинга с помощью Prometheus. В этом году мюнхенский офис Google предложил нам гораздо больше места, что позволило нам увеличить количество участников с 80 до 220, при этом все еще распродавая билеты!
 Посмотрите краткое видео, чтобы получить представление о мероприятии:
 
 Продолжить чтение »
 Опубликовано: 22 июня 2017 г. Автор: Goutham Veeramachaneni Сегодня мы выпускаем третью альфа-версию Prometheus 2.0. Помимо множества исправлений ошибок на новом уровне хранилища, он содержит несколько запланированных критических изменений.
 Изменения флага 
 Во-первых, мы перешли к новой библиотеке флагов, в которой используется более распространенный префикс с двойным тире  --  для флагов вместо префикса с одним тире, использовавшегося до сих пор Prometheus. Развертывание должно быть соответствующим образом адаптировано. Кроме того, в этой альфе были удалены некоторые флаги. Полный список начиная с Prometheus 1.0.0:
  web.telemetry-путь 
 Все  Удаленное.хранилище.*  Флаги
 Все  storage.local.*  флаги
  query.staleness-delta 
  alertmanager.url 
 Изменения правил записи 
 Правила оповещения и записи — одна из важнейших функций Prometheus. Но у них также есть несколько проблем с дизайном и недостающие функции, а именно:
. Все правила запускались с одинаковым интервалом. У нас могут быть несколько сложных правил, которые лучше запускать с интервалом в 10 минут, и несколько правил, которые можно запускать с интервалом в 15 секунд.
 Все правила оценивались одновременно, что на самом деле является самой старой открытой ошибкой Prometheus. У этого есть пара проблем, очевидная из которых заключается в том, что нагрузка увеличивается каждый интервал оценки, если у вас много правил. Другой заключается в том, что правила, которые зависят друг от друга, могут получать устаревшие данные. Например:
 экземпляр: network_bytes: rate1m = сумма по (экземпляру) (скорость (network_bytes_total [1m]))
ПРЕДУПРЕЖДЕНИЕ Высокий сетевой трафик
  ЕСЛИ экземпляр:network_bytes:rate1m > 10e6
  ЗА 5м
 
 Здесь мы оповещаем о  instance:network_bytes:rate1m  , но  instance:network_bytes:rate1m  сами по себе генерируются другим правилом. Мы можем получить ожидаемые результаты только в том случае, если предупреждение  HighNetworkTraffic  запускается после того, как будет записано текущее значение для  instance:network_bytes:rate1m .
 Правила и оповещения требовали от пользователей изучения еще одного DSL.
 Для решения вышеуказанных проблем группировка правил была предложена давно, но только недавно была реализована как часть Prometheus 2.0. В рамках этой реализации мы также перенесли правила в хорошо известный формат YAML, что также упрощает создание правил оповещения на основе распространенных шаблонов в пользовательских средах.
 Вот как выглядит новый формат:
 групп:
- имя: имя-моей-группы
  interval: 30s # по умолчанию глобальный интервал
  правила:
  - запись: instance:errors:rate5m
    выражение: скорость (общее_ошибок [5 м])
  - запись: instance:requests:rate5m
    выражение: скорость (общее_запросов [5м])
  - оповещение: HighErrors
    # Выражения остаются в PromQL как прежде и могут быть распределены по
    # несколько строк через многострочные строки YAML.
    выражение: |
      сумма без (экземпляр) (экземпляр: ошибки: скорость 5 м)
      /
      сумма без (экземпляр) (экземпляр: запросы: скорость 5 м)
    для: 5м
    этикетки:
      серьезность: критическая
    аннотации:
      description: "Что-то происходит с {{ $labels. service }}"
 
 Правила в каждой группе выполняются последовательно, и вы можете установить интервал оценки для каждой группы.
 Поскольку это изменение не работает, мы собираемся выпустить его вместе с версией 2.0 и добавить в promtool команду для миграции:  promtool update rules   К преобразованным файлам добавлен суффикс  .yml , и необходимо адаптировать пункт  rule_files  в вашей конфигурации Prometheus.
 Помогите нам перейти к стабильной версии Prometheus 2.0, протестировав эту новую альфа-версию! Вы можете сообщать об ошибках в нашем трекере ошибок и оставлять общие отзывы через каналы нашего сообщества.
 Опубликовано: 14 июня 2017 г. Автор: Brian Brazil  Продолжая серию интервью с пользователями Prometheus, Филипп Панайте и Бартелеми Стивенс из L’Atelier Animation рассказывают о том, как они перешли их анимационная студия от смеси Nagios, Graphite и InfluxDB до Прометей. 
 Расскажите о себе и о том, чем занимается L’Atelier Animation? 
 L’Atelier Animation — студия 3D-анимации, расположенная в красивый город Монреаль Канада. Наш первый полнометражный фильм «Балерина» (также известная как "Leap") был выпущен во всем мире в 2017 году, релиз в США ожидается в конце этого года.
 В настоящее время мы усердно работаем над анимационным сериалом и вторым полнометражным фильмом. фильм. Наша инфраструктура состоит примерно из 300 блейд-модулей рендеринга, 150 рабочих станций и двадцать различных серверов. За исключением пары Маков все работает на Linux (CentOS) и ни на одной машине с Windows.
  
 Каков был ваш опыт мониторинга до Prometheus? 
 Сначала мы использовали смесь Nagios, графит и ИнфлюксБД. Первоначальная настройка была «хорошей», но ничего специальные и слишком сложные (слишком много движущихся частей).
 Почему ты решил посмотреть на Прометея? 
 Когда мы перевели все наши сервисы на CentOS 7, мы рассмотрели новый мониторинг решения и Прометей подошли по многим причинам, но самое главное:
 Node Exporter: благодаря возможностям настройки мы можем получать любые данные от клиентов
 Поддержка SNMP: устраняет необходимость в сторонней службе SNMP
 Система оповещения: Пока, Nagios
 Поддержка Графана
 Как вы перешли? 
 Когда мы закончили наш первый фильм, у нас был небольшой перерыв, так что это было идеально. возможность для нашего ИТ-отдела внести большие изменения. Мы решили промыть нашу вся система мониторинга оказалась не так хороша, как мы хотели.
 Одной из наиболее важных частей является мониторинг сетевого оборудования, поэтому мы начали настроив snmp_exporter на получить данные с одного из наших коммутаторов. Вызовы NetSNMP, которые экспортер make в CentOS отличаются, поэтому нам пришлось перекомпилировать некоторые бинарные файлы, мы сталкивались с небольшими сбоями здесь и там, но с помощью Брайана Бразилии от Robust Perception мы получили все разобрались быстро. Как только у нас заработал snmp_exporter, мы смогли легко добавить новые устройства и получить данные SNMP. Теперь наша основная сеть контролируется в Grafana (включая 13 коммутаторов, 10 VLAN).
 После этого мы настроили node_exporter, как мы и требовали аналитика на рабочих станциях, рендер блейдах и серверах. В нашей области, когда ЦП не на 100% это проблема, мы хотим использовать все силы, которые мы можем, поэтому в конечная температура более критична. Кроме того, нам нужно как можно больше времени безотказной работы, поэтому на всех наших станциях настроены оповещения по электронной почте через Prometheus Alertmanager, так что мы в курсе, когда что-то не так.
 Наши особые потребности требуют от нас мониторинга пользовательских данных от клиентов, это сделано легко благодаря использованию текстового файла node_exporter коллекционер функция. Cronjob выводит определенные данные из любого заданного инструмента в предварительно отформатированный текстовый файл в формате, читаемом Prometheus.
 Поскольку все данные доступны по протоколу HTTP, мы написали Скрипт Python для извлечения данных из Prometheus. Мы сохранить его в базе данных MySQL, доступ к которой осуществляется через Интернет приложение, которое создает живую карту этажей. Это позволяет нам узнать с помощью простого мыши над тем, какой пользователь сидит, где и с каким типом оборудования. Мы также создал еще одну страницу с изображением пользователя и информацией об отделе, это помогает новые сотрудники знают, кто их сосед. Сайт все еще работает проекта, поэтому, пожалуйста, не судите о внешнем виде, мы все-таки системные администраторы, а не веб-сайты. дизайнеры 🙂
 Какие улучшения вы заметили после перехода? 
 Это дало нам возможность изменить то, как мы контролируем все в студии. и вдохновил нас на создание новой пользовательской карты этажей со всеми данными, которые был первоначально получен Прометеем. Настройка намного проще с одним служба, чтобы управлять ими всеми.
 Как вы думаете, какое будущее ждет L’Atelier Animation и Prometheus? 
 В настоящее время мы находимся в процессе интеграции использования лицензий на программное обеспечение с Прометей. Эта информация даст художникам хорошее представление о том, кто что использует. и где.
 Мы продолжим настраивать и добавлять новые функции в Prometheus по требованию пользователей. а поскольку мы работаем с артистами, то знаем, что их будет много 🙂 С SNMP и входные данные пользовательского текстового файла node_exporter, возможности безграничны. ..
 Опубликовано: 17 мая 2017 г. Брайаном Бразилом  Продолжая серию интервью с пользователями Prometheus, Лоран COMMARIEU из iAdvize рассказывает о том, как они заменили свои устаревшие Nagios и Мониторинг Centreon с Prometheus. 
 Можете ли вы рассказать нам о iAdvize? 
 Я Лоран КОМАРЬЕ, системный инженер iAdvize. Я работаю в пределах 60 человек отдел R&D в команде из 5 системных инженеров. Наша работа в основном состоит в том, чтобы убедиться, что приложения, службы и базовая система запущены и Бег. Мы работаем с разработчиками, чтобы обеспечить самый простой путь для их код в производство и предоставлять необходимую обратную связь на каждом этапе. Это где важен мониторинг.
 iAdvize — это полнофункциональная платформа диалоговой коммерции. Мы предоставляем легкий способ для бренда централизованно взаимодействовать со своими клиентами, независимо от канал связи (чат, звонок, видео, Facebook Pages, Facebook Messenger, Twitter, Instagram, WhatsApp, SMS и т. д.). Наши клиенты работают в сфере электронной коммерции, банки, путешествия, мода и т.д. в 40 страны. Мы международная компания из 200 сотрудников с офисами во Франции, Великобритании, Германии, Испании и Италии. В 2015 году мы привлекли 16 миллионов долларов США.
 Каков был ваш опыт мониторинга до Prometheus? 
 Я присоединился к iAdvize в феврале 2016 года. Ранее я работал в компаниях, специализирующихся в мониторинге сети и приложений. Мы работали с программным обеспечением с открытым исходным кодом как Нагиос, Кактусы, Центрон, Заббикс, OpenNMS и т. д., а также некоторые несвободные, такие как HP. НМ, IBM Netcool люкс, БМС Патруль, и т.д.
 iAdvize используется для делегирования мониторинга внешнему провайдеру. Они обеспечили 24/7 мониторинг с помощью Nagios и Centreon. Этот набор инструментов отлично работал с устаревшая статическая архитектура (баребон-серверы, без виртуальных машин, без контейнеров). К завершить этот стек мониторинга, мы также используем Pingdom.
 С переходом нашего монолитного приложения на архитектуру микросервисов (используя Docker) и наше желание перенести нашу текущую рабочую нагрузку в инфраструктуру облачного провайдера, нам нужно было больше контроля и гибкости при мониторинге. В в то же время iAdvize наняла 3 человек, которые увеличили команду инфраструктуры с 2 до 5. При старой системе на добавление уходило как минимум несколько дней или неделя некоторые новые показатели в Centreon и потребовали реальных затрат (времени и денег).
 Почему ты решил посмотреть на Прометея? 
 Мы знали, что Nagios и ему подобные — не лучший выбор. Прометей был восходящим звезда в то время, и мы решили PoC это. Сенсу был тоже был в списке вначале, но Прометей показался нам более многообещающим сценарии использования.
 Нам нужно было что-то, что могло бы интегрироваться с Consul, нашим сервисом обнаружения система. У наших микросервисов уже был маршрут /health; добавление /метрики конечная точка была проста. Практически для каждого инструмента, который мы использовали, был доступен экспортер. (MySQL, Memcached, Redis, nginx, FPM и т. д.).
 На бумаге все выглядело хорошо.
 Как вы перешли? 
 В первую очередь нужно было убедить команду разработчиков (40 человек), что Prometheus был подходящим инструментом для этой работы, и им пришлось добавить экспортер к своим приложениям. Итак, мы сделали небольшую демонстрацию на RabbitMQ, мы установили RabbitMQ экспортер и построил простую панель инструментов Grafana для отображать метрики использования для разработчиков. Сценарий Python был написан для создания некоторых ставить в очередь и публиковать/потреблять сообщения.
 Они были весьма впечатлены тем, что очереди и сообщения появляются в режиме реального времени. До этого у разработчиков не было доступа ни к каким данным мониторинга. Центреон был ограничено нашим поставщиком инфраструктуры. Сегодня Grafana доступна для все в iAdvize, используя интеграцию Google Auth для аутентификации. Там на нем 78 активных аккаунтов (от команд разработчиков до генерального директора).
 После того, как мы начали мониторинг существующих сервисов с помощью Consul и cAdvisor, мы отслеживание фактического наличия контейнеров. За ними следили с помощью Pingdom проверяет, но этого недостаточно.
 Мы разработали несколько пользовательских экспортеров в Go, чтобы собирать некоторые бизнес-метрики из наши базы данных (MySQL и Redis).
 Достаточно скоро мы смогли заменить весь устаревший мониторинг Prometheus.
 Какие улучшения вы заметили после перехода? 
 Бизнес-показатели стали очень популярными, и в периоды распродаж все подключился к Grafana, чтобы посмотреть, побьем ли мы какой-нибудь рекорд. Мы следим за количество одновременных разговоров, ошибки маршрутизации, подключенные агенты, количество посетителей, загружающих тег iAdvize, обращающихся к нашему API-шлюзу и т. д.
 В течение месяца мы работали над оптимизацией наших серверов MySQL с помощью анализа, основанного на Экспортер Newrelic и Percona дашборд для графана. Это было настоящий успех, позволяющий нам обнаруживать неэффективность и выполнять оптимизации, которые сокращают размер базы данных на 45% и пиковую задержку на 75%.
 Есть что сказать. Мы знаем, не имеет ли очередь AMQP потребителя или она Наполнение ненормальное. Мы знаем, когда контейнер перезапускается.
 Видимость просто потрясающая.
 Это было только для устаревшей платформы.
 Все больше и больше микросервисов будет развернуто в облаке и Prometheus используется для наблюдения за ними. Мы используем Consul для регистрации services и Prometheus для обнаружения маршрутов метрик. Все работает как очарование, и мы можем построить панель инструментов Grafana с большим количеством важных метрики бизнеса, приложений и системы.
 Мы создаем масштабируемую архитектуру для развертывания наших сервисов с Кочевник. Кочевник регистрирует медицинские услуги в Consul и с перемаркировкой некоторых тегов мы можем фильтровать те, у кого есть тег имя "метрика = истина". .
 Мы также используем обнаружение службы EC2. Это действительно полезно с автоматическим масштабированием группы. Мы масштабируем и перерабатываем экземпляры, и это уже отслеживается. Больше не надо ожидая, пока наш внешний поставщик инфраструктуры заметит, что происходит в производство.
 Мы используем alertmanager для отправки некоторых предупреждений по SMS или на наш Флоудок.
 Как вы думаете, какое будущее ждет iAdvize и Prometheus? 
 Ждем простой способ добавить долгосрочное масштабируемое хранилище для нашего планирование мощностей.
 У нас есть мечта, что однажды наше автоматическое масштабирование будет запущено Предупреждение Прометея. Мы хотим построить автономную систему на основе реагирования время и бизнес-показатели.
 Раньше я работал с Netuitive, у него было отличное функция обнаружения аномалий с автоматической корреляцией. Было бы здорово есть в Прометее.
 Опубликовано: 10 апреля 2017 г., автор Fabian Reinartz В июле 2016 года Prometheus достиг важной вехи, выпустив версию 1. 0. С тех пор было добавлено множество новых функций, таких как интеграция новых сервисов и наши экспериментальные удаленные API. Мы также поняли, что новые разработки в области инфраструктуры, в частности Kubernetes, позволили отслеживаемым средам стать значительно более динамичными. Неудивительно, что это также создает новые проблемы для Prometheus, и мы выявили узкие места производительности на его уровне хранения.
 В течение последних нескольких месяцев мы разрабатывали и внедряли новую концепцию хранения данных, которая устраняет эти узкие места и в целом демонстрирует значительное повышение производительности. Это также открывает путь к добавлению таких функций, как горячее резервное копирование.
 Изменения настолько фундаментальны, что они вызовут новую основную версию: Prometheus 2.0. 
 Важные функции и изменения, выходящие за рамки хранилища, запланированы до выхода стабильной версии. Однако сегодня мы выпускаем раннюю альфа-версию Prometheus 2.0, чтобы начать процесс стабилизации нового хранилища.
 Теперь доступны архивы выпуска и контейнеры Docker. Если вы заинтересованы в новой механике хранилища, обязательно прочитайте подробный пост в блоге, заглянув под капот.
 Эта версия не работает со старыми данными хранилища и не должна заменять существующие производственные развертывания. Для его запуска каталог данных должен быть пуст, а все существующие флаги хранилища, кроме  -storage.local.retention , должны быть удалены.
 Например; до:
 ./prometheus -storage.local.retention=200h -storage.local.memory-chunks=1000000 -storage.local.max-chunks-to-persist=500000 -storage.local.chunk-encoding=2 -config.file =/etc/prometheus.yaml
 
 после:
 ./prometheus -storage.local.retention=200h -config.file=/etc/prometheus.yaml
 
 Это очень ранняя версия, и следует ожидать сбоев, повреждения данных и ошибок в целом. Помогите нам перейти к стабильной версии, отправив их в наш трекер проблем.
 В этой альфа-версии отключены экспериментальные API удаленного хранилища. Очистка целей, раскрывающих временные метки, таких как федеративные серверы Prometheus, пока не работает. Формат хранения ломается и снова сломается между последующими альфа-версиями. Мы планируем задокументировать путь обновления с 1.0 до 2.0, как только мы приблизимся к стабильной версии.
 Опубликовано: 6 апреля 2017 г. Автор: Brian Brazil  Продолжая серию интервью с пользователями Prometheus, Тобиас Гезельхен из Europace рассказывает о том, как они открыли Прометея. 
 Можете ли вы рассказать нам о Europace? 
 Europace AG занимается разработкой и эксплуатацией веб-сайта Финансовый рынок EUROPACE, который является крупнейшей платформой Германии для ипотечные кредиты, строительные финансовые продукты и потребительские кредиты. Полностью интегрированный система связывает около 400 партнеров – банки, страховые компании и финансовый продукт дистрибьюторы. Несколько тысяч пользователей выполняют около 35 000 транзакций на сумму в общей сложности до 4 миллиардов евро на EUROPACE каждый месяц. Наши инженеры регулярно блог на http://tech.europace.de/ и @ЕвропейсТех.
 Каков был ваш опыт мониторинга до Prometheus? 
 Нагиос/Исинга все еще используется для других проектов, но с растущим количеством сервисов и выше потребность в гибкости, мы искали другие решения. Благодаря Nagios и Icinga будучи более централизованным, Prometheus соответствовал нашей цели, чтобы иметь полный DevOps накапливается в нашей команде и переносит определенные обязанности с наших команда инфраструктуры участникам проекта.
 Почему ты решил посмотреть на Прометея? 
 Благодаря нашей деятельности в Docker Berlin сообщество, с которым мы контактировали SoundCloud и Джулиус Volz, который дал нам хороший обзор. сочетание гибких контейнеров Docker с очень гибким концепция убедила нас попробовать Prometheus. Настройка Prometheus была простой достаточно, и Alertmanager работал для наших нужд, так что мы не видели никаких причина попробовать альтернативы. Даже наши небольшие пулреквесты для улучшения интеграция в среде Docker и с инструментами обмена сообщениями была объединена очень быстро. Со временем мы добавили в стек несколько экспортеров и Grafana. Мы никогда не оглядывались назад и не искали альтернатив.
 Как вы перешли? 
 Наша команда представила Prometheus в новом проекте, поэтому переход не происходит в нашей команде. Другие команды начали с добавления Prometheus бок о бок к существующие решения, а затем шаг за шагом переносили сборщики метрик. Пользовательские экспортеры и другие временные сервисы помогли во время миграции. Grafana уже существовала, поэтому нам не пришлось думать о другой панели инструментов. Немного проекты по-прежнему используют параллельно Icinga и Prometheus.
 Какие улучшения вы заметили после перехода? 
 У нас были проблемы с использованием Icinga из-за масштабируемости — несколько команд поддерживали решение с централизованным управлением не сработало. Использование стека Prometheus вместе с помощью Alertmanager мы разделили наши команды и проекты. Alertmanager это теперь можно развернуть в режиме высокой доступности режим, который является большое улучшение в основе нашей инфраструктуры мониторинга.
 Как вы думаете, какое будущее ждет Европу и Прометей? 
 Другие команды нашей компании постепенно внедряют Prometheus в свои проекты. Мы ожидаем, что больше проектов представит Prometheus вместе с Alertmanager и потихоньку заменяем Icinga. Благодаря присущей ему гибкости Prometheus мы ожидаем, что он будет масштабироваться с нашими потребностями и что у нас не будет вопросы адаптации его к будущим требованиям.
 Опубликовано: 20 февраля 2017 г. Автор: Brian Brazil  Продолжая серию интервью с пользователями Prometheus, Том Уилки из Weaveworks рассказывает о том, как они выбрали Prometheus и теперь строят его. 
 Можете ли вы рассказать нам о Weaveworks? 
 Weaveworks предлагает Weave Облако, сервис, который «вводит в действие» микросервисы за счет комбинации проектов с открытым исходным кодом. и программное обеспечение как услуга.
 Weave Cloud состоит из:
 Визуализация с Weave Scope
 Непрерывное развертывание с помощью Weave Flux
 Сеть с Weave Net, контейнер SDN
 Мониторинг с помощью Weave Cortex, нашего продукта с открытым исходным кодом, распространяемого по модели Prometheus-as-a-Service.
 Вы можете попробовать Weave Cloud бесплатно в течение 60 дней. Чтобы быть в курсе последних новостей о наших продуктах, читайте наш блог, Twitter или Slack (пригласите).
 Каков был ваш опыт мониторинга до Prometheus? 
 Weave Cloud была реализована с чистого листа, поэтому ранее не было Система наблюдения. В предыдущих жизнях команда использовала типичные инструменты, такие как как Мунин и Нагиос. Weave Cloud начал свою жизнь как мультиарендатор, версия Сферы. Область включает в себя базовый мониторинг таких вещей, как ЦП и использование памяти, поэтому я думаю, вы могли бы сказать, что мы использовали это. Но нам нужно было что-то контролировать сам Scope...
 Почему ты решил посмотреть на Прометея? 
 У нас есть куча бывших сотрудников Google SRE в штате, так что у нас было много опыта с Borgmon и бывший SoundClouder с опытом работы с Prometheus. Мы построили сервис на Kubernetes и искали что-то, что бы «соответствовало» его динамически запланированный характер - так что Prometheus не составлял труда. Мы даже написал серию сообщений в блоге, в которых рассказывается, почему Prometheus и Kubernetes работают вместе. так хорошо первое.
 Как вы перешли? 
 Когда мы начинали с Prometheus, обнаружение службы Kubernetes было еще PR и как таковых документов было мало. Некоторое время мы запускали пользовательскую сборку и как бы просто запутались, разрабатывая это для себя. В итоге мы дали рассказали на лондонской встрече Prometheus о нашем опыте и опубликовали серия постов в блоге.
 Мы перепробовали практически все варианты запуска Prometheus. Мы начали создавать собственные образы контейнеров со встроенной конфигурацией, запуская их все вместе в одном модуле вместе с Grafana и Alert Manager. Мы использовали эфемерное внутреннее хранилище данных временных рядов. Затем мы разбили это на разные поды, чтобы нам не пришлось перезапускать Prometheus (и терять историю) всякий раз, когда мы меняли наши информационные панели. Совсем недавно мы перешли к использованию восходящие образы и сохранение конфигурации в карте конфигурации Kubernetes, которая получает обновляется нашей системой CI всякий раз, когда мы ее меняем. Мы используем маленькую коляску контейнер в модуле Prometheus для просмотра файла конфигурации и проверки связи с Prometheus. когда он меняется. Это означает, что нам не нужно слишком часто перезапускать Prometheus, можно уйти, не делая ничего необычного для хранения, и не потерять историю.
 До сих пор не давала нам покоя проблема периодической потери истории Прометея, и все доступные решения, такие как тома Kubernetes или периодические резервные копии S3, их минусы. Наряду с нашим фантастическим опытом использования Prometheus для контролировать службу Scope, это побудило нас создать облачную, распределённая версия Prometheus - та, которую можно было бы апгрейдить, тасовать вокруг и пережить сбои хоста, не теряя истории. И вот как Weave Кортекс родился.
 Какие улучшения вы заметили после перехода? 
 Не обращая внимания на Cortex на секунду, мы были особенно взволнованы, увидев введение диспетчера оповещений о высокой доступности; хотя в основном потому, что это был один из первые проекты, не относящиеся к Weaveworks, в которых используется Weave Mesh, наш слой сплетен и координации.
 Мне также особенно понравилась вторая версия сервиса Kubernetes. изменения Фабиана - это решило острую проблему с мониторингом наши Consul Pods, где нам нужно было очистить несколько портов в одном и том же Pod.
 И было бы упущением не упомянуть функцию удаленной записи (то, что я работал над собой). При этом Prometheus образует ключевой компонент Weave Cortex. себя, очищая цели и отправляя образцы нам.
 Как вы думаете, какое будущее ждет Weaveworks и Prometheus? 
 Для меня ближайшее будущее - это Weave Cortex, Prometheus Weaveworks как Обслуживание. Мы широко используем его внутри компании и начинаем достигать довольно хорошая производительность запросов из него. Он работает в производстве с реальными пользователями прямо сейчас, а вскоре мы добавим поддержку оповещений и достижения функция паритета с вышестоящим Prometheus. Оттуда мы войдем в бета-версию программа стабилизации до общедоступности в середине год.
 В рамках Cortex мы разработали интеллектуальное выражение Prometheus браузер с автозаполнением для ноутбуков PromQL и Jupyter-esque. Были с нетерпением жду возможности представить это большему количеству людей и, в конечном итоге, открыть поиск его.
 У меня также есть небольшой побочный проект под названием Локи, который приносит Прометея обнаружение сервисов и парсинг в OpenTracing, а также делает распределенную трассировку легкий и прочный. Я расскажу об этом на KubeCon/CNCFCon. Берлин в конце марта.
 Опубликовано: 16 ноября 2016 г. Автор: Brian Brazil  Продолжаем серию интервью с пользователями Prometheus, Canonical talks о том, как они переходят к Прометею. 
 Можете ли вы рассказать нам о себе и о том, чем занимается Canonical? 
 Canonical, вероятно, наиболее известна как компания которая спонсирует Ubuntu Linux. Мы также производим или участвуем в ряде других проекты с открытым исходным кодом, включая MAAS, Juju и OpenStack, и предоставлять коммерческая поддержка этих продуктов. Ubuntu поддерживает большую часть OpenStack развертываний, при этом 55 % производственных облаков и 58 % крупных облачных развертывания.
 Моя группа BootStack — это наша полностью управляемая частная облачная служба. Мы строим и управлять облаками OpenStack для клиентов Canonical.
 Каков был ваш опыт мониторинга до Prometheus? 
 Мы использовали комбинацию Nagios, графит/статсд, и собственные приложения Django. Эти не предлагали нам уровень гибкости и отчетности, которые нам нужны как в нашей внутренней, так и в клиентские облачные среды.
 Почему ты решил посмотреть на Прометея? 
 Мы рассмотрели несколько альтернатив, в том числе InfluxDB и расширение использования Графит, но наш первый опыт с Прометеем показал, что он сочетание простоты и мощности, которое мы искали. Мы особенно оцените удобство меток, простой HTTP-протокол и Оповещение о временных рядах коробки. потенциал Prometheus для замены 2 разных инструментов (оповещения и тренды) с одним особенно привлекательным.
 Кроме того, некоторые из наших сотрудников уже имели опыт работы с Боргмоном. в Google, что значительно повысило наш интерес!
 Как вы перешли? 
 Мы все еще находимся в процессе перехода, мы ожидаем, что это займет некоторое время. время из-за количества пользовательских проверок, которые мы в настоящее время используем в наших существующих системы, которые нужно будет заново реализовать в Prometheus. Самый полезный ресурсом была документация сайта prometheus.io.
 Долго выбирали экспортера. Мы изначально шли с collectd, но столкнулся с ограничениями при этом. Мы работаю над написанием openstack-экспортер сейчас и были немного удивлены, обнаружив, что нет хорошего, рабочего примера, как написать экспортер с нуля.
 Вот некоторые проблемы, с которыми мы столкнулись: отсутствие поддержки понижающей дискретизации, отсутствие долгосрочной решение для хранения (пока), и мы были удивлены двухнедельным сроком хранения по умолчанию период. В настоящее время нет привязки к Джуджу, но мы работаем над этим!
 Какие улучшения вы заметили после перехода? 
 Как только мы освоились с экспортерами, мы обнаружили, что их очень легко писать и дали нам очень полезные показатели. Например, мы разрабатываем openstack-exporter для наших облачных сред. Мы также видели очень быстро кросс-командное внедрение от наших групп DevOps и WebOps и разработчиков. мы не еще есть оповещения, но ожидайте увидеть гораздо больше, когда мы доберемся до этот этап перехода.
 Как вы думаете, какое будущее ждет Canonical и Prometheus? 
 Мы ожидаем, что Prometheus будет важной частью нашего мониторинга и отчетности инфраструктура, обеспечивающая сбор и хранение метрик для многочисленных современные и будущие системы. Мы видим, что он потенциально заменит Nagios в отношении оповещение.
 Опубликовано: 12 октября 2016 г. Автор: Brian Brazil  Продолжая серию интервью с пользователями Prometheus, JustWatch talks о том, как они установили свой мониторинг. 
 Расскажите о себе и о том, чем занимается JustWatch? 
 Для потребителей JustWatch — это потоковый поиск движок, который помогает узнать, где легально смотреть фильмы и сериалы онлайн и в театрах. Вы можете искать киноконтент во всех основных потоковых сервисах. провайдеры, такие как Netflix, HBO, Amazon Video, iTunes, Google Play и многие другие. в 17 странах.
 Для наших клиентов, таких как киностудии или поставщики видео по запросу, мы международная компания киномаркетинга, которая собирает анонимные данные о покупательское поведение и вкус поклонников фильмов по всему миру в наших потребительских приложениях. Мы помогать студиям рекламировать свой контент нужной аудитории и делать цифровые видеореклама намного эффективнее в минимизации покрытия отходов.
 С момента запуска в 2014 году мы прошли путь от нуля до одного из крупнейших 20 000 веб-сайтов. на международном уровне, не тратя ни доллара на маркетинг, став крупнейшая поисковая система потокового вещания в мире менее чем за два года. В настоящее время с команда инженеров всего из 10 человек, мы создаем и эксплуатируем полностью докеризованный стек около 50 микро- и макросервисов, работающих в основном на Кубернетес.
 Каков был ваш опыт мониторинга до Prometheus? 
 В предыдущих компаниях многие из нас работали с большинством систем мониторинга с открытым исходным кодом. продукты есть. У нас есть некоторый опыт работы с Нагиос, Айсинга, Заббикс, Монит, Мунин, Графит и несколько других систем. В одной компании я помогал создавать распределенную установку Nagios. с куклой. Эта установка была удобной, так как новые сервисы автоматически появлялись в система, но удаление экземпляров все еще было болезненным. Как только у вас есть некоторые различия в ваших системах, наборах мониторинга на основе хоста и службы просто не совсем подходит. Подход Prometheus, основанный на метках, был то, что я всегда хотел иметь, но не находил раньше.
 Почему ты решил посмотреть на Прометея? 
 На JustWatch публичное объявление Prometheus попало как раз в нужное время. Мы в основном проводил мониторинг черного ящика в течение первых нескольких месяцев работы компании - CloudWatch для некоторых из наиболее важных внутренние показатели в сочетании с внешними сервисами, такими как Pingdom для обнаружения сбоев в работе сайта. Кроме того, ни один классических host-based решений нас удовлетворили. В мире контейнеров и микросервисы, хост-инструменты, такие как Icinga, Thruk или Zabbix казались устаревшими и не готовыми к работа. Когда мы начали изучать мониторинг белого ящика, некоторые из нас, к счастью, посетил встречу в Голанге, где Юлий и Бьорн объявили о Прометее. Мы быстро настроили сервер Prometheus и начали инструментировать наши сервисы Go (мы используем почти только Go для бэкенда). Удивительно, как легко это было - дизайн казался ориентированным на облако и сервис в качестве первого принципа и никогда не мешал.
 Как вы перешли? 
 Переход был не таким уж трудным с точки зрения времени, нам посчастливилось перейти от нет релевантного мониторинга непосредственно в Prometheus.
 Переход на Prometheus в основном заключался в включении клиента Go в наши приложения. и обертывание обработчиков HTTP. Мы также написали и развернули несколько экспортеров, включая node_exporter и несколько экспортеров для API облачных провайдеров. По нашему опыту мониторинга и оповещение — это проект, который никогда не заканчивается, но основная часть работы уже сделана в течение нескольких недель в качестве побочного проекта.
 С момента развертывания Prometheus мы склонны рассматривать метрики всякий раз, когда мы пропустите что-то или когда мы разрабатываем новые услуги с нуля.
 Потребовалось некоторое время, чтобы полностью осознать элегантность концепции PromQL и меток. полностью, но усилия действительно окупились.
 Какие улучшения вы заметили после перехода? 
 Prometheus просветил нас, позволив невероятно легко пожинать плоды от мониторинга белого ящика и канареечного развертывания на основе меток. Нестандартный метрики для многих аспектов Golang (HTTP Handler, Go Runtime) помогли нам достичь окупаемость инвестиций очень быстро - одни только метрики goroutine спасли положение много раз. Единственный компонент мониторинга, который нам действительно нравился раньше - Grafana - кажется естественным подходом для Prometheus и позволил нам создать несколько очень полезных информационных панелей. Мы оценили это Прометей не пытался заново изобретать велосипед, а скорее идеально вписался в лучшее решение там. Еще одним огромным улучшением по сравнению с предшественниками было Сосредоточенность Прометея на правильном расчете (процентили и т. д.). В других системах, мы никогда не были уверены, что предлагаемые операции имеют смысл. Особенно процентили являются таким естественным и необходимым способом рассуждения о производительность микросервиса, что было здорово, что они получают первоклассный лечение.
 Интегрированное обнаружение служб упрощает управление сбором данных. цели. Для Kubernetes все работает «из коробки». Для некоторых других системы, еще не работающие в Kubernetes, мы используем Консульский подход. Все, что нужно, чтобы получить Приложение, отслеживаемое Prometheus, состоит в том, чтобы добавить клиента, выставить  /metrics  и установите одну простую аннотацию на Container/Pod. Эта низкая связь выводит много разногласий между разработкой и эксплуатацией — многие сервисы построен хорошо спланирован с самого начала, потому что это просто и весело.
 Сочетание временных рядов и интеллектуальных функций обеспечивает отличные оповещения сверхспособности. Агрегации, работающие на сервере и обрабатывающие оба временные ряды, их комбинации и даже функции от этих комбинаций как Первоклассные граждане делают оповещение легким делом - часто постфактум.
 Как вы думаете, какое будущее ждет JustWatch и Prometheus? 
 Хотя мы очень ценим то, что Прометей сосредотачивается не на том, чтобы быть блестящим, а на действительно работающий и приносящий пользу, будучи достаточно простым в развертывании и работать - особенно Alertmanager оставляет желать лучшего. Лишь некоторые простые улучшения, такие как упрощенное создание и редактирование интерактивных предупреждений в интерфейс будет иметь большое значение в работе с предупреждениями, будучи еще проще.
 Мы действительно с нетерпением ждем продолжающихся улучшений уровня хранения, включая удаленное хранилище. Мы также надеемся, что некоторые из подходов, принятых в Проект Призма и Vulcan будет портирован на ядро Прометей. Наиболее интересные темы для нас сейчас — GCE Service Обнаружение, более легкое масштабирование и гораздо более длительные периоды хранения (даже ценой более холодного хранения и гораздо более длительного времени запроса для более старых событий).
 Мы также надеемся использовать Prometheus для более нетехнических также отделы. Мы хотели бы покрыть большинство наших KPI с помощью Prometheus, чтобы позволяют каждому создавать красивые информационные панели, а также оповещения. Были в настоящее время даже планирую злоупотреблять потрясающим механизмом оповещения для нового, внутреннего бизнес-проект, а также - следите за обновлениями!
 Опубликовано: 21 сентября 2016 г. Автор: Brian Brazil  Продолжая серию интервью с пользователями Prometheus, доклады Compose об их переходе от Graphite и InfluxDB к Prometheus. 
 Расскажите о себе и о том, чем занимается Compose? 
 Compose предоставляет готовые к работе кластеры баз данных как услуга для разработчиков по всему миру. К нам может прийти разработчик приложения и в несколько кликов получите многохостовую, высокодоступную, автоматически поддерживаемую и безопасная база данных готова за считанные минуты. Эти развертывания базы данных затем автоматическое масштабирование по мере увеличения спроса, чтобы разработчик мог тратить свое время на создавать свои замечательные приложения, а не запускать свою базу данных.
 У нас есть десятки кластеров хостов как минимум в двух регионах в каждом из AWS, Облачная платформа Google и SoftLayer. Каждый кластер охватывает зоны доступности где поддерживается и содержит около 1000 высокодоступных баз данных развертывания в собственных частных сетях. Больше регионов и провайдеров в работы.
 Каков был ваш опыт мониторинга до Prometheus? 
 До Прометея было опробовано несколько различных систем метрик. Первый система, которую мы пробовали, была Graphite, которая работала довольно сначала, но огромный объем различных показателей, которые нам приходилось хранить, в сочетании с тем, как файлы Whisper хранятся и доступны на диске, быстро перегрузили наши системы. Хотя мы знали, что Graphite можно масштабировать горизонтально относительно легко, это был бы дорогой кластер. InfluxDB выглядел более многообещающе, поэтому мы начали пробовал ранние версии этого, и это, казалось, хорошо работало для хорошего пока. Прощай графит.
 В более ранних версиях InfluxDB были проблемы с повреждением данных. время от времени. Нам почти регулярно приходилось очищать все наши показатели. Это не было Сокрушительный проигрыш для нас обычный, но раздражающий. Продолжающиеся обещания черт, которые так и не материализовались, откровенно говоря, носили нас.
 Почему ты решил посмотреть на Прометея? 
 Казалось, что он сочетает в себе более высокую эффективность с более простыми операциями, чем другие опции.
 Сбор метрик на основе извлечения поначалу озадачил нас, но вскоре мы поняли преимущества. Первоначально казалось, что он может быть слишком тяжелым для масштабирования. хорошо в нашей среде, где у нас часто есть несколько сотен контейнеров с свои метрики на каждом хосте, но объединив его с Telegraf, мы можем организовать экспорт метрик каждого хоста для всех его контейнеров (а также общие метрики ресурсов) через единую цель очистки Prometheus.
 Как вы перешли? 
 Мы являемся магазином Chef, поэтому мы развернули большой экземпляр с большим объемом EBS и затем потянулся прямо к шеф-повару сообщества кулинарная книга для Прометея.
 Разместив Prometheus на хосте, мы написали небольшой Ruby-скрипт, использующий Chef API для запроса всех наших хостов и записи целевого файла конфигурации Prometheus. Мы используем этот файл с  file_sd_config , чтобы убедиться, что все хосты обнаружены и очищаются, как только они регистрируются в Chef. Благодаря открытому Прометею экосистемы, мы смогли использовать Telegraf из коробки с простой конфигурацией для напрямую экспортировать метрики на уровне хоста.
 Мы проверяли, насколько далеко может масштабироваться один Прометей, и ждали, когда он упасть. Это не так! На самом деле он справился с нагрузкой собранных метрик на уровне хоста. каждые 15 секунд около 450 хостов в нашей новой инфраструктуре с очень небольшое использование ресурсов.
 У нас есть много контейнеров на каждом хосте, поэтому мы ожидали, что нам придется начать к шарду Prometheus, как только мы добавили все метрики использования памяти из них, но Прометей просто продолжал идти без какой-либо драмы и все же не слишком близок к насыщению своих ресурсов. В настоящее время мы отслеживаем более 400 000 различных метрики каждые 15 секунд примерно для 40 000 контейнеров на 450 хостах с один экземпляр m4.xlarge prometheus с хранилищем 1 ТБ. Вы можете увидеть наш хост панель управления для этого хоста ниже. Дисковый ввод-вывод на томе EBS gp2 SSD объемом 1 ТБ будет вероятно, будет ограничивающим фактором в конечном итоге. Наше первоначальное предположение хорошо на данный момент выделено больше ресурсов, но мы быстро растем как по собираемым показателям, так и по хосты/контейнеры для мониторинга.
 В этот момент сервер Prometheus, который мы запустили для тестирования, был намного лучше. надежнее, чем кластер InfluxDB, который выполнял ту же работу раньше, поэтому мы некоторую базовую работу, чтобы сделать ее менее единой точкой отказа. Мы добавили еще один идентичный узел очищает все те же цели, а затем добавляет простой переход на другой ресурс схема с keepalived + обновления DNS. Теперь это было более доступно, чем наша предыдущая система, поэтому мы переключили наши графики, ориентированные на клиентов, на использование Prometheus и разрушил старую систему.
 Какие улучшения вы заметили после перехода? 
 Наша предыдущая установка мониторинга была ненадежной и сложной в управлении. С Prometheus, у нас есть система, которая хорошо работает для построения графиков множества показателей, и у нас есть члены команды, внезапно воодушевленные новыми способами его использования, а не опасайтесь касаться системы метрик, которую мы использовали раньше.
 Кластер тоже проще, всего два одинаковых узла. Когда мы растем, мы знаем нам придется распределить работу по большему количеству хостов Prometheus, и мы рассмотрели несколько способов сделать это.
 Как вы думаете, что ждет Compose и Prometheus в будущем? 
 Прямо сейчас мы воспроизвели только метрики, которые мы уже собрали в предыдущем системы — базовое использование памяти для клиентских контейнеров, а также на уровне хоста использование ресурсов для собственных операций. Следующим логическим шагом является включение команды базы данных для отправки метрик в локальный экземпляр Telegraf изнутри Контейнеры БД, чтобы мы могли также записывать статистику на уровне базы данных без увеличения количество целей, которые нужно очистить.
 У нас также есть несколько других систем, которые мы хотим получить в Prometheus, чтобы получить лучшая видимость. Мы запускаем наши приложения на Mesos и интегрировали базовый Docker. метрики контейнера уже лучше, чем раньше, но мы также хотим иметь больше компонентов инфраструктуры в записи кластера Mesos для центральный Prometheus, чтобы мы могли иметь централизованные информационные панели, показывающие все элементы поддержки работоспособности системы от балансировщиков нагрузки до приложения метрики.
 В конце концов нам нужно будет раздробить Прометея. Мы уже разделили клиента развертывания среди множества небольших кластеров по разным причинам, поэтому один логичным вариантом было бы перейти на меньший сервер Prometheus (или пару для избыточность) на кластер, а не на один глобальный.
 Для большинства потребностей в отчетности это не является большой проблемой, поскольку нам обычно не требуется хосты/контейнеры из разных кластеров на одной панели, но мы можем сохранить небольшой глобальный кластер с гораздо более длительным сроком хранения и лишь скромным количеством субдискретизированные и агрегированные метрики из Prometheus каждого кластера с использованием Правила записи.
 Опубликовано: 14 сентября 2016 г. Автор: Brian Brazil  Следующее в нашей серии интервью с пользователями Prometheus, DigitalOcean talks о том, как они используют Прометея. Карлос Амеди также говорил о социальной аспекты внедрения на PromCon 2016. 
 Можете ли вы рассказать нам о себе и о том, чем занимается DigitalOcean? 
 Меня зовут Ян Хансен, и я работаю в команде по платформенным метрикам. DigitalOcean предоставляет простые облачные вычисления. На сегодняшний день мы создали 20 миллионов дроплетов (облачных серверов SSD) в 13 регионы. Мы также недавно выпустили новый продукт Block Storage.
 Каков был ваш опыт мониторинга до Prometheus? 
 До Prometheus мы использовали Graphite и ОпенТСДБ. Графит использовался для мелкосерийного производства. приложения и OpenTSDB использовались для сбора метрик со всех наших физические серверы через Collectd. Nagios будет извлекать эти базы данных для запуска предупреждений. Мы по-прежнему используем Graphite, но больше не используем OpenTSDB.
 Почему ты решил посмотреть на Прометея? 
 Меня разочаровала OpenTSDB, потому что я отвечал за сохранение кластер онлайн, но обнаружил, что ему трудно защититься от метрических штормов. Иногда команда запускала новую (очень болтливую) службу, которая влияла на общую емкость кластера и повредить моим соглашениям об уровне обслуживания.
 Мы можем внести в черный или белый список новые метрики, поступающие в OpenTSDB, но не было отличного способа защититься от болтливых сервисов, за исключением организационный процесс (который было трудно изменить/внедрить). Другие команды были разочарованы языком запросов и инструментами визуализации, доступными на время. Я болтал с Джулиусом Волцем о метрических системах выталкивания и вытягивания и был продался в желании попробовать Prometheus, когда я увидел, что действительно буду контролировать моего SLA, когда я могу определить, что я извлекаю и как часто. Плюс я действительно очень понравился язык запросов.
 Как вы перешли? 
 Мы собирали метрики через Collectd, отправляя их в OpenTSDB. Установка Node Exporter параллельно с наша уже работающая установка Collectd позволила нам начать экспериментировать с Прометей. Мы также создали собственный экспортер для предоставления метрик Droplet. Скоро, у нас был паритет функций с нашим сервисом OpenTSDB, и мы начали отключать Collectd, а затем выключил кластер OpenTSDB.
 Людям очень понравился Prometheus и инструменты визуализации, которые к нему прилагались. Внезапно у моей небольшой команды по метрикам накопилось отставание, которое мы не смогли быстро выполнить. достаточно, чтобы сделать людей счастливыми, и вместо того, чтобы обеспечивать и поддерживать Prometheus для обслуживания людей, мы рассмотрели создание инструментов, чтобы сделать его максимально чтобы другим командам было проще запускать свои собственные серверы Prometheus и также управляйте общими экспортерами, которые мы используем в компании.
 Некоторые команды начали использовать Alertmanager, но у нас все еще есть концепция извлечение Prometheus из наших существующих инструментов мониторинга.
 Какие улучшения вы заметили после перехода? 
 Мы улучшили наше понимание машин с гипервизором. Данные, которые мы могли получить у Collectd и Node Exporter примерно одинаковые, но гораздо проще для нашего команда разработчиков golang для создания нового пользовательского экспортера, который предоставляет данные специфичные для сервисов, которые мы запускаем на каждом гипервизоре.
 Мы представляем лучшие показатели приложения. Легче учиться и учить, как чтобы создать метрику Prometheus, которую можно будет правильно агрегировать позже. С Graphite легко создать метрику, которую нельзя агрегировать определенным образом позже, потому что имя, разделенное точками, не было правильно структурировано.
 Создавать оповещения намного быстрее и проще, чем раньше, плюс в язык, который знаком. Это дало возможность командам создавать более эффективные оповещения. для сервисов, которые они знают и понимают, потому что они могут быстро выполнять итерации.
 Как вы думаете, какое будущее ждет DigitalOcean и Prometheus? 
 Мы продолжаем искать способы максимально упростить сбор метрик для команд в DigitalOcean. Сейчас команды запускают собственный Prometheus. серверы для того, что им небезразлично, что позволило нам добиться наблюдаемости иначе у нас не было бы так быстро. Но не каждая команда должна уметь управлять Прометеем. Мы думаем, что мы можем сделать, чтобы Прометей настолько автоматически, насколько это возможно, чтобы команды могли просто сосредоточиться на том, какие запросы и оповещения, которые они хотят получить в своих службах и базах данных.
 Мы также создали Вулкан, чтобы имеют долгосрочное хранилище данных, сохраняя при этом язык запросов Prometheus, который мы создали инструменты и обучили людей, как их использовать.
 Опубликовано: 7 сентября 2016 г. Автор Brian Brazil  Продолжая нашу серию интервью с пользователями Prometheus, ShuttleCloud рассказывает о том, как они начали использовать Prometheus. Игнасио из ShuttleCloud также объяснил, чем Prometheus хорош для вашего небольшого стартапа, на PromCon 2016. 
 Что делает ShuttleCloud? 
 ShuttleCloud — самая масштабируемая в мире система импорта данных электронной почты и контактов. Мы помогаем некоторым ведущим поставщикам электронной почты и адресных книг, в том числе Google и Comcast, увеличить рост числа пользователей и вовлеченность, автоматизируя процесс переключения посредством импорта данных.
 Интегрируя наш API в свои предложения, наши клиенты позволяют своим пользователям легко переносить свою электронную почту и контакты с одного участвующего поставщика на другого, уменьшая трения, с которыми сталкиваются пользователи при переходе на нового поставщика. Поддерживаемые поставщики электронной почты 24/7 включают всех основных поставщиков интернет-услуг в США: Comcast, Time Warner Cable, AT&T, Verizon и других.
 Предлагая конечным пользователям простой способ переноса их электронной почты (при сохранении полного контроля над пользовательским интерфейсом инструмента импорта), наши клиенты значительно улучшают активацию пользователей и адаптацию.
   Интеграция ShuttleCloud с платформой Google Gmail.    Gmail импортировал данные для 3 миллионов пользователей с помощью нашего API. 
 Технология ShuttleCloud шифрует все данные, необходимые для обработки импорта, в дополнение к самым безопасным стандартам (SSL, oAuth) для обеспечения конфиденциальности и целостности запросов API. Наша технология позволяет нам гарантировать высокую доступность нашей платформы, до 9Гарантия безотказной работы 9,5%.
 Каков был ваш опыт мониторинга до Prometheus? 
 Вначале правильная система мониторинга нашей инфраструктуры не была одним из наших главных приоритетов. У нас было не так много проектов и экземпляров, как сейчас, поэтому мы работали с другими простыми системами, чтобы предупредить нас, если что-то не работает должным образом, и взять это под контроль.
 У нас был набор автоматических сценариев для мониторинга большинства операционных показателей машин. Они были основаны на cron и выполнялись с помощью Ansible с централизованной машины. Оповещения были отправлены по электронной почте всей команде разработчиков.
 Мы доверили Pingdom внешний мониторинг черного ящика и проверку работоспособности всех наших интерфейсов. Они предоставили простой интерфейс и систему оповещения в случае, если какой-либо из наших внешних сервисов был недоступен.
 К счастью, появились крупные клиенты, и SLA стали более требовательными. Поэтому нам нужно было что-то еще, чтобы измерить нашу работу и убедиться, что мы соблюдаем все соглашения об уровне обслуживания. Одной из функций, которые нам требовались, было наличие точных статистических данных о нашей производительности и бизнес-показателях (т. е. о том, сколько миграций завершилось правильно), поэтому мы больше думали об отчетах, чем о мониторинге.
 Мы разработали следующую систему:
 Источником всех необходимых данных является база данных состояния в CouchDB. Там каждый документ представляет один статус операции. Эта информация обрабатывается средством импорта состояния и сохраняется реляционным образом в базе данных MySQL.
 Компонент собирает данные из этой базы данных, при этом информация агрегируется и обрабатывается в нескольких представлениях.
 Одним из представлений является отчет по электронной почте, который нам нужен для целей отчетности. Это отправляется по электронной почте.
 Другое представление отправляет данные на панель управления, где ими можно легко управлять. Служба панели мониторинга, которую мы использовали, была внешней. Мы доверяли Ducksboard не только потому, что информационные панели были просты в настройке и красиво выглядели, но и потому, что они выдавали автоматические оповещения при достижении порогового значения.
 Со всем этим нам не потребовалось много времени, чтобы понять, что нам понадобятся надлежащие показатели, система мониторинга и оповещения, поскольку количество проектов начало увеличиваться.
 Некоторыми недостатками систем, которые у нас были в то время, были:
 Нет централизованной системы мониторинга. Каждый тип метрики имел свой собственный: Системные показатели → Скрипты, запускаемые Ansible.
 Бизнес-показатели → Ducksboard и отчеты по электронной почте.
 Метрики черного ящика → Pingdom.
 Нет стандартной системы оповещения. У каждого типа метрик были разные оповещения (электронная почта, push-уведомления и т. д.).
 Для некоторых бизнес-показателей не было предупреждений. Они были проверены вручную.
 Почему ты решил посмотреть на Прометея? 
 Мы проанализировали несколько систем мониторинга и оповещения. Нам не терпелось запачкать руки и проверить, будет ли решение успешным или нет. Системой, которую мы решили испытать, был Прометей по следующим причинам:
 Во-первых, вам не нужно определять фиксированную метрическую систему, чтобы начать с ней работать; метрики могут быть добавлены или изменены в будущем. Это обеспечивает ценную гибкость, когда вы еще не знаете все показатели, которые хотите отслеживать.
 Если вы что-нибудь знаете о Prometheus, вы знаете, что метрики могут иметь метки, которые отвлекают нас от того факта, что учитываются разные временные ряды. Это, вместе с его языком запросов, обеспечило еще большую гибкость и мощный инструмент. Например, у нас может быть определена одна и та же метрика для разных сред или проектов, и мы можем получить определенный временной ряд или агрегировать определенные метрики с соответствующими метками:  http_requests_total{job="my_super_app_1",environment="staging"}  — временной ряд, соответствующий промежуточной среде для приложения «my_super_app_1».
  http_requests_total{job="my_super_app_1"}  - временной ряд для всех сред для приложения "my_super_app_1".
  http_requests_total{environment="staging"}  — временной ряд для всех промежуточных сред для всех заданий.
 Prometheus поддерживает службу DNS для обнаружения служб. У нас уже была внутренняя служба DNS.
 Нет необходимости устанавливать какие-либо внешние службы (в отличие, например, от Sensu, которому требуется служба хранения данных, такая как Redis, и шина сообщений, такая как RabbitMQ). Возможно, это не мешает, но определенно упрощает выполнение, развертывание и обслуживание теста.
 Prometheus довольно легко установить, так как вам нужно всего лишь загрузить исполняемый файл Go. Контейнер Docker также работает хорошо, и его легко запустить.
 Как пользоваться Прометеем? 
 Изначально мы использовали только некоторые метрики, предоставляемые node_exporter из коробки, в том числе:
 Использование жесткого диска.
 Использование памяти.
, если экземпляр запущен или отключен.
 Наша внутренняя служба DNS интегрирована для обнаружения служб, поэтому каждый новый экземпляр автоматически отслеживается.
 Некоторые из используемых нами метрик, которые не были предоставлены node_exporter по умолчанию, были экспортированы с помощью функции сборщика текстовых файлов node_exporter. Первые предупреждения, которые мы объявили в Prometheus Alertmanager, в основном были связаны с операционными показателями, упомянутыми выше.
 Позже мы разработали экспортер операций, который позволял нам узнавать состояние системы почти в режиме реального времени. Он выставлял бизнес-метрики, а именно статусы всех операций, количество входящих миграций, количество завершенных миграций и количество ошибок. Мы могли бы агрегировать их на стороне Prometheus и позволить ему рассчитывать разные скорости.
 Мы решили экспортировать и отслеживать следующие показатели:
  Operation_requests_total 
  Operation_statuses_total 
  Operation_errors_total 
 Большинство наших сервисов продублировано в двух зонах доступности Google Cloud Platform. В том числе и система мониторинга. Несложно иметь более одного экспортера операций в двух или более разных зонах, поскольку Prometheus может агрегировать данные из всех и сделать одну метрику (то есть максимальную из всех). В настоящее время у нас нет Prometheus или Alertmanager в HA — только экземпляр метамониторинга — но мы над этим работаем.
 Для внешнего мониторинга черного ящика мы используем Prometheus Blackbox Exporter. Помимо проверки того, работают ли наши внешние интерфейсы, это особенно полезно для получения метрик для дат истечения срока действия SSL-сертификатов. Он даже проверяет всю цепочку сертификатов. Престижность Robust Perception за то, что они прекрасно объяснили это в своем блоге.
 Мы настроили некоторые графики в Grafana для визуального мониторинга в некоторых дашбордах, и интеграция с Prometheus была тривиальной. Язык запросов, используемый для определения диаграмм, такой же, как и в Prometheus, что значительно упростило их создание.
 Мы также интегрировали Prometheus с Pagerduty и создали график дежурных людей для критических предупреждений. Для тех предупреждений, которые не считались критическими, мы только отправили электронное письмо.
 Как Прометей помогает вам? 
 Мы не можем сравнить Prometheus с нашим предыдущим решением, потому что у нас его не было, но мы можем рассказать о том, какие функции Prometheus являются для нас основными:
 Требует минимального обслуживания.
 Это эффективно: одна машина может контролировать весь кластер.
 Сообщество дружелюбное — как разработчики, так и пользователи. Более того, блог Брайана — очень хороший ресурс.
 Не имеет сторонних требований; это просто сервер и экспортеры. (Поддерживать RabbitMQ или Redis не требуется.)
 Развертывание приложений Go очень просто.
 Как вы думаете, какое будущее ждет ShuttleCloud и Prometheus? 
 Мы очень довольны Prometheus, но всегда рады новым экспортерам (например, Celery или Spark).
 Каждый раз, когда мы добавляем новый будильник, мы сталкиваемся с одним вопросом: как проверить, что будильник работает должным образом? Было бы неплохо иметь возможность вводить поддельные метрики, чтобы поднимать тревогу, чтобы протестировать ее.
 Опубликовано: 4 сентября 2016 г. Юлиусом Волцем Что произошло 
 На прошлой неделе восемьдесят пользователей и разработчиков Prometheus со всего мира пришли вместе в течение двух дней в Берлине на первой в истории конференции о Система мониторинга Prometheus: PromCon 2016. Цель эта конференция должна была обменяться знаниями, лучшими практиками и опытом получено с помощью Прометея. Мы также хотели развивать сообщество и помогать людям. строить профессиональные связи вокруг мониторинга услуг. Вот некоторые впечатлений от первого утра:
 Продолжить чтение »
 Posted at: July 23, 2016 by Julius Volz Давайте поговорим об особо живучем мифе. Всякий раз, когда есть обсуждение о системах мониторинга и сборе метрик Prometheus по запросу подход, кто-то неизбежно вмешивается о том, как подход, основанный на вытягивании просто «принципиально не масштабируется». Приведенные причины часто расплывчаты или только применимы к системам, принципиально отличным от Prometheus. Фактически, работая с мониторингом на основе запросов в самых больших масштабах, это утверждение выполняется вопреки нашему собственному опыту эксплуатации.
 У нас уже есть запись FAQ о почему Прометей предпочитает тянуть, а не толкать, но он не фокусируется конкретно на аспектах масштабирования. Давайте посмотрим поближе на обычные заблуждения вокруг этого утверждения и проанализировать, как они относится к Прометею.
 Прометей не Нагиос 
 Когда люди думают о системе мониторинга, которая активно тянет, они часто думают из Нагиоса. Nagios имеет репутацию плохо масштабируемого, отчасти из-за нереста подпроцессы для активных проверок, которые могут запускать произвольные действия в Nagios хост, чтобы определить работоспособность определенного хоста или службы. Этот вид архитектуры проверки действительно плохо масштабируется, так как центральный узел Nagios быстро перегружается. В результате люди обычно настраивают проверки только выполняться каждые пару минут, иначе возникнут более серьезные проблемы.
 Однако «Прометей» придерживается совершенно иного подхода. Вместо выполнения сценариев проверки он только собирает данные временных рядов из набор инструментированных целей по сети. Для каждой цели Прометей сервер просто получает текущее состояние всех показателей этой цели по HTTP (очень параллельно, с использованием горутин) и не имеет другого исполнения накладные расходы, связанные с вытягиванием. Это подводит нас к следующему пункту:
 Неважно, кто инициирует соединение 
 В целях масштабирования не имеет значения, кто инициирует TCP-соединение через какие показатели затем передаются. В любом случае вы делаете это, усилия для установление соединения невелико по сравнению с полезной нагрузкой метрик и другими требуемая работа.
 Но подход на основе push может использовать UDP и избежать установления соединения вообще, говоришь! Верно, но накладные расходы TCP/HTTP в Prometheus по-прежнему пренебрежимо мала по сравнению с другой работой, которую должен выполнять сервер Prometheus, чтобы принимать данные (особенно сохраняющиеся данные временных рядов на диске). положить некоторые за этим стоят цифры: один большой сервер Prometheus может легко хранить миллионы временных рядов с записью 800 000 входящих отсчетов в секунду (как измерено с помощью данных реальных производственных показателей в SoundCloud). Учитывая 10-секундный интервал очистки и 700 временных рядов на хост, что позволяет отслеживать более 10 000 машин с одного сервера Prometheus. Узкое место масштабирования здесь никогда не было связано с получением метрик, но обычно со скоростью, с которой сервер Prometheus может принимать данные в память, а затем устойчиво сохранять и удалять данные на диске/SSD.
 Кроме того, несмотря на то, что в наши дни сети довольно надежны, использование подход гарантирует, что данные метрик поступят надежно или что мониторинг система, по крайней мере, сразу узнает, когда передача метрик не удалась из-за сломанная сеть.
 Prometheus не является системой, основанной на событиях 
 Некоторые системы мониторинга основаны на событиях. То есть они сообщают о каждом отдельном событие (запрос HTTP, исключение, что угодно) в центральный мониторинг система сразу же, как это происходит. Затем эта центральная система либо агрегирует события в метрики (StatsD является ярким примером этого) или сохраняет события индивидуально для последующей обработки (примером этого является стек ELK). В такой системы вытягивание было бы действительно проблематичным: сервис с инструментами пришлось бы буферизовать события между пуллами, и пуллы должны были бы произойти невероятно часто, чтобы имитировать ту же «живость» подход на основе push и не перегружать буферы событий.
 Однако опять же, Prometheus не является системой мониторинга событий. Ты не отправлять необработанные события в Prometheus и не может их хранить. Прометей находится в бизнес по сбору агрегированных данных временных рядов. Это означает, что это только заинтересованы в регулярном сборе текущего  состояния  заданного набора метрики, а не основные события, которые привели к созданию этих метрик. Например, инструментальная служба не будет отправлять сообщение о каждом HTTP-запросе. запрос Прометею, как он обрабатывается, а просто подсчитывал бы те запросы в памяти. Это может происходить сотни тысяч раз в секунду не вызывая никакого мониторинга трафика. Прометей тогда просто спрашивает службу экземпляр каждые 15 или 30 секунд (или что вы настроите) о текущем значение счетчика и сохраняет это значение вместе с отметкой времени очистки в виде образец. Другие типы метрик, такие как датчики, гистограммы и сводки, обрабатываются аналогично. В результате трафик мониторинга низкий, а подход также не создает проблем в этом случае.
 Но теперь моему мониторингу нужно знать о моих экземплярах службы! 
 При подходе на основе извлечения ваша система мониторинга должна знать, какая служба существуют экземпляры и как к ним подключиться. Некоторые люди беспокоятся о это требует дополнительной настройки со стороны системы мониторинга и см. это как проблема операционной масштабируемости.
 Мы утверждаем, что вы не можете избежать этих усилий по настройке для серьезные настройки мониторинга в любом случае: если ваша система мониторинга не знает что за мир  должен выглядеть как  и какие отслеживаемые экземпляры службы  должен быть , как он сможет сказать, когда экземпляр просто никогда не сообщает, не работает из-за сбоя или действительно больше не должен существовать? Это приемлемо только в том случае, если вы никогда не заботитесь о здоровье отдельных экземпляров вообще, например, когда вы запускаете эфемерных рабочих только там, где они достаточно для достаточно большого числа из них, чтобы сообщить о некотором результате. Самый среды не являются исключительно такими.
 Если системе мониторинга в любом случае необходимо знать желаемое состояние мира, тогда подход, основанный на проталкивании, фактически требует в общей сложности еще  конфигурации . Нет вашей системе мониторинга нужно только знать, какие экземпляры службы должны существуют, но экземпляры службы теперь также должны знать, как связаться с вашим Система наблюдения. Вытягивающий подход не только требует меньше конфигурации, это также делает вашу настройку мониторинга более гибкой. С тягой вы можете просто бежать копию производственного мониторинга на вашем ноутбуке, чтобы поэкспериментировать с ним. Это также позволяет вам просто получать метрики с помощью какого-либо другого инструмента или проверять конечные точки метрик вручную. Чтобы получить высокую доступность, pull позволяет вам просто запустить два одинаковых настроенные серверы Prometheus параллельно. И, наконец, если вам нужно переместить конечная точка, из которой доступен ваш мониторинг, метод вытягивания не работает. требуют, чтобы вы перенастроили все свои источники метрик.
 С практической точки зрения Prometheus упрощает настройку желаемого состояния. со всего мира благодаря встроенной поддержке широкого спектра сервисов механизмы для облачных провайдеров и систем контейнерного планирования: Consul, Marathon, Kubernetes, EC2, SD на основе DNS, Azure, наборы серверов Zookeeper и многое другое. Prometheus также позволяет вам подключать свой собственный механизм, если это необходимо. В мире микросервисов или любой многоуровневой архитектуре это также фундаментальное преимущество, если ваша система мониторинга использует тот же метод для обнаруживать цели для мониторинга, поскольку ваши экземпляры службы используют для обнаружения их бэкенды. Таким образом, вы можете быть уверены, что отслеживаете одни и те же цели. которые обслуживают рабочий трафик, и у вас есть только один механизм обнаружения поддерживать.
 Случайный DDoS-атака вашего мониторинга 
 Независимо от того, вытягиваете вы или выталкиваете, любая база данных временных рядов перестанет работать, если вы отправите это больше образцов, чем он может обработать. Однако, по нашему опыту, это немного более вероятно, что подход, основанный на толчке, случайно сломает ваш мониторинг. Если контроль над тем, какие метрики поступают из каких экземпляров не централизована (в вашей системе мониторинга), то вы сталкиваетесь с опасностью экспериментальные или мошеннические задания, которые внезапно загружают много мусорных данных в ваш мониторинг производства и его снижение. Есть еще много способов, как это может произойти с подходом, основанным на вытягивании (который только контролирует, где вытягивать метрики, но не размер и характер полезной нагрузки метрик), но риск ниже. Что еще более важно, такие инциденты можно смягчить централизованно. точка.
 Доказательство реального мира 
 Помимо того, что Prometheus уже используется для мониторинга очень больших настройки в реальном мире (например, использование его для мониторинга миллионов машин в DigitalOcean), есть и другие известные примеры мониторинга на основе запросов. успешно в самых больших возможных средах. Прометей был вдохновлен Google Borgmon, который использовался (и частично до сих пор) в Google для контролировать все свои критически важные производственные службы, используя подход, основанный на вытягивании. Любой Проблемы с масштабированием, с которыми мы столкнулись при использовании Borgmon в Google, не были связаны с его притяжением. подойти либо. Если подход, основанный на вытягивании, масштабируется до глобальной среды с многие десятки датацентров и миллионы машин, вряд ли можно сказать, что тянут не масштабируется.
 Но есть и другие проблемы с pull! 
 Действительно, существуют настройки, которые трудно отслеживать с помощью подхода на основе извлечения. Ярким примером является ситуация, когда у вас есть много конечных точек, разбросанных по мира, которые недоступны напрямую из-за брандмауэров или сложных сетевые настройки и где невозможно запустить сервер Prometheus непосредственно в каждом из сегментов сети. Это не совсем среда для который был построен Prometheus, хотя часто возможны обходные пути (через Pushgateway или реструктуризация вашей установки). В любой В этом случае эти остающиеся опасения по поводу мониторинга на основе извлечения обычно не решаются. связанные с масштабированием, но из-за проблем с работой сети при открытии TCP соединения.
 Итак, все хорошо? 
 В этой статье рассматриваются наиболее распространенные проблемы масштабируемости, связанные с мониторинговый подход. С Prometheus и другими системами, основанными на вытягивании успешно в очень больших средах, а аспект вытягивания не создает узкое место в реальности, результат должен быть ясен: «вытягивание не масштабируется» аргумент не является реальной проблемой. Мы надеемся, что будущие дебаты будут сосредоточены на аспекты, которые имеют большее значение, чем этот отвлекающий маневр.
 Опубликовано: 18 июля 2016 г. Фабианом Рейнарцем от имени команды Prometheus В январе мы опубликовали запись в блоге о первом годе публичного существования Prometheus, в которой резюмировали то, что было для нас удивительным путешествием и, надеюсь, новаторским и полезным решением для мониторинга для вас. С тех пор Prometheus также присоединился к Cloud Native Computing Foundation, где мы находимся в хорошей компании, в качестве второго уставного проекта после Kubernetes.
 Наша недавняя работа была сосредоточена на предоставлении стабильного API и пользовательского интерфейса, отмеченного версией 1.0 Prometheus. Мы рады сообщить, что достигли этой цели, и Prometheus 1.0 доступен уже сегодня.
 Что для вас значит 1.0? 
 Если вы какое-то время пользовались Prometheus, то могли заметить, что скорость и влияние критических изменений значительно снизились за последний год. В том же духе достижение версии 1.0 означает, что последующие версии 1.x останутся стабильными API. Обновления не сломают программы, созданные на основе API Prometheus, а обновления не потребуют повторной инициализации хранилища или изменений в развертывании. Пользовательские информационные панели и оповещения останутся неизменными и в обновлениях версии 1.x. Мы уверены, что Prometheus 1.0 — надежное решение для мониторинга. Теперь, когда сервер Prometheus достиг стабильного состояния API, другие модули со временем последуют его собственным стабильным выпускам версии 1.0.
 Мелкий шрифт 
 Так что же означает стабильность API? Прометей имеет большую площадь поверхности, и некоторые его части определенно более зрелые, чем другие. Есть две простые категории:  стабильный  и  нестабильный :
. Стабильность, начиная с версии 1.0 и во всей серии 1.x:
 Язык запросов и модель данных
 Правила оповещения и записи
 Форматы экспозиции приема
 Имена флагов конфигурации
 HTTP API (используется информационными панелями и пользовательскими интерфейсами)
 Формат файла конфигурации (за вычетом нестабильных интеграций службы обнаружения, см. ниже)
 Интеграция оповещений с Alertmanager 0.1+ в обозримом будущем
 Синтаксис и семантика шаблона консоли
 Нестабильно и может измениться в пределах 1. x:
 Интеграция с удаленным хранилищем (InfluxDB, OpenTSDB, Graphite) все еще является экспериментальной и в какой-то момент будет удалена в пользу общего, более сложного API, позволяющего хранить образцы в произвольных системах хранения.
 Несколько интеграций обнаружения служб являются новыми и должны идти в ногу с быстро развивающимися системами. Следовательно, интеграции с Kubernetes, Marathon, Azure и EC2 остаются в статусе бета-версии и могут быть изменены. Тем не менее, изменения будут четко объявлены.
 При необходимости точное значение флага может измениться. Однако изменения никогда не приведут к тому, что сервер не запустится с предыдущими конфигурациями флагов.
 Go API пакетов, являющихся частью сервера.
 HTML, созданный веб-интерфейсом.
 Метрики в конечной точке  /metrics  самого Prometheus.
 Точный формат на диске. Однако потенциальные изменения будут совместимы и прозрачно обработаны Prometheus.
 Итак, Прометей готов? 
 Абсолютно нет. У нас впереди длинная дорожная карта, полная замечательных функций для реализации. Prometheus не останется в 1.x на долгие годы. Инфраструктурное пространство быстро развивается, и мы полностью намерены, чтобы Prometheus развивался вместе с ним. Это означает, что мы по-прежнему будем готовы подвергнуть сомнению то, что мы делали в прошлом, и готовы оставить позади то, что потеряло актуальность. Будут новые основные версии Prometheus, чтобы облегчить планы на будущее, такие как постоянное долгосрочное хранилище, более новые итерации Alertmanager, улучшения внутреннего хранилища и многие другие вещи, о которых мы даже не знаем.
 Заключительные мысли 
 Мы хотим поблагодарить наше фантастическое сообщество за полевые испытания новых версий, отправку отчетов об ошибках, добавление кода, помощь другим членам сообщества и формирование Prometheus, участвуя в бесчисленных продуктивных дискуссиях. В конце концов, именно вы делаете Прометея успешным.
 Спасибо, и продолжайте в том же духе!
 Опубликовано: 9 мая 2016 г. Юлиусом Волцем от имени основных разработчиков Prometheus С момента создания Prometheus мы искали устойчивую модель управления проектом, независимая от какой-либо отдельной компании. Недавно мы вели переговоры с недавно созданным Cloud Native. Computing Foundation (CNCF) при поддержке Google. CoreOS, Docker, Weaveworks, Mesosphere и другие передовые инфраструктуры компании.
 Сегодня мы рады сообщить, что Комитет технического надзора CNCF единогласно проголосовали за принять Prometheus в качестве второго размещенного проекта после Kubernetes! Ты можешь найти больше информации об этих планах в официальный пресс-релиз CNCF.
 Присоединившись к CNCF, мы надеемся создать четкий и устойчивый проект модели управления, а также извлекать выгоду из ресурсов, инфраструктуры и рекомендации, которые независимый фонд предоставляет своим членам.
 Мы считаем, что CNCF и Prometheus идеально подходят друг другу по тематике, так как оба сосредоточиться на создании современного видения облака.
 В следующие месяцы мы будем работать с CNCF над завершением структура управления проектом. Мы сообщим, когда будут подробности анонсировать.
 Опубликовано: 8 мая 2016 г. Автор: Бьорн «Беорн» Рабенштейн Встроенная база данных временных рядов (TSDB) сервера Prometheus организует необработанные выборочные данные каждого временного ряда в кусках постоянного размера 1024 байта. В Помимо необработанных выборочных данных, чанк содержит некоторые метаданные, что позволяет выбор различной кодировки для каждого чанка. Самый фундаментальный различие заключается в версии кодировки. Вы выбираете версию для вновь созданных чанки через флаг командной строки  -storage.local.chunk-encoding-version  . Вплоть до теперь было только две поддерживаемые версии: 0 для оригинальной дельта-кодировки, и 1 для улучшенного двойного дельта-кодирования. С выпуском 0.18.0, мы добавлена версия 2, которая представляет собой еще одну разновидность двойного дельта-кодирования. Мы называем это  varbit, кодирующий , потому что он включает в себя переменную битовую ширину на выборку в пределах кусок. Хотя версия 1 превосходит версию 0 почти во всех аспектах, существует реальный компромисс между версиями 1 и 2. Этот пост в блоге поможет вам чтобы принять это решение. Версия 1 остается кодировкой по умолчанию, поэтому, если вы хотите чтобы попробовать версию 2 после прочтения этой статьи, вы должны выбрать ее явно через флаг командной строки. Нет ничего плохого в переключении назад и далее, но обратите внимание, что существующие фрагменты не изменят свою версию кодировки. как только они были созданы. Тем не менее, эти куски будут постепенно сокращаться. в соответствии с настроенным временем хранения и, таким образом, будут заменены кусками с кодировкой, указанной в флаге командной строки.
 Продолжить чтение »
 Опубликовано: 1 мая 2016 г. Автор: Brian Brazil  Это второе из серии интервью с пользователями Prometheus, позволяющее поделиться своим опытом оценки и использования Prometheus. 
 Расскажите о себе и о том, чем занимается ShowMax? 
 Меня зовут Антонин Крал, и я руковожу исследованиями и архитектурой для ПоказатьМакс. До этого я проходил архитектурный и технический ролей за последние 12 лет.
 ShowMax — это сервис видео по запросу, запущенный в Южной Африке по подписке. в 2015 году. У нас есть обширный каталог контента с более чем 20 000 эпизоды телепередач и фильмов. Наш сервис в настоящее время доступен в 65 странах мира. Пока более известные соперники перестреливаются в Америке и Европа, ShowMax борется с более сложной проблемой: как вы смотрите запоем в едва связанной деревне в Африке к югу от Сахары? Уже 35% видео транслируется по всему миру, но еще так много мест, где революция остался нетронутым.
 Мы управляем примерно 50 службами, работающими в основном на частных кластерах, построенных вокруг CoreOS. Они в основном обрабатывают запросы API от наших клиентов. (Android, iOS, AppleTV, JavaScript, Samsung TV, LG TV и т. д.), а некоторые из них используются внутрь. Один из самых больших внутренних конвейеров — кодирование видео. который может занимать более 400 физических серверов при обработке больших пакетов загрузки.
 Большинство наших внутренних сервисов написаны на Ruby, Go или Python. Мы используем EventMachine при написании приложений на Ruby (Goliath на MRI, Puma на JRuby). Перейти это обычно используется в приложениях, которые требуют большой пропускной способности и не имеют так много бизнес-логика. Мы очень довольны Falcon для сервисов, написанных на Python. Данные хранятся в кластерах PostgreSQL и ElasticSearch. Мы используем etcd и custom инструментарий для настройки Varnish для маршрутизации запросов.
 Продолжить чтение »
 Опубликовано: 23 марта 2016 г. Автор: Brian Brazil  Это первое интервью из серии интервью с пользователями Prometheus, позволяющее поделиться своим опытом оценки и использования Prometheus. Наш первый интервью с Дэниелом из Life360. 
 Расскажите о себе и о том, чем занимается Life360? 
 Меня зовут Даниэль Бен Йосеф, также известный как dby, и я инженер по инфраструктуре для Life360, а до этого я держал системы инженерные должности за последние 9годы.
 Life360 создает технологию, которая помогает семьям оставаться на связи, мы семья Сетевое приложение для семей. Мы очень заняты работой с этими семьями - на пике мы обслуживаем 700 тысяч запросов в минуту для 70 миллионов зарегистрированных семей.
 Мы управляем примерно 20 службами в производстве, в основном обрабатывая запросы о местоположении. из мобильных клиентов (Android, iOS и Windows Phone), охватывающих более 150 экземпляры на пике. Избыточность и высокая доступность — наши цели, и мы стремимся поддерживать 100% время безотказной работы, когда это возможно, потому что семьи доверяют нам доступный.
 Мы храним пользовательские данные как в нашем кластере с несколькими мастерами MySQL, так и в нашем 12-узловом кластере. Кольцо Cassandra, которое в любой момент времени содержит около 4 ТБ данных. У нас есть сервисы, написанные на Go, Python, PHP, а также планы по внедрению Java в нашу куча. Мы используем Consul для обнаружения сервисов и, конечно же, нашу настройку Prometheus. интегрируется с ним.
 Продолжить чтение »
 Опубликовано: 3 марта 2016 г., Фабиан Рейнарц Alertmanager обрабатывает оповещения, отправленные серверами Prometheus, и отправляет уведомления о них разным получателям на основе их меток.
 Получатель может быть одной из многих различных интеграций, таких как PagerDuty, Slack, электронная почта или пользовательская интеграция через общий интерфейс веб-перехватчика (например, JIRA).
 Шаблоны 
 Сообщения, отправляемые получателям, строятся по шаблонам. Alertmanager поставляется с шаблонами по умолчанию, но также позволяет определять пользовательские те.
 В этом сообщении блога мы рассмотрим простую настройку Slack. уведомления.
 Мы используем эту простую конфигурацию Alertmanager, которая отправляет все оповещения в Slack:
 глобальный:
  slack_api_url: ''
маршрут:
  получатель: 'slack-уведомления'
  # Все оповещения в уведомлении имеют одинаковое значение для этих меток. 
  group_by: [название оповещения, центр обработки данных, приложение]
приемники:
- название: 'slack-уведомления'
  slack_configs:
  - канал: '#оповещения'
 
 По умолчанию сообщение Slack, отправляемое Alertmanager, выглядит так:
 Это показывает нам, что есть одно оповещение о срабатывании, за которым следуют значения метки группировка оповещений (имя оповещения, центр обработки данных, приложение) и дополнительные значения меток оповещения имеют общее (критическое).
 Продолжить чтение »
 Опубликовано: 26 января 2016 г. Юлиусом Волцем Начало 
 Сегодня ровно год назад мы официально представили Prometheus всему миру. Этот это прекрасная возможность для нас оглянуться назад и поделиться некоторыми замечательными вещи, которые произошли с проектом с тех пор. Но сначала начнем с начало.
 Хотя мы уже запустили Prometheus как проект с открытым исходным кодом на GitHub в 2012, мы сначала не шумели по этому поводу. Мы хотели дать проекту пора созреть и иметь возможность экспериментировать без трения. Прометей был постепенно вводится для производственного контроля на SoundCloud в 2013 году, а затем видел все больше и больше использование внутри компании, а также некоторое раннее принятие нашими друзьями в Docker и Boxever в 2014 году. С годами Prometheus рос все больше и больше. более зрелой и хотя уже решала проблемы наблюдения за людьми, он был еще неизвестен широкой публике.
 Продолжить чтение »
 Опубликовано: 17 августа 2015 г. Автор: Fabian Reinartz В предыдущем посте мы представил множество новых способов обнаружения сервисов в Prometheus. С тех пор многое произошло. Мы улучшили внутреннюю реализацию и получил фантастический вклад от нашего сообщества, добавив поддержку для обнаружение сервисов с помощью Kubernetes и Marathon. Они станут доступны с выходом версии 0.16.
 Мы также затронули тему обнаружения пользовательских сервисов.
 Не каждый тип обнаружения служб является достаточно общим, чтобы его можно было включить напрямую в Прометее. Скорее всего, ваша организация имеет собственный система на месте, и вам просто нужно заставить ее работать с Prometheus. Это не означает, что вы не можете пользоваться преимуществами автоматического обнаружение новых объектов мониторинга.
 В этом посте мы реализуем небольшую утилиту, которая подключает кастомный подход к обнаружению сервисов, основанный на etcd, высококонсистентное распределенное хранилище ключей и значений для Prometheus.
 Продолжить чтение »
 Размещено: 24 июня 2015 г. Кристианом Свенссоном (команда DreamHack Network)  Примечание редактора: эта статья является гостевым постом, написанным пользователем Prometheus. 
  Если вы управляете сетью для 10 000 требовательных игроков, вам необходимо действительно знать, что происходит внутри вашей сети. О, и все должно быть построен с нуля всего за пять дней. 
 Если вы никогда раньше не слышали о DreamHack, вот суть: собрать вместе 20 000 человек и заставить большинство из них принести их собственный компьютер. Смешайте профессиональные игры (киберспорт), соревнования по программированию, и концерты живой музыки. Результатом стал крупнейший в мире фестиваль, посвященный исключительно ко всему цифровому.
 Чтобы такое мероприятие стало возможным, в городе должна быть развита инфраструктура. место. Обычная инфраструктура такого размера строится месяцами, но команда в DreamHack строит все с нуля всего за пять дней. Это конечно включает в себя такие вещи, как настройка сетевых коммутаторов, а также создание распределение электроэнергии, создание магазинов для еды и напитков и даже построение реальных таблиц.
 Команда, которая строит и управляет всем, что связано с сетью, официально называется командой Network, но мы обычно называем себя  тех.  или  dhtech . Этот пост будет посвящен работе dhtech и тому, как мы использовали Prometheus во время DreamHack Summer 2015, чтобы попытаться поднять наш мониторинг еще на один уровень. выемка.
 Продолжить чтение »
 Опубликовано: 18 июня 2015 г. Брайаном Бразилом Джон Оллспоу утверждает, что попытка «точно обнаружить аномалии в нужное время невозможна».
 Я видел несколько попыток талантливых инженеров построить системы, автоматически обнаруживать и диагностировать проблемы на основе данных временных рядов. Пока это конечно, можно заставить работать демонстрацию, данные всегда быть слишком шумным, чтобы заставить этот подход работать для чего-либо, кроме самого простого из системы реального мира.
 Однако надежда еще не потеряна. Есть много общих аномалий, которые вы можете обнаруживать и обрабатывать с помощью настраиваемых правил. Запрос Прометея язык дает вам инструменты для открытия эти аномалии, избегая ложных срабатываний.
 Продолжить чтение »
 Опубликовано: 1 июня 2015 г. Авторами: Fabian Reinartz, Julius Volz На этой неделе мы выпустили Prometheus v0.14.0 — версию со множеством долгожданных дополнений. и улучшения.
 На стороне пользователя Prometheus теперь поддерживает новые механизмы обнаружения служб. В в дополнение к записям DNS-SRV теперь поддерживает Consul из коробки, а файловый интерфейс позволяет подключать собственные механизмы обнаружения. Со временем мы планируем добавить другие распространенные службы обнаружения. механизмы Прометея.
 Помимо множества мелких исправлений и улучшений, теперь вы также можете перезагружать конфигурацию во время время выполнения, отправив  SIGHUP  процессу Prometheus. Полный список изменений см. список изменений для этого релиза.
 В этом сообщении блога мы более подробно рассмотрим встроенные механизмы обнаружения служб и предоставим несколько практических примеров. В качестве дополнительного ресурса см. Документация по настройке Prometheus.
 Продолжить чтение »
 Опубликовано: 24 апреля 2015 г. Брайан Бразил Прошло почти три месяца с тех пор, как мы публично анонсировали версию Prometheus 0.10.0, и сейчас у нас версия 0.13.1.
 Объявление в блоге SoundCloud остается лучшим обзором ключевых компонентов Prometheus, но было много другой онлайн-активности вокруг Prometheus. Этот пост позволит вам догнать все, что вы пропустили.
 В будущем мы будем использовать этот блог для публикации большего количества статей и объявлений. чтобы помочь вам получить максимальную отдачу от Prometheus.
 Продолжить чтение »
 Ubuntu Manpage: prometheus-node-exporter — экспортер Prometheus для машинных метрик 
 Предоставлено: prometheus-node-exporter_1.3.1-1_amd64
 
 ИМЯ        prometheus-node-exporter — экспортер Prometheus для машинных метрик
 
 ОБЗОР          prometheus-node-exporter   [] 
 
 ОПИСАНИЕ  
 ОПЦИИ          -ч,   --помощь 
              Показать контекстно-зависимую справку (попробуйте также --help-long и --help-man).
         --collector.bcache.priorityStats 
              Выставлять дорогие приоритетные статы.
         --collector. cpu.guest 
              Включает метрику node_cpu_guest_seconds_total
         --collector.cpu.info 
              Включает метрику cpu_info
         --collector.cpu.info.flags-include=COLLECTOR.CPU.INFO.FLAGS-INCLUDE 
              Отфильтруйте поле `flags` в cpuInfo со значением, которое должно быть регулярным выражением.
         --collector.cpu.info.bugs-include=COLLECTOR.CPU.INFO.BUGS-INCLUDE 
              Отфильтруйте поле «ошибки» в cpuInfo со значением, которое должно быть регулярным выражением.
         --collector.diskstats.ignored-devices 
              Регулярное выражение устройств, которые нужно игнорировать для diskstats.
         --collector.ethtool.device-include=COLLECTOR.ETHTOOL.DEVICE-INCLUDE 
              Регулярное выражение устройств ethtool для включения (взаимоисключающее для исключения устройств).
         --collector.ethtool.device-exclude=COLLECTOR.ETHTOOL.DEVICE-EXCLUDE 
              Регулярное выражение устройств ethtool для исключения (взаимоисключающее для включения устройств). 
         --collector.ethtool.metrics-include 
              Регулярное выражение статистики ethtool для включения.
         --collector.filesystem.mount-points-exclude 
              Регулярное выражение точек монтирования для исключения для сборщика файловой системы.
         --collector.filesystem.fs-types-exclude 
              Регулярное выражение типов файловых систем, которые необходимо исключить для сборщика файловых систем.
         --collector.ipvs.backend-метки 
              Разделенный запятыми список меток статистики IPVS.
         --collector.netclass.ignored-устройства 
              Регулярное выражение сетевых устройств для игнорирования сборщиком сетевых классов.
         --collector.netclass.ignore-invalid-скорость 
              Игнорировать устройства, где скорость недействительна. Это будет поведение по умолчанию в
              2.х.
         --collector.netdev.device-include=COLLECTOR.NETDEV.DEVICE-INCLUDE 
              Регулярное выражение сетевых устройств для включения (взаимоисключающее для исключения устройств). 
         --collector.netdev.device-exclude 
              Регулярное выражение сетевых устройств для исключения (взаимоисключающее для включения устройств).
         --collector.netdev.address-info 
              Собирайте адресную информацию для каждого устройства
         --collector.netstat.fields 
              Регулярное выражение полей, возвращаемых для сборщика netstat.
         --collector.ntp.сервер 
              NTP-сервер для использования для сборщика ntp
         --collector.ntp.protocol-version=4 
              Версия протокола NTP
         --collector.ntp.server-is-local 
              Подтвердите, что адрес collect.ntp.server не является общедоступным ntp-сервером.
         --collector.ntp.ip-ttl=1 
              IP TTL для использования при отправке запроса NTP
         --collector.ntp.max-distance=3,46608 с 
              Максимальное накопленное расстояние до корня
         --collector.ntp.local-offset-tolerance=1 мс 
              Смещение между локальными часами и локальным временем ntpd, чтобы допустить
         --path. procfs 
              точка монтирования procfs.
         --path.sysfs 
              точка монтирования sysfs.
         --path.rootfs 
              точка монтирования rootfs.
         --collector.perf.cpus 
              Список ЦП, с которых следует собирать показатели производительности
         --collector.perf.tracepoint=COLLECTOR.PERF.TRACEPOINT 
              perf tracepoint, который должен быть собран
         --collector.powersupply.ignored-поставки 
              Регулярное выражение блоков питания, которое следует игнорировать для коллектора класса питания.
         --collector.qdisc.fixtures 
              тестовые приспособления для сквозного тестирования коллектора qdisc
         --collector.runit.servicedir 
              Путь к каталогу службы runit.
         --collector.supervisord.url 
              Конечная точка XML RPC.
         --collector.systemd.unit-include 
              Регулярное выражение единиц systemd для включения.  Единицы должны как совпадать, так и не совпадать
              исключить, чтобы быть включенным.
         --collector.systemd.unit-exclude 
              Регулярное выражение единиц systemd для исключения. Единицы должны как совпадать, так и не совпадать
              исключить, чтобы быть включенным.
         --collector.systemd.enable-task-metrics 
              Включает метрики задач единицы обслуживания unit_tasks_current и unit_tasks_max
         --collector.systemd.enable-restarts-метрики 
              Включает метрику единицы обслуживания service_restart_total
         --collector.systemd.enable-start-time-metrics 
              Включает метрику единицы обслуживания unit_start_time_seconds
         --collector.tapestats.ignored-devices 
              Регулярное выражение устройств, которые следует игнорировать для TapStats.
         --collector.textfile.directory 
              Каталог для чтения текстовых файлов с метриками.
         --collector. vmstat.fields 
              Регулярное выражение полей, возвращаемых сборщиком vmstat.
         --collector.wifi.fixtures 
              тестовые приборы для использования в метриках сборщика Wi-Fi
         --collector.arp 
              Включите сборщик arp (по умолчанию: включен).
         --collector.bcache 
              Включите сборщик bcache (по умолчанию: включен).
         --связывание коллектора 
              Включите сборщик соединений (по умолчанию: включено).
         --collector.btrfs 
              Включите сборщик btrfs (по умолчанию: включен).
         --collector.buddyinfo 
              Включите сборщик buddyinfo (по умолчанию: отключен).
         --collector.conntrack 
              Включите сборщик conntrack (по умолчанию: включен).
         --collector.процессор 
              Включите сборщик процессоров (по умолчанию: включено).
         --collector.cpufreq 
              Включите сборщик cpufreq (по умолчанию: включен). 
         --collector.diskstats 
              Включите сборщик diskstats (по умолчанию: включен).
         --collector.dmi 
              Включите сборщик dmi (по умолчанию: включен).
         --collector.drbd 
              Включите сборщик drbd (по умолчанию: отключено).
         --collector.drm 
              Включите сборщик drm (по умолчанию: отключен).
         --collector.edac 
              Включите сборщик edac (по умолчанию: включен).
         --collector.энтропия 
              Включите сборщик энтропии (по умолчанию: включен).
         --collector.ethtool 
              Включите сборщик ethtool (по умолчанию: отключено).
         --collector.fiberchannel 
              Включите коллектор fiberchannel (по умолчанию: включено).
         --collector.filefd 
              Включите сборщик файлов filefd (по умолчанию: включен).
         --collector.файловая система 
              Включите сборщик файловой системы (по умолчанию: включен). 
         --collector.hwmon 
              Включите сборщик hwmon (по умолчанию: включен).
         --collector.infiniband 
              Включите коллектор infiniband (по умолчанию: включено).
         --collector.interrupts 
              Включите сборщик прерываний (по умолчанию: отключен).
         --collector.ipvs 
              Включите сборщик ipvs (по умолчанию: включен).
         --collector.ksmd 
              Включите сборщик ksmd (по умолчанию: отключен).
         --collector.lnstat 
              Включите сборщик lnstat (по умолчанию: отключен).
         --collector.loadavg 
              Включите сборщик loadavg (по умолчанию: включен).
         --collector.логин 
              Включите сборщик логинов (по умолчанию: отключен).
         --collector.mdadm 
              Включите сборщик mdadm (по умолчанию: включен).
         --collector.meminfo 
              Включите сборщик meminfo (по умолчанию: включен). 
         --collector.meminfo_numa 
              Включите сборщик meminfo_numa (по умолчанию: отключен).
         --collector.mountstats 
              Включите сборщик mountstats (по умолчанию: отключен).
         --collector.netclass 
              Включите сборщик сетевых классов (по умолчанию: включен).
         --collector.netdev 
              Включите сборщик netdev (по умолчанию: включен).
         --collector.netstat 
              Включите сборщик netstat (по умолчанию: включен).
         --collector.network_route 
              Включите сборщик network_route (по умолчанию: отключен).
         --collector.nfs 
              Включите сборщик nfs (по умолчанию: включен).
         --collector.nfsd 
              Включите сборщик nfsd (по умолчанию: включен).
         --collector.ntp 
              Включите сборщик ntp (по умолчанию: отключен).
         --collector.nvme 
              Включите сборщик nvme (по умолчанию: включен). 
         --collector.os 
              Включите сборщик ОС (по умолчанию: включен).
         --collector.perf 
              Включите сборщик производительности (по умолчанию: отключено).
         --collector.powersupplyclass 
              Включите сборщик класса электропитания (по умолчанию: включен).
         --давление в коллекторе 
              Включите коллектор давления (по умолчанию: включен).
         --collector.процессы 
              Включить сборщик процессов (по умолчанию: отключен).
         --collector.qdisc 
              Включите сборщик qdisc (по умолчанию: отключен).
         --collector.rapl 
              Включите сборщик rapl (по умолчанию: включено).
         --collector.runit 
              Включите сборщик runit (по умолчанию: отключен).
         --collector.schedstat 
              Включите сборщик schedstat (по умолчанию: включен).
         --collector.sockstat 
              Включите сборщик sockstat (по умолчанию: включено). 
         --collector.softnet 
              Включите сборщик софтнета (по умолчанию: включен).
         --collector.stat 
              Включить сборщик статистики (по умолчанию: включен).
         --collector.supervisord 
              Включите супервизор коллектора (по умолчанию: отключено).
         --collector.systemd 
              Включите сборщик systemd (по умолчанию: включен).
         --collector.tapestats 
              Включите сборщик TapStats (по умолчанию: включен).
         --collector.tcpstat 
              Включите сборщик tcpstat (по умолчанию: отключен).
         --collector.текстовый файл 
              Включите сборщик текстовых файлов (по умолчанию: включено).
         --collector.thermal_zone 
              Включите коллектор Thermal_zone (по умолчанию: включено).
         --collector.time 
              Включите сборщик времени (по умолчанию: включено).
         --collector.timex 
              Включите коллектор timex (по умолчанию: включено). 
         --collector.udp_queues 
              Включите сборщик udp_queues (по умолчанию: включен).
         --collector.uname 
              Включите сборщик uname (по умолчанию: включен).
         --collector.vmstat 
              Включите сборщик vmstat (по умолчанию: включен).
         --collector.wifi 
              Включите сборщик Wi-Fi (по умолчанию: отключено).
         --collector.xfs 
              Включите сборщик xfs (по умолчанию: включен).
         --collector.zfs 
              Включите сборщик zfs (по умолчанию: включен).
         --collector.zoneinfo 
              Включите сборщик zoneinfo (по умолчанию: отключено).
         --web.listen-адрес 
              Адрес, по которому выставлять метрики и веб-интерфейс.
         --web.telemetry-путь 
              Путь, по которому выставлять метрики.
         --web.disable-exporter-metrics 
              Исключите метрики о самом экспортере (promhttp_*, process_*, go_*). 
         --web.max-requests=40 
              Максимальное количество параллельных запросов очистки. Используйте 0 для отключения.
         --collector.disable-по умолчанию 
              По умолчанию отключите все коллекторы.
         --web.config 
              [ЭКСПЕРИМЕНТАЛЬНЫЙ] Путь к файлу конфигурации yaml, который может включить TLS или аутентификацию.
         --log.level=информация 
              Записывать в журнал только сообщения с заданной серьезностью или выше. Один из: [отладка, информация, предупреждение,
              ошибка]
         --log.format=logfmt 
              Формат вывода сообщений журнала. Один из: [logfmt, json]
         --версия 
              Показать версию приложения.
 
 Представляем Grafana Cloud Agent, агент Prometheus, ориентированный на удаленную запись, который может сэкономить 40% памяти при использовании 
 После пяти лет руководства разработкой Cortex Grafana Labs больше не участвует в этом проекте. В марте 2022 года мы запустили Grafana Mimir, долгосрочное хранилище с открытым исходным кодом для Prometheus, которое позволяет масштабировать данные до 1 миллиарда метрик и выше. Чтобы узнать больше, прочитайте блог объявлений TSDB и посетите страницу Grafana Mimir.
 30 марта 2022 г.
 Сегодня мы анонсируем Grafana Cloud Agent (примечание редактора: теперь называется Grafana Agent), подмножество Prometheus, созданное для размещенных метрик, которое работает с минимальным объемом памяти и использует тот же проверенный в боевых условиях код. что сделало Прометея таким удивительным.
 В Grafana Labs мы любим Prometheus. Мы развертываем его для нашего внутреннего мониторинга, используем его вместе с Alertmanager и настраиваем его для отправки своих данных в Cortex через  remote_write . К сожалению, по мере того, как мы масштабируемся, чтобы обрабатывать более 4 миллионов активных серий в одном Prometheus, нашим развертыванием становится все труднее управлять. Хотя в большинстве организаций не так много серий, нам все чаще приходится вертикально масштабировать узел, на котором работает Prometheus, чтобы справиться с растущим использованием памяти.
 Его большие требования к памяти приводят к тому, что он является единственной опасной точкой отказа. Если у него заканчивается память, мы больше не контролируем нашу инфраструктуру. Обычное решение состоит в том, чтобы начать сегментировать ваши экземпляры Prometheus, но мы предпочитаем работать с одним экземпляром Prometheus на кластер, и правильное добавление сегментирования может быть нетривиальной задачей. В общем, нам нужно очень внимательно следить за Prometheus, чтобы наша система мониторинга работала.
 Это обычная проблема для организаций, использующих Prometheus в таком же крупном масштабе, и она кажется еще более обременительной при использовании размещенного решения для метрик, такого как Cortex. Пользователям Cortex не нужно локальное хранилище и запросы; данные уже отправляются в Cortex через  remote_write  и API запросов, совместимый с Prometheus. Кроме того, если бы было проще разделить нашу конфигурацию Prometheus на весь кластер, у нас не было бы тех же проблем с масштабированием, о которых говорилось ранее. Поэтому мы создали облачный агент Grafana, созданный для упрощения запуска инфраструктуры в стиле Prometheus при использовании размещенного решения для метрик.
 Что это? 
 Как следует из названия этого сообщения, облачный агент Grafana является подмножеством Prometheus без каких-либо запросов или локального хранилища, с использованием того же обнаружения службы, перемаркировки, WAL и  remote_write  Код найден в Prometheus. Благодаря сокращению до частей, необходимых только для взаимодействия с Cortex, тесты нашего первого выпуска показали снижение использования памяти до 40% по сравнению с эквивалентным процессом Prometheus.
 Агент может быть развернут с или без того, что мы называем  фильтрацией хоста  . Фильтрация узлов, если она включена, игнорирует любые обнаруженные цели, обнаруженные на машине, отличной от той, на которой работает агент. Это особенно полезно при развертывании агента в Kubernetes в качестве DaemonSet: каждый агент будет очищать и отправлять метрики только из модулей, которые работают на том же узле, что и агент. Это позволяет распределять использование памяти по кластеру, а не по одному узлу, хотя это также означает, что если на самом узле начнутся проблемы, метрики, показывающие эти проблемы, не будут доставлены на 9 серверов.0055 remote_write  и система оповещения.
 Независимо от того, включена ли фильтрация узлов, миграция на облачный агент Grafana проходит относительно безболезненно, требуется лишь небольшая работа по миграции. Мы написали краткое руководство, чтобы объяснить, как настроить Агент из существующей конфигурации Prometheus.
 Могу ли я использовать его без Grafana Cloud? 
 Несмотря на схожесть названия с Grafana Cloud, нашей размещенной платформой для метрик и журналов, вы можете использовать облачный агент Grafana с любой платформой, поддерживающей Prometheus 9. 0055 remote_write  API. В будущем мы планируем объединить дополнительные функции, которые позволят агенту беспрепятственно работать с Grafana Cloud, но его всегда можно будет использовать с любым сервисом, совместимым с  remote_write .
 Еще один агент ? Прежде чем мы решились выпустить еще одного агента в мир, мы тщательно изучили то, что было доступно сегодня. Хотя для сбора метрик Prometheus можно использовать и другие агенты сбора данных, у них, как правило, та же проблема. Эти агенты не  чувствует себя  как Prometheus, отсутствуют функции, на которые мы полагаемся, такие как обнаружение сервисов или правила перемаркировки. В конце концов, альтернативные решения казались мастером на все руки, а не мастером ни в чем.
 Мы используем другой подход. Сосредоточившись непосредственно на Прометее, мы можем заставить его чувствовать себя первоклассным гражданином. Мы хотим, чтобы пользователи делали меньше компромиссов с нашим агентом по сравнению с другими, чтобы уменьшить трения при переходе на агент. Короче говоря, в то время как другие агенты поддерживают парсинг метрик в стиле Prometheus, наш агент  напоминает  Прометея, потому что это , основанный на  Прометее.
 Компромиссы 
 Оптимизируя облачный агент Grafana для снижения требований к ресурсам, нам пришлось пойти на некоторые компромиссы и удалить некоторые стандартные возможности Prometheus. Самое главное, Агент не поддерживает правила записи или оповещения. На первый взгляд это кажется полностью противоречащим основному назначению Прометея (разумеется, предупреждать). Однако теперь мы поддерживаем правила записи и оповещения в Cortex и Grafana Cloud. Это помогает сбалансировать решение об удалении поддержки из агента, хотя это также ограничивает надежность ваших предупреждений надежностью размещенного решения.
 Дорожная карта 
 Мы планируем расширить облачный агент Grafana для сбора всех типов данных, поддерживаемых Grafana Cloud. Поддержка как Graphite, так и Loki в конечном итоге будет включена в Agent.
 Одновременно мы планируем другой режим развертывания для агента, который мы назвали  режимом службы парсинга  , в котором кластер агентов будет взаимодействовать и балансировать нагрузку парсинга между другими агентами в кластере. Это поможет решить некоторые из компромиссов, упомянутых ранее в этом сообщении в блоге, например, восстановить возможность захвата метрик с проблемных узлов при сегментировании агента. Следите за дополнительной информацией об этом в будущем.
 Попробуйте! 
 Образы Docker и статические двоичные файлы доступны на странице выпусков GitHub. Мы были довольны преимуществами, которые дал нам агент, и мы рады, что другие тоже попробуют его. Поделитесь с нами вашими мыслями!
 Узнайте больше о Cortex 
 Если вы хотите узнать больше о Cortex, зарегистрируйтесь на наш вебинар, запланированный на 31 марта в 9:30 по тихоокеанскому времени. Будет предварительный просмотр новых функций в предстоящем выпуске Cortex 1.0, демонстрация и вопросы и ответы с сопровождающими Cortex Томом Уилки и Гутамом Вирамачанени.
 Зарегистрируйтесь на вебинар Cortex
 1. Что такое Prometheus? - Prometheus: Up & Running [Книга] 
 Prometheus — это система мониторинга с открытым исходным кодом, основанная на метриках. Конечно, Прометей далеко не единственный из них, так что же делает его заметный?
 Прометей делает одну вещь, и делает это хорошо. Он имеет простой, но мощный модель данных и язык запросов, которые позволяют анализировать, как ваши приложения и инфраструктура работают. Он не пытается решать проблемы за пределами пространство метрик, оставив их другим более подходящим инструментам.
 С самого начала, когда в SoundCloud в 2012 году вокруг Prometheus выросло сообщество и экосистема. Prometheus в основном написан на Go и распространяется под лицензией Apache 2.0. лицензия. Есть сотни людей, которые внесли свой вклад в проект сама по себе, которая не контролируется какой-либо одной компанией. Всегда трудно сказать сколько пользователей имеет проект с открытым исходным кодом, но, по моим оценкам, по состоянию на 2018 год десятки тысяч организаций используют Prometheus в производстве. В 2016 проект Прометей стал вторым участником ¹ Фонда облачных вычислений (CNCF).
 Для инструментирования собственного кода во всех популярных языки и среды выполнения, включая Go, Java/JVM, C#/.Net, Python, Ruby, Node.js, Haskell, Erlang и Rust. Такие программы, как Kubernetes и Docker, уже оснащен клиентскими библиотеками Prometheus. Для стороннего программного обеспечения, которое предоставляет метрики в формате, отличном от Prometheus, существуют сотни доступные интеграции. Они называются экспортерами и включают HAProxy, MySQL, PostgreSQL, Redis, JMX, SNMP, Consul и Kafka. Мой друг даже добавил поддержка мониторинга серверов Minecraft, так как он очень заботится о своих кадрах в секунду.
 Простой текстовый формат упрощает предоставление метрик Prometheus. Другой системы мониторинга, как с открытым исходным кодом, так и коммерческие, добавили поддержку этот формат. Это позволяет всем этим системам мониторинга больше сосредоточиться на основных функции, а не каждый должен тратить время на дублирование усилий для поддержки каждое отдельное программное обеспечение, которое такой пользователь, как вы, может захотеть контролировать.
 Модель данных идентифицирует каждый временной ряд не только по имени, но и по неупорядоченный набор пар ключ-значение, называемый метками. Язык запросов PromQL позволяет проводить агрегацию по любому из этих ярлыков, поэтому вы можете анализировать не только по процесса, но также и для каждого центра обработки данных и для каждой службы или любых других меток, которые вы определили. Их можно графически отображать в системах информационных панелей, таких как Grafana.
 Оповещения могут быть определены с использованием того же языка запросов PromQL, что и вы. для построения графиков. Если вы можете изобразить это на графике, вы можете предупредить об этом. Этикетки делают обслуживание оповещения проще, так как вы можете создать одно оповещение, охватывающее все возможные метки ценности. В некоторых других системах мониторинга вам пришлось бы индивидуально создавать предупреждение для каждой машины/приложения. Соответственно, обнаружение услуг может автоматически определять, какие приложения и машины следует очищать источники, такие как Kubernetes, Consul, Amazon Elastic Compute Cloud (EC2), Azure, Google Compute Engine (GCE) и OpenStack.
 При всех этих функциях и преимуществах Prometheus эффективен и прост в использовании. бегать. Один сервер Prometheus может обрабатывать миллионы выборок в секунду. Это представляет собой один статически связанный двоичный файл с файлом конфигурации. Все компоненты Prometheus можно запускать в контейнерах, и они не делают ничего необычного, что будет мешать инструментам управления конфигурацией. Он разработан, чтобы быть интегрированы в уже имеющуюся у вас инфраструктуру и построены поверх нее, а не быть платформой управления.
 Теперь, когда у вас есть представление о том, что такое Прометей, давайте вернитесь на минуту назад и посмотрите, что подразумевается под «мониторингом», чтобы предоставить некоторый контекст. После этого я рассмотрю, какие основные компоненты Прометей есть и то, чем Прометей не является.
 В средней школе один из моих учителей сказал нам, что если вы спросите десять экономистов, что такое экономика, вы получите одиннадцать ответов. Мониторинг имеет аналогичное отсутствие консенсуса относительно того, что именно это означает. Когда я рассказываю другим, чем занимаюсь, люди думают, что моя работа включает в себя все, от следить за температурой на фабриках, контролировать сотрудников, где я был один, чтобы узнать, кто заходил в Facebook в рабочее время, и даже обнаружение злоумышленников в сети.
 Прометей не был создан ни для одной из этих вещей. ² Он был построен, чтобы помочь разработчики программного обеспечения и администраторы в эксплуатации производственного компьютера системы, такие как приложения, инструменты, базы данных и сети, поддерживающие популярные сайты.
 Так что же такое мониторинг в этом контексте? Мне нравится сужать этот вид оперативный мониторинг компьютерных систем до четырех вещей:
 Оповещение
 Знать, когда что-то идет не так, как правило, важнее всего. вы хотите контролировать. Вы хотите, чтобы система мониторинга вызвала человека посмотреть.
 Отладка
 Теперь, когда вы вызвали человека, им необходимо провести расследование, чтобы определить первопричину и, в конечном счете, решить проблему.
 В тренде
 Предупреждение и отладка обычно происходят в масштабах времени порядка минут. до часов. Хотя это менее важно, возможность видеть, как используются ваши системы и меняться со временем тоже полезно. Тенденции могут влиять на дизайнерские решения и такие процессы, как планирование мощностей.
 Сантехника
 Когда все, что у тебя есть, это молоток, все начинает выглядеть как гвоздь. В в конце концов, все системы мониторинга являются конвейерами обработки данных. Иногда удобнее выделить часть вашей системы мониторинга для другую цель, а не создание индивидуального решения. это не строго мониторинг, но это распространено на практике, поэтому я хотел бы включить его.
 В зависимости от того, с кем вы разговариваете, и их происхождения, они могут учитывать только некоторые из них подлежат мониторингу. Это приводит к многочисленным дискуссиям о мониторинге по кругу, оставляя всех разочарованными. Чтобы помочь вам понять, где другие приходят из, я собираюсь посмотреть на Немного истории мониторинга.
 Краткая и неполная история мониторинга 
 Хотя в мониторинге наблюдается сдвиг в сторону инструментов, включая Prometheus в последние несколько лет доминирующим решением остается некоторая комбинация Nagios и Графит или их разновидности.
 Когда я говорю Nagios, я подразумеваю любое программное обеспечение из того же большого семейства, например как Исинга, Змон и Сенсу. Они работают в основном за счет регулярного выполнения скриптов. называются чеками. Если проверка завершается неудачей, возвращая ненулевой код выхода, выдается предупреждение. сгенерировано. Первоначально Nagios был запущен Итаном Галстадом в 1996, как MS-DOS приложение, используемое для проверки связи. Впервые он был выпущен как NetSaint в 1999 году. переименован в Nagios в 2002 году.
 Чтобы рассказать об истории Graphite, мне нужно вернуться в 1994 год. Тобиас Oetiker создал Perl-скрипт, который стал Multi Router Traffic Grapher, или MRTG. 1.0, в 1995 году. Как следует из названия, он в основном использовался для мониторинга сети. через простой протокол управления сетью (SNMP). Он также может получать метрики путем выполнения скриптов. ³ 1997 год принес большие изменения с переносом части кода на C, и создание базы данных Round Robin (RRD), которая использовалась для хранения метрических данных. Это привело к заметным улучшениям производительности, и RRD стал основой для других инструменты, включая Smokeping и Graphite.
 Запущенный в 2006 году, Graphite использует Whisper для хранения метрик, который имеет конструкция аналогична RRD. Graphite не собирает данные, а отправляет их с помощью инструментов сбора данных, таких как collectd и Statsd, которые были созданы в 2005 году. и 2010 соответственно.
 Ключевым моментом здесь является то, что построение графиков и оповещение когда-то были совершенно разными задачами, выполняемыми разными инструментами. Вы могли бы написать скрипт проверки для оценки запроса в Graphite и генерации предупреждений на его основе, но большинство проверок, как правило, находились в неожиданных состояниях, таких как незапущенный процесс.
 Еще одним пережитком той эпохи является относительно ручной подход к администрирование компьютерных сервисов. Службы были развернуты на отдельных машинах и с любовью заботятся системными администраторами. Предупреждения, которые потенциально могут указывают на проблему, на которую набросились преданные инженеры. Как облако и облако родные технологии, такие как EC2, Docker и Kubernetes, получили известность, обращение с отдельными машинами и сервисами как с домашними животными, когда каждому уделяется индивидуальное внимание, не масштабируется. Скорее, они следует рассматривать больше как крупный рогатый скот, а управлять и контролировать как группу. В точно так же, как отрасль перешла от ручного управления к такие инструменты, как Chef и Ansible, теперь начинают использовать такие технологии, как Kubernetes мониторингу также необходимо совершить аналогичный переход от проверок отдельные процессы на отдельных машинах для мониторинга на основе работоспособности службы в целом.
 Возможно, вы заметили, что я не упомянул ведение журнала. Исторически журналы использовались как нечто, что вы используете вручную с помощью tail, grep и awk. Возможно, у вас был инструмент анализа, такой как AWStats, для создания отчетов один раз в час или в день. В большем последние годы они также использовались в качестве значительной части мониторинга, например как со стеком Elasticsearch, Logstash и Kibana (ELK).
 Теперь, когда мы немного рассмотрели графики и оповещения, давайте посмотрим, как метрики и бревна вписываются в вещи. Есть ли другие категории мониторинга, кроме этих двух?
 Категории мониторинга 
 В конце концов, большая часть мониторинга посвящена одному и тому же: событиям. События может быть почти любым, в том числе:
 Получение HTTP-запроса
 Отправка ответа HTTP 400
 Ввод функции
 Достижение оператора  else  оператора  if 
 Выход из функции
 Вход пользователя
 Запись данных на диск
 Чтение данных из сети
 Запрос дополнительной памяти у ядра
 Все события также имеют контекст. HTTP-запрос будет иметь IP-адрес, который он исходящие и исходящие, запрашиваемый URL-адрес, установленные файлы cookie, и пользователь, сделавший запрос. HTTP-ответ будет иметь длину принятый ответ, код состояния HTTP и длина тела ответа. События включающие функции имеют стек вызовов функций над ними, и что бы ни вызвало эту часть стека, например HTTP-запрос.
 Наличие всего контекста для всех событий было бы полезно для отладки и понимание того, как ваши системы работают как в технической, так и в деловой сфере условиях, но такой объем данных нецелесообразно обрабатывать и хранить. Таким образом есть то, что я бы назвал примерно четырьмя способами сократить этот объем данных до чего-то работоспособного, а именно профилирование, отслеживание, ведение журнала и метрики.
 Профилирование 
 Профилирование использует подход, согласно которому вы не можете иметь весь контекст для всех событий все время, но вы можете иметь некоторый контекст для ограниченного периоды времени.
 Tcpdump — один из примеров инструмента профилирования. Позволяет записывать сетевой трафик на основе заданного фильтра. Это важный инструмент отладки, но вы не можете действительно включайте его все время, так как у вас закончится место на диске.
 Другим примером являются отладочные сборки двоичных файлов, которые отслеживают данные профилирования. Они предоставляют множество полезной информации, но влияние на производительность сбор всей этой информации, такой как время каждого вызова функции, означает что обычно нецелесообразно запускать его в производство на постоянной основе.
 В ядре Linux улучшенные фильтры пакетов Berkeley (eBPF) позволяют детально профилирование событий ядра от операций файловой системы до сетевых странностей. Они обеспечивают доступ к уровню понимания, который обычно не был доступен. ранее, и я рекомендую прочитать Работы Брендана Грегга на эту тему.
 Профилирование в основном предназначено для тактической отладки. Если он используется в течение более длительного терминальной основе, то объем данных должен быть урезан, чтобы уместиться в один из другие категории мониторинга.
 Отслеживание 
 При трассировке учитываются не все события, а определенная часть событий. например, один из ста, которые проходят через некоторые интересующие функции. Отслеживание отметит функции в трассировке стека точек интереса и часто также сколько времени потребовалось для выполнения каждой из этих функций. Из этого вы можете получить представление о том, где ваша программа тратит время и какие пути кода больше всего способствует задержке.
 Вместо того, чтобы делать моментальные снимки трассировки стека в точках интереса, некоторые трассировки системы отслеживают и записывают время каждого вызова функции ниже интересующая функция. Например, один из ста пользовательских HTTP-запросов может быть сэмплированы, и по этим запросам можно было увидеть, сколько времени было потрачено на разговоры к бэкэндам, таким как базы данных и кэши. Это позволяет вам видеть, как тайминги различаются в зависимости от таких факторов, как попадания в кеш и промахи в кеше.
 Распределенная трассировка идет еще дальше. Это позволяет отслеживать работу через процессы, прикрепляя уникальные идентификаторы к запросам, которые передаются из одного процесса другому в удаленных вызовах процедур (RPC) в дополнение к тому, является ли этот запрос это тот, который должен быть прослежен. Следы различных процессов и машины могут быть сшиты вместе на основе идентификатора запроса. Это жизненно важное инструмент для отладки архитектур распределенных микросервисов. Технологии в это пространство включает OpenZipkin и Jaeger.
 Для трассировки именно выборка сохраняет объемы данных и инструменты влияние на производительность в пределах разумного.
 Регистрация 
 Ведение журнала просматривает ограниченный набор событий и записывает часть контекста для них. каждое из этих событий. Например, он может просматривать все входящие HTTP-запросы или все исходящие вызовы базы данных. Чтобы не потреблять слишком много ресурсов, как правило, thumb вы ограничены где-то сотней полей на запись в журнале. Помимо этого, пропускная способность и место для хранения, как правило, становятся проблемой.
 Например, для сервера, обрабатывающего тысячу запросов в секунду, запись в журнале с сотней полей, каждое из которых занимает десять байтов, работает как мегабайт в секунду. Это нетривиальная пропорция 100-мегабитной сетевой карты и 84 ГБ памяти. в день только для регистрации.
 Большим преимуществом ведения журнала является то, что (обычно) нет выборки событий, поэтому несмотря на то, что существует ограничение на количество полей, полезно определить, насколько медленные запросы влияют на одного конкретного пользователя, разговаривающего с одним конкретная конечная точка API.
 Точно так же, как мониторинг означает разные вещи для разных людей, регистрация также означает разные вещи в зависимости от того, кого вы спрашиваете, что может вызвать путаницу. Различные типы регистрации имеют различное использование, долговечность и требования к хранению. Как я понимаю, их четыре общие и частично перекрывающиеся категории:
 Журналы транзакций
 Это важные деловые записи, которые вы должны хранить в безопасности любой ценой. скорее всего навсегда. Все, что касается денег или используется для критического пользовательские функции, как правило, относятся к этой категории.
 Журналы запросов
 Если вы отслеживаете каждый HTTP-запрос или каждый вызов базы данных, это журнал запросов. Они могут быть обработаны для реализации функций, ориентированных на пользователя, или просто для внутренние оптимизации. Как правило, вы не хотите их терять, но это не конец света, если кто-то из них пропадет.
 Журналы приложений
 Не все журналы относятся к запросам; некоторые о самом процессе. Запускать сообщения, фоновые задачи обслуживания и другие строки журнала на уровне процесса. типичный. Эти журналы часто читаются непосредственно человеком, поэтому вам следует избегать имея более чем несколько в минуту в нормальных условиях эксплуатации.
 Журналы отладки
 Журналы отладки, как правило, очень подробные, поэтому их создание и хранение требует больших затрат. Они часто используются только в очень узких ситуациях отладки и имеют тенденцию к профилированию из-за их объема данных. Требования к надежности и хранению, как правило, низкие, а журналы отладки могут даже не покидать машину, на которой они сгенерированы.
 Одинаковая обработка различных типов бревен может привести к худшему из всех миров, где у вас есть объем данных журналов отладки в сочетании с экстремальными Требования к надежности журналов транзакций. Таким образом, по мере роста вашей системы вы следует планировать разделение журналов отладки, чтобы их можно было обрабатывать отдельно.
 Примеры систем журналирования включают стек ELK и Graylog.
 Метрики 
 Метрики в значительной степени игнорируют контекст, вместо этого отслеживая агрегирование с течением времени. различные типы событий. Чтобы поддерживать разумное использование ресурсов, количество отслеживаемых различных чисел должно быть ограничено: десять тысяч на процесс — это разумная верхняя граница для вас, чтобы иметь в виду.
 Примерами метрик, которые у вас могут быть, могут быть количество раз, когда вы полученных HTTP-запросов, сколько времени было потрачено на обработку запросов и сколько запросы в настоящее время находятся в обработке. Исключая любую информацию о контексте, объемы данных и требуемая обработка остаются разумными.
 Однако это не означает, что этот контекст всегда игнорируется. Для HTTP-запроса вы можете решить иметь метрику для каждого URL-пути. Но десятитысячная метрика следует помнить, так как каждый отдельный путь теперь считается метрика. Использование контекста, такого как адрес электронной почты пользователя, было бы неразумным, поскольку они имеют неограниченную мощность. ⁴
 Вы можете использовать метрики для отслеживания задержки и объемов данных, обрабатываемых каждым из подсистемы в ваших приложениях, что упрощает определение того, что именно вызывает замедление. Журналы не могли записать столько полей, но как только вы знать, какая подсистема виновата, журналы могут помочь вам выяснить, какой именно пользователь участвуют запросы.
 Здесь наиболее очевидным становится компромисс между журналами и метриками. Метрики позволяют собирать информацию о событиях со всего вашего процесса, но обычно не более чем с одним или двумя контекстными полями с ограниченная мощность. Журналы позволяют собирать информацию обо всех тип события, но может отслеживать только сотню полей контекста с неограниченным мощность. Это понятие мощности и ограничений, которые оно накладывает на метрики, важно понять, и я вернусь к этому в последующих главах.
 Как система мониторинга, основанная на метриках, Prometheus предназначена для отслеживания общее состояние системы, поведение и производительность, а не отдельные События. Иными словами, Prometheus заботится о том, чтобы в памяти было 15 запросов. последняя минута, которая заняла 4 секунды, привела к 40 базам данных звонки, 17 попаданий в кеш и 2 покупки клиентами. Стоимость и код пути отдельных вызовов будут предметом профилирования или регистрации.
 Теперь, когда вы понимаете, какое место Прометей занимает в общем мониторинг пространства, давайте посмотрим на различные компоненты Prometheus.
 На рис. 1-1 показана общая архитектура Prometheus. Прометей обнаруживает цели для извлечения из службы обнаружения. Это могут быть ваши собственные инструментальные приложения или сторонние приложения, которые вы можете очистить через экспортер. Собранные данные сохраняются, и вы можете использовать их в дашборды с помощью PromQL или отправлять оповещения в Alertmanager, который преобразует их на страницы, электронные письма и другие уведомления.
 Рис. 1-1. Архитектура Prometheus 
 Клиентские библиотеки 
 Метрики, как правило, не возникают из приложений волшебным образом; у кого-то есть добавить инструменты, которые их производят. Здесь клиентские библиотеки войти. Обычно с помощью всего лишь двух или трех строк кода вы оба можете определить метрику и добавьте нужные инструменты в код, которым вы управляете. Это называется прямой аппаратурой.
 Клиентские библиотеки доступны для всех основных языков и сред выполнения. Проект Prometheus предоставляет официальные клиентские библиотеки на Go, Python, Java/JVM и Рубин. Существует также множество сторонних клиентских библиотек, например, для C#/.Net, Node.js, Haskell, Erlang и Rust.
 Клиентские библиотеки позаботятся обо всех мельчайших деталях, таких как потокобезопасность, бухгалтерский учет и создание формата текстовой экспозиции Prometheus в ответ на HTTP-запросы. Поскольку мониторинг на основе метрик не отслеживает отдельные события, использование памяти клиентской библиотекой не увеличивается события у вас есть. Скорее, память связана с количеством имеющихся у вас показателей.
 Если в одной из зависимостей библиотеки вашего приложения есть Prometheus инструментарий, он будет автоматически подобран. Таким образом, с помощью инструментов ключевой библиотеке, такой как ваш RPC-клиент, вы можете получить инструменты для нее во всех ваших приложений.
 Некоторые метрики обычно предоставляются клиентскими библиотеками по умолчанию, например использование ЦП. и статистика сборки мусора, в зависимости от библиотеки и среды выполнения.
 Клиентские библиотеки не ограничены выводом метрик в Prometheus текстовый формат. Prometheus — это открытая экосистема, и те же API, которые используются для подачи текстовый формат генерации можно использовать для создания метрик в других форматах или вводить в другие системы приборов. Аналогично можно взять метрики из других инструментальных систем и передать их в Prometheus клиентская библиотека, если вы не совсем все конвертировали в Prometheus приборка еще.
 Экспортеры 
 Не весь код, который вы запускаете, является кодом, которым вы можете управлять или даже иметь к нему доступ, и поэтому добавление прямого инструментария на самом деле не вариант. Например, это маловероятно, что ядра операционных систем начнут выводить метрики в формате Prometheus через HTTP в ближайшее время.
 Такое ПО часто имеет некий интерфейс, через который можно получить доступ к метрикам. Это может быть специальный формат, требующий пользовательского синтаксического анализа и обработки, например требуется для многих метрик Linux или хорошо зарекомендовавшего себя стандарта, такого как SNMP.
 Экспортер — это программа, которую вы развертываете рядом с приложением. из которых вы хотите получить метрики. Принимает запросы от Прометея, собирает требуемые данные из приложения, преобразует их в правильный формат и, наконец, возвращает их в ответ Прометею. Вы можете думать об экспортере как о небольшой прокси-сервер один к одному, преобразующий данные между интерфейсом метрик приложение и формат экспозиции Prometheus.
 В отличие от прямого инструментирования, которое вы бы использовали для кода, которым управляете, экспортеры используют другой стиль инструментирования, известный как 9.0491 таможенные коллекторы  или  КонстМетрикс  . ⁵
 Хорошая новость заключается в том, что, учитывая размер сообщества Prometheus, нужный экспортер, вероятно, уже существует и может быть использован с небольшими затратами. усилий с вашей стороны. Если у экспортера отсутствует интересующая вас метрика, вы можете всегда отправляйте запрос на извлечение, чтобы улучшить его, сделав его лучше для следующий человек, который будет использовать его.
 Обнаружение службы 
 После того, как все ваши приложения настроены и экспортеры запущены, Прометей должен знать, где они. Это чтобы Прометей знал, что предназначен для мониторинга и может заметить, если что-то, за чем он должен следить, не отвечает. С динамических средах вы не можете просто предоставить список приложений и экспортеры один раз, так как он устареет. Вот тут-то и начинается обнаружение сервисов.
 Вероятно, у вас уже есть база данных ваших машин, приложения и что они делают. Это может быть в базе данных Chef, в инвентаре. файл для Ansible на основе тегов вашего экземпляра EC2, в метках и аннотациях в Kubernetes или, может быть, просто сидите в своей вики документации.
 Prometheus интегрируется со многими распространенными механизмами обнаружения служб, такими как Kubernetes, EC2 и Consul. Существует также общая интеграция для тех, чьи установка немного не в глуши (см. «Файл»).
 Это все еще оставляет проблему. Просто потому, что у Прометея есть список машин и услуги не означает, что мы знаем, как они вписываются в вашу архитектуру. Например, вы можете использовать тег EC2  Name  ⁶, чтобы указать, какое приложение работает на машине, в то время как другие могут использовать тег  app  .
 Поскольку каждая организация делает это немного по-своему, Prometheus позволяет вам настроить, как метаданные из службы обнаружения сопоставляются с целями мониторинга и их метки с помощью  перемаркировка  .
 Зачистка 
 Обнаружение сервисов и перемаркировка дают нам список целей, которые необходимо контролируется. Теперь Prometheus нужно получить метрики. Прометей делает это отправка HTTP-запроса, называемого очисткой   . Ответ на очистку анализируется и принимается в хранилище. Также добавлено несколько полезных показателей, например, удалось и сколько времени это заняло. Царапины случаются регулярно; обычно вы бы настроить, чтобы это происходило каждые 10-60 секунд для каждой цели.
 Хранение 
 Prometheus хранит данные локально в пользовательской базе данных. Распределенные системы сложно сделать надежными, поэтому Prometheus не пытается сделать какую-либо форму кластеризации. Помимо надежности, это упрощает запуск Prometheus.
 За прошедшие годы система хранения претерпела ряд изменений. система в Prometheus 2.0 является третьей итерацией. Система хранения может обрабатывать миллионы образцов в секунду, что позволяет отслеживать тысячи машин с одним сервером Prometheus. Сжатие используемый алгоритм может достигать 1,3 байта на выборку на реальных данных. SSD это рекомендуется, но не является строго обязательным.
 Приборные панели 
 В Prometheus есть несколько API-интерфейсов HTTP, которые позволяют вам как запрашивать необработанные данные, и оценить запросы PromQL. Их можно использовать для создания графиков и информационных панелей. По умолчанию Prometheus предоставляет браузер выражений   . Он использует эти API и подходит для специальных запросов и исследования данных, но это не общая система приборной панели.
 Рекомендуется использовать Grafana для информационных панелей. Он имеет большое разнообразие функции, включая официальную поддержку Prometheus в качестве источника данных. Может создавать самые разные информационные панели, такие как показанная на рис. 1–2. Grafana поддерживает связь с несколькими серверами Prometheus даже в пределах одного приборная панель.
 Рис. 1-2. Панель инструментов Grafana 
 Правила записи и оповещения 
 Хотя PromQL и механизм хранения являются мощными и эффективными, агрегирование метрики с тысяч машин «на лету» каждый раз, когда вы визуализируете график. немного запаздывать. Правила записи позволяют оценивать выражения PromQL на регулярно, а их результаты загружаются в механизм хранения.
 Правила предупреждений — это еще одна форма правил записи. Они также оценивают PromQL выражения регулярно, и любые результаты этих выражений становятся предупреждениями. Оповещения отправляются на  Диспетчер предупреждений  .
 Управление предупреждениями 
 Alertmanager получает оповещения от серверов Prometheus и превращает их в в уведомления. Уведомления могут включать электронную почту, приложения чата, такие как Slack и такие сервисы, как PagerDuty.
 Alertmanager не просто слепо превращает предупреждения в уведомления один к одному. Связанные оповещения могут быть объединены в одно уведомление, регулируемое для уменьшения количества пейджеров, ⁷ и различные выходы маршрутизации и уведомлений могут быть настроены для каждого из ваших различных команды. Оповещения также можно отключить, например, чтобы отложить проблему, о которой вы уже знаете заранее, когда вы знаете, что запланировано техническое обслуживание.
 Роль Alertmanager прекращается при отправке уведомлений; управлять человеком реакции на инциденты, вы должны использовать такие службы, как PagerDuty и продажа билетов системы.
 Совет 
 Оповещения и их пороги настраиваются в Prometheus, а не в Alertmanager.
 Долгосрочное хранилище 
 Поскольку Prometheus хранит данные только на локальном компьютере, вы ограничены тем, как много дискового пространства, которое вы можете поместить на этой машине. ⁸ Хотя обычно вас интересуют только самые последние данных за день или около того, для долгосрочного планирования емкости и более длительного хранения период желателен.
 Prometheus не предлагает кластерное решение для хранения данных на нескольких машинах, но есть API для удаленного чтения и записи которые позволяют другим системам подключаться и брать на себя эту роль. Это позволяет PromQL запросы для прозрачного выполнения как для локальных, так и для удаленных данных.
 Теперь, когда у вас есть представление о том, какое место Прометей занимает в более широком мониторинге пейзаж и каковы его основные компоненты, давайте посмотрим на некоторые виды использования случаях, для которых Prometheus не является особенно хорошим выбором.
 Как система, основанная на метриках, Prometheus не подходит для хранения журналов событий или отдельных событий. Это также не лучший выбор для данных с высокой кардинальностью, таких как адреса электронной почты или имена пользователей.
 Prometheus предназначен для оперативного контроля, где небольшие неточности и условия гонки из-за таких факторов, как планирование ядра и неудачные очистки, являются факт жизни. Prometheus идет на компромисс и предпочитает предоставлять вам данные, которые 99,9% исправляют проблемы с вашим мониторингом в ожидании точных данных. Таким образом, в приложениях, связанных с деньгами или выставлением счетов, Prometheus следует использовать с осторожностью.
 В следующей главе я покажу вам, как запустить Prometheus и сделать некоторые основные мониторинг.
 ¹ Kubernetes был первым участником.
 ² Мониторинг температуры машин и центров обработки данных на самом деле не редкость. Есть даже несколько пользователей, которые используют Prometheus для отслеживания погоды ради развлечения.
 ³ У меня остались приятные воспоминания о настройке MRTG в начале 2000-х, написании сценариев для отчетов о температуре и использовании сети на моих домашних компьютерах.
 ⁴ Адреса электронной почты также, как правило, содержат личную информацию (PII), что влечет за собой проблемы соблюдения требований и конфиденциальности, которых лучше избегать при мониторинге.
 ⁵ Термин ConstMetric является разговорным и происходит от функции  MustNewConstMetric  клиентской библиотеки Go, используемой для создания метрик экспортерами, написанными на Go.
 ⁶ Тег EC2  Name  — это отображаемое имя экземпляра EC2 в веб-консоли EC2.
 ⁷ Страница   — это уведомление дежурному инженеру, которое он должен немедленно изучить или принять меры. Хотя вы можете получать пейджинг через традиционный радиопейджер, в наши дни он, скорее всего, придет на ваш мобильный телефон в виде SMS, уведомления или телефонного звонка. Пейджерный шторм — это когда вы получаете строку страниц в быстрой последовательности.
 ⁸ Однако современные машины могут хранить достаточно много данных локально, поэтому вам может не понадобиться отдельная кластерная система хранения.
 Мониторинг серверов Linux с помощью Prometheus и Node Exporter 
 Мониторинг состояния ваших серверов и запущенных на них процессов имеет решающее значение для оптимизации настроек, исправления ошибок или реагирования на увеличение нагрузки в время, прежде чем ваши пользователи заметят снижение производительности. Это требует мониторинга система, позволяющая собирать метрики с серверов, сетевых устройств, приложения или контейнеры. Несмотря на то, что в это пространство, одной из популярных и многофункциональных систем является Прометей.
 Prometheus — это решение для мониторинга с открытым исходным кодом, состоящее из нескольких компоненты, написанные на языке программирования Go. Его основным компонентом является база данных временных рядов для хранения метрик, но есть и другие компоненты, такие как экспортеры для сбор данных с различных сервисов и менеджер предупреждений, который обрабатывает предупреждения.
 В этом руководстве содержится информация о том, как установить и настроить Prometheus и Node Exporter на вашем Linux серверы. Node Exporter — это инструмент, предоставляющий доступ к широкому спектру аппаратных и связанные с ядром метрики для Unix-подобные системы. Существует также Экспортер Windows для Windows, которая служит аналогичной цели.
 🔭 Хотите получать уведомления, когда ваш сайт выходит из строя? 
 Перейти к Better Uptime и начать мониторинг через 2 минуты.
 Предварительные условия 
 Для выполнения этого руководства вам потребуется доступ к двум системам Linux. Это могло, это может быть локальными машинами, виртуальными машинами или удаленными серверами. Мы будем использовать первый система для запуска экземпляра Prometheus, который будет отслеживать производительность вторая система, на которой запущен Node Exporter для извлечения метрик из ОС.
 Если у вас нет двух доступных систем, не стесняйтесь запускать обе Экземпляр Prometheus и Node Exporter на одном сервере и настроить команды и инструкции ниже по мере необходимости. Для простоты мы будем использовать Ubuntu. 20.04 для обоих серверов, но процесс должен быть почти идентичен для других Операционные системы на базе Linux.
 Шаг 1 — Подготовка серверов 
 Прежде чем приступить к установке Prometheus и Node Exporter, необходимо подготовить ваши серверы, создав пользователей и каталоги, открыв порты в брандмауэре и создание сертификата, который защитит соединение между сервером Prometheus и сервером Node Exporter.
 Начнем с первой системы. Войдите на сервер и создайте пользователя с именем  prometheus  с помощью следующих команд:
 ssh 
 
 Скопировано!
 sudo useradd --no-create-home --shell /bin/false prometheus
 
 Скопировано!
 Здесь параметры  --no-create-home  и  --shell /bin/false  гарантируют, что для этого пользователя не создается домашний каталог, и этот пользователь не может войти в сервер.
 Затем создайте следующие каталоги для хранения конфигурации Prometheus файлы и данные:
 sudo mkdir /etc/prometheus
 
 Скопировано!
 sudo mkdir /var/lib/prometheus
 
 Скопировано!
 Затем измените права пользователя и группы на новые каталоги на  прометей  пользователь.
 sudo chown -R прометей: прометей /etc/прометей /var/lib/прометей
 
 Скопировано!
 Следующие две команды являются необязательными. Если вы планируете запустить Prometheus на локальной сети и не используйте брандмауэр, их можно пропустить.
 Откройте порт HTTP по умолчанию для сервера Prometheus:
 sudo ufw allow 9090/tcp
 
 Скопировано!
 sudo ufw перезагрузить
 
 Скопировано!
 На этом мы закончили первоначальную подготовку Прометея сервер. Давайте продолжим и подготовим вторую систему, в которой будет работать Node. Экземпляр экспортера. Войдите на сервер и создайте нового пользователя с именем  nodeuser  :
 ssh 
 
 Скопировано!
 sudo useradd --no-create-home --shell /bin/false nodeuser
 
 Скопировано!
 Затем создайте каталог для хранения файлов конфигурации Node Exporter:
 sudo mkdir /etc/node_exporter
 
 Скопировано!
 Node Exporter использует порт  9100  для входящих подключений, поэтому Prometheus сервер будет подключаться к этому порту. Если вы используете брандмауэр, выполните приведенные ниже команды. на сервере Node Exporter, чтобы разрешить соединения через этот порт:
 sudo ufw allow 9100/TCP
 
 Скопировано!
 sudo ufw перезагрузить
 
 Скопировано!
 Шаг 2 — Защита соединения между серверами 
 Нам необходимо создать SSL-сертификат для защиты соединений между Сервер Prometheus и Node Exporter. В этом уроке мы будем использовать самоподписанные учетные данные. Выполните следующую команду на сервере Node Exporter. для создания сертификата:
 openssl req -new -newkey rsa:2048 -days 365 -nodes -x509 -keyout node_exporter.key -out node_exporter.crt -subj "/C=US/ST=Utah/L=Lehi/O =Your Company, Inc./OU=IT/CN=yourdomain.com" -addext "subjectAltName = IP:"
 
 Скопировано!
 Не забудьте заменить строку    на IP-адрес ваш второй сервер, к которому будет подключаться сервер Prometheus. Ты увидишь следующий вывод:
 Выход
 Создание закрытого ключа RSA
. ..++++++
..............................................+++ ++
запись нового закрытого ключа в 'node_exporter.key'
-----
 
 В результате вы получите два файла в текущем каталоге:  node_exporter.crt  и  node_exporter.key  . Скопируйте эти файлы в  /etc/node_exporter  каталог:
 sudo cp node_exporter.* /etc/node_exporter
 
 Скопировано!
 После этого измените права пользователя и группы на новые каталоги и файлы до  пользователь узла  .
 sudo chown -R nodeuser:nodeuser /etc/node_exporter
 
 Скопировано!
 Затем скопируйте файл  node_exporter.crt  на первый сервер любым доступным способом. Например, вы можете показать содержимое файла и скопировать его в буфер обмена:
 кот /etc/node_exporter/node_exporter.crt
 
 Скопировано!
 Выход
 ----- СЕРТИФИКАТ НАЧАЛА -----
MIIDzjCCAragAwIBAgIUCQuU1Y/15mJiRHF5zKc5nPql8wUwDQYJKoZIhvcNAQEL
BQAwbjELMAkGA1UEBhMCVVMxDTALBgNVBAgMBFV0YWgxDTALBgNVBAcMBExlaGkx
GzAZBgNVBAoMEllvdXigQ29tcGFueSwgSW5jLjELMAkGA1UECwwCSVQxFzAVBgNV
BAMMDnlvdXJkb21haW4uY29tMB4XDTIyMDQxMzE3MjIyM1oXDTIzMDQxMzE3MjIy
M1owbjELMAkGA1UEBhMCVVMxDTALBgNVBAgMBFV0YWgxDTALBgNVBAcMBExlaGkx
GzAZBgNVBAoMEllvdXigQ29tcGFueSwgSW5jLjELMAkGA1UECwwCSVQxFzAVBgNV
BAMMDnlvdXJkb21haW4uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAqXopi/6gWVx7qe4ADPc1g2VK8uEcCVLj6EPlfTmatxK8AlUGMFx8zP5H8xrb
7S3sdUN+iGQAYTLavoUIBR2k8IBmq073ziuK+Dd56TYvcjdJvOXyKgRo2R49NdtN
3uYtx3ZZp9E1QmMQMuMev4qCQ0jIwVtxb0jEk8RimAQFoFc5z86JD9oFSVp+VqA3
HPUElmr5at7+Nczf07m874S47QfvhHIiUDl8PX/Ch+gm6gUBqic7adltz+pgkl1W
КиевBGGbK48QBR57rMn0Juy3DHHgQyEYNXWUlQ2gjc1UuK0NZZW8KTXY29jF8mwZh
tdZ/UFiqoIgMfRry3522AnAZwQIDAQABo2QwYjAdBgNVHQ4EFgQUF3juV9xC32zU
S33qwuo1V6LIPNowHwYDVR0jBBgwFoAUF3juV9xC32zUS33qwuo1V6LIPNowDwYD
VR0TAQH/BAUwAwEB/zAPBgNVHREECDAGhwSHtW71MA0GCSqGSIb3DQEBCwUAA4IB
AQARRTXVPzgpKWfgkF4dG0Cqd/HlmdRGFGU4S7LGWdbHSW6B7s0A4YvXOzQmL+ib
ucnbbsJn4Vy4GtOkpkfJgzSQqqm0ozcZsKOJdRkZ7/S8NNdVI/leqO5QT9I0kinQ
NfTd544f/i4MCBhvGx0yhQum32xIJy75RcQC4m8y76dzlW8OCyFidcw+S9plcsml
JIOV0tzfeYc8vQrHMGyhOrJk9FCCtnipDd5AtlFqB1Q3J2bz+7A4JvG2uK2qGOAI
JuiBuqDpNGgIotV3LcqzkAmIT0JomTDx9MGCfIJFz71iO80JXGHkk/L4U2U+9cvQ
Gllx69QjPJirRJj2LNyEB0PD
-----КОНЕЦ СЕРТИФИКАТА-----
 
 Затем создайте новый файл на сервере Prometheus и вставьте туда содержимое:
 sudo nano /etc/prometheus/node_exporter. crt
 
 Скопировано!
 /etc/prometheus/node_exporter.crt
 ----- НАЧАТЬ СЕРТИФИКАТ-----
MIIDzjCCAragAwIBAgIUCQuU1Y/15mJiRHF5zKc5nPql8wUwDQYJKoZIhvcNAQEL
BQAwbjELMAkGA1UEBhMCVVMxDTALBgNVBAgMBFV0YWgxDTALBgNVBAcMBExlaGkx
GzAZBgNVBAoMEllvdXIgQ29tcGFueSwgSW5jLjELMAkGA1UECwwCSVQxFzAVBgNV
BAMMDnlvdXJkb21haW4uY29tMB4XDTIyMDQxMzE3MjIyM1oXDTIzMDQxMzE3MjIy
M1owbjELMAkGA1UEBhMCVVMxDTALBgNVBAgMBFV0YWgxDTALBgNVBAcMBExlaGkx
GzAZBgNVBAoMEllvdXigQ29tcGFueSwgSW5jLjELMAkGA1UECwwCSVQxFzAVBgNV
BAMMDnlvdXJkb21haW4uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAqXopi/6gWVx7qe4ADPc1g2VK8uEcCVLj6EPlfTmatxK8AlUGMFx8zP5H8xrb
7S3sdUN+iGQAYTLavoUIBR2k8IBmq073ziuK+Dd56TYvcjdJvOXyKgRo2R49NdtN
3uYtx3ZZp9E1QmMQMuMev4qCQ0jIwVtxb0jEk8RimAQFoFc5z86JD9oFSVp+VqA3
HPUElmr5at7+Nczf07m874S47QfvhHIiUDl8PX/Ch+gm6gUBqic7adltz+pgkl1W
КиевBGGbK48QBR57rMn0Juy3DHHgQyEYNXWUlQ2gjc1UuK0NZZW8KTXY29jF8mwZh
tdZ/UFiqoIgMfRry3522AnAZwQIDAQABo2QwYjAdBgNVHQ4EFgQUF3juV9xC32zU
S33qwuo1V6LIPNowHwYDVR0jBBgwFoAUF3juV9xC32zUS33qwuo1V6LIPNowDwYD
VR0TAQH/BAUwAwEB/zAPBgNVHREECDAGhwSHtW71MA0GCSqGSIb3DQEBCwUAA4IB
AQARRTXVPzgpKWfgkF4dG0Cqd/HlmdRGFGU4S7LGWdbHSW6B7s0A4YvXOzQmL+ib
ucnbbsJn4Vy4GtOkpkfJgzSQqqm0ozcZsKOJdRkZ7/S8NNdVI/leqO5QT9I0kinQ
NfTd544f/i4MCBhvGx0yhQum32xIJy75RcQC4m8y76dzlW8OCyFidcw+S9plcsml
JIOV0tzfeYc8vQrHMGyhOrJk9FCCtnipDd5AtlFqB1Q3J2bz+7A4JvG2uK2qGOAI
JuiBuqDpNGgIotV3LcqzkAmIT0JomTDx9MGCfIJFz71iO80JXGHkk/L4U2U+9cvQ
Gllx69QjPJirRJj2LNyEB0PD
-----КОНЕЦ СЕРТИФИКАТА-----
 
 Скопировано!
 Также на обоих серверах вам понадобится утилита  htpasswd , входящая в состав пакет  apache2-utils .
 sudo apt установить apache2-utils
 
 Скопировано!
 На этом предварительная подготовка закончена и можно переходить к установке Prometheus на первом сервере на следующем шаге.
 Шаг 3 — Загрузка и установка Prometheus 
 Prometheus не может быть установлен из стандартных репозиториев Ubuntu в данный момент написания, поэтому вам нужно получить архив текущей версии. Перейти к официальная страница загрузки и копия ссылка на пакет Linux последней стабильной версии.
 Затем войдите на свой первый сервер Linux и загрузите архив с  wget  :
 wget https://github.com/prometheus/prometheus/releases/download/v2.34.0/prometheus-2.34.0. Linux-amd64.tar.gz
 
 Скопировано!
 После сохранения архива мы проверим целостность загрузки запустите программу  sha256sum  и сравните ее вывод с соответствующим  SHA256 Контрольная сумма Значение  указано на сайте:
 sha256sum prometheus-2. 34.0.linux-amd64.tar.gz
 
 Скопировано!
 Вывод должен выглядеть так:
 Выход
 9ec560940bf53361dd9d3a867d51ceb96f3854ae12f5e532b7d3f60c27f364d0 prometheus-2.34.0.linux-amd64.tar.gz
 
 После того, как вы подтвердите, что указанное выше значение соответствует контрольной сумме  SHA256  на веб-сайт, вы можете продолжить и распаковать архив с помощью показанной команды ниже:
 tar zxvf prometheus-2.34.0.linux-amd64.tar.gz
 
 Скопировано!
 Выход
 прометей-2.34.0.линукс-амд64/
прометей-2.34.0.linux-amd64/консоли/
прометей-2.34.0.linux-amd64/consoles/index.html.example
прометей-2.34.0.linux-amd64/consoles/node-cpu.html
прометей-2.34.0.linux-amd64/consoles/node-disk.html
прометей-2.34.0.linux-amd64/consoles/node-overview.html
прометей-2.34.0.linux-amd64/consoles/node.html
прометей-2.34.0.linux-amd64/консоли/прометей-обзор. html
прометей-2.34.0.linux-amd64/consoles/prometheus.html
прометей-2.34.0.linux-amd64/console_libraries/
прометей-2.34.0.linux-amd64/console_libraries/menu.lib
прометей-2.34.0.linux-amd64/console_libraries/prom.lib
прометей-2.34.0.linux-amd64/prometheus.yml
прометей-2.34.0.linux-amd64/ЛИЦЕНЗИЯ
прометей-2.34.0.linux-amd64/УВЕДОМЛЕНИЕ
прометей-2.34.0.linux-amd64/прометей
прометей-2.34.0.linux-amd64/promtool
 
 Перейдите во вновь созданный каталог:
 cd prometheus-2.34.0.linux-amd64/
 
 Скопировано!
 Давайте распределим файлы в этом каталоге по соответствующим местам. Копировать два бинарных файла в текущем каталоге на  /usr/local/bin  :
 sudo cp prometheus promtool /usr/local/bin/
 
 Скопировано!
 Скопируйте каталоги  console  и  console_libraries  в  /etc/prometheus  . Также скопируйте туда пример файла конфигурации:
 sudo cp -r console_libraries consoles prometheus. yml /etc/prometheus
 
 Скопировано!
 Теперь изменен владелец для всех скопированных файлов на  prometheus  :
 sudo chown prometheus: prometheus /usr/local/bin/prometheus /usr/local/bin/promtool
 
 Скопировано!
 sudo chown -R прометей: прометей /etc/prometheus
 
 Скопировано!
 Prometheus теперь установлен на вашем сервере! Прежде чем приступить к ней, давайте посмотрите его конфигурационный файл в следующем разделе.
 Шаг 4 — Настройка Prometheus 
 На предыдущем шаге мы скопировали образец файла конфигурации в папку  /etc/prometheus . каталог. Откройте его в текстовом редакторе для проверки.
 sudo nano /etc/prometheus/prometheus.yml
 
 Скопировано!
 Вы должны соблюдать следующее содержимое:
 /etc/prometheus/prometheus.yml
 # моя глобальная конфигурация
Глобальный:
  scrape_interval: 15s # Установить интервал очистки каждые 15 секунд. По умолчанию — каждую 1 минуту. 
  Evaluation_interval: 15s # Оценивать правила каждые 15 секунд. По умолчанию — каждую 1 минуту.
  # scrape_timeout установлен на глобальное значение по умолчанию (10 с).
# Конфигурация диспетчера оповещений
оповещение:
  менеджеры предупреждений:
    - статические_конфигурации:
        - цели:
          # - диспетчер предупреждений:9093
# Загружать правила один раз и периодически оценивать их в соответствии с глобальным 'evaluation_interval'.
файлы_правил:
  # - "first_rules.yml"
  # - "second_rules.yml"
# Конфигурация очистки, содержащая только одну конечную точку для очистки:
# Вот это сам Прометей.
scrape_configs:
  # Имя задания добавляется в виде метки `job=` ко всем временным рядам, извлеченным из этой конфигурации.
  - job_name: "прометей"
    # metrics_path по умолчанию "/metrics"
    # схема по умолчанию 'http'.
    статические_конфигурации:
      - цели: ["localhost:9090"]
 
 Скопировано!
 Этот файл использует формат YAML, который строго запрещает вкладки и требует двух пробелы для отступов, поэтому будьте осторожны при редактировании. Он содержит некоторые комментарии чтобы помочь вам понять каждую настройку. Например, в разделе  глобальных настроек  вы можно изменить интервал по умолчанию для извлечения метрик из экспортеров.
 /etc/prometheus/prometheus.yml
 . . .
Глобальный:
  scrape_interval: 15s # Установить интервал очистки каждые 15 секунд. По умолчанию — каждую 1 минуту.
. . .
 
 Скопировано!
 Раздел  scrape_configs  содержит все экспортеры, из которых нужно собирать метрики. По умолчанию он настроен на сбор данных с самого Прометея:
 /etc/prometheus/prometheus.yml
. . .
scrape_configs:
  # Имя задания добавляется в виде метки `job=` ко всем временным рядам, извлеченным из этой конфигурации.
  - job_name: "прометей"
    # metrics_path по умолчанию "/metrics"
    # схема по умолчанию 'http'.
    статические_конфигурации:
      - цели: ["localhost:9090"]
 
 Скопировано!
 Пока мы не будем менять какие-либо настройки, пока не настроим наш узел. Экземпляр экспортера. В следующем разделе мы выполним CLI  prometheus  для первый раз.
 Шаг 5 — Запуск интерфейса командной строки Prometheus 
 Сначала мы запустим Prometheus вручную, а затем создадим Systemd сервис, чтобы управлять им должным образом.
 Выполните следующую команду на своем первом сервере:
 sudo -u prometheus /usr/local/bin/prometheus \
    --config.file /etc/prometheus/prometheus.yml \
    --storage.tsdb.path /var/lib/prometheus/ \
    --web.console.templates=/etc/прометей/консоли \
    --web.console.libraries=/etc/prometheus/console_libraries
 
 Скопировано!
 Вы должны наблюдать следующий журнал запуска:
 Выход
 ts=2022-04-14T07:35:54.363Z caller=main.go:479 level=info msg="Время или размер хранения не установлены, поэтому используется время хранения по умолчанию" duration=15d
ts=2022-04-14T07:35:54.364Z caller=main.go:516 level=info msg="Запуск Prometheus" version="(версия=2. 34.0, ветвь=HEAD, ревизия=881111fec4332c33094a6fb2680c71fffc427275)"
ts=2022-04-14T07:35:54.364Z caller=main.go:521 level=info build_context="(go=go1.17.8, [электронная почта защищена], дата=20220315-15:18:00)"
ts=2022-04-14T07:35:54.364Z caller=main.go:522 level=info host_details="(Linux 5.4.0-104-generic #118-Ubuntu SMP Ср, 2 марта 19:02:41 UTC 2022 x86_64 ubuntu-2gb-nbg1-1 (нет))"
ts=2022-04-14T07:35:54.365Z caller=main.go:523 level=info fd_limits="(soft=1024, hard=1048576)"
ts=2022-04-14T07:35:54.365Z caller=main.go:524 level=info vm_limits="(soft=unlimited, hard=unlimited)"
ts=2022-04-14T07:35:54.378Z caller=web.go:540 level=info component=web msg="Начать прослушивание подключений" address=0.0.0.0:9090
ts=2022-04-14T07:35:54.387Z caller=main.go:937 level=info msg="Запуск TSDB..."
ts=2022-04-14T07:35:54.394Z вызывающий абонент=tls_config.go:195 level=info component=web msg="TLS отключен." http2=ложь
ts=2022-04-14T07:35:54.405Z caller=head.go:493 level=info component=tsdb msg="Повторное воспроизведение фрагментов памяти на диске, если они есть"
ts=2022-04-14T07:35:54. 406Z caller=head.go:536 level=info component=tsdb msg="Воспроизведение отображаемых фрагментов памяти на диске завершено" продолжительность=4,385 мкс
ts=2022-04-14T07:35:54.406Z caller=head.go:542 level=info component=tsdb msg="Воспроизведение WAL, это может занять некоторое время"
ts=2022-04-14T07:35:54.407Z caller=head.go:613 level=info component=tsdb msg="сегмент WAL загружен" segment=0 maxSegment=0
ts=2022-04-14T07:35:54.407Z вызывающий абонент=head.go:619level=info component=tsdb msg="Воспроизведение WAL завершено" checkpoint_replay_duration=49,735 мкс wal_replay_duration=1,364197 мс total_replay_duration=1,547724 мс
ts=2022-04-14T07:35:54.409Z caller=main.go:958 level=info fs_type=EXT4_SUPER_MAGIC
ts=2022-04-14T07:35:54.409Z caller=main.go:961 level=info msg="TSDB запущен"
ts=2022-04-14T07:35:54.409Z caller=main.go:1142 level=info msg="Загрузка файла конфигурации" имя_файла=/etc/prometheus/prometheus.yml
ts=2022-04-14T07:35:54.413Z caller=main.go:1179 level=info msg="Завершена загрузка файла конфигурации" имя_файла=/etc/prometheus/prometheus. yml totalDuration=3,377506 мс db_storage=1,585 мкс remote_storage =2,659мкс web_handler=718 нс query_engine=8,708 мкс очистка=2,301903 мс scrape_sd=31,007 мкс notify=386,697 мкс notify_sd=21,135 мкс правила=1,695 мкс трассировка=11,188 мкс
ts=2022-04-14T07:35:54.413Z caller=main.go:910 level=info msg="Сервер готов принимать веб-запросы."
 
 Последняя строка выше подтверждает, что сервер успешно запущен, что означает, что наша конфигурация работает правильно. Однако запуск сервера вручную не идеально, поэтому мы создадим новый файл модуля  systemd , чтобы он мог управляться через демон Systemd.
 Убейте существующий сервер с помощью  Ctrl-C  , затем создайте файл  prometheus.service  в каталоге  /etc/systemd/system , как показано ниже:
 sudo nano /etc/systemd/system/prometheus.service
 
 Скопировано!
 Вставьте в файл следующее содержимое и сохраните его:
 /etc/systemd/system/prometheus. service
 [Unit]
Описание=Сервис Прометей
После=network.target
[Обслуживание]
Пользователь=прометей
Группа=прометей
Тип=простой
ExecStart=/usr/local/bin/prometheus \
    --config.file /etc/prometheus/prometheus.yml \
    --storage.tsdb.path /var/lib/prometheus/ \
    --web.console.templates=/etc/прометей/консоли \
    --web.console.libraries=/etc/prometheus/console_libraries
ExecReload=/bin/kill -HUP $MAINPID
Перезапуск = при сбое
[Установить]
WantedBy=многопользовательская.цель
 
 Скопировано!
 Эта служба выполнит процесс запуска, аналогичный тому, что мы делали вручную до. Он также автоматически перезапустит службу, если возникнут какие-либо ошибки и убедитесь, что программа запущена и работает после перезагрузки системы.
 Сохраните и закройте файл, затем перезагрузите конфигурацию  systemd  через команда ниже:
 sudo systemctl daemon-reload
 
 Скопировано!
 Теперь вы можете запустить Prometheus, введя следующую команду:
 sudo systemctl запустить прометей
 
 Скопировано!
 Подтвердите правильность запуска:
 systemctl status prometheus
 
 Скопировано!
 Вы должны увидеть следующий вывод:
 Выход
 ● prometheus. service — служба Prometheus
     Загружено: загружено (/etc/systemd/system/prometheus.service; отключено; предустановка поставщика: включена)
     Активно: активно (работает) с чт 14 апреля 2022 г., 07:49:39 UTC; 8 сек. назад
   Основной PID: 17 (прометей)
      Заданий: 6 (лимит: 2275)
     Память: 36,1 Мб
     Группа CG: /system.slice/prometheus.service
             └─17 /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus /консоли --веб.>
14 апреля 07:49:39 ubuntu-2gb-nbg1-1 prometheus[17]: ts=2022-04-14T07:49:39.939Z caller=head.go:536 level=info component=tsdb msg="On-disk Воспроизведение отображаемых фрагментов памяти завершено" продолжительность>
14 апр 07:49:39 ubuntu-2gb-nbg1-1 prometheus[17]: ts=2022-04-14T07:49:39.939Z caller=head.go:542 level=info component=tsdb msg="Воспроизведение WAL, это может занять некоторое время "
14 апреля 07:49:40 ubuntu-2gb-nbg1-1 prometheus[1
7]: ts=2022-04-14T07:49:40. 280Z caller=head.go:613 level=info component=tsdb msg="сегмент WAL загружен " сегмент = 0 макссегмент = 1
14 апреля 07:49:40 ubuntu-2gb-nbg1-1 prometheus[17]: ts=2022-04-14T07:49:40.281Z caller=head.go:613 level=info component=tsdb msg="сегмент WAL загружен "сегмент=1 макссегмент=1
14 апр 07:49:40 ubuntu-2gb-nbg1-1 prometheus[17]: ts=2022-04-14T07:49:40.282Z caller=head.go:619 level=info component=tsdb msg="Воспроизведение WAL завершено" checkpoint_replay_duration=61.49µs >
14 апреля 07:49:40 ubuntu-2gb-nbg1-1 prometheus[17]: ts=2022-04-14T07:49:40.288Z caller=main.go:958 level=info fs_type=EXT4_SUPER_MAGIC
14 апреля 07:49:40 ubuntu-2gb-nbg1-1 prometheus[17]: ts=2022-04-14T07:49:40.289Z caller=main.go:961 level=info msg="TSDB запущен"
14 апреля 07:49:40 ubuntu-2gb-nbg1-1 прометей[17]: ts=2022-04-14T07:49:40.289Z caller=main.go:1142 level=info msg="Загрузка файла конфигурации" имя_файла=/etc/prometheus/prometheus.yml
14 апреля 07:49:40 ubuntu-2gb-nbg1-1 prometheus[1
7]: ts=2022-04-14T07:49:40. 306Z caller=main.go:1179 level=info msg="Завершена загрузка файла конфигурации" имя_файла=/etc/prometheus/prome>
14 апреля 07:49:40 ubuntu-2gb-nbg1-1 prometheus[17]: ts=2022-04-14T07:49:40.307Z caller=main.go:910 level=info msg="Сервер готов принимать веб Запросы."
 
 Наконец, разрешите автозапуск службы:
 sudo systemctl включить прометей
 
 Скопировано!
 Выход
 Создана символическая ссылка /etc/systemd/system/multi-user.target.wants/prometheus.service → /etc/systemd/system/prometheus.service.
 
 На данный момент Prometheus работает на первой системе. В следующий раздел, мы настроим экземпляр Node Exporter на втором.
 Шаг 6 — Загрузка и установка Node Exporter 
 Как и Prometheus, Node Exporter нельзя установить из Ubuntu по умолчанию 20.04, поэтому вам нужно получить архив текущей версии на Сайт Прометея. Скопируйте ссылку на соответствующий пакет Linux, затем войдите на свой второй сервер Linux и скачать архив:
 wget https://github. com/prometheus/node_exporter/releases/download/v1.3.1/node_exporter-1.3.1.linux-amd64.tar.gz
 
 Скопировано!
 Вы также можете получить контрольную сумму загруженного файла и сравнить ее с  SHA256 Контрольная сумма  аналогично тому, как мы подтвердили загрузку Prometheus в шаг 3.
 sha256sum node_exporter-1.3.1.linux-amd64.tar.gz
 
 Скопировано!
 Выход
 68f3802c2dd3980667e4ba65ea2e1fb03f4a4ba026cca375f15a0390ff850949 node_exporter-1.3.1.linux-amd64.tar.gz
 
 Далее распакуйте архив и перейдите в каталог с распакованные файлы:
 tar zxvf node_exporter-1.3.1.linux-amd64.tar.gz
 
 Скопировано!
 Выход
 node_exporter-1.3.1.linux-amd64/
node_exporter-1.3.1.linux-amd64/ЛИЦЕНЗИЯ
node_exporter-1.3.1.linux-amd64/УВЕДОМЛЕНИЕ
node_exporter-1.3.1.linux-amd64/node_exporter
 
 компакт-диск node_exporter-1. 3.1.linux-amd64
 
 Скопировано!
 После этого скопируйте двоичный файл  node_exporter  в каталог  /usr/local/bin , и установите владельца пользователя и группы на  nodeuser :
 sudo cp node_exporter /usr/local/bin/
 
 Скопировано!
 sudo chown -R nodeuser:nodeuser /usr/local/bin/node_exporter
 
 Скопировано!
 Интерфейс командной строки Node Exporter теперь готов к работе, но нам необходимо дополнительно защитить его, поэтому что к нему могут подключаться только авторизованные клиенты.
 Шаг 7. Защита и запуск экземпляра Node Exporter 
 Перед запуском Node Exporter настроим безопасное соединение. Сделать это, мы будем использовать SSL-соединения, а также базовую авторизацию. Первый, сгенерировать хэш пароля с помощью команды  htpasswd :
 htpasswd -nBC 10 "" | тр -д ':\n'
 
 Скопировано!
 Эта команда предложит вам ввести и подтвердить пароль. Введите что-нибудь вы можете запомнить или использовать менеджер паролей для его создания. С целью в этом уроке мы использовали пароль  пром  . В результате вы получите строку вот так:
 Выход
 $2y$10$fhJONsmSqbvjCB9sCjAe8.XyEDP39P36tCVoX8qx3sX3jcyCOhnHi
 
 Скопируйте всю строку выше и запишите ее куда-нибудь. Он понадобится позже на этом шаге.
 Теперь давайте настроим Node Exporter, создав следующий файл конфигурации:
 sudo nano /etc/node_exporter/web.yml
 
 Скопировано!
 Вставьте в него следующее содержимое:
 /etc/node_exporter/web.yml
 tls_server_config:
  cert_file: /etc/node_exporter/node_exporter.crt
  ключевой_файл: /etc/node_exporter/node_exporter.key
basic_auth_users:
  выпускной: $2г$10$fhJONsmSqbvjCB9sCjAe8.XyEDP39P36tCVoX8qx3sX3jcyCOhnHi
 
 Скопировано!
 Мы указали путь к ранее созданному сертификату и имя пользователя и хешированный пароль, необходимый для подключения. В демонстрационных целях мы также использовал  prom  в качестве имени пользователя.
 После этого обновить права на файлы:
 sudo chown -R nodeuser:nodeuser /etc/node_exporter
 
 Скопировано!
 Для управления экземпляром Node Exporter с помощью Systemd мы создадим новый блок такой файл:
 sudo nano /etc/systemd/system/node_exporter.service
 
 Скопировано!
 Вставьте следующее содержимое в файл и сохраните его.
 /etc/systemd/system/node_exporter.service
 [Единица измерения]
Описание=Служба экспортера узлов
После=network.target
[Обслуживание]
Пользователь=nodeuser
Группа=nodeuser
Тип=простой
ExecStart=/usr/local/bin/node_exporter --web.config=/etc/node_exporter/web.yml
ExecReload=/bin/kill -HUP $MAINPID
Перезапуск = при сбое
[Установить]
WantedBy=многопользовательская.цель
 
 Скопировано!
 Затем перезагрузите конфигурацию  systemd :
 sudo systemctl daemon-reload
 
 Скопировано!
 Теперь вы можете запустить службу Node Exporter с помощью  systemctl :
 sudo systemctl start node_exporter
 
 Скопировано!
 Проверьте правильность запуска:
 systemctl status node_exporter
 
 Скопировано!
 Выход
 ● node_exporter. service — служба экспорта узлов
     Загружено: загружено (/etc/systemd/system/node_exporter.service; отключено; настройка поставщика: отключена)
     Active: активно (работает) с четверга 2022-04-14 09:05:34 UTC; 6 с назад
   Основной PID: 302230 (node_exporter)
      Заданий: 4 (лимит: 2254)
     Память: 2,2 м
        ЦП: 15 мс
     Группа CG: /system.slice/node_exporter.service
             └─302230 /usr/local/bin/node_exporter --web.config=/etc/node_exporter/web.yml
14 апреля, 09:05:34 fedora-2gb-hel1-1 node_exporter[302230]: ts=2022-04-14T09:05:34.082Z caller=node_exporter.go:115 level=info collection=thermal_zone
14 апреля, 09:05:34 fedora-2gb-hel1-1 node_exporter[302230]: ts=2022-04-14T09:05:34.082Z caller=node_exporter.go:115 уровень=сборщик информации=время
14 апр. 09 г.:05:34 fedora-2gb-hel1-1 node_exporter[302230]: ts=2022-04-14T09:05:34.082Z caller=node_exporter.go:115 level=сборщик информации=timex
14 апреля, 09:05:34 fedora-2gb-hel1-1 node_exporter[302230]: ts=2022-04-14T09:05:34. 082Z caller=node_exporter.go:115 level=info collection=udp_queues
14 апреля, 09:05:34 fedora-2gb-hel1-1 node_exporter[302230]: ts=2022-04-14T09:05:34.082Z caller=node_exporter.go:115 level=info collection=uname
14 апреля, 09:05:34 fedora-2gb-hel1-1 node_exporter[302230]: ts=2022-04-14T09:05:34.082Z caller=node_exporter.go:115 level=info collection=vmstat
14 апр. 09 г.:05:34 fedora-2gb-hel1-1 node_exporter[302230]: ts=2022-04-14T09:05:34.082Z caller=node_exporter.go:115 level=сборщик информации=xfs
14 апреля, 09:05:34 fedora-2gb-hel1-1 node_exporter[302230]: ts=2022-04-14T09:05:34.083Z caller=node_exporter.go:115 level=info collection=zfs
14 апреля, 09:05:34 fedora-2gb-hel1-1 node_exporter[302230]: ts=2022-04-14T09:05:34.083Z caller=node_exporter.go:199 level=info msg="Прослушивание" address=: 9100
14 апреля, 09:05:34 fedora-2gb-hel1-1 node_exporter[302230]: ts=2022-04-14T09:05:34.085Z caller=tls_config.go:228 level=info msg="TLS включен." http2=правда
 
 Наконец, включите Node Exporter для запуска при загрузке:
 sudo systemctl enable node_exporter
 
 Скопировано!
 Выход
 Создана символическая ссылка /etc/systemd/system/multi-user. target.wants/node_exporter.service → /etc/systemd/system/node_exporter.service.
 
 Перед добавлением вновь созданного экспортера в наш конфиг Prometheus, давайте проверим что все работает правильно. Вернитесь на первый сервер и используйте  curl . сделать запрос на второй сервер:
 curl https://:9100/metrics -k -u 'пром:пром'
 
 Скопировано!
, где    — это IP-адрес вашего второго сервера.
 Вы увидите примерно такой вывод:
 Выход
 # ПОМОЩЬ go_gc_duration_seconds Сводка продолжительности паузы циклов сборки мусора.
# TYPE сводка go_gc_duration_seconds
go_gc_duration_seconds{quantile="0"} 0
go_gc_duration_seconds{quantile="0,25"} 0
go_gc_duration_seconds{quantile="0,5"} 0
go_gc_duration_seconds{quantile="0,75"} 0
go_gc_duration_seconds{quantile="1"} 0
go_gc_duration_seconds_sum 0
go_gc_duration_seconds_count 0
# ПОМОЩЬ go_goroutines Количество существующих на данный момент горутин. 
# TYPE датчик go_goroutines
go_goroutines 8
. . .
 
 Если вы не получаете аналогичный вывод, убедитесь, что брандмауэр не блокирует подключений, а также проверьте правильность предоставленных имени пользователя и пароля.
 Шаг 8 — Настройка Prometheus для очистки узлов экспортера 
 На этом шаге мы обновим настройки Prometheus, чтобы иметь возможность собирать метрики из Node Exporter. Оставаясь на первом сервере, откройте Прометей файл конфигурации:
 sudo nano /etc/prometheus/prometheus.yml
 
 Скопировано!
 Добавьте следующие строки в конец файла под  scrape_configs  :
 /etc/prometheus/prometheus.yml
 . . .
scrape_configs:
  # Имя задания добавляется в виде метки `job=` ко всем временным рядам, извлеченным из этой конфигурации.
  - job_name: "прометей"
    # metrics_path по умолчанию "/metrics"
    # схема по умолчанию 'http'.
    статические_конфигурации:
      - цели: ["localhost:9090"]
  - job_name: 'node_exporter_client' 
  scrape_interval: 5s 
  Схема: https 
  TLS_CONFIG: 
  CA_FILE: /etc/prometheus/node_exporter. crt 
  Basic_auth: 
  username: PROM 
 : PROM 
  stative_con_con_con_con_con_con_con_con_con_con_con: 
 . 9100'] 
 
 Скопировано!
 Заполнитель    должен быть заменен IP-адресом вашего второго сервера. Сохраните файл и перезапустите сервер Prometheus:
 sudo systemctl reboot prometheus
 
 Скопировано!
 Прометей теперь работает и собирает информацию не только о себе, но и также с указанного удаленного сервера.
 Шаг 9 — Защита и работа с веб-интерфейсом Prometheus 
 Prometheus не имеет встроенной аутентификации или авторизации возможности, поэтому для предотвращения несанкционированного доступа к данным в Prometheus мы будем использовать NGINX в качестве прокси. Убедитесь, что он установлен на вашем первом сервере:
 sudo apt install nginx
 
 Скопировано!
 Если вы используете брандмауэр, вы также должны разрешить подключения из NGINX:
 sudo ufw разрешить 'Nginx HTTP'
 
 Скопировано!
 Теперь с помощью утилиты  htpasswd  создадим файл паролей. В этом случае мы будем используйте имя пользователя  promadmin  для доступа к веб-интерфейсу.
 sudo htpasswd -c /etc/nginx/.htpasswd promadmin
 
 Скопировано!
 Далее необходимо настроить NGINX. Для нашего урока мы будем использовать  по умолчанию  конфигурационный файл. Откройте его для редактирования:
 sudo nano /etc/nginx/sites-enabled/default
 
 Скопировано!
 Найдите блок  location/ под блоком  server . Это должно выглядеть так:
 /etc/nginx/sites-enabled/default
 . . .
        расположение / {
                # Сначала пытаемся обслужить запрос как файл, затем
                # в качестве каталога, затем вернуться к отображению 404.
                try_files $uri $uri/ =404;
        }
. . .
 
 Скопировано!
 Замените этот блок следующим содержимым:
 /etc/nginx/sites-enabled/default
 . . .
        расположение / {
          прокси_пароль http://localhost:9090/;
          auth_basic "Прометей";
          auth_basic_user_file "/etc/nginx/. htpasswd";
        }
. . .
 
 Скопировано!
 Сохраните и закройте файл, затем проверьте конфигурацию NGINX:
 sudo nginx -t
 
 Скопировано!
 Вывод должен показать, что синтаксис в порядке и тест прошел успешно:
 Выход
 nginx: синтаксис файла конфигурации /etc/nginx/nginx.conf в порядке
nginx: проверка файла конфигурации /etc/nginx/nginx.conf прошла успешно
 
 После этого перезагрузите службу NGINX:
 sudo systemctl перезагрузить nginx
 
 Скопировано!
 Откройте веб-браузер и перейдите по адресу  http://  . в В диалоговом окне HTTP-аутентификации введите имя пользователя и пароль, которые вы выбрали. ранее на этом шаге. После успешного входа вы увидите Prometheus Пользовательский интерфейс:
 Вы можете проверить статус Node Explorer, щелкнув меню  Статус  в вверху, а затем в пункте меню  Targets .
 Как видите, все конечные точки активны и ошибок нет. Если какая-либо ошибка происходит, его описание будет отображаться в столбце  Ошибка .
 Заключение 
 Из этого туториала вы узнали, как установить и настроить сервер Prometheus и экспортер узлов. Мы также обсудили создание безопасных соединений между этими два компонента, чтобы гарантировать, что никакая информация не просочится во внешний мир.
 Вы можете использовать накопленные метрики для анализа производительности ваших серверов, но может быть лучше использовать платформу для наблюдения, например Графана для этого. В следующем уроке мы описать, как настроить Grafana и как настроить ее для запросов и мониторинга Данные Прометея.
 Спасибо за внимание!
 Журналы рассказывают истории. 

 Прочтите их. Опыт работы с SQL-совместимостью 
 управление структурированным журналом.
 Исследование журнала →
 Соберите все журналы в одном месте.

Автоматический котел ПРОМЕТЕЙ™ 40 — Прометей™

Автоматические котлы «Прометей-Автомат»

Автоматический котел ПРОМЕТЕЙ™ 40 Автоматический котел ПРОМЕТЕЙ™ 40

Автоматический котел ПРОМЕТЕЙ™ 80 Автоматический котел ПРОМЕТЕЙ™ 80

Автоматический котел ПРОМЕТЕЙ™ 140М Автоматический котел ПРОМЕТЕЙ™ 140М

Автоматический котел ПРОМЕТЕЙ™ 200М Автоматический котел ПРОМЕТЕЙ™ 200М

Автоматический котел ПРОМЕТЕЙ™ 300М Автоматический котел ПРОМЕТЕЙ™ 300М

Автоматический котел ПРОМЕТЕЙ™ 400М Автоматический котел ПРОМЕТЕЙ™ 400М

Автоматический котел ПРОМЕТЕЙ™ 600М Автоматический котел ПРОМЕТЕЙ™ 600М

Автоматический котел ПРОМЕТЕЙ™ 800М Автоматический котел ПРОМЕТЕЙ™ 800М

Автоматический котел ПРОМЕТЕЙ™ 1000М Автоматический котел ПРОМЕТЕЙ™ 1000М

Автоматический котел ПРОМЕТЕЙ™ 1500М Автоматический котел ПРОМЕТЕЙ™ 1500М

СанТехРесурс

Понимание и использование шаблона многоцелевого экспортера

Шаблон многоцелевого экспортера?

Запуск многоцелевых экспортеров

Основные запросы многоцелевых экспортеров

Настройка модулей

Запрос многоцелевых экспортеров с помощью Prometheus

Блог | Прометей

История варианта использования переадресации

Удаленная запись

Практический пример удаленной записи: учебное пособие по Katacoda

Режим агента Прометея

Мечта: Автоматически масштабируемый прием метрик

Режим агента был проверен в масштабе

Подробное описание использования режима агента

Практический пример агента Prometheus: руководство по Katacoda

Резюме

новых категорий

Призыв к действию

Зарегистрироваться для тестирования

Полная совместимость с Prometheus

проектов

Прохождение

Не проходит

ААС

Прохождение

Не проходит

Агент/Коллекционер

Прохождение

Не проходит

удаленных API

Удаленная запись

Удаленное чтение

Решение

эталонов

Память

Без потоковой передачи

С потоковой передачей

процессор

Без потоковой передачи

С потоковой передачей

Задержка

Совместимость

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

Следующие шаги

Резюме

Расскажите о себе и о том, чем занимается ForgeRock?

Каков был ваш опыт мониторинга до Prometheus?

Почему ты решил посмотреть на Прометея?

Как вы перешли?

Какие улучшения вы заметили после перехода?

Как вы думаете, какое будущее ждет ForgeRock и Prometheus?

Можете ли вы рассказать нам о себе и о том, чем занимается Hostinger?

Каков был ваш опыт мониторинга до Prometheus?

Почему ты решил посмотреть на Прометея?

Как вы перешли?

Какие улучшения вы заметили после перехода?

Как вы думаете, какое будущее ждет Hostinger и Prometheus?

Введение

Мотивация

подзапросов

Примеры

Эпилог

Расскажите о себе и о том, чем занимается Presslabs?

Каков был ваш опыт мониторинга до Prometheus?

Почему ты решил посмотреть на Прометея?

Как вы перешли?

Какие улучшения вы заметили после перехода?