pushgateway
1.10.0
Prometheus Pushgateway существует для того, чтобы позволить эфемерным и пакетным заданиям предоставлять свои метрики Prometheus. Поскольку такого рода задания могут существовать недостаточно долго, чтобы их можно было очистить, вместо этого они могут передать свои показатели в Pushgateway. Затем Pushgateway предоставляет эти метрики Prometheus.
Прежде всего, Pushgateway не способен превратить Prometheus в систему мониторинга на основе push-уведомлений. Общее описание вариантов использования Pushgateway можно найти в разделе «Когда использовать Pushgateway».
Pushgateway явно не является агрегатором или распределенным счетчиком , а скорее кэшем метрик. Он не имеет семантики, подобной statsd. Загруженные метрики точно такие же, как и при парсинге в постоянно работающей программе. Если вам нужен распределенный подсчет, вы можете либо использовать сам statsd в сочетании с экспортером statsd Prometheus, либо взглянуть на prom-aggregation-gateway. Собрав больше опыта, проект Prometheus однажды сможет предоставить собственное решение, отдельное от Pushgateway или, возможно, даже как его часть.
Для показателей машинного уровня обычно более подходящим является сборщик текстовых файлов экспортера узлов. Pushgateway предназначен для показателей уровня обслуживания.
Pushgateway не является хранилищем событий . Хотя вы можете использовать Prometheus в качестве источника данных для аннотаций Grafana, отслеживание чего-то вроде событий выпуска должно происходить с помощью некоторой платформы регистрации событий.
Некоторое время назад мы решили не реализовывать «таймаут» или TTL для отправленных метрик, потому что почти все предложенные варианты использования оказались антишаблонами, которые мы настоятельно не одобряем. Вы можете следить за недавним обсуждением в списке рассылки prometheus-developers.
Загрузите бинарные версии для вашей платформы со страницы релизов и распакуйте архив.
Если вы хотите скомпилировать самостоятельно из исходников, вам понадобится работающая установка Go. Затем используйте предоставленный Makefile (введите make ).
Для самой простой настройки просто запустите двоичный файл. Чтобы изменить адрес для прослушивания, используйте флаг --web.listen-address (например, «0.0.0.0:9091» или «:9091»). По умолчанию Pushgateway не сохраняет метрики. Однако флаг --persistence.file позволяет указать файл, в котором будут сохраняться отправленные метрики (чтобы они выдерживали перезапуск Pushgateway).
Вы можете развернуть Pushgateway, используя образ Docker prom/pushgateway.
Например:
docker pull prom/pushgateway
docker run -d -p 9091:9091 prom/pushgateway Pushgateway должен быть настроен как цель для парсинга Prometheus, используя один из обычных методов. Однако вы всегда должны устанавливать honor_labels: true в конфигурации очистки (подробное объяснение см. ниже).
Клиентские библиотеки Prometheus должны иметь функцию отправки зарегистрированных метрик в Pushgateway. Обычно клиент Prometheus пассивно предоставляет метрику для очистки сервером Prometheus. Клиентская библиотека, поддерживающая отправку, имеет функцию push, которую необходимо вызывать из клиентского кода. Затем он будет активно передавать метрики в Pushgateway, используя API, описанный ниже.
Используя текстовый протокол Prometheus, передача метрик настолько проста, что отдельный интерфейс командной строки не предоставляется. Просто используйте HTTP-инструмент командной строки, например curl . Ваш любимый язык сценариев, скорее всего, имеет некоторые встроенные возможности HTTP, которые вы также можете использовать здесь.
Обратите внимание, что в текстовом протоколе каждая строка должна заканчиваться символом перевода строки (он же «LF» или «n»). Завершение строки другими способами, например, с помощью «CR», иначе «r», «CRLF», иначе «rn», или просто конца пакета, приведет к ошибке протокола.
Передаваемые метрики управляются группами, определяемыми ключом группировки любого количества меток, первой из которых должна быть метка job . Группы легко проверить через веб-интерфейс.
Значение специальных символов в значениях меток см. в разделе URL-адресов ниже.
Примеры:
Отправьте один образец в группу, определенную {job="some_job"} :
echo "some_metric 3.14" | curl --data-binary @- http://pushgateway.example.org:9091/metrics/job/some_job
Поскольку информация о типе не предоставлена, some_metric будет иметь тип untyped .
Добавьте что-нибудь более сложное в группу, идентифицированную {job="some_job",instance="some_instance"} :
cat <Обратите внимание, как предоставляется информация о типе и строки справки. Эти строки не являются обязательными, но настоятельно рекомендуется использовать их в случае чего-либо более сложного.
Удалите все метрики в группе, указанной {job="some_job",instance="some_instance"} :
curl -X DELETE http://pushgateway.example.org:9091/metrics/job/some_job/instance/some_instance
Удалите все метрики в группе, указанной {job="some_job"} (обратите внимание, что это не включает метрики в группе {job="some_job",instance="some_instance"} из предыдущего примера, даже если эти метрики имеют та же должность):
curl -X DELETE http://pushgateway.example.org:9091/metrics/job/some_job
Удалить все метрики во всех группах (требуется включить API администратора с помощью флага командной строки --web.enable-admin-api ):
curl -X PUT http://pushgateway.example.org:9091/api/v1/admin/wipe
Сервер Prometheus прикрепит метку job и метку instance к каждой очищенной метрике. Значение метки job берется из конфигурации очистки. Когда вы настраиваете Pushgateway в качестве цели очистки для вашего сервера Prometheus, вы, вероятно, выберете имя задания, например pushgateway . Значение метки instance автоматически устанавливается на хост и порт очищаемой цели. Следовательно, все метрики, полученные из Pushgateway, будут иметь хост и порт Pushgateway в качестве метки instance и метку job , например pushgateway . Конфликт с метками job и instance которые вы могли прикрепить к метрикам, отправленным в Pushgateway, решается путем переименования этих меток в exported_job и exported_instance .
Однако такое поведение обычно нежелательно при очистке Pushgateway. Как правило, вы хотели бы сохранить метки job и instance метрик, передаваемых в Pushgateway. Вот почему вам необходимо установить honor_labels: true в конфигурации очистки для Pushgateway. Это обеспечивает желаемое поведение. Подробности смотрите в документации.
Это оставляет нам случай, когда метрики, передаваемые в Pushgateway, не имеют метки instance . Этот случай довольно распространен, поскольку передаваемые метрики часто находятся на уровне обслуживания и, следовательно, не связаны с конкретным экземпляром. Даже при использовании honor_labels: true сервер Prometheus прикрепит метку instance , если метка instance не была установлена изначально. Таким образом, если метрика передается в Pushgateway без метки экземпляра (и без метки экземпляра в ключе группировки, см. ниже), Pushgateway экспортирует ее с пустой меткой экземпляра ( {instance=""} ), что эквивалентно отсутствие метки instance вообще, но не позволяет серверу прикрепить ее.
Pushgateway предоставляет все отправленные метрики вместе со своими собственными метриками через одну и ту же конечную точку /metrics . (Подробную информацию см. в разделе об открытых метриках.) Таким образом, все метрики должны быть согласованы друг с другом: метрики с одинаковыми именами должны иметь один и тот же тип, даже если они помещены в разные группы, и не должно быть дубликатов. , т. е. метрики с одинаковыми именами и одинаковыми парами меток. Нажатия, которые могут привести к несоответствиям, отклоняются с кодом состояния 400.
Однако непоследовательные справочные строки допускаются. Pushgateway выберет выигрышную строку справки и зарегистрирует ее на информационном уровне.
Устаревшее примечание: строка справки собственной метрики push_time_seconds Pushgateway изменилась в версии 0.10.0. Используя файл персистентности, метрики, отправленные в Pushgateway более ранней версии, могут превратиться в Pushgateway версии 0.10.0 или более поздней. В этом случае появится вышеупомянутое сообщение журнала. Как только каждая ранее отправленная группа будет удалена или получит новую отправку, сообщение журнала исчезнет.
Проверка целостности, выполняемая во время отправки, такая же, как и во время очистки. В обычных случаях царапины случаются чаще, чем толчки. Таким образом, стоимость производительности проверки времени отправки не имеет значения. Однако если большое количество метрик на Pushgateway сочетается с частыми push-уведомлениями, продолжительность push-уведомлений может стать непомерно большой. В этом случае вы можете рассмотреть возможность использования флага командной строки --push.disable-consistency-check , который экономит затраты на проверку согласованности во время отправки, но позволяет отправлять противоречивые метрики. Проверка по-прежнему будет выполняться во время очистки, что приводит к сбою всех операций очистки до тех пор, пока противоречивые метрики хранятся на Pushgateway. Таким образом, установка флага подвергает вас риску отключить Pushgateway одним несогласованным нажатием.
Если вы отправите метрики в момент времени t 1 , у вас может возникнуть соблазн поверить, что Prometheus очистит их с той же меткой времени t 1 . Вместо этого Прометей прикрепляет в качестве временной метки время, когда он очищает Пушгейт. Почему так?
В мировоззрении Prometheus метрику можно очистить в любой момент. Метрика, которую невозможно очистить, фактически перестала существовать. Prometheus в некоторой степени терпим, но если он не может получить образцы для метрики за 5 минут, он будет вести себя так, как будто этой метрики больше не существует. Предотвращение этого на самом деле является одной из причин использования Pushgateway. Pushgateway сделает показатели вашей эфемерной работы доступными в любое время. Прикрепление времени отправки в качестве временной метки противоречит этой цели, потому что через 5 минут после последней отправки ваша метрика будет выглядеть для Prometheus такой устаревшей, как если бы ее вообще невозможно было очистить. (Prometheus знает только одну временную метку для каждой выборки, поэтому невозможно отличить «время нажатия» и «время очистки».)
Поскольку не существует случаев использования, когда имело бы смысл прикреплять другую метку времени, и многие пользователи пытаются сделать это неправильно (несмотря на то, что клиентская библиотека не поддерживает это), Pushgateway отклоняет любые push-уведомления с метками времени.
Если вы считаете, что вам нужно отправить метку времени, см. раздел «Когда использовать Pushgateway».
Чтобы упростить оповещение о неудачных или не запущенных в последнее время пушах, Pushgateway добавит метрики push_time_seconds и push_failure_time_seconds с меткой времени Unix последнего успешного и неудачного POST / PUT в каждую группу. Это переопределит любую отправленную метрику с таким именем. Нулевое значение любой метрики означает, что группа никогда не видела успешных или неудачных POST / PUT .
Все push-уведомления выполняются через HTTP. Интерфейс отдаленно похож на REST.
Порт по умолчанию, который прослушивает Pushgateway, — 9091. Путь выглядит так:
/metrics/job/{//}
job , за которым следует любое количество других пар меток (которые могут включать или не включать метку instance ). Набор меток, определенный путем URL-адреса, используется в качестве ключа группировки. Любая из этих меток, уже установленных в теле запроса (как обычные метки, например, name{job="foo"} 42 ), будет перезаписана, чтобы соответствовать меткам, определенным путем URL-адреса!
Если имя job или любой метки имеет суффикс @base64 , следующее имя задания или значение метки интерпретируется как строка в кодировке Base64 в соответствии с RFC 4648 с использованием безопасного алфавита URL-адреса и имени файла. (Заполнение не является обязательным, но для кодирования пустого значения метки требуется один знак = .) Это единственный способ обработки следующих случаев:
/ , поскольку простой / (или даже закодированный в URI) / в противном случае интерпретировался бы как разделитель пути.// или конечный / исчезнет, когда путь будет очищен кодом HTTP-маршрутизатора. Обратите внимание, что пустое имя job является недопустимым. Значения пустых меток допустимы, но редко полезны. Чтобы закодировать их с помощью base64, вам необходимо использовать хотя бы один символ заполнения = , чтобы избежать // или завершающего символа / .Для других специальных символов также работает обычная кодировка компонента URI, но base64 может быть более удобным.
В идеале клиентские библиотеки заботятся о суффиксах и кодировании.
Примеры:
Чтобы использовать ключ группировки job="directory_cleaner",path="/var/tmp" , следующий путь не будет работать:
/metrics/job/directory_cleaner/path//var/tmp
Вместо этого используйте URL-безопасную кодировку Base64 для значения метки и отметьте ее, добавив к имени метки суффикс @base64 :
/metrics/job/directory_cleaner/path@base64/L3Zhci90bXA
Если вы не используете клиентскую библиотеку, которая выполняет кодирование за вас, вы можете использовать инструменты кодирования. Например, существует инструмент командной строки base64url (пакет Debian basez ), который вы можете объединить с curl для отправки из командной строки следующим образом:
echo 'some_metric{foo="bar"} 3.14' | curl --data-binary @- http://pushgateway.example.org:9091/metrics/job/directory_cleaner/path@base64/$(echo -n '/var/tmp' | base64url)
Чтобы использовать ключ группировки, содержащий пустое значение метки, например job="example",first_label="",second_label="foobar" , следующий путь не будет работать:
/metrics/job/example/first_label//second_label/foobar
Вместо этого используйте следующий путь, включая символ заполнения = :
/metrics/job/example/first_label@base64/=/second_label/foobar
Ключ группировки job="titan",name="Προμηθεύς" может быть представлен «традиционно» с помощью кодировки URI:
/metrics/job/titan/name/%CE%A0%CF%81%CE%BF%CE%BC%CE%B7%CE%B8%CE%B5%CF%8D%CF%82
Или вы можете использовать более компактную кодировку Base64:
/metrics/job/titan/name@base64/zqDPgc6_zrzOt864zrXPjc-C
Более новые версии форматов представления Prometheus (текст и protobuf) поддерживают полный набор символов UTF-8 в именах метрик и меток. Pushgateway принимает специальные символы в именах только в том случае, если установлен флаг командной строки --push.enable-utf8-names . Чтобы разрешить использование специальных символов в именах меток, которые являются частью URL-пути, этот флаг также включает специальный механизм кодирования. Это похоже на кодировку base64 для значений меток, описанную выше, но в деталях работает иначе по техническим и историческим причинам. Как и раньше, клиентские библиотеки обычно должны заботиться о кодировании. Это работает следующим образом:
U__ ._1F60A_ .__ .U__ , эти символы также необходимо закодировать, в результате чего получится U___55_____ . (Это U__ + _55_ (для U ) + __ + __ ).U__ в закодированной форме, но содержащее недопустимые последовательности (например, U__in_xxx_valid ), остается неизменным. Например, метка "foo.bar"="baz" будет закодирована следующим образом:
/metrics/job/example/U__foo_2e_bar/baz
Эта кодировка совместима с кодировкой base64 для значений меток:
/metrics/job/example/U__foo_2e_bar@base64/YmF6
Обратите внимание, что этот метод имеет маловероятный крайний случай, который не обрабатывается должным образом: толкатель, не знающий о механизме кодирования, может использовать имя метки, которое также является допустимой закодированной версией другого имени метки. Например, если отправитель намеревается использовать имя метки U__foo_2e_bar , но не кодирует его как U___55_____foo__2e__bar , Pushgateway декодирует U__foo_2e_bar в foo.bar . Это основная причина, по которой декодирование включается с помощью флага --push.enable-utf8-names .
PUT метод PUT используется для отправки группы метрик. Все метрики с ключом группировки, указанным в URL-адресе, заменяются метриками, отправленными с помощью PUT .
Тело запроса содержит метрики, которые необходимо отправить либо в виде буферов двоичного протокола с разделителями, либо в простом текстовом формате (оба в версии 0.0.4, см. спецификацию формата представления данных). Различение между двумя вариантами осуществляется через заголовок Content-Type . (Используйте значение application/vnd.google.protobuf; proto=io.prometheus.client.MetricFamily; encoding=delimited для буферов протокола, в противном случае текстовый формат будет использоваться как запасной вариант.)
Код ответа в случае успеха — 200, 202 или 400. Ответ 200 означает успешную отправку, либо замену существующей группы метрик, либо создание новой. Ответ 400 может произойти, если запрос имеет неверный формат или если отправленные метрики несовместимы с метриками, отправленными в другие группы, или конфликтуют с метриками самого Pushgateway. Объяснение возвращается в теле ответа и регистрируется на уровне ошибки. Ошибка 202 может возникнуть только в том случае, если установлен флаг --push.disable-consistency-check . В этом случае отправленные метрики просто ставятся в очередь и не проверяются на согласованность. Однако несоответствия приведут к неудачным очисткам, как описано выше.
В редких случаях возможно, что в Pushgateway уже отправлен противоречивый набор метрик. В этом случае новые отправки также отклоняются как несогласованные, даже если виновниками являются метрики, которые были отправлены ранее. Удалите нарушающие метрики, чтобы выйти из этой ситуации.
При использовании формата protobuf не отправляйте дубликаты прото-сообщений MetricFamily (т. е. более одного с одинаковым именем) за один раз, так как они перезапишут друг друга.
Обратите внимание, что Pushgateway не предоставляет каких-либо надежных гарантий того, что отправленные метрики сохраняются на диске. (Сбой сервера может привести к потере данных. Или Pushgateway настроен так, чтобы вообще не сохраняться на диске.)
Запрос PUT с пустым телом эффективно удаляет все метрики с указанным ключом группировки. Однако, в отличие от запроса DELETE , описанного ниже, он обновляет метрику push_time_seconds .
POST метод POST работает точно так же, как метод PUT , но заменяются только метрики с тем же именем, что и у вновь отправленных метрик (среди тех, которые имеют тот же ключ группировки).
Запрос POST с пустым телом просто обновляет метрики push_time_seconds , но не меняет ни одну из ранее отправленных метрик.
DELETE метод DELETE используется для удаления метрик из Pushgateway. Запрос не должен содержать никакого контента. Все метрики, ключ группировки которых указан в URL-адресе, удаляются.
Код ответа в случае успеха всегда равен 202. В этот момент запрос на удаление просто ставится в очередь. Нет никакой гарантии, что запрос действительно будет выполнен или что результат попадет на уровень персистентности (например, в случае сбоя сервера). Однако порядок запросов PUT / POST и DELETE гарантирован, т.е. если вы успешно отправили запрос DELETE , а затем отправили PUT , то гарантированно, что DELETE будет обработан первым (и наоборот).
Удаление ключа группировки без метрик не является операцией и не приведет к ошибке.
Тело запроса POST или PUT может быть сжато с помощью gzip или snappy. Для этого добавьте заголовок Content-Encoding: gzip или Content-Encoding: snappy .
Примеры:
echo " some_metric 3.14 " | gzip | curl -H ' Content-Encoding: gzip ' --data-binary @- http://pushgateway.example.org:9091/metrics/job/some_job
echo " some_metric 3.14 " | snzip | curl -H ' Content-Encoding: snappy ' --data-binary @- http://pushgateway.example.org:9091/metrics/job/some_job API администратора обеспечивает административный доступ к Pushgateway и должен быть явно включен путем установки флага --web.enable-admin-api .
Порт по умолчанию, который прослушивает Pushgateway, — 9091. Путь выглядит следующим образом:
/api//admin/
| HTTP_METHOD | API_VERSION | ХАНДЛЕР | ОПИСАНИЕ |
|---|---|---|---|
| ПОМЕЩАТЬ | v1 | вытирать | Безопасно удаляет все метрики из Pushgateway. |
Например, чтобы стереть все метрики с Pushgateway:
curl -X PUT http://pushgateway.example.org:9091/api/v1/admin/wipe
API запросов позволяет получить доступ к отправленным метрикам, а также информации о сборке и времени выполнения.
/api//
| HTTP_METHOD | API_VERSION | ХАНДЛЕР | ОПИСАНИЕ |
|---|---|---|---|
| ПОЛУЧАТЬ | v1 | статус | Возвращает информацию о сборке, флаги командной строки и время начала в формате JSON. |
| ПОЛУЧАТЬ | v1 | метрики | Возвращает отправленные семейства метрик в формате JSON. |
Например :
curl -X GET http://pushgateway.example.org:9091/api/v1/status | jq
{
"status": "success",
"data": {
"build_information": {
"branch": "master",
"buildDate": "20200310-20:14:39",
"buildUser": "[email protected]",
"goVersion": "go1.13.6",
"revision": "eba0ec4100873d23666bcf4b8b1d44617d6430c4",
"version": "1.1.0"
},
"flags": {
"log.format": "logfmt",
"log.level": "info",
"persistence.file": "",
"persistence.interval": "5m0s",
"push.disable-consistency-check": "false",
"web.enable-admin-api": "false",
"web.enable-lifecycle": "false",
"web.external-url": "",
"web.listen-address": ":9091",
"web.route-prefix": "",
"web.telemetry-path": "/metrics"
},
"start_time": "2020-03-11T01:44:49.9189758+05:30"
}
}
curl -X GET http://pushgateway.example.org:9091/api/v1/metrics | jq
{
"status": "success",
"data": [
{
"labels": {
"job": "batch"
},
"last_push_successful": true,
"my_job_duration_seconds": {
"time_stamp": "2020-03-11T02:02:27.716605811+05:30",
"type": "GAUGE",
"help": "Duration of my batch job in seconds",
"metrics": [
{
"labels": {
"instance": "",
"job": "batch"
},
"value": "0.2721322309989773"
}
]
},
"push_failure_time_seconds": {
"time_stamp": "2020-03-11T02:02:27.716605811+05:30",
"type": "GAUGE",
"help": "Last Unix time when changing this group in the Pushgateway failed.",
"metrics": [
{
"labels": {
"instance": "",
"job": "batch"
},
"value": "0"
}
]
},
"push_time_seconds": {
"time_stamp": "2020-03-11T02:02:27.716605811+05:30",
"type": "GAUGE",
"help": "Last Unix time when changing this group in the Pushgateway succeeded.",
"metrics": [
{
"labels": {
"instance": "",
"job": "batch"
},
"value": "1.5838723477166057e+09"
}
]
}
}
]
}
Pushgateway предоставляет набор API управления для упрощения автоматизации и интеграции.
| HTTP_METHOD | ПУТЬ | ОПИСАНИЕ |
|---|---|---|
| ПОЛУЧАТЬ | /-/здоровый | Возвращает 200, когда Pushgateway исправен. |
| ПОЛУЧАТЬ | /-/готовый | Возвращает 200 всякий раз, когда Pushgateway готов обслуживать трафик. |
--web.enable-lifecycle .| HTTP_METHOD | ПУТЬ | ОПИСАНИЕ |
|---|---|---|
| ПОМЕЩАТЬ | /-/покидать | Запускает корректное завершение работы Pushgateway. |
Альтернативно, плавное завершение работы можно запустить, отправив SIGTERM процессу Pushgateway.
Pushgateway предоставляет следующие метрики через настроенный --web.telemetry-path (по умолчанию: /metrics ):
push_time_seconds и push_failure_time_seconds , как описано выше.process_...go_...promhttp_metric_handler_requests_... # HELP pushgateway_build_info A metric with a constant '1' value labeled by version, revision, branch, and goversion from which pushgateway was built.
# TYPE pushgateway_build_info gauge
pushgateway_build_info{branch="master",goversion="go1.10.2",revision="8f88ccb0343fc3382f6b93a9d258797dcb15f770",version="0.5.2"} 1
# HELP pushgateway_http_push_duration_seconds HTTP request duration for pushes to the Pushgateway.
# TYPE pushgateway_http_push_duration_seconds summary
pushgateway_http_push_duration_seconds{method="post",quantile="0.1"} 0.000116755
pushgateway_http_push_duration_seconds{method="post",quantile="0.5"} 0.000192608
pushgateway_http_push_duration_seconds{method="post",quantile="0.9"} 0.000327593
pushgateway_http_push_duration_seconds_sum{method="post"} 0.001622878
pushgateway_http_push_duration_seconds_count{method="post"} 8
# HELP pushgateway_http_push_size_bytes HTTP request size for pushes to the Pushgateway.
# TYPE pushgateway_http_push_size_bytes summary
pushgateway_http_push_size_bytes{method="post",quantile="0.1"} 166
pushgateway_http_push_size_bytes{method="post",quantile="0.5"} 182
pushgateway_http_push_size_bytes{method="post",quantile="0.9"} 196
pushgateway_http_push_size_bytes_sum{method="post"} 1450
pushgateway_http_push_size_bytes_count{method="post"} 8
# HELP pushgateway_http_requests_total Total HTTP requests processed by the Pushgateway, excluding scrapes.
# TYPE pushgateway_http_requests_total counter
pushgateway_http_requests_total{code="200",handler="static",method="get"} 5
pushgateway_http_requests_total{code="200",handler="status",method="get"} 8
pushgateway_http_requests_total{code="202",handler="delete",method="delete"} 1
pushgateway_http_requests_total{code="202",handler="push",method="post"} 6
pushgateway_http_requests_total{code="400",handler="push",method="post"} 2
В общем, хорошей идеей является оповещение о том, что push_time_seconds отстают намного дальше, чем ожидалось. Это позволит обнаружить как неудачные пуши, так и полностью опущенные толкатели.
Чтобы обнаружить неудачные отправки гораздо раньше, предупреждайте о push_failure_time_seconds > push_time_seconds .
Push также может потерпеть неудачу, потому что они неправильно сформированы. В этом случае они никогда не достигают какой-либо группы метрик и, следовательно, не будут устанавливать никакие метрики push_failure_time_seconds . Эти push-уведомления по-прежнему учитываются как pushgateway_http_requests_total{code="400",handler="push"} . Вы можете предупредить о rate этого показателя, но вам придется просмотреть журналы, чтобы определить нарушителя.
Pushgateway поддерживает TLS и базовую аутентификацию. Это обеспечивает лучший контроль над различными конечными точками HTTP.
Чтобы использовать TLS и/или базовую аутентификацию, вам необходимо передать файл конфигурации с помощью параметра --web.config.file . Формат файла описан в репозитории экспортера-инструментария.
Обратите внимание, что настройки TLS и базовой аутентификации влияют на все конечные точки HTTP: /metrics для очистки, API для отправки метрик через /metrics/..., API администратора через /api/... и веб-интерфейс.
Обычный двоичный файл встраивает веб-файлы в каталог resources . В целях разработки удобно, чтобы работающий двоичный файл использовал эти файлы напрямую (чтобы вы могли сразу увидеть эффект изменений). Чтобы переключиться на прямое использование, добавьте -tags dev к записи flags в .promu.yml , а затем make build . Вернитесь в «обычный» режим, вернув изменения в .promu.yml и набрав make assets .
Соответствующие рекомендации по стилю — это комментарии к обзору кода Go и раздел «Форматирование и стиль» книги Питера Бургона Go: Best Practices for Production Environments.
