Bonjour, chers lecteurs!
Dans la première note sur posgres_exporter , j'ai examiné un cas assez spécial lorsque je travaillais avec un nouveau fitcha à ce moment-là, à savoir la possibilité de surveiller un ensemble d'instances et / ou de bases de données par un exportateur. Et il a décrit ce «bouquet» de problèmes qu'il a rencontrés et les solutions de contournement qu'il a utilisées pour le faire fonctionner.
Et donc, le 25 novembre, la prochaine version de postgres_exporter 0.8.0 est sortie. Il a résolu les problèmes décrits dans l'article précédent et, ce qui est particulièrement agréable, a ajouté de nouvelles fonctionnalités.
Je demande un chat ...
Pour commencer, je voudrais vous présenter plus en détail postgre_exporter et écrire une sorte de petit guide de démarrage rapide. Passons en revue les points principaux:
- Variables d'environnement et paramètres de démarrage
- Quelles sont les mesures par défaut?
- Comment ajouter vos propres métriques
La description
postgres_exporter - un utilitaire pour collecter des métriques à partir d'instances d'un cluster SGBD PostgreSQL dans un format Prometheus accessible, écrit en Go, est open source et distribué gratuitement.
Variables d'environnement et arguments de ligne de commande
Postgres_exporter, en tant que tel, ne possède pas de fichier de configuration et tous les paramètres sont transmis à l'exportateur via des variables d'environnement ou via des arguments de ligne de commande. Dans le même temps, les paramètres de connexion au SGBD ne peuvent être transférés que via des variables d'environnement.
Variables d'environnement
Comme mentionné ci-dessus, les variables d'environnement peuvent être divisées en deux groupes. Les premiers passent la chaîne de connexion, les seconds dupliquent les arguments de la ligne de commande.
Commençons par le premier groupe. Ces variables commencent par le préfixe DATA_SOURCE_ :
DATA_SOURCE_NAME - utilisé par défaut. Vous permet d'enregistrer la chaîne de connexion au format = et sous la forme d'un URI et peut contenir l'identifiant et le mot de passe de la connexion.
Options de travail valides pour la connexion à PostgreSQL:
postgresql://rolename@dbhost:dbport/datname?sslmode=disable ;postgresql://rolename:rolpass@dbhost:dbport?sslmode=disable&db=datname ;postgresql://rolename:rolpass@?sslmode=disable&dbname=database&host=dbhost&port=dbport ;postgresql://rolename:rolpass@?sslmode=disable&dbname=database&host=/tmp (connexion via un socket UNIX, extraite des répertoires unix_socket_directories d'une instance PostgreSQL);host=dbhost port=dbport dbname=database user=rolename sslmode=disable ;
Si vous devez vous connecter à plusieurs instances (l'utilisation d'un espace après le point décimal n'est pas autorisée):
postgresql://rolename@dbhost:dbport/datname?sslmode=disable,postgresql://rolename@dbhost:dbport/datname?sslmode=disable ;sslmode=disable dbname=postgres host=127.0.0.1 port=5434 user=postgres,sslmode=disable dbname=postgres port=5432 user=postgres .
- DATA_SOURCE_URI - Alternative à DATA_SOURCE_NAME. Cette option ne convient que si vous avez l'intention de vous connecter à une seule instance de PostgreSQL).
La variable DATA_SOURCE_URI définit la partie de l'URI sans nom d'utilisateur et mot de passe, sous la forme "dbhost: dbport / dbname? Key = value". Le nom d'utilisateur et le mot de passe sont extraits des variables d'environnement DATA_SOURCE_USER et DATA_SOURCE_PASS, ou des fichiers DATA_SOURCE_USER_FILE DATA_SOURCE_PASS_FILE.
Lorsque le nom d'utilisateur et le mot de passe sont stockés dans des fichiers, leur contenu est extrait et réaffecté aux variables DATA_SOURCE_USER et DATA_SOURCE_PASS. En outre, dans le code, tout cela est collecté dans un URI à part entière du formulaire: "postgresql://" + DATA_SOURCE_USER + ":" + DATA_SOURCE_PASS + "@" + DATA_SOURCE_URI - DATA_SOURCE_URI_FILE - identique à DATA_SOURCE_URI, lu uniquement à partir du fichier;
- DATA_SOURCE_USER - lors de l'utilisation de DATA_SOURCE_URI, définit le nom d'utilisateur pour la connexion au SGBD;
- DATA_SOURCE_USER_FILE - identique à DATA_SOURCE_USER, lu uniquement à partir du fichier;
- DATA_SOURCE_PASS - lors de l'utilisation de DATA_SOURCE_URI, définit le mot de passe utilisateur pour la connexion au SGBD;
- DATA_SOURCE_PASS_FILE - identique à DATA_SOURCE_PASS, lu uniquement à partir du fichier;.
Le deuxième groupe comprend des arguments en double variables. C'est-à-dire au démarrage, vous avez le choix, définissez les paramètres de fonctionnement de l'application sous forme de variables d'environnement ou passez comme arguments au démarrage. Commencez par le préfixe PG_EXPORTER_ :
- PG_EXPORTER_WEB_LISTEN_ADDRESS - définit l'adresse et le port par lesquels l'exportateur recevra les demandes de Prometheus. Par défaut
:9187 ; - PG_EXPORTER_WEB_TELEMETRY_PATH - le chemin le long duquel les métriques sont données. Par défaut
/metrics ; - PG_EXPORTER_DISABLE_DEFAULT_METRICS - désactive la collection de métriques par défaut. Le fait que ces mesures seront ci-dessous. Seul vrai ou faux accepte les valeurs. Faux par défaut (la collecte de métriques est autorisée);
- PG_EXPORTER_DISABLE_SETTINGS_METRICS - désactive la collecte de métriques à partir de la vue pg_settings. Le fait que ces mesures seront ci-dessous. Seul vrai ou faux accepte les valeurs. Faux par défaut (la collecte de métriques est autorisée);
- PG_EXPORTER_AUTO_DISCOVER_DATABASES - détecte toutes les bases de données d'une instance de cluster pour collecter leurs métriques. Seul vrai ou faux accepte les valeurs. Par défaut, false (les métriques sont collectées uniquement dans la base de données spécifiée dans les paramètres de connexion);
- PG_EXPORTER_EXCLUDE_DATABASES - exclut la base de données de la liste des bases de données pour lesquelles des mesures sont collectées si
PG_EXPORTER_AUTO_DISCOVER_DATABASES=true . Représente une liste de noms de base de données séparés par des virgules. La valeur par défaut est une chaîne vide. IMPORTANT :
- modèles template0 et template1 - pas besoin d'exclure, donc ils sont coupés au stade de l'obtention d'une liste de bases de données à partir de pg_databases;
- ne peut pas exclure la base de données spécifiée dans l'URI.
- PG_EXPORTER_EXTEND_QUERY_PATH - Chemin d'accès au fichier YAML qui contient les requêtes des utilisateurs. Le fichier queries.yaml contient des exemples;
- PG_EXPORTER_CONSTANT_LABELS - Étiquette (constante) ajoutée à toutes les métriques. Il est écrit comme une liste de paires
= , séparées par une virgule.
Arguments de ligne de commande
- web.listen-address est le même que PG_EXPORTER_WEB_LISTEN_ADDRESS;
- web.telemetry-path - identique à PG_EXPORTER_WEB_TELEMETRY_PATH;
- disable-default-metrics est identique à PG_EXPORTER_DISABLE_DEFAULT_METRICS;
- disable-settings-metrics est le même que PG_EXPORTER_DISABLE_SETTINGS_METRICS;
- les bases de données de découverte automatique sont les mêmes que PG_EXPORTER_AUTO_DISCOVER_DATABASES;
- exclude-databases est identique à PG_EXPORTER_EXCLUDE_DATABASES;
- extend.query-path - identique à PG_EXPORTER_EXTEND_QUERY_PATH;
- constantLabels - identique à PG_EXPORTER_CONSTANT_LABELS;
- dumpmaps - Affiche le contenu interne de la carte de métriques. Utilisé pour déboguer les demandes des utilisateurs. Ne démarre pas l'application;
- log.level - définit l'un des niveaux de journalisation possibles:
debug , info , warn , error , fatal ; - log.format - définit la méthode et le format de sortie du journal. Par exemple:
logger:syslog?appname=bob&local=7 ou logger:stdout?json=true . Par défaut, logger:stderr .
Mesures par défaut
- métriques - sont un certain ensemble de métriques de surveillance, dont la collection est définie directement dans le code. La collection - peut être désactivée en définissant les paramètres de ligne de commande --disable-default-metrics et / ou --disable-settings-metrics ou en définissant les variables d'environnement appropriées.
Je note que dans la version actuelle, le problème d'utilisation des métriques a été résolu lorsque la découverte automatique était activée, en raison de laquelle il y avait une duplication des métriques, ce qui entraînait des erreurs.
Par défaut, les mesures des vues suivantes sont envoyées à la surveillance:
- pg_stat_bgwriter;
- pg_stat_database;
- pg_stat_database_conflicts;
- pg_locks;
- pg_stat_replication;
- pg_stat_activity;
- pg_settings.
De ce à quoi vous devez faire attention sont pg_stat_replication et pg_stat_activity, car l'ensemble des champs retournés dépend de la version de PostgreSQL. Pour cela, la version du SGBD est vérifiée dans l'exportateur et la requête correspondante est sélectionnée. Vous ne pouvez pas spécifier de version dans les requêtes utilisateur. Il est supposé que l'administrateur sait à l'avance quelle version l'instance sera surveillée. Des problèmes peuvent également survenir si vous essayez de collecter des métriques par un exportateur à partir d'instances de versions différentes.
Avec les métriques de paramètres d'instance (pg_settings), tout est un peu plus simple, elles sont formées par la requête:
SELECT name, setting, COALESCE(unit, ''), short_desc, vartype FROM pg_settings WHERE vartype IN ('bool', 'integer', 'real');
Ainsi, par défaut, un ensemble de métriques n'est formé qu'à partir de valeurs numériques.
De plus, nous examinerons la conclusion de l'exportateur, y compris comment nous comprendrons pourquoi les mesures codées en dur ont leur droit d'exister. Par exemple, prenez deux mesures: shared_buffers et wal_sender_timeout. Dans la sortie de l'exportateur, pour chaque statistique, nous obtenons trois lignes.
La première ligne - représente l'indice et se compose du nom de la métrique dans postgres_exporter, une description (la colonne short_desc de la vue pg_settings) et si le type a été converti en type de base, il est indiqué lequel (la valeur entre crochets).
La deuxième ligne indique le type de valeur, en termes de Prométhée. Et la troisième ligne, une métrique avec un ensemble d'étiquettes et une valeur assignée.
Renvoie des valeurs pour shared_buffers.
# HELP pg_settings_shared_buffers_bytes Sets the number of shared memory buffers used by the server. [Units converted to bytes.] # TYPE pg_settings_shared_buffers_bytes gauge pg_settings_shared_buffers_bytes{server="127.0.0.1:5432"} 1.34217728e+08
pg_settings_shared_buffers_bytes - le nom de la métrique. Il, selon les règles de bonne forme, est composé du nom de la table, du nom de la métrique et de l'unité de mesure. Vient ensuite une brève description de la table pg_settings. Et enfin, une indication que la valeur métrique a été convertie en une unité d'octets (Unités converties en octets). Pourquoi cela vaut la peine de prêter attention à ce dernier, car directement dans la base de données, la valeur semble un peu différente, à savoir:
name | setting | unit | short_desc
Le type de métrique que nous avons est GAUGE, ce qui signifie qu'il peut prendre des valeurs arbitraires au fil du temps. Dans notre cas, le nombre de tampons, lors d'un réglage fin, peut changer dans les deux sens.
Vous pouvez en savoir plus sur les types de métriques et leurs différences dans la documentation Prometheus.
La métrique suivante est wal_sender_timeout. Les champs d'information sont collectés selon le même principe que celui décrit ci-dessus. Dans ce cas uniquement, la valeur métrique est convertie en secondes et la base de données est stockée en millisecondes. Avec cette fonctionnalité, vous devez être prudent et prendre en compte lors du traçage des graphiques.
# HELP pg_settings_wal_sender_timeout_seconds Sets the maximum time to wait for WAL replication. [Units converted to seconds.] # TYPE pg_settings_wal_sender_timeout_seconds gauge pg_settings_wal_sender_timeout_seconds{server="127.0.0.1:5432"} 60
La valeur stockée dans la base de données:
demo=
Toutes les valeurs ayant des unités sont réduites à deux types: mesures de volume en octets; métriques de temps en secondes.
Ensemble de mesures personnalisées
En plus ou à la place des mesures par défaut, vous pouvez utiliser les vôtres. Pour ce faire, définissez simplement le chemin du fichier, avec les requêtes des utilisateurs, via l'argument --extend.query-path = query.yaml ou via la variable d'environnement PG_EXPORTER_EXTEND_QUERY_PATH.
Le référentiel de projet a un fichier YAML avec des exemples: queries.yaml
Je note que par rapport à la version précédente, dans 0.8.0, de nouvelles clés master et cache_seconds ont été ajoutées. Dans l'exemple ci-dessous, nous analysons le format d'enregistrement et la fonction des champs.
Exemple de contenu du fichier queries.yaml
pg_database: query: "SELECT pg_database.datname, pg_database_size(pg_database.datname) as size_bytes FROM pg_database" master: true cache_seconds: 30 metrics: - datname: usage: "LABEL" description: "Name of the database" - size_bytes: usage: "GAUGE" description: "Disk space used by the database"
Clés et valeurs de l'exemple ci-dessus:
pg_database - un préfixe arbitraire pour les métriques renvoyées par la demande (obligatoire);query - contient une requête SQL (obligatoire);master - n'exécute la demande que dans la base de données spécifiée lors de la connexion à l'URI (base de données master). Obligatoire lors du démarrage de l'exportateur avec l'indicateur --auto-Discover-Database. Accepte vrai ou faux. Faux par défaut. (Facultatif);cache_seconds - temps pendant lequel les données du cache seront retournées. Il est réglé en quelques secondes;metrics - contient une liste de balises et de métriques;datname , size_bytes - élément de liste. Le nom de l'élément de liste doit correspondre au nom de la colonne dans la requête;usage - type de valeur. Accepte COUNTER, GAUGE, LABLE (plus dans la documentation Prometheus)description - Description de la métrique personnalisée
Exemples de mesures de retour:
# HELP pg_database_size_bytes Disk space used by the database # TYPE pg_database_size_bytes gauge pg_database_size_bytes{datname="dbtest1",server="localhost:5432"} 1.0105503e+07 pg_database_size_bytes{datname="demo",server="localhost:5432"} 2.813719199e+09 pg_database_size_bytes{datname="postgres",server="localhost:5432"} 4.735491e+06 pg_database_size_bytes{datname="template0",server="localhost:5432"} 7.758339e+06 pg_database_size_bytes{datname="template1",server="localhost:5432"} 7.758339e+06
Résumé
Eh bien, nous résumons tout ce que nous avons dans la dernière version de postgres_exporter 0.8.0. Fondamentalement, toutes les améliorations concernent la surveillance de plusieurs instances et / ou de plusieurs bases de données dans une instance.
- L'argument exclude-databases (apparu dans la version 0.6.0) vous permet d'exclure des bases de données de la liste des bases de données pour lesquelles des métriques seront collectées. Mais vous ne pouvez pas exclure la base de données spécifiée dans la connexion URI, car il s'agit d'une base principale;
- Vous pouvez maintenant utiliser des requêtes personnalisées pour des vues globales (pg_stat_activity, pg_stat_database, etc.) avec l'argument auto-discovery-databases. Pour ce faire, un champ maître supplémentaire a été ajouté, indiquant que la demande doit être exécutée uniquement dans la base de données maître;
- Vous pouvez maintenant utiliser les métriques par défaut avec l'argument auto-discovery-databases;
- Pour les demandes des utilisateurs, le champ cache_seconds a été ajouté, ce qui vous permet de définir la durée (en secondes) à laquelle la réponse du serveur à la demande correspondante sera mise en cache.
Les sources
- Prometheus [ 1 ] est une application open source utilisée pour surveiller et alerter les événements. Il écrit des métriques en temps réel dans une base de données de séries chronologiques construite à l'aide du modèle de requête HTTP, avec des requêtes flexibles et des alertes en temps réel.
- postgres_exporter est un exportateur de métriques PostgreSQL pour Prometheus.
Version, au moment de la rédaction, v 0.5.1. Versions prises en charge de PostgreSQL 9.4+ (mais comme la pratique l'a montré, cela fonctionne sur 9.3).