puerta de enlace
1.10.0
Prometheus Pushgateway existe para permitir que trabajos efímeros y por lotes expongan sus métricas a Prometheus. Dado que es posible que este tipo de trabajos no existan el tiempo suficiente para ser eliminados, en su lugar pueden llevar sus métricas a un Pushgateway. Pushgateway luego expone estas métricas a Prometheus.
En primer lugar, Pushgateway no es capaz de convertir a Prometheus en un sistema de monitoreo basado en push. Para obtener una descripción general de los casos de uso de Pushgateway, lea Cuándo utilizar Pushgateway.
Pushgateway no es explícitamente un agregador ni un contador distribuido , sino más bien un caché de métricas. No tiene una semántica similar a la de las estadísticas. Las métricas enviadas son exactamente las mismas que las que presentaría para el scraping en un programa en ejecución permanente. Si necesita un conteo distribuido, puede usar las estadísticas reales en combinación con el exportador de estadísticas de Prometheus o echar un vistazo a la puerta de enlace de agregación de prom. Con más experiencia acumulada, el proyecto Prometheus podría algún día proporcionar una solución nativa, separada o posiblemente incluso como parte de Pushgateway.
Para métricas a nivel de máquina, el recopilador de archivos de texto del exportador de Node suele ser más apropiado. Pushgateway está destinado a métricas de nivel de servicio.
Pushgateway no es una tienda de eventos . Si bien puede utilizar Prometheus como fuente de datos para las anotaciones de Grafana, el seguimiento de algo como los eventos de lanzamiento debe realizarse con algún marco de registro de eventos.
Hace un tiempo, decidimos no implementar un "tiempo de espera" o TTL para las métricas enviadas porque casi todos los casos de uso propuestos resultaron ser antipatrones que desaconsejamos enfáticamente. Puede seguir una discusión más reciente en la lista de correo de desarrolladores de Prometheus.
Descargue versiones binarias para su plataforma desde la página de versiones y descomprima el archivo tar.
Si desea compilarse usted mismo a partir de las fuentes, necesita una configuración de Go que funcione. Luego use el Makefile proporcionado (escriba make ).
Para la configuración más básica, simplemente inicie el binario. Para cambiar la dirección para escuchar, utilice el indicador --web.listen-address (por ejemplo, "0.0.0.0:9091" o ":9091"). De forma predeterminada, Pushgateway no conserva las métricas. Sin embargo, el indicador --persistence.file le permite especificar un archivo en el que se conservarán las métricas enviadas (para que sobrevivan a los reinicios de Pushgateway).
Puede implementar Pushgateway utilizando la imagen de Docker prom/pushgateway.
Por ejemplo:
docker pull prom/pushgateway
docker run -d -p 9091:9091 prom/pushgateway El Pushgateway debe configurarse como un objetivo para que Prometheus lo rastree, utilizando uno de los métodos habituales. Sin embargo, siempre debes configurar honor_labels: true en la configuración de scrape (ver más abajo para una explicación detallada).
Las bibliotecas cliente de Prometheus deberían tener una función para enviar las métricas registradas a un Pushgateway. Por lo general, un cliente de Prometheus presenta pasivamente métricas para que un servidor de Prometheus las raspe. Una biblioteca cliente que admite envíos tiene una función de envío, que debe ser llamada mediante el código del cliente. Luego enviará activamente las métricas a Pushgateway, utilizando la API que se describe a continuación.
Al utilizar el protocolo de texto Prometheus, impulsar métricas es tan fácil que no se proporciona una CLI separada. Simplemente use una herramienta HTTP de línea de comandos como curl . Lo más probable es que su lenguaje de programación favorito tenga algunas capacidades HTTP integradas que también puede aprovechar aquí.
Tenga en cuenta que en el protocolo de texto, cada línea debe terminar con un carácter de avance de línea (también conocido como 'LF' o 'n'). Finalizar una línea de otras maneras, por ejemplo con 'CR' también conocido como 'r', 'CRLF' también conocido como 'rn', o simplemente con el final del paquete, resultará en un error de protocolo.
Las métricas enviadas se gestionan en grupos, identificados mediante una clave de agrupación de cualquier número de etiquetas, de las cuales la primera debe ser la etiqueta job . Los grupos son fáciles de inspeccionar a través de la interfaz web.
Para conocer las implicaciones de los caracteres especiales en los valores de las etiquetas, consulte la sección URL a continuación.
Ejemplos:
Inserte una sola muestra en el grupo identificado por {job="some_job"} :
echo "some_metric 3.14" | curl --data-binary @- http://pushgateway.example.org:9091/metrics/job/some_job
Dado que no se ha proporcionado información de tipo, some_metric será de tipo untyped .
Introduzca algo más complejo en el grupo identificado por {job="some_job",instance="some_instance"} :
cat <Observe cómo se proporciona la información de tipo y las cadenas de ayuda. Esas líneas son opcionales, pero se recomiendan encarecidamente para cualquier cosa más compleja.
Elimine todas las métricas del grupo identificado por {job="some_job",instance="some_instance"} :
curl -X DELETE http://pushgateway.example.org:9091/metrics/job/some_job/instance/some_instance
Elimine todas las métricas del grupo identificado por {job="some_job"} (tenga en cuenta que esto no incluye las métricas del grupo {job="some_job",instance="some_instance"} del ejemplo anterior, incluso si esas métricas tienen la misma etiqueta de trabajo):
curl -X DELETE http://pushgateway.example.org:9091/metrics/job/some_job
Elimine todas las métricas en todos los grupos (requiere habilitar la API de administración mediante la marca de línea de comando --web.enable-admin-api ):
curl -X PUT http://pushgateway.example.org:9091/api/v1/admin/wipe
El servidor Prometheus adjuntará una etiqueta job y una etiqueta instance a cada métrica extraída. El valor de la etiqueta job proviene de la configuración de raspado. Cuando configura Pushgateway como destino de raspado para su servidor Prometheus, probablemente elija un nombre de trabajo como pushgateway . El valor de la etiqueta de instance se establece automáticamente en el host y el puerto del objetivo extraído. Por lo tanto, todas las métricas extraídas de Pushgateway tendrán el host y el puerto de Pushgateway como etiqueta instance y una etiqueta job como pushgateway . El conflicto con las etiquetas job e instance que podría haber adjuntado a las métricas enviadas a Pushgateway se resuelve cambiando el nombre de esas etiquetas a exported_job y exported_instance .
Sin embargo, este comportamiento generalmente no es deseado cuando se raspa un Pushgateway. Generalmente, le gustaría conservar las etiquetas job e instance de las métricas enviadas a Pushgateway. Es por eso que debes configurar honor_labels: true en la configuración de scrape para Pushgateway. Permite el comportamiento deseado. Consulte la documentación para obtener más detalles.
Esto nos deja con el caso en el que las métricas enviadas a Pushgateway no incluyen una etiqueta instance . Este caso es bastante común ya que las métricas enviadas suelen estar en un nivel de servicio y, por lo tanto, no están relacionadas con una instancia en particular. Incluso con honor_labels: true , el servidor Prometheus adjuntará una etiqueta instance si no se ha establecido ninguna etiqueta instance en primer lugar. Por lo tanto, si una métrica se envía a Pushgateway sin una etiqueta de instancia (y sin una etiqueta de instancia en la clave de agrupación, ver más abajo), Pushgateway la exportará con una etiqueta de instancia vacía ( {instance=""} ), que es equivalente a no tener ninguna etiqueta instance pero impide que el servidor adjunte una.
Pushgateway expone todas las métricas enviadas junto con sus propias métricas a través del mismo punto final /metrics . (Consulte la sección sobre métricas expuestas para obtener más detalles). Por lo tanto, todas las métricas deben ser coherentes entre sí: las métricas del mismo nombre deben tener el mismo tipo, incluso si se envían a grupos diferentes, y no debe haber duplicados. , es decir, métricas con el mismo nombre y exactamente los mismos pares de etiquetas. Los push que podrían dar lugar a inconsistencias se rechazan con el código de estado 400.
Sin embargo, se toleran cadenas de ayuda inconsistentes. Pushgateway elegirá una cadena de ayuda ganadora y la registrará en el nivel de información.
Nota heredada: la cadena de ayuda de la métrica push_time_seconds de Pushgateway ha cambiado en la versión 0.10.0. Al utilizar un archivo de persistencia, las métricas enviadas a un Pushgateway de una versión anterior pueden convertirse en un Pushgateway de la versión 0.10.0 o posterior. En este caso, aparecerá el mensaje de registro mencionado anteriormente. Una vez que cada grupo previamente enviado haya sido eliminado o haya recibido un nuevo envío, el mensaje de registro desaparecerá.
La verificación de consistencia realizada durante un empujón es la misma que ocurre durante un raspado. En casos de uso comunes, los rasguños ocurren con más frecuencia que los empujones. Por lo tanto, el costo de rendimiento de la verificación del tiempo de inserción no es relevante. Sin embargo, si se combina una gran cantidad de métricas en Pushgateway con envíos frecuentes, la duración del envío podría volverse prohibitivamente larga. En este caso, podría considerar usar la marca de línea de comando --push.disable-consistency-check , que ahorra el costo de la verificación de coherencia durante una inserción, pero permite enviar métricas inconsistentes. La verificación aún se realizará durante un raspado, por lo que fallarán todos los raspados mientras se almacenen métricas inconsistentes en Pushgateway. Por lo tanto, establecer la bandera lo pone en riesgo de desactivar Pushgateway con una sola pulsación inconsistente.
Si impulsa métricas en el momento t 1 , podría verse tentado a creer que Prometheus las eliminará con esa misma marca de tiempo t 1 . En cambio, lo que Prometheus adjunta como marca de tiempo es el momento en que raspa Pushgateway. ¿Por qué es así?
En la visión del mundo de Prometheus, una métrica se puede eliminar en cualquier momento. Una métrica que no se puede eliminar básicamente ha dejado de existir. Prometheus es algo tolerante, pero si no puede obtener muestras para una métrica en 5 minutos, se comportará como si esa métrica ya no existiera. Prevenir eso es en realidad una de las razones para usar Pushgateway. Pushgateway hará que las métricas de su trabajo efímero sean descartables en cualquier momento. Adjuntar el tiempo de envío como una marca de tiempo anularía ese propósito porque 5 minutos después del último envío, su métrica le parecerá tan obsoleta a Prometheus como si ya no pudiera eliminarse en absoluto. (Prometheus solo conoce una marca de tiempo por muestra, no hay forma de distinguir un "momento de empujar" y un "momento de raspar").
Como no hay casos de uso en los que tenga sentido adjuntar una marca de tiempo diferente, y muchos usuarios intentan hacerlo incorrectamente (a pesar de que ninguna biblioteca cliente lo admite), Pushgateway rechaza cualquier envío con marcas de tiempo.
Si cree que necesita enviar una marca de tiempo, consulte Cuándo utilizar Pushgateway.
Para que sea más fácil alertar sobre empujadores fallidos o aquellos que no se han ejecutado recientemente, Pushgateway agregará las métricas push_time_seconds y push_failure_time_seconds con la marca de tiempo Unix del último POST / PUT exitoso y fallido a cada grupo. Esto anulará cualquier métrica enviada con ese nombre. Un valor de cero para cualquiera de las métricas implica que el grupo nunca ha visto un POST / PUT exitoso o fallido.
Todos los envíos se realizan a través de HTTP. La interfaz es vagamente parecida a REST.
El puerto predeterminado que escucha Pushgateway es 9091. La ruta se ve así
/metrics/job/{//}
job , seguido de cualquier número de otros pares de etiquetas (que pueden incluir o no una etiqueta instance ). El conjunto de etiquetas definido por la ruta URL se utiliza como clave de agrupación. Cualquiera de esas etiquetas ya establecidas en el cuerpo de la solicitud (como etiquetas normales, por ejemplo, name{job="foo"} 42 ) se sobrescribirá para que coincida con las etiquetas definidas por la ruta URL.
Si el nombre job o de cualquier etiqueta tiene el sufijo @base64 , el siguiente nombre de trabajo o valor de etiqueta se interpreta como una cadena codificada en base64 de acuerdo con RFC 4648, utilizando la URL y el alfabeto seguro para nombres de archivos. (El relleno es opcional, pero se requiere un solo = para codificar un valor de etiqueta vacío). Esta es la única forma de manejar los siguientes casos:
/ , porque el / simple (o incluso codificado en URI) se interpretaría de otro modo como un separador de ruta.// o final / desaparecería cuando el código del enrutador HTTP desinfecte la ruta. Tenga en cuenta que un nombre job vacío no es válido. Los valores de etiquetas vacías son válidos pero rara vez son útiles. Para codificarlos con base64, debe usar al menos un carácter de relleno = para evitar un // o un / final.Para otros caracteres especiales, la codificación habitual del componente URI también funciona, pero la base64 podría ser más conveniente.
Idealmente, las bibliotecas cliente se encargan del sufijo y la codificación.
Ejemplos:
Para utilizar la clave de agrupación job="directory_cleaner",path="/var/tmp" , la siguiente ruta no funcionará:
/metrics/job/directory_cleaner/path//var/tmp
En su lugar, utilice la codificación segura para URL base64 para el valor de la etiqueta y márquela añadiendo al nombre de la etiqueta el sufijo @base64 :
/metrics/job/directory_cleaner/path@base64/L3Zhci90bXA
Si no está utilizando una biblioteca cliente que maneje la codificación por usted, puede usar herramientas de codificación. Por ejemplo, existe una herramienta de línea de comandos base64url (paquete Debian basez ), que puede combinar con curl para enviar desde la línea de comandos de la siguiente manera:
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 utilizar una clave de agrupación que contenga un valor de etiqueta vacío como job="example",first_label="",second_label="foobar" , la siguiente ruta no funcionará:
/metrics/job/example/first_label//second_label/foobar
En su lugar, utilice la siguiente ruta que incluya el carácter de relleno = :
/metrics/job/example/first_label@base64/=/second_label/foobar
La clave de agrupación job="titan",name="Προμηθεύς" se puede representar “tradicionalmente” con codificación URI:
/metrics/job/titan/name/%CE%A0%CF%81%CE%BF%CE%BC%CE%B7%CE%B8%CE%B5%CF%8D%CF%82
O puede utilizar la codificación base64 más compacta:
/metrics/job/titan/name@base64/zqDPgc6_zrzOt864zrXPjc-C
Las versiones más recientes de los formatos de exposición de Prometheus (texto y protobuf) admiten el juego completo de caracteres UTF-8 en nombres de métricas y etiquetas. Pushgateway solo acepta caracteres especiales en los nombres si está configurado el indicador de línea de comando --push.enable-utf8-names . Para permitir caracteres especiales en los nombres de las etiquetas que forman parte de la ruta URL, la bandera también habilita un mecanismo de codificación específico. Esto es similar a la codificación base64 para valores de etiquetas descrita anteriormente, pero funciona de manera diferente en detalle por razones técnicas e históricas. Como antes, las bibliotecas cliente normalmente deberían encargarse de la codificación. Funciona de la siguiente manera:
U__ ._1F60A_ .__ .U__ , estos caracteres también deben codificarse, lo que da como resultado U___55_____ . (Eso es U__ + _55_ (para U ) + __ + __ ).U__ en su forma codificada, pero que contiene secuencias no válidas (por ejemplo, U__in_xxx_valid ) no se modifica. Por ejemplo, la etiqueta "foo.bar"="baz" se codificaría así:
/metrics/job/example/U__foo_2e_bar/baz
Esta codificación es compatible con la codificación base64 para valores de etiquetas:
/metrics/job/example/U__foo_2e_bar@base64/YmF6
Tenga en cuenta que este método tiene un caso extremo poco probable que no se maneja adecuadamente: un empujador que no conoce el mecanismo de codificación podría usar un nombre de etiqueta que también sea una versión codificada válida de otro nombre de etiqueta. Por ejemplo, si un empujador tiene la intención de usar el nombre de etiqueta U__foo_2e_bar , pero no lo codifica como U___55_____foo__2e__bar , Pushgateway decodificará U__foo_2e_bar a foo.bar . Esta es la razón principal por la que la decodificación se habilita mediante el indicador --push.enable-utf8-names .
PUT PUT se utiliza para impulsar un grupo de métricas. Todas las métricas con la clave de agrupación especificada en la URL se reemplazan por las métricas enviadas con PUT .
El cuerpo de la solicitud contiene las métricas para enviar como buffers de protocolo binario delimitados o en formato de texto plano simple (ambos en la versión 0.0.4, consulte la especificación del formato de exposición de datos). La discriminación entre las dos variantes se realiza a través del encabezado Content-Type . (Utilice el valor application/vnd.google.protobuf; proto=io.prometheus.client.MetricFamily; encoding=delimited para los buffers de protocolo; de lo contrario, se prueba el formato de texto como alternativa).
El código de respuesta en caso de éxito es 200, 202 o 400. Una respuesta 200 implica un impulso exitoso, ya sea reemplazando un grupo existente de métricas o creando uno nuevo. Puede ocurrir una respuesta 400 si la solicitud tiene un formato incorrecto o si las métricas enviadas son inconsistentes con las métricas enviadas a otros grupos o chocan con las métricas del propio Pushgateway. Se devuelve una explicación en el cuerpo de la respuesta y se registra en el nivel de error. Un 202 solo puede ocurrir si el indicador --push.disable-consistency-check está configurado. En este caso, las métricas enviadas simplemente se ponen en cola y no se verifica su coherencia. Sin embargo, las inconsistencias conducirán a raspaduras fallidas, como se describió anteriormente.
En casos raros, es posible que Pushgateway termine con un conjunto inconsistente de métricas ya implementadas. En ese caso, los nuevos impulsos también se rechazan por ser inconsistentes, incluso si el culpable son métricas que se impulsaron anteriormente. Elimine las métricas ofensivas para salir de esa situación.
Si utiliza el formato protobuf, no envíe mensajes proto de MetricFamily duplicados (es decir, más de uno con el mismo nombre) de una sola vez, ya que se sobrescribirán entre sí.
Tenga en cuenta que Pushgateway no ofrece garantías sólidas de que las métricas enviadas se conserven en el disco. (Una falla del servidor puede causar pérdida de datos. O Pushgateway está configurado para no persistir en el disco en absoluto).
Una solicitud PUT con un cuerpo vacío elimina efectivamente todas las métricas con la clave de agrupación especificada. Sin embargo, a diferencia de la solicitud DELETE que se describe a continuación, actualiza las métricas push_time_seconds .
POST POST funciona exactamente igual que el método PUT , pero solo se reemplazan las métricas con el mismo nombre que las métricas recién enviadas (entre aquellas con la misma clave de agrupación).
Una solicitud POST con un cuerpo vacío simplemente actualiza las métricas push_time_seconds pero no cambia ninguna de las métricas enviadas anteriormente.
DELETE DELETE se utiliza para eliminar métricas de Pushgateway. La solicitud no debe contener ningún contenido. Se eliminan todas las métricas con la clave de agrupación especificada en la URL.
El código de respuesta en caso de éxito es siempre 202. La solicitud de eliminación simplemente se pone en cola en ese momento. No hay garantía de que la solicitud realmente se ejecute o que el resultado llegue a la capa de persistencia (por ejemplo, en caso de una falla del servidor). Sin embargo, el orden de las solicitudes PUT / POST y DELETE está garantizado, es decir, si ha enviado con éxito una solicitud DELETE y luego envía un PUT , se garantiza que DELETE se procesará primero (y viceversa).
Eliminar una clave de agrupación sin métricas no es una operación y no generará un error.
El cuerpo de una solicitud POST o PUT puede estar comprimido con gzip o snappy. Agregue un encabezado Content-Encoding: gzip o Content-Encoding: snappy para hacerlo.
Ejemplos:
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 La API de administración proporciona acceso administrativo a Pushgateway y debe habilitarse explícitamente estableciendo el indicador --web.enable-admin-api .
El puerto predeterminado que escucha Pushgateway es 9091. La ruta es similar a la siguiente:
/api//admin/
| HTTP_METHOD | API_VERSION | ENTRENADOR DE ANIMALES | DESCRIPCIÓN |
|---|---|---|---|
| PONER | v1 | limpiar | Elimina de forma segura todas las métricas de Pushgateway. |
Por ejemplo, para borrar todas las métricas de Pushgateway:
curl -X PUT http://pushgateway.example.org:9091/api/v1/admin/wipe
La API de consulta permite acceder a métricas enviadas e información de compilación y tiempo de ejecución.
/api//
| HTTP_METHOD | API_VERSION | ENTRENADOR DE ANIMALES | DESCRIPCIÓN |
|---|---|---|---|
| CONSEGUIR | v1 | estado | Devuelve información de compilación, indicadores de línea de comando y la hora de inicio en formato JSON. |
| CONSEGUIR | v1 | métrica | Devuelve las familias de métricas enviadas en formato JSON. |
Por ejemplo :
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 proporciona un conjunto de API de administración para facilitar la automatización y las integraciones.
| HTTP_METHOD | CAMINO | DESCRIPCIÓN |
|---|---|---|
| CONSEGUIR | /-/saludable | Devuelve 200 siempre que Pushgateway esté en buen estado. |
| CONSEGUIR | /-/listo | Devuelve 200 siempre que Pushgateway esté listo para atender el tráfico. |
--web.enable-lifecycle .| HTTP_METHOD | CAMINO | DESCRIPCIÓN |
|---|---|---|
| PONER | /-/abandonar | Activa un cierre elegante de Pushgateway. |
Alternativamente, se puede activar un cierre elegante enviando un SIGTERM al proceso Pushgateway.
Pushgateway expone las siguientes métricas a través de la --web.telemetry-path configurada (predeterminada: /metrics ):
push_time_seconds y push_failure_time_seconds como se explicó anteriormente.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
En general, es una buena idea alertar sobre push_time_seconds que están mucho más retrasados de lo esperado. Esto detectará tanto los empujones fallidos como los empujadores que estén completamente caídos.
Para detectar envíos fallidos mucho antes, alerte en push_failure_time_seconds > push_time_seconds .
Los empujones también pueden fallar porque están mal formados. En este caso, nunca llegan a ningún grupo de métricas y, por lo tanto, no establecerán ninguna métrica push_failure_time_seconds . Esos envíos todavía se cuentan como pushgateway_http_requests_total{code="400",handler="push"} . Puede alertar sobre la rate de esta métrica, pero debe inspeccionar los registros para identificar al infractor.
Pushgateway admite TLS y autenticación básica. Esto permite un mejor control de los distintos puntos finales HTTP.
Para usar TLS y/o autenticación básica, debe pasar un archivo de configuración usando el parámetro --web.config.file . El formato del archivo se describe en el repositorio del kit de herramientas del exportador.
Tenga en cuenta que TLS y la configuración de autenticación básica afectan a todos los puntos finales HTTP: /metrics para scraping, la API para enviar métricas a través de /metrics/..., la API de administración a través de /api/... y la interfaz de usuario web.
El binario normal incorpora los archivos web en el directorio resources . Para fines de desarrollo, es útil tener un binario en ejecución que use esos archivos directamente (para que pueda ver el efecto de los cambios inmediatamente). Para cambiar al uso directo, agregue -tags dev a la entrada flags en .promu.yml y luego make build . Vuelva al modo "normal" revirtiendo los cambios en .promu.yml y escribiendo make assets .
Las pautas de estilo relevantes son los comentarios de revisión de código de Go y la sección de formato y estilo de Go de Peter Bourgon: mejores prácticas para entornos de producción.
