pushgateway
1.10.0
O Prometheus Pushgateway existe para permitir que trabalhos efêmeros e em lote exponham suas métricas ao Prometheus. Como esses tipos de trabalhos podem não existir por tempo suficiente para serem eliminados, eles podem, em vez disso, enviar suas métricas para um Pushgateway. O Pushgateway então expõe essas métricas ao Prometheus.
Em primeiro lugar, o Pushgateway não é capaz de transformar o Prometheus em um sistema de monitoramento baseado em push. Para obter uma descrição geral dos casos de uso do Pushgateway, leia Quando usar o Pushgateway.
O Pushgateway não é explicitamente um agregador ou contador distribuído , mas sim um cache de métricas. Não possui semântica semelhante ao statsd. As métricas enviadas são exatamente as mesmas que você apresentaria para raspagem em um programa em execução permanente. Se precisar de contagem distribuída, você pode usar o statsd real em combinação com o exportador statsd do Prometheus ou dar uma olhada no gateway de agregação de baile. Com mais experiência acumulada, o projeto Prometheus poderá um dia ser capaz de fornecer uma solução nativa, separada ou possivelmente até mesmo como parte do Pushgateway.
Para métricas em nível de máquina, o coletor de arquivo de texto do exportador Node geralmente é mais apropriado. O Pushgateway destina-se a métricas de nível de serviço.
O Pushgateway não é um armazenamento de eventos . Embora você possa usar o Prometheus como fonte de dados para anotações do Grafana, o rastreamento de algo como eventos de lançamento deve acontecer com alguma estrutura de registro de eventos.
Há algum tempo, decidimos não implementar um “tempo limite” ou TTL para métricas enviadas porque quase todos os casos de uso propostos revelaram-se antipadrões que desencorajamos fortemente. Você pode acompanhar uma discussão mais recente na lista de discussão prometheus-developers.
Baixe versões binárias para sua plataforma na página de lançamento e descompacte o tarball.
Se quiser compilar-se a partir dos fontes, você precisa de uma configuração Go funcional. Em seguida, use o Makefile fornecido (tipo make ).
Para a configuração mais básica, basta iniciar o binário. Para alterar o endereço de escuta, use o sinalizador --web.listen-address (por exemplo, "0.0.0.0:9091" ou ":9091"). Por padrão, o Pushgateway não persiste métricas. No entanto, o sinalizador --persistence.file permite especificar um arquivo no qual as métricas enviadas serão persistidas (para que sobrevivam às reinicializações do Pushgateway).
Você pode implantar o Pushgateway usando a imagem do Docker prom/pushgateway.
Por exemplo:
docker pull prom/pushgateway
docker run -d -p 9091:9091 prom/pushgateway O Pushgateway deve ser configurado como um alvo para ser raspado pelo Prometheus, usando um dos métodos usuais. No entanto, você deve sempre definir honor_labels: true na configuração do scrape (veja abaixo para uma explicação detalhada).
As bibliotecas cliente Prometheus devem ter um recurso para enviar as métricas registradas para um Pushgateway. Normalmente, um cliente Prometheus apresenta passivamente métricas para raspagem por um servidor Prometheus. Uma biblioteca cliente que suporta push possui uma função push, que precisa ser chamada pelo código do cliente. Em seguida, ele enviará ativamente as métricas para um Pushgateway, usando a API descrita abaixo.
Usando o protocolo de texto Prometheus, enviar métricas é tão fácil que nenhuma CLI separada é fornecida. Basta usar uma ferramenta HTTP de linha de comando como curl . Sua linguagem de script favorita provavelmente possui alguns recursos HTTP integrados que você também pode aproveitar aqui.
Observe que no protocolo de texto, cada linha deve terminar com um caractere de avanço de linha (também conhecido como 'LF' ou 'n'). Terminar uma linha de outras maneiras, por exemplo, com 'CR' também conhecido como 'r', 'CRLF' também conhecido como 'rn', ou apenas o final do pacote, resultará em um erro de protocolo.
As métricas enviadas são gerenciadas em grupos, identificados por uma chave de agrupamento de qualquer número de rótulos, dos quais o primeiro deve ser o rótulo job . Os grupos são fáceis de inspecionar por meio da interface web.
Para implicações de caracteres especiais em valores de rótulos, consulte a seção URL abaixo.
Exemplos:
Envie uma única amostra para o grupo identificado por {job="some_job"} :
echo "some_metric 3.14" | curl --data-binary @- http://pushgateway.example.org:9091/metrics/job/some_job
Como nenhuma informação de tipo foi fornecida, some_metric será do tipo untyped .
Coloque algo mais complexo no grupo identificado por {job="some_job",instance="some_instance"} :
cat <Observe como as informações de tipo e as sequências de ajuda são fornecidas. Essas linhas são opcionais, mas fortemente recomendadas para qualquer coisa mais complexa.
Exclua todas as métricas do grupo identificado por {job="some_job",instance="some_instance"} :
curl -X DELETE http://pushgateway.example.org:9091/metrics/job/some_job/instance/some_instance
Exclua todas as métricas do grupo identificado por {job="some_job"} (observe que isso não inclui métricas no grupo {job="some_job",instance="some_instance"} do exemplo anterior, mesmo que essas métricas tenham o mesmo rótulo de trabalho):
curl -X DELETE http://pushgateway.example.org:9091/metrics/job/some_job
Exclua todas as métricas em todos os grupos (requer ativar a API admin por meio do sinalizador de linha de comando --web.enable-admin-api ):
curl -X PUT http://pushgateway.example.org:9091/api/v1/admin/wipe
O servidor Prometheus anexará um rótulo job e um rótulo instance a cada métrica extraída. O valor do rótulo job vem da configuração do scrape. Ao configurar o Pushgateway como um destino de raspagem para seu servidor Prometheus, você provavelmente escolherá um nome de trabalho como pushgateway . O valor do rótulo instance é definido automaticamente para o host e a porta do destino copiado. Conseqüentemente, todas as métricas extraídas do Pushgateway terão o host e a porta do Pushgateway como rótulo instance e um rótulo job como pushgateway . O conflito com os rótulos job e instance que você pode ter anexado às métricas enviadas ao Pushgateway é resolvido renomeando esses rótulos para exported_job e exported_instance .
No entanto, esse comportamento geralmente é indesejado ao raspar um Pushgateway. Geralmente, você gostaria de manter os rótulos job e instance das métricas enviadas ao Pushgateway. É por isso que você deve definir honor_labels: true na configuração do scrape para o Pushgateway. Ele permite o comportamento desejado. Consulte a documentação para obter detalhes.
Isso nos deixa com o caso em que as métricas enviadas ao Pushgateway não apresentam um rótulo instance . Este caso é bastante comum, pois as métricas enviadas geralmente estão em um nível de serviço e, portanto, não estão relacionadas a uma instância específica. Mesmo com honor_labels: true , o servidor Prometheus anexará um rótulo instance se nenhum rótulo instance tiver sido definido em primeiro lugar. Portanto, se uma métrica for enviada para o Pushgateway sem um rótulo de instância (e sem rótulo de instância na chave de agrupamento, veja abaixo), o Pushgateway a exportará com um rótulo de instância vazio ( {instance=""} ), que é equivalente a não ter nenhum rótulo instance , mas impede que o servidor anexe um.
O Pushgateway expõe todas as métricas enviadas junto com suas próprias métricas por meio do mesmo endpoint /metrics . (Veja a seção sobre métricas expostas para detalhes.) Portanto, todas as métricas devem ser consistentes entre si: Métricas com o mesmo nome devem ter o mesmo tipo, mesmo que sejam enviadas para grupos diferentes, e não deve haver duplicatas , ou seja, métricas com o mesmo nome e exatamente os mesmos pares de rótulos. Pushes que levariam a inconsistências são rejeitados com o código de status 400.
No entanto, strings de ajuda inconsistentes são toleradas. O Pushgateway escolherá uma string de ajuda vencedora e registrará sobre ela no nível de informação.
Nota herdada: a string de ajuda da própria métrica push_time_seconds do Pushgateway foi alterada na v0.10.0. Ao usar um arquivo de persistência, as métricas enviadas para um Pushgateway de uma versão anterior podem transformá-lo em um Pushgateway v0.10.0 ou posterior. Neste caso, a mensagem de log mencionada acima aparecerá. Depois que cada grupo enviado anteriormente for excluído ou receber um novo push, a mensagem de log desaparecerá.
A verificação de consistência realizada durante um push é a mesma que acontece durante um scrape. Em casos de uso comuns, arranhões acontecem com mais frequência do que empurrões. Portanto, o custo de desempenho da verificação push-time não é relevante. No entanto, se uma grande quantidade de métricas no Pushgateway for combinada com pushes frequentes, a duração do push poderá se tornar proibitivamente longa. Nesse caso, você pode considerar usar o sinalizador de linha de comando --push.disable-consistency-check , que economiza o custo da verificação de consistência durante um push, mas permite enviar métricas inconsistentes. A verificação ainda acontecerá durante uma raspagem, falhando assim em todas as raspagens enquanto métricas inconsistentes forem armazenadas no Pushgateway. Definir o sinalizador, portanto, coloca você em risco de desabilitar o Pushgateway por meio de um único push inconsistente.
Se você enviar métricas no momento t 1 , poderá ficar tentado a acreditar que o Prometheus as eliminará com o mesmo carimbo de data / hora t 1 . Em vez disso, o que o Prometheus atribui como carimbo de data/hora é o momento em que ele raspa o Pushgateway. Por que isso?
Na visão de mundo do Prometheus, uma métrica pode ser eliminada a qualquer momento. Uma métrica que não pode ser eliminada basicamente deixou de existir. O Prometheus é um tanto tolerante, mas se não conseguir obter nenhuma amostra para uma métrica em 5 minutos, ele se comportará como se essa métrica não existisse mais. Evitar isso é, na verdade, um dos motivos para usar um Pushgateway. O Pushgateway tornará as métricas do seu trabalho efêmero descartáveis a qualquer momento. Anexar o tempo de push como um carimbo de data / hora anularia esse propósito porque 5 minutos após o último push, sua métrica parecerá tão obsoleta para o Prometheus como se não pudesse mais ser extraída. (O Prometheus conhece apenas um carimbo de data/hora por amostra, não há como distinguir um 'tempo de empurrar' e um 'tempo de raspagem'.)
Como não há casos de uso em que faria sentido anexar um carimbo de data/hora diferente, e muitos usuários tentam fazê-lo incorretamente (apesar de nenhuma biblioteca cliente suportar isso), o Pushgateway rejeita qualquer push com carimbo de data/hora.
Se você acha que precisa enviar um carimbo de data/hora, consulte Quando usar o Pushgateway.
Para facilitar o alerta sobre pushers com falha ou aqueles que não foram executados recentemente, o Pushgateway adicionará as métricas push_time_seconds e push_failure_time_seconds com o carimbo de data/hora Unix do último POST / PUT bem-sucedido e com falha em cada grupo. Isso substituirá qualquer métrica enviada por esse nome. Um valor zero para qualquer uma das métricas implica que o grupo nunca viu um POST / PUT bem-sucedido ou com falha.
Todos os push são feitos via HTTP. A interface é vagamente semelhante a REST.
A porta padrão que o Pushgateway está escutando é 9091. O caminho se parece com
/metrics/job/{//}
job , seguido por qualquer número de outros pares de rótulos (que podem ou não incluir um rótulo instance ). O conjunto de rótulos definido pelo caminho da URL é usado como chave de agrupamento. Qualquer um dos rótulos já definidos no corpo da solicitação (como rótulos regulares, por exemplo, name{job="foo"} 42 ) será substituído para corresponder aos rótulos definidos pelo caminho da URL!
Se o nome job ou de qualquer rótulo tiver o sufixo @base64 , o nome do trabalho ou valor do rótulo a seguir será interpretado como uma string codificada em base64 de acordo com RFC 4648, usando o URL e o alfabeto seguro do nome do arquivo. (O preenchimento é opcional, mas um único = é necessário para codificar um valor de rótulo vazio.) Esta é a única maneira de lidar com os seguintes casos:
/ , porque o / simples (ou mesmo codificado por URI) seria interpretado como um separador de caminho.// resultante ou / final desapareceria quando o caminho fosse limpo pelo código do roteador HTTP. Observe que um nome job vazio é inválido. Valores de rótulo vazios são válidos, mas raramente úteis. Para codificá-los com base64, você deve usar pelo menos um caractere de preenchimento = para evitar um // ou um / final.Para outros caracteres especiais, a codificação usual do componente URI também funciona, mas a base64 pode ser mais conveniente.
Idealmente, as bibliotecas clientes cuidam do sufixo e da codificação.
Exemplos:
Para usar a chave de agrupamento job="directory_cleaner",path="/var/tmp" , o seguinte caminho não funcionará:
/metrics/job/directory_cleaner/path//var/tmp
Em vez disso, use a codificação segura de URL base64 para o valor do rótulo e marque-o com o sufixo do nome do rótulo @base64 :
/metrics/job/directory_cleaner/path@base64/L3Zhci90bXA
Se você não estiver usando uma biblioteca cliente que lide com a codificação para você, poderá usar ferramentas de codificação. Por exemplo, existe uma ferramenta de linha de comando base64url (pacote Debian basez ), que você pode combinar com curl para enviar por push a partir da linha de comando da seguinte maneira:
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)
Para usar uma chave de agrupamento contendo um valor de rótulo vazio, como job="example",first_label="",second_label="foobar" , o seguinte caminho não funcionará:
/metrics/job/example/first_label//second_label/foobar
Em vez disso, use o seguinte caminho incluindo o caractere de preenchimento = :
/metrics/job/example/first_label@base64/=/second_label/foobar
A chave de agrupamento job="titan",name="Προμηθεύς" pode ser representada “tradicionalmente” com codificação URI:
/metrics/job/titan/name/%CE%A0%CF%81%CE%BF%CE%BC%CE%B7%CE%B8%CE%B5%CF%8D%CF%82
Ou você pode usar a codificação base64 mais compacta:
/metrics/job/titan/name@base64/zqDPgc6_zrzOt864zrXPjc-C
Versões mais recentes dos formatos de exposição do Prometheus (texto e protobuf) suportam o conjunto completo de caracteres UTF-8 em nomes de métricas e rótulos. O Pushgateway só aceita caracteres especiais em nomes se o sinalizador de linha de comando --push.enable-utf8-names estiver definido. Para permitir caracteres especiais em nomes de rótulos que fazem parte do caminho da URL, o sinalizador também habilita um mecanismo de codificação específico. Isto é semelhante à codificação base64 para valores de rótulo descrita acima, mas funciona de forma diferente em detalhes por razões técnicas e históricas. Como antes, as bibliotecas clientes geralmente devem cuidar da codificação. Funciona da seguinte maneira:
U__ ._1F60A_ .__ .U__ , esses caracteres também deverão ser codificados, resultando em U___55_____ . (Isso é U__ + _55_ (para U ) + __ + __ ).U__ em sua forma codificada, mas contendo sequências inválidas (por exemplo, U__in_xxx_valid ) permanece inalterado. Por exemplo, o rótulo "foo.bar"="baz" seria codificado como:
/metrics/job/example/U__foo_2e_bar/baz
Esta codificação é compatível com a codificação base64 para valores de rótulo:
/metrics/job/example/U__foo_2e_bar@base64/YmF6
Observe que este método tem um caso extremo improvável que não é tratado corretamente: um pusher que não conhece o mecanismo de codificação pode usar um nome de rótulo que também seja uma versão codificada válida de outro nome de rótulo. Por exemplo, se um pusher pretende usar o nome do rótulo U__foo_2e_bar , mas não o codifica como U___55_____foo__2e__bar , o Pushgateway irá decodificar U__foo_2e_bar para foo.bar . Esta é a principal razão pela qual a decodificação é ativada por meio do sinalizador --push.enable-utf8-names .
PUT PUT é usado para enviar um grupo de métricas. Todas as métricas com a chave de agrupamento especificada na URL são substituídas pelas métricas enviadas com PUT .
O corpo da solicitação contém as métricas para enviar como buffers de protocolo binário delimitados ou no formato de texto simples (ambos na versão 0.0.4, consulte a especificação do formato de exposição de dados). A discriminação entre as duas variantes é feita através do cabeçalho Content-Type . (Use o valor application/vnd.google.protobuf; proto=io.prometheus.client.MetricFamily; encoding=delimited para buffers de protocolo, caso contrário, o formato de texto será tentado como substituto.)
O código de resposta em caso de sucesso é 200, 202 ou 400. Uma resposta 200 implica um push bem-sucedido, seja substituindo um grupo existente de métricas ou criando um novo. Uma resposta 400 pode ocorrer se a solicitação estiver malformada ou se as métricas enviadas forem inconsistentes com as métricas enviadas para outros grupos ou colidirem com as métricas do próprio Pushgateway. Uma explicação é retornada no corpo da resposta e registrada no nível de erro. Um 202 só pode ocorrer se o sinalizador --push.disable-consistency-check estiver definido. Nesse caso, as métricas enviadas são apenas enfileiradas e não verificadas quanto à consistência. No entanto, inconsistências levarão a falhas, conforme descrito acima.
Em casos raros, é possível que o Pushgateway acabe com um conjunto inconsistente de métricas já enviadas. Nesse caso, novos pushes também são rejeitados como inconsistentes, mesmo que o culpado sejam as métricas que foram enviadas anteriormente. Exclua as métricas ofensivas para sair dessa situação.
Se estiver usando o formato protobuf, não envie mensagens proto duplicadas do MetricFamily (ou seja, mais de uma com o mesmo nome) de uma só vez, pois elas substituirão umas às outras.
Observe que o Pushgateway não fornece nenhuma garantia forte de que as métricas enviadas sejam persistidas no disco. (Uma falha no servidor pode causar perda de dados. Ou o Pushgateway está configurado para não persistir no disco.)
Uma solicitação PUT com corpo vazio exclui efetivamente todas as métricas com a chave de agrupamento especificada. No entanto, em contraste com a solicitação DELETE descrita abaixo, ela atualiza as métricas push_time_seconds .
POST POST funciona exatamente como o método PUT , mas apenas as métricas com o mesmo nome das métricas recém-enviadas são substituídas (entre aquelas com a mesma chave de agrupamento).
Uma solicitação POST com corpo vazio apenas atualiza as métricas push_time_seconds , mas não altera nenhuma das métricas enviadas anteriormente.
DELETE DELETE é usado para excluir métricas do Pushgateway. A solicitação não deve conter nenhum conteúdo. Todas as métricas com a chave de agrupamento especificada no URL serão excluídas.
O código de resposta em caso de sucesso é sempre 202. A solicitação de exclusão é meramente colocada na fila naquele momento. Não há garantia de que a solicitação será realmente executada ou que o resultado chegará à camada de persistência (por exemplo, no caso de falha do servidor). Porém, a ordem da solicitação PUT / POST e DELETE é garantida, ou seja, se você enviou com sucesso uma solicitação DELETE e depois enviou um PUT , é garantido que o DELETE será processado primeiro (e vice-versa).
Excluir uma chave de agrupamento sem métricas é uma operação autônoma e não resultará em erro.
O corpo de uma solicitação POST ou PUT pode ser compactado com gzip ou snappy. Adicione um cabeçalho Content-Encoding: gzip ou Content-Encoding: snappy para fazer isso.
Exemplos:
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 A API Admin fornece acesso administrativo ao Pushgateway e deve ser explicitamente habilitada configurando o sinalizador --web.enable-admin-api .
A porta padrão que o Pushgateway está escutando é 9091. O caminho é semelhante a:
/api//admin/
| HTTP_METHOD | API_VERSION | MANIPULADOR | DESCRIÇÃO |
|---|---|---|---|
| COLOCAR | v1 | limpar | Exclui com segurança todas as métricas do Pushgateway. |
Por exemplo, para limpar todas as métricas do Pushgateway:
curl -X PUT http://pushgateway.example.org:9091/api/v1/admin/wipe
A API de consulta permite acessar métricas enviadas e informações de construção e tempo de execução.
/api//
| HTTP_METHOD | API_VERSION | MANIPULADOR | DESCRIÇÃO |
|---|---|---|---|
| PEGAR | v1 | status | Retorna informações de compilação, sinalizadores de linha de comando e horário de início no formato JSON. |
| PEGAR | v1 | métricas | Retorna as famílias de métricas enviadas no formato JSON. |
Por exemplo :
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"
}
]
}
}
]
}
O Pushgateway fornece um conjunto de API de gerenciamento para facilitar a automação e integrações.
| HTTP_METHOD | CAMINHO | DESCRIÇÃO |
|---|---|---|
| PEGAR | /-/saudável | Retorna 200 sempre que o Pushgateway estiver íntegro. |
| PEGAR | /-/preparar | Retorna 200 sempre que o Pushgateway estiver pronto para atender o tráfego. |
--web.enable-lifecycle .| HTTP_METHOD | CAMINHO | DESCRIÇÃO |
|---|---|---|
| COLOCAR | /-/desistir | Aciona um desligamento normal do Pushgateway. |
Alternativamente, um desligamento normal pode ser acionado enviando um SIGTERM para o processo Pushgateway.
O Pushgateway expõe as seguintes métricas por meio do --web.telemetry-path configurado (padrão: /metrics ):
push_time_seconds e push_failure_time_seconds conforme explicado acima.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
Em geral, é uma boa ideia alertar sobre push_time_seconds que está muito mais atrasado do que o esperado. Isso detectará tanto os pushes com falha quanto os pushers completamente inativos.
Para detectar pushes com falha muito antes, alerte em push_failure_time_seconds > push_time_seconds .
Os push também podem falhar porque estão malformados. Neste caso, eles nunca alcançam nenhum grupo de métricas e, portanto, não definirão nenhuma métrica push_failure_time_seconds . Esses pushes ainda são contados como pushgateway_http_requests_total{code="400",handler="push"} . Você pode alertar sobre a rate dessa métrica, mas precisa inspecionar os registros para identificar o traficante infrator.
O Pushgateway oferece suporte a TLS e autenticação básica. Isto permite um melhor controle dos vários pontos de extremidade HTTP.
Para usar TLS e/ou autenticação básica, você precisa passar um arquivo de configuração usando o parâmetro --web.config.file . O formato do arquivo está descrito no repositório do exporter-toolkit.
Observe que as configurações de TLS e de autenticação básica afetam todos os endpoints HTTP: /metrics para raspagem, a API para enviar métricas via /metrics/..., a API administrativa via /api/... e a UI da web.
O binário normal incorpora os arquivos da web no diretório resources . Para fins de desenvolvimento, é útil ter um binário em execução usando esses arquivos diretamente (para que você possa ver o efeito das alterações imediatamente). Para mudar para uso direto, adicione -tags dev à entrada flags em .promu.yml e, em seguida, make build . Volte ao modo "normal" revertendo as alterações para .promu.yml e digitando make assets .
As diretrizes de estilo relevantes são os comentários de revisão do código Go e a seção Formatação e estilo de Go: Best Practices for Production Environments de Peter Bourgon.
