passerelle push
1.10.0
Le Prometheus Pushgateway existe pour permettre aux tâches éphémères et par lots d'exposer leurs métriques à Prometheus. Étant donné que ces types de tâches n’existent peut-être pas assez longtemps pour être supprimés, ils peuvent plutôt transmettre leurs métriques à un Pushgateway. Le Pushgateway expose ensuite ces métriques à Prometheus.
Tout d’abord, Pushgateway n’est pas capable de transformer Prometheus en un système de surveillance basé sur le push. Pour une description générale des cas d’utilisation du Pushgateway, veuillez lire Quand utiliser le Pushgateway.
Le Pushgateway n'est explicitement pas un agrégateur ou un compteur distribué mais plutôt un cache de métriques. Il n'a pas de sémantique de type statsd. Les métriques poussées sont exactement les mêmes que celles que vous présenteriez pour le scraping dans un programme exécuté en permanence. Si vous avez besoin d'un comptage distribué, vous pouvez soit utiliser le statsd réel en combinaison avec l'exportateur statsd de Prometheus, soit consulter la passerelle prom-aggregation-gateway. Avec plus d’expérience acquise, le projet Prometheus pourrait un jour être en mesure de fournir une solution native, distincte ou peut-être même faisant partie de Pushgateway.
Pour les métriques au niveau machine, le collecteur de fichiers texte de l'exportateur Node est généralement plus approprié. Le Pushgateway est destiné aux métriques de niveau de service.
Le Pushgateway n'est pas un magasin d'événements . Bien que vous puissiez utiliser Prometheus comme source de données pour les annotations Grafana, le suivi de quelque chose comme les événements de publication doit avoir lieu avec un cadre de journalisation des événements.
Il y a quelque temps, nous avons décidé de ne pas implémenter de « timeout » ou TTL pour les métriques poussées car presque tous les cas d'utilisation proposés se sont avérés être des anti-modèles que nous déconseillons fortement. Vous pouvez suivre une discussion plus récente sur la liste de diffusion prometheus-developers.
Téléchargez les versions binaires pour votre plate-forme à partir de la page des versions et décompressez l'archive tar.
Si vous souhaitez vous compiler à partir des sources, vous avez besoin d'une configuration Go fonctionnelle. Utilisez ensuite le Makefile fourni (tapez make ).
Pour la configuration la plus basique, démarrez simplement le binaire. Pour changer l'adresse d'écoute, utilisez l'indicateur --web.listen-address (par exemple "0.0.0.0:9091" ou ":9091"). Par défaut, Pushgateway ne conserve pas les métriques. Cependant, l'indicateur --persistence.file vous permet de spécifier un fichier dans lequel les métriques poussées seront conservées (afin qu'elles survivent aux redémarrages de Pushgateway).
Vous pouvez déployer Pushgateway à l’aide de l’image Docker prom/pushgateway.
Par exemple:
docker pull prom/pushgateway
docker run -d -p 9091:9091 prom/pushgateway Le Pushgateway doit être configuré comme une cible à gratter par Prometheus, en utilisant l'une des méthodes habituelles. Cependant, vous devez toujours définir honor_labels: true dans la configuration scrape (voir ci-dessous pour une explication détaillée).
Les bibliothèques clientes Prometheus doivent avoir une fonctionnalité permettant de transmettre les métriques enregistrées vers une passerelle Pushgateway. Habituellement, un client Prometheus présente passivement des métriques à récupérer par un serveur Prometheus. Une bibliothèque client qui prend en charge le push possède une fonction push, qui doit être appelée par le code client. Il poussera ensuite activement les métriques vers une Pushgateway, à l'aide de l'API décrite ci-dessous.
Grâce au protocole de texte Prometheus, la transmission de métriques est si simple qu'aucune CLI distincte n'est fournie. Utilisez simplement un outil HTTP en ligne de commande comme curl . Votre langage de script préféré possède probablement des fonctionnalités HTTP intégrées que vous pouvez également exploiter ici.
Notez que dans le protocole texte, chaque ligne doit se terminer par un caractère de saut de ligne (alias 'LF' ou 'n'). Terminer une ligne d'une autre manière, par exemple avec 'CR' alias 'r', 'CRLF' alias 'rn', ou simplement la fin du paquet, entraînera une erreur de protocole.
Les métriques poussées sont gérées en groupes, identifiés par une clé de regroupement d'un nombre quelconque d'étiquettes, dont la première doit être l'étiquette job . Les groupes sont faciles à inspecter via l'interface Web.
Pour connaître les implications des caractères spéciaux dans les valeurs d'étiquette, consultez la section URL ci-dessous.
Exemples :
Poussez un seul échantillon dans le groupe identifié par {job="some_job"} :
echo "some_metric 3.14" | curl --data-binary @- http://pushgateway.example.org:9091/metrics/job/some_job
Puisqu’aucune information de type n’a été fournie, some_metric sera de type untyped .
Poussez quelque chose de plus complexe dans le groupe identifié par {job="some_job",instance="some_instance"} :
cat <Notez comment les informations de type et les chaînes d'aide sont fournies. Ces lignes sont facultatives, mais fortement encouragées pour tout ce qui est plus complexe.
Supprimez toutes les métriques du groupe identifié par {job="some_job",instance="some_instance"} :
curl -X DELETE http://pushgateway.example.org:9091/metrics/job/some_job/instance/some_instance
Supprimez toutes les métriques du groupe identifié par {job="some_job"} (notez que cela n'inclut pas les métriques du groupe {job="some_job",instance="some_instance"} de l'exemple précédent, même si ces métriques ont l'attribut même étiquette de poste) :
curl -X DELETE http://pushgateway.example.org:9091/metrics/job/some_job
Supprimez toutes les métriques de tous les groupes (nécessite d'activer l'API d'administration via l'indicateur de ligne de commande --web.enable-admin-api ) :
curl -X PUT http://pushgateway.example.org:9091/api/v1/admin/wipe
Le serveur Prometheus attachera une étiquette job et une étiquette instance à chaque métrique récupérée. La valeur de l'étiquette job provient de la configuration de scrape. Lorsque vous configurez Pushgateway comme cible de scrape pour votre serveur Prometheus, vous choisirez probablement un nom de travail tel que pushgateway . La valeur de l'étiquette instance est automatiquement définie sur l'hôte et le port de la cible récupérée. Par conséquent, toutes les métriques extraites de Pushgateway auront l’hôte et le port de Pushgateway comme étiquette instance et une étiquette job comme pushgateway . Le conflit avec les étiquettes job et instance que vous pourriez avoir attachées aux métriques transmises à Pushgateway est résolu en renommant ces étiquettes en exported_job et exported_instance .
Cependant, ce comportement n’est généralement pas souhaité lors du scraping d’un Pushgateway. En règle générale, vous souhaitez conserver les étiquettes job et instance des métriques transmises à Pushgateway. C'est pourquoi vous devez définir honor_labels: true dans la configuration scrape du Pushgateway. Il permet le comportement souhaité. Consultez la documentation pour plus de détails.
Cela nous laisse avec le cas où les métriques poussées vers Pushgateway ne comportent pas d'étiquette instance . Ce cas est assez courant car les métriques poussées se situent souvent au niveau du service et ne sont donc pas liées à une instance particulière. Même avec honor_labels: true , le serveur Prometheus attachera une étiquette instance si aucune étiquette instance n'a été définie en premier lieu. Par conséquent, si une métrique est poussée vers Pushgateway sans étiquette d'instance (et sans étiquette d'instance dans la clé de regroupement, voir ci-dessous), Pushgateway l'exportera avec une étiquette d'instance vide ( {instance=""} ), ce qui est équivalent à n'avoir aucune étiquette instance mais empêche le serveur d'en attacher une.
Le Pushgateway expose toutes les métriques poussées avec ses propres métriques via le même point de terminaison /metrics . (Voir la section sur les métriques exposées pour plus de détails.) Par conséquent, toutes les métriques doivent être cohérentes les unes avec les autres : les métriques du même nom doivent avoir le même type, même si elles sont transmises à des groupes différents, et il ne doit y avoir aucun doublon. , c'est-à-dire des métriques portant le même nom et exactement les mêmes paires d'étiquettes. Les push qui entraîneraient des incohérences sont rejetés avec le code d'état 400.
Les chaînes d'aide incohérentes sont cependant tolérées. Le Pushgateway choisira une chaîne d'aide gagnante et l'enregistrera au niveau des informations.
Remarque héritée : la chaîne d'aide de la métrique push_time_seconds de Pushgateway a changé dans la v0.10.0. En utilisant un fichier de persistance, les métriques poussées vers un Pushgateway d'une version antérieure peuvent en faire un Pushgateway de v0.10.0 ou version ultérieure. Dans ce cas, le message de journal mentionné ci-dessus s'affichera. Une fois que chaque groupe précédemment poussé a été supprimé ou a reçu un nouveau push, le message du journal disparaîtra.
Le contrôle de cohérence effectué lors d'une poussée est le même que lors d'un grattage. Dans les cas d’utilisation courants, les éraflures se produisent plus souvent que les poussées. Par conséquent, le coût des performances de la vérification du temps de poussée n’est pas pertinent. Cependant, si un grand nombre de métriques sur Pushgateway sont combinées à des push fréquents, la durée du push peut devenir prohibitive. Dans ce cas, vous pouvez envisager d'utiliser l'indicateur de ligne de commande --push.disable-consistency-check , qui permet d'économiser le coût de la vérification de cohérence lors d'un push mais permet de pousser des métriques incohérentes. La vérification aura toujours lieu lors d'un scrape, faisant ainsi échouer tous les scrapes tant que des métriques incohérentes sont stockées sur Pushgateway. Définir le drapeau vous expose donc au risque de désactiver le Pushgateway par une seule pression incohérente.
Si vous poussez les métriques au temps t 1 , vous pourriez être tenté de croire que Prometheus les récupérera avec le même horodatage t 1 . Au lieu de cela, ce que Prometheus attache comme horodatage est l’heure à laquelle il gratte le Pushgateway. Pourquoi ?
Dans la vision du monde de Prometheus, une métrique peut être récupérée à tout moment. Une métrique qui ne peut être récupérée a pratiquement cessé d’exister. Prometheus est quelque peu tolérant, mais s'il ne peut obtenir aucun échantillon pour une métrique en 5 minutes, il se comportera comme si cette métrique n'existait plus. Empêcher cela est en fait l’une des raisons d’utiliser une Pushgateway. Le Pushgateway rendra les métriques de votre travail éphémère récupérables à tout moment. Attacher l'heure de poussée comme horodatage irait à l'encontre de cet objectif, car 5 minutes après la dernière poussée, votre métrique semblera aussi obsolète à Prometheus que si elle ne pouvait plus être récupérée du tout. (Prometheus ne connaît qu'un seul horodatage par échantillon, il n'y a aucun moyen de distinguer un « temps de poussée » et un « temps de grattage ».)
Comme il n'existe aucun cas d'utilisation dans lequel il serait logique d'attacher un horodatage différent et que de nombreux utilisateurs tentent de le faire de manière incorrecte (bien qu'aucune bibliothèque client ne le prenne en charge), Pushgateway rejette tout push avec horodatage.
Si vous pensez que vous devez pousser un horodatage, veuillez consulter Quand utiliser Pushgateway.
Afin de faciliter l'alerte sur les pushers ayant échoué ou ceux qui n'ont pas été exécutés récemment, Pushgateway ajoutera les métriques push_time_seconds et push_failure_time_seconds avec l'horodatage Unix du dernier POST / PUT réussi et échoué à chaque groupe. Cela remplacera toute métrique poussée portant ce nom. Une valeur de zéro pour l'une ou l'autre métrique implique que le groupe n'a jamais vu un POST / PUT réussi ou échoué.
Tous les push sont effectués via HTTP. L'interface ressemble vaguement à REST.
Le port par défaut écouté par le Pushgateway est 9091. Le chemin ressemble à
/metrics/job/{//}
job , suivi d'un nombre quelconque d'autres paires d'étiquettes (qui peuvent ou non inclure une étiquette instance ). L'ensemble d'étiquettes défini par le chemin de l'URL est utilisé comme clé de regroupement. N'importe laquelle de ces étiquettes déjà définies dans le corps de la requête (en tant qu'étiquettes normales, par exemple name{job="foo"} 42 ) sera écrasée pour correspondre aux étiquettes définies par le chemin de l'URL !
Si le nom job ou d'un nom d'étiquette est suivi de @base64 , le nom de travail ou la valeur d'étiquette suivant est interprété comme une chaîne codée en base64 conformément à la RFC 4648, en utilisant l'alphabet sécurisé de l'URL et du nom de fichier. (Le remplissage est facultatif, mais un seul = est requis pour coder une valeur d'étiquette vide.) C'est la seule façon de gérer les cas suivants :
/ , car le / brut (ou même codé en URI) serait autrement interprété comme un séparateur de chemin.// ou le / final résultant disparaîtrait lorsque le chemin serait nettoyé par le code du routeur HTTP. Notez qu'un nom job vide n'est pas valide. Les valeurs d'étiquette vides sont valides mais rarement utiles. Pour les encoder en base64, vous devez utiliser au moins un caractère de remplissage = pour éviter un // ou un / final.Pour les autres caractères spéciaux, l'encodage habituel des composants URI fonctionne également, mais le base64 pourrait être plus pratique.
Idéalement, les bibliothèques clientes s'occupent du suffixe et de l'encodage.
Exemples :
Pour utiliser la clé de regroupement job="directory_cleaner",path="/var/tmp" , le chemin suivant ne fonctionnera pas :
/metrics/job/directory_cleaner/path//var/tmp
Utilisez plutôt le codage sécurisé pour les URL base64 pour la valeur de l'étiquette et marquez-la en suffixant le nom de l'étiquette avec @base64 :
/metrics/job/directory_cleaner/path@base64/L3Zhci90bXA
Si vous n'utilisez pas de bibliothèque client qui gère l'encodage pour vous, vous pouvez utiliser des outils d'encodage. Par exemple, il existe un outil de ligne de commande base64url (paquet Debian basez ), que vous pouvez combiner avec curl pour pousser depuis la ligne de commande de la manière suivante :
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)
Pour utiliser une clé de regroupement contenant une valeur d'étiquette vide telle que job="example",first_label="",second_label="foobar" , le chemin suivant ne fonctionnera pas :
/metrics/job/example/first_label//second_label/foobar
Utilisez plutôt le chemin suivant incluant le caractère de remplissage = :
/metrics/job/example/first_label@base64/=/second_label/foobar
La clé de regroupement job="titan",name="Προμηθεύς" peut être représentée « traditionnellement » avec un codage URI :
/metrics/job/titan/name/%CE%A0%CF%81%CE%BF%CE%BC%CE%B7%CE%B8%CE%B5%CF%8D%CF%82
Ou vous pouvez utiliser l'encodage base64 plus compact :
/metrics/job/titan/name@base64/zqDPgc6_zrzOt864zrXPjc-C
Les versions plus récentes des formats d'exposition Prometheus (texte et protobuf) prennent en charge le jeu de caractères UTF-8 complet dans les noms de métriques et d'étiquettes. Pushgateway n'accepte les caractères spéciaux dans les noms que si l'indicateur de ligne de commande --push.enable-utf8-names est défini. Pour autoriser les caractères spéciaux dans les noms d'étiquettes qui font partie du chemin de l'URL, l'indicateur active également un mécanisme de codage spécifique. Ceci est similaire au codage base64 pour les valeurs d'étiquette décrit ci-dessus, mais fonctionne différemment en détail pour des raisons techniques et historiques. Comme auparavant, les bibliothèques clientes doivent généralement s'occuper de l'encodage. Cela fonctionne comme suit :
U__ ._1F60A_ .__ .U__ , ces caractères doivent également être codés, ce qui donne U___55_____ . (C'est U__ + _55_ (pour U ) + __ + __ ).U__ dans sa forme codée, mais contenant des séquences invalides (par exemple U__in_xxx_valid ) reste inchangé. Par exemple, le label "foo.bar"="baz" serait codé comme :
/metrics/job/example/U__foo_2e_bar/baz
Cet encodage est compatible avec l'encodage base64 pour les valeurs d'étiquette :
/metrics/job/example/U__foo_2e_bar@base64/YmF6
Notez que cette méthode présente un cas limite peu probable qui n'est pas géré correctement : un pousseur ignorant le mécanisme de codage peut utiliser un nom d'étiquette qui est également une version codée valide d'un autre nom d'étiquette. Par exemple, si un pousseur a l'intention d'utiliser le nom de l'étiquette U__foo_2e_bar , mais ne l'encode pas comme U___55_____foo__2e__bar , le Pushgateway décodera U__foo_2e_bar en foo.bar . C'est la principale raison pour laquelle le décodage est opt-in via l'indicateur --push.enable-utf8-names .
PUT PUT est utilisé pour pousser un groupe de métriques. Toutes les métriques avec la clé de regroupement spécifiée dans l'URL sont remplacées par les métriques poussées avec PUT .
Le corps de la requête contient les métriques à transmettre soit sous forme de tampons de protocole binaires délimités, soit au format texte plat simple (tous deux en version 0.0.4, voir la spécification du format d'exposition des données). La discrimination entre les deux variantes se fait via l'en-tête Content-Type . (Utilisez la valeur application/vnd.google.protobuf; proto=io.prometheus.client.MetricFamily; encoding=delimited pour les tampons de protocole, sinon le format texte est essayé comme solution de secours.)
Le code de réponse en cas de succès est 200, 202 ou 400. Une réponse 200 implique une poussée réussie, soit en remplaçant un groupe de métriques existant, soit en en créant un nouveau. Une réponse 400 peut se produire si la demande est mal formée ou si les métriques poussées sont incohérentes avec les métriques poussées vers d'autres groupes ou entrent en collision avec les métriques du Pushgateway lui-même. Une explication est renvoyée dans le corps de la réponse et enregistrée au niveau d'erreur. Un 202 ne peut se produire que si l'indicateur --push.disable-consistency-check est défini. Dans ce cas, les métriques poussées sont simplement mises en file d’attente et leur cohérence n’est pas vérifiée. Cependant, des incohérences entraîneront des échecs, comme décrit ci-dessus.
Dans de rares cas, il est possible que Pushgateway se retrouve avec un ensemble incohérent de métriques déjà poussées. Dans ce cas, les nouvelles poussées sont également rejetées comme incohérentes, même si le coupable réside dans des mesures qui ont été poussées plus tôt. Supprimez les métriques incriminées pour sortir de cette situation.
Si vous utilisez le format protobuf, n'envoyez pas de messages proto MetricFamily en double (c'est-à-dire plus d'un avec le même nom) en une seule fois, car ils s'écraseront les uns les autres.
Notez que Pushgateway ne fournit aucune garantie solide que les métriques poussées sont conservées sur le disque. (Une panne de serveur peut entraîner une perte de données. Ou Pushgateway est configuré pour ne pas persister du tout sur le disque.)
Une requête PUT avec un corps vide supprime effectivement toutes les métriques avec la clé de regroupement spécifiée. Cependant, contrairement à la requête DELETE décrite ci-dessous, elle met à jour les métriques push_time_seconds .
POST POST fonctionne exactement comme la méthode PUT mais seules les métriques portant le même nom que les métriques nouvellement poussées sont remplacées (parmi celles ayant la même clé de regroupement).
Une requête POST avec un corps vide met simplement à jour les métriques push_time_seconds mais ne modifie aucune des métriques précédemment poussées.
DELETE DELETE est utilisé pour supprimer des métriques de Pushgateway. La demande ne doit contenir aucun contenu. Toutes les métriques avec la clé de regroupement spécifiée dans l'URL sont supprimées.
Le code de réponse en cas de succès est toujours 202. La demande de suppression est simplement mise en file d'attente à ce moment-là. Il n'y a aucune garantie que la requête sera réellement exécutée ou que le résultat parviendra à la couche de persistance (par exemple en cas de panne du serveur). Cependant, l'ordre des requêtes PUT / POST et DELETE est garanti, c'est-à-dire que si vous avez envoyé avec succès une requête DELETE puis envoyez un PUT , il est garanti que le DELETE sera traité en premier (et vice versa).
La suppression d’une clé de regroupement sans métriques n’est pas une opération et n’entraînera pas d’erreur.
Le corps d'une requête POST ou PUT peut être compressé par gzip ou snappy. Ajoutez un en-tête Content-Encoding: gzip ou Content-Encoding: snappy pour ce faire.
Exemples :
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 L'API Admin fournit un accès administratif à Pushgateway et doit être explicitement activée en définissant l'indicateur --web.enable-admin-api .
Le port par défaut écouté par Pushgateway est 9091. Le chemin ressemble à :
/api//admin/
| HTTP_METHOD | API_VERSION | MANIPULATEUR | DESCRIPTION |
|---|---|---|---|
| METTRE | v1 | essuyer | Supprime en toute sécurité toutes les métriques de Pushgateway. |
Par exemple, pour effacer toutes les métriques de Pushgateway :
curl -X PUT http://pushgateway.example.org:9091/api/v1/admin/wipe
L'API de requête permet d'accéder aux métriques poussées et aux informations de construction et d'exécution.
/api//
| HTTP_METHOD | API_VERSION | MANIPULATEUR | DESCRIPTION |
|---|---|---|---|
| OBTENIR | v1 | statut | Renvoie les informations de build, les indicateurs de ligne de commande et l'heure de début au format JSON. |
| OBTENIR | v1 | métrique | Renvoie les familles de métriques poussées au format JSON. |
Par exemple :
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"
}
]
}
}
]
}
Le Pushgateway fournit un ensemble d'API de gestion pour faciliter l'automatisation et les intégrations.
| HTTP_METHOD | CHEMIN | DESCRIPTION |
|---|---|---|
| OBTENIR | /-/en bonne santé | Renvoie 200 chaque fois que le Pushgateway est sain. |
| OBTENIR | /-/prêt | Renvoie 200 chaque fois que Pushgateway est prêt à desservir le trafic. |
--web.enable-lifecycle .| HTTP_METHOD | CHEMIN | DESCRIPTION |
|---|---|---|
| METTRE | /-/quitter | Déclenche un arrêt progressif de Pushgateway. |
Alternativement, un arrêt progressif peut être déclenché en envoyant un SIGTERM au processus Pushgateway.
Le Pushgateway expose les métriques suivantes via le --web.telemetry-path configuré (par défaut : /metrics ) :
push_time_seconds et push_failure_time_seconds comme expliqué ci-dessus.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
C'est en général une bonne idée d'alerter lorsque push_time_seconds est beaucoup plus en retard que prévu. Cela détectera à la fois les poussées échouées et les poussoirs complètement arrêtés.
Pour détecter les push ayant échoué beaucoup plus tôt, alertez sur push_failure_time_seconds > push_time_seconds .
Les push peuvent également échouer parce qu’ils sont mal formés. Dans ce cas, ils n’atteignent jamais aucun groupe de métriques et ne définiront donc aucune métrique push_failure_time_seconds . Ces poussées sont toujours comptées comme pushgateway_http_requests_total{code="400",handler="push"} . Vous pouvez alerter sur le rate de cette métrique, mais vous devez inspecter les journaux pour identifier le pousseur incriminé.
Le Pushgateway prend en charge TLS et l'authentification de base. Cela permet un meilleur contrôle des différents points de terminaison HTTP.
Pour utiliser TLS et/ou l'authentification de base, vous devez transmettre un fichier de configuration à l'aide du paramètre --web.config.file . Le format du fichier est décrit dans le référentiel exportateur-toolkit.
Notez que les paramètres TLS et d'authentification de base affectent tous les points de terminaison HTTP : /metrics pour le scraping, l'API pour transmettre les métriques via /metrics/..., l'API d'administration via /api/... et l'interface utilisateur Web.
Le binaire normal intègre les fichiers Web dans le répertoire resources . À des fins de développement, il est pratique qu'un binaire en cours d'exécution utilise directement ces fichiers (afin que vous puissiez voir immédiatement l'effet des modifications). Pour passer à une utilisation directe, ajoutez -tags dev à l'entrée flags dans .promu.yml , puis make build . Revenez au mode "normal" en annulant les modifications apportées à .promu.yml et en tapant make assets .
Les directives de style pertinentes sont les commentaires de Go Code Review et la section Formatage et style de Go: Best Practices for Production Environments de Peter Bourgon.
