Page 2 sur 3

Re: Support du traqueur

Posté : dim. 4 mars 2018 16:57
par Phil
Le traqueur a été mis à jour pour éviter la faille de sécurité CVE-2018-1058. A noter que, si vous exécutiez le traqueur dans une base de travail dédiée sans aucun privilège public conformément aux recommandations, le risque était de toute façon nul en ce qui concerne cette faille.

Re: Support du traqueur

Posté : dim. 17 juin 2018 13:29
par Phil
Merci à un DBA pour sa question :

"Les rapports font des full sur les tables du traqueur, il ne manquerait pas des index sur vos tables ?"

Réponse : vous utilisez le traqueur avec une version 9.4 ou inférieure de PostgreSQL. Le traqueur crée des index BRIN introduits en 9.5. Si vous voulez éviter les seq scan, vous pouvez mettre à jour votre version de PostgreSQL ou créer vos propres index B-Tree sur les tables du traqueur.
De manière générale, le traqueur utilise les petites et grandes innovations de PostgreSQL au fur et à mesure de leur mise à disposition :
- fonctionnalités json de PostgreSQL 9.3
- fonction pg_sleep_for de PostgreSQL 9.4
- indexation BRIN de PostgreSQL 9.5
- indexation BLOOM et wait events de PostgreSQL 9.6
- résumé automatique (autosummarize) des index BRIN, partitionnement déclaratif de PostgreSQL 10
- indexation automatique des partitions, procédures avec transactions embarquées de PostgreSQL 11
- ...

Re: Support du traqueur

Posté : sam. 15 sept. 2018 18:57
par Phil
La version 2.05.03 était la dernière version du traqueur compatible avec PostgreSQL 9.3. Cette version restera en ligne mais elle n'est plus maintenue.
Le traqueur en version 3.00.00 est compatible avec les versions PostgreSQL 9.4 à 12.

Support du traqueur

Posté : ven. 28 sept. 2018 18:42
par Phil
Merci à un administrateur RHEL pour sa question :

"Je n'ai rien du tout dans les infos mémoire remontées par le tracker, c'est toujours à 0. Bug ? Version de PostgreSQL 10.1, version de RHEL : 7.4 "

Réponse :

J'ai expérimenté un agrégat dans l'affichage des résultats concernant la mémoire, en interactif et dans les rapports produits par -r, donc il peut y avoir bug.
Mais s'il y a 0 partout, c'est plutôt le même problème que celui remonté le 3 novembre 2017.
Vérifiez votre version de psutil depuis un shell :

Code : Tout sélectionner

python
Python 2.7.5 (default, May  3 2017, 07:55:04)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-14)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import psutil
>>> psutil.__version__
'2.2.1'
Dans cet exemple, la version de psutil est trop ancienne, il faut au moins une version 4 (5+ recommandée).

Support du traqueur

Posté : lun. 8 oct. 2018 22:01
par Phil
Merci à un architecte pour sa question :

Depuis la 12.2.0.1, Oracle Database facilite le suivi des performances dans les configurations de type "Active Dataguard" (hot standby pour PostgreSQL) en autorisant l'enregistrement d'informations AWR concernant la standby dans la base primaire. Il est ensuite possible de produire des rapports et cela permet de suivre l'activité de la base de secours bien qu'elle soit en lecture seule. Est-ce possible avec le traqueur et PostgreSQL ?

Réponse :

Désolé, il est actuellement impossible d'utiliser le traqueur sur une hot standby, que ce soit en mode batch ou en mode interactif.
En mode batch, le traqueur peut enregistrer les informations dans un cluster distinct du cluster à superviser. Cependant, aucune opération INSERT n'est autorisée dans les transactions en lecture seule des hot standby, même si l'insertion concerne une table étrangère située dans un cluster en lecture/écriture. L'erreur obtenue sera "ERREUR: ne peut pas exécuter INSERT dans une transaction en lecture seule"
En mode interactif, le traqueur crée des tables temporaires. Permettre la création de tables temporaires dans les hot standby était discuté sur la liste pgsql-hackers. Ce sera donc peut-être possible à l'avenir mais ce n'est pas encore implémenté, même dans PostgreSQL 12. Je vais réfléchir à une solution permettant de contourner cette limitation mais je ne peux donner de délai concernant la disponibilité.

Support du traqueur

Posté : sam. 27 oct. 2018 21:58
par Phil
Il est ensuite possible de produire des rapports et cela permet de suivre l'activité de la base de secours bien qu'elle soit en lecture seule. Est-ce possible avec le traqueur et PostgreSQL ?
C'est fait en version 3.2.0. En mode batch (option -b H), le traqueur permet à présent d'historiser pg_stat_activity dans un fichier plat afin d'analyser l'activité des clusters en lecture seule (hot standby) de versions PostgreSQL 11 et supérieures.

