Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Je travaille sur des bases en 8.4 et 9.0 sous CentOs 5.
Nous souhaitons mettre en place une surveillance de nos serveurs :
Nagios pour les alertes,
Munin pour les perfs,
PgFouine pour les requêtes.
J'aimerai avoir votre avis sur l'impact de nombreux changements de paramètres dans le fichier PostgreSQL.conf
# Journalisation des messages du Serveur
log_destination = 'stderr'
# Capture et redirection des traces
logging_collector = ON
# Destination des traces
log_directory = '/home/postgres/PG_LOG'
# Fichiers traces
log_filename = '%u-%H.log'
log_rotation_age = 1h
log_rotation_size = 0
log_truncate_on_rotation = ON
Avoir un fichier de trace à l'heure, sur un cycle d'une semaine, avec écrasement.
Ceci afin de pouvoir analyser plus facilement les traces et éviter d'avoir des fichiers trop gros.
# Durée de toutes les instructions
log_min_duration_statement = 0
# Tracer les Checkpoints
log_checkpoints = ON
# Tracer les Connexions
log_connections = ON
# Tracer les Déconnexions
log_disconnections = ON
# Formattage des lignes de traces
log_line_prefix = '%t [%p]: [%l-1] user=%u %h %s '
Pour pouvoir exploiter les traces avec PgFouine
# Tracer les attentes de verrous
log_lock_waits = ON
# Tracer les instructions SQL
log_statement = 'all'
# Tracer l'utilisation des fichiers temporaires
log_temp_files = 0
# Tracer les appels aux Fonctions PL
track_functions = pl
Tout ces changements peuvent ils avoir des impacts importants sur les performances ?
La taille des fichiers traces va t'elle explosé ?
Ce paramètrage est-il en adéquation avec la surveillance ?
Hors ligne
Le changement qui aura le plus gros impact à mon avis est le log_min_duration_statement à 0, c'est-à-dire que votre serveur tracera en log l'intégralité des requêtes. Si votre répertoire /home/postgres/PG_LOG est sur le même disque physique que la base, cela risque de beaucoup ralentir les accès disques, et sur un disque séparé cela fera aussi baisser les performances mais à moindre échelle. Cela risque de remplir également assez vite l'espace disque disponible.
Tout cela dépend bien sur du nombre de requêtes exécutées sur votre serveur chaque jour, ainsi que du taux de requêtes en écriture sur votre serveur.
En général, c'est un réglage que l'on peut faire quelques heures pour auditer une base, mais pas à laisser en production.
Julien.
https://rjuju.github.io/
Hors ligne
Pour commencer, on ne met pas à la fois log_min_duration_statement à 0 et log_statement à all. Soit l'un soit l'autre. De plus, si vous mettez l'un ou l'autre, vous allez tracer toutes les requêtes exécutées. Cela peut avoir une répercussion importante sur les performances du serveur. Tout dépend du nombre de requêtes que vous exécutez évidemment. Cela aura aussi un impact sur la taille des fichiers qui vont exploser.
Personnellement, je vous conseille de placer log_statement à none et log_min_duration_statement à une valeur légérement supérieur à ce que vous considérez comme tolérable pour une requête (par exemple 2 ou 3 secondes).
Pour infos, track_functions n'aura aucun impact au niveau des journaux applicatifs vu que les informations récupérées par ce paramètre ne sont pas tracées dans les journaux.
Le reste ne devrait pas gêner.
Guillaume.
Hors ligne
Vous voulez dire quoi par gérer les perfs par munin ?
Hors ligne
Bonjour à tous,
Merci pour le retour d'infos.
Sur un serveur en production, nous avons actuellement le paramètrage suivant :
log_filename = '%d.log'
log_truncate_on_rotation = on
log_rotation_age = 1d
log_min_duration_statement = 300
log_statement = 'all'
Cela veut-il dire que toutes les requêtes sont tracées + la durée pour celles qui s'exécutent en plus de 300 millisecondes ?
Nous avons 1 fichier trace par jour avec rotation sur un mois. La taille des fichiers varie entre 1 et 4 Go.
Cela est-il fortement pénalisant ?
Nous souhaitons tracer toutes les requêtes pour surveiller l'activité de certains utilisateurs. Y a t'il un autre moyen ?
Mais également pour pouvoir analyser avec pgfouine et peut être mettre en évidence certaines choses. Qu'en pensez-vous ?
Nous voulons utiliser Munin pour :
- La volumétrie
- Le nombre d'Insert, Update, Delete
- Les transactions validées, annulées
- Le hit ratio
Nous voulons utiliser Nagios pour :
- Alerter si la base ne répond pas
- Surveiller le nombre de connexions
- Surveiller les locks
Est-ce une bonne approche ? manque t'il certaines choses ?
Je pose beaucoup de questions mais je suis un tout petit DBA et j'ai grand besoin de votre aide pour progresser.
Hors ligne
Cela veut-il dire que toutes les requêtes sont tracées + la durée pour celles qui s'exécutent en plus de 300 millisecondes ?
Cela veut dire que toutes les requêtes sont tracées. Celles qui durent plus de 300 millisecondes sont tracées une deuxième fois avec leur durée d'exécution.
Cela est-il fortement pénalisant ?
Ça dépend énormément de votre système. Si vous avez des lenteurs, cela peut être un facteur aggravant.
Nous souhaitons tracer toutes les requêtes pour surveiller l'activité de certains utilisateurs. Y a t'il un autre moyen ?
Encore une fois, cela dépend du contexte. Quel est le but de cette surveillance ?
Mais également pour pouvoir analyser avec pgfouine et peut être mettre en évidence certaines choses. Qu'en pensez-vous ?
Généralement, on ne trace que les requêtes qu'on considère vraiment lente. Et quand on veut faire un audit du serveur, on trace toutes les requêtes mais seulement sur une certaine période. De toute façon, l'analyse d'un fichier de 4 Go par pgFouine n'est certainement pas une opération aisée : très consommateur en ressource, très long.
Est-ce une bonne approche ?
Oui.
manque t'il certaines choses ?
Ça dépend de votre cahier des charges. Nous utilisons uniquement Nagios et on lui fait surveiller pas mal de choses chez nos clients : changement de la configuration, connexion possible, nombre de connexions, taille des bases, retard des esclaves (en streaming replication ou avec Slony), dernier analyze, dernier vacuum, durée d'exécution de la requête la plus longue, fragmentation des tables et index, nombre de journaux, nombre de journaux restant à archiver, état de la dernière sauvegarde, sans compter un certain nombre de paramètres systèmes. Pour tout ce qui est PostgreSQL, check_postgres.pl est vraiment bien.
Guillaume.
Hors ligne
Guillaume,
Pas de remontée d'infos sur des lenteurs.
Le but de la surveillance et de pouvoir identifier, par exemple, une personne qui ferait un delete violent dans la base.
Nous avons mis en place des rôles de connexions et des rôles de groupes pour gérer un maximum d'utilisateurs (interfaçes logiciels), mais certains ont tout de même accès à PgAdmin ou autres.
A l'inverse, ne peut on pas écarter les utilisateurs logiciels qui font toujours les mêmes requêtes ?
Je prend note des autres points à surveiller.
Merci.
Hors ligne
Un DELETE violent OK. Mais ce qui vous embête, c'est le fait qu'il ait le droit de faire ce DELETE et que vous voulez l'en empêcher ou est-ce un problème du type "tout le monde est limite bloqué et je veux lui virer sa requête" ? dans le deuxième cas, il n'est pas nécessaire de tracer quoi que ce soit vu que l'information est disponible dans la vue pg_stat_activity.
A l'inverse, ne peut on pas écarter les utilisateurs logiciels qui font toujours les mêmes requêtes ?
Je ne comprends pas ce que vous voulez dire.
Guillaume.
Hors ligne
Merci pour la réponse sur munin.
Je pense que vous pouvez tout faire avec nagios, si c'est des graphes que vous voulez en plus il suffit de rajouter une interface web à nagios.
je pense Guillaume qu'ils voudraient pouvoir logguer toutes les requetes sauf celles qui reviennent tt le temps.
Dernière modification par kenrio (28/03/2012 10:11:06)
Hors ligne
Ce serait dommage. Une requête néfaste pour les performances n'est pas forcément une requête très lente. Ça peut aussi être une requête d'une durée acceptable mais qui est exécutée tellement de fois qu'elle prend toute la puissance du système.
Guillaume.
Hors ligne
Rebonjour,
Guillaume, oui, ce qui nous embête c'est qu'il a le droit de faire ce DELETE.
Kenrio, sur conseil de l'équipe en charge de Nagios (Centrion) il faut limiter le nombre de demande car énormément de machines supervisées. Et oui c'est bien de pouvoir logguer toutes les requêtes sauf celles qui reviennent toujours.
Hors ligne
oui c'est sur, par curiosité c'est quoi énormément de machines supervisées ?
Sinon utiliser tail_n_mail pour les requetes de delete ça serait pas utile ?
Hors ligne
Kenrio,
Je crois qu'il y a 10 machines Centrion pour 500 machines surveillées, mais je crois que tout n'est pas déployé encore. J'attend des retours d'infos sur la possibilé d'avoir notre propre Centrion pour surveiller les machines PostgreSQL.
Je ne connais pas tail_n_mail, je vais regarder cela de plus prés.
Merci.
Hors ligne
Pages : 1