Support du traqueur

Posté : ven. 22 mars 2019 15:48
par Phil
Merci à Patrice pour sa question :

"Nous utilisons PostgreSQL 8.4 avec Debian 6, est-il possible d'utiliser le traqueur avec des anciennes versions ?"

Réponse :

Le support LTS (long term support) de Debian 6 s'est arrêté en 2016. Je vous suggère d'envisager rapidement une mise à jour.
Le traqueur n'a de toute façon jamais fonctionné avec PostgreSQL 8.4. Il fonctionne avec PostgreSQL 9.3 et versions supérieures. Seules les versions 9.4 et supérieures sont encore activement supportées au 22/03/2019.
Il est bien sûr théoriquement possible d'adapter le script. Il faut pour cela se passer des blocs pl/pgsql anonyme et des "IF NOT EXISTS" au niveau DDL, renommer dans le script la colonne "query" de pg_stat_activity en "current_query" etc
Ce n'est cependant pas envisagé. Vous pouvez faire cette adaptation si vous le souhaitez ou sponsoriser un backport.

Re: Support du traqueur

Posté : mer. 18 sept. 2019 17:52
par Phil
Merci à un RSSI pour sa question :

"Dans la page supplémentaire de la sécurité du traqueur https://pgphil.ovh/traqueur_10_14.php vous suggérez de créer un utilisateur OS "traqueur" distinct de l'utilisateur OS "postgres" pour faire tourner localement le traqueur mais ensuite l'utilisateur "traqueur" doit être SUPERUSER au niveau du cluster.
En quoi est-ce utile puisque de toute façon tout utilisateur SGBD avec l'attribut SUPERUSER a automatiquement les mêmes droits que l'utilisateur OS "postgres" comme il est noté dans le communiqué sur la faille CVE-2019-9193 https://www.postgresql.org/about/news/1935/ ?
By design, there exists no security boundary between a database superuser and the operating system user the server runs under. As such, by design the PostgreSQL server is not allowed to run as an operating system superuser (e.g. "root"). The features for COPY .. PROGRAM added in PostgreSQL 9.3 did not change any of the above, but added a new command within the same security boundaries that already existed.
"


Réponse :

Vous avez tout à fait raison, ce compte OS supplémentaire n'empêcherait aucunement les actions malveillantes s'il était compromis puisque l'utilisateur traqueur "superuser" pourrait agir en tant qu'utilisateur OS "postgres" sur le serveur sans restriction. J'ai supprimé cette partie qui pouvait prêter à confusion.
Ce compte permettrait tout de même de limiter certaines erreurs humaines comme un rm malencontreux ou autre mais il obligerait aussi à modifier les droits sur la socket Unix, ce qui n'est pas souhaitable.

Re: Support du traqueur

Posté : mer. 5 févr. 2020 21:04
par Phil
La version 4.02.00 était la dernière version du traqueur compatible avec PostgreSQL 9.4. Cette version restera en ligne mais elle n'est plus maintenue.
Le traqueur en version 4.02.01 est compatible avec les versions PostgreSQL 9.5 à 13.

Re: Support du traqueur

Posté : lun. 10 févr. 2020 10:34
par Phil
Merci à Vincent pour sa question :

"J'ai cette erreur à l'utilisation du traqueur :

-bash-4.2$ ./traqueur.sh
traqueur 4.02.01 - https://pgphil.ovh - outil de diagnostic performance pour PostgreSQL 9.5 => 13
AVERTISSEMENT, aucune base dediee detectee et aucun parametre de connexion fourni, tentative de connexion sans parametres
AVERTISSEMENT, la base de travail n'est pas appelee traqueur
AVERTISSEMENT, l'utilisateur de connexion et le schema de travail ont des noms differents : postgres traqueur

INFORMATION, version de PostgreSQL detectee : 110006
INFORMATION, preparation de la collecte ...
INFORMATION, execution de la collecte et presentation des resultats ...
psql:/tmp/traqueur.16837:17: ERREUR: n'a pas pu ouvrir le fichier de contrôle d'extension « /usr/pgsql-11/share/extension/bloom.control » : Aucun fichier ou dossier de ce type

Version traqueur : 4.2.1
Version PostgreSQL : 11.6
Version RHEL : 7.7"


Réponse :

Le message est clair : l'extension Bloom n'est pas disponible. Sur RHEL 7, il faut installer le paquet postgresql11-contrib. L'indexation Bloom est moins importante que l'indexation Brin pour le traqueur.
J'ai ajouté une condition pour tester la disponibilité de l'extension Bloom et émettre un simple warning dans ce cas, c'est fait dès la 4.02.02.