Permettez-moi de discuter d'un sujet qui n'est pas intrinsèquement spécifique à PostgreSQL, mais que je rencontre régulièrement en enquêtant sur des problèmes sur les systèmes clients, en évaluant la "supportabilité" de ces systèmes, etc. , et pourquoi sar est toujours de loin mon outil préféré (du moins sous Linux).
Sur l'importance de la surveillance
Tout d'abord, la surveillance des métriques système de base (CPU, E/S, mémoire) est extrêmement importante. C'est un peu étrange d'avoir à signaler cela dans des discussions avec d'autres ingénieurs, mais je dirais qu'un ingénieur sur 10 pense qu'il n'a pas vraiment besoin de surveillance. Le raisonnement va généralement dans ce sens :
C'est vrai que la surveillance ajoute des frais généraux, sans aucun doute à ce sujet. Mais c'est probablement négligeable par rapport à ce que fait l'application. En fait, sar n'ajoute pas vraiment d'instrumentation supplémentaire, il s'agit simplement de lire les compteurs du nernel, de calculer les deltas et de les écrire sur le disque. Il peut avoir besoin d'espace disque et d'E/S (selon le nombre de processeurs et de disques), mais c'est à peu près tout.
Par exemple, la collecte de statistiques par seconde sur une machine avec 32 cœurs et plusieurs disques produira environ 5 Go de données brutes par jour, mais elle se compresse extrêmement bien, souvent à environ 5 à 10 %). Et c'est à peine visible en top . La résolution par seconde est un peu extrême, et l'utilisation de 5 ou 10 secondes réduira encore la surcharge.
Donc non, il s'avère que la surcharge n'est pas une raison valable pour ne pas activer la surveillance.
Coûts par rapport aux avantages
Plus important encore, "Combien de frais généraux est-ce que j'élimine en n'activant pas la surveillance ?" est la mauvaise question à poser. Au lieu de cela, vous devriez demander « Quels avantages puis-je retirer de la surveillance ? Les avantages l'emportent-ils sur les coûts ?"
Nous savons déjà que les coûts (frais généraux) sont assez faibles ou entièrement négligeables. Quels sont les bénéfices? D'après mon expérience, disposer de données de surveillance est effectivement inestimable.
Premièrement, cela vous permet d'enquêter sur les problèmes - regarder un tas de graphiques et rechercher des changements soudains est étonnamment efficace et vous mène souvent directement au bon problème. De même, comparer les données actuelles (collectées lors du problème) à une ligne de base (collectée quand tout va bien) est très utile, et impossible si vous n'activez la surveillance que lorsque les choses se cassent.
Deuxièmement, cela vous permet d'évaluer les tendances et d'identifier les problèmes potentiels avant qu'ils ne vous frappent réellement. Combien de CPU utilisez-vous ? L'utilisation du processeur augmente-t-elle avec le temps ? Existe-t-il des schémas suspects dans l'utilisation de la mémoire ? Vous ne pouvez répondre à ces questions que si la surveillance est en place.
Pourquoi sar est mon outil préféré
Supposons que je vous ai convaincu que la surveillance est importante et que vous devez absolument le faire. Mais pourquoi sar notre outil préféré, alors qu'il existe diverses alternatives sophistiquées, à la fois sur site et dans le cloud ?
- Il est inclus dans toutes les distributions, et est simple à installer/configurer. Il est donc assez simple de convaincre les gens de l'activer.
- C'est directement sur la machine. Ainsi, si vous vous connectez en SSH à la machine, vous pouvez également obtenir les données de surveillance.
- Il utilise une sortie texte simple. Trivial traite les données – importez-les dans une base de données, analysez-les, joignez-les à un ticket de support. C'est assez difficile avec d'autres outils qui ne vous permettent généralement pas d'exporter facilement les données, d'afficher uniquement des graphiques et/ou de restreindre considérablement les analyses que vous pouvez effectuer, etc.
J'admets que cela vient en partie du fait que je travaille pour une entreprise fournissant des services PostgreSQL à d'autres entreprises (qu'il s'agisse d'un support 24 × 7 ou d'un administrateur de base de données à distance. Nous n'avons donc généralement qu'un accès très limité aux systèmes clients (principalement uniquement des serveurs de base de données). et rien de plus). Cela signifie que disposer de toutes les données importantes sur le serveur de base de données lui-même, accessible via SSH, est extrêmement pratique et élimine les allers-retours inutiles uniquement pour demander une autre donnée à un autre système. Ce qui permet d'économiser du temps et de la santé mentale. des deux côtés.
Si vous avez de nombreux systèmes à gérer, vous préférerez probablement une solution de surveillance qui collecte les données de plusieurs machines à un seul endroit. Mais pour moi, sar gagne toujours.
Alors, comment le configurer ?
J'ai mentionné l'installation et l'activation de sar (ou plutôt sysstat , qui est le package comprenant sar ) est très simple. Malheureusement, la configuration par défaut est quelque peu mauvaise. Après avoir installé sysstat , vous trouverez quelque chose comme ça dans /etc/cron.d/sysstat (ou partout où votre distribution stocke cron configuration):
*/10 * * * * root /usr/lib64/sa/sa1 1 1
Cela dit effectivement le sa1 La commande sera exécutée toutes les 10 minutes et collectera un seul échantillon en 1 seconde. Il y a deux problèmes, ici. Premièrement, 10 minutes est une résolution assez faible. Deuxièmement, l'échantillon ne couvre qu'une seconde sur 600, donc les 9:59 restants n'y sont pas vraiment inclus. C'est assez acceptable pour les tendances à long terme, où un échantillonnage aléatoire à faible résolution est suffisant. À d'autres fins, vous devrez probablement faire quelque chose comme ceci :
* * * * * root /usr/lib64/sa/sa1 -S XALL 60 1
Qui collecte un échantillon par minute, et chaque échantillon couvre une minute. Le -S XALL signifie que toutes les statistiques doivent être collectées, y compris les interruptions, les périphériques de bloc individuels et les partitions, etc. Voir man sadc pour plus de détails.
Résumé
Donc, pour résumer cet article en quelques points simples :
- Vous devriez avoir une surveillance, même si vous pensez que vous n'en avez pas besoin. Une fois que vous rencontrez des problèmes, il est trop tard.
- Les coûts de surveillance sont probablement négligeables, mais certainement bien inférieurs aux avantages de disposer des données de surveillance.
sarest pratique et très efficace. Vous utiliserez peut-être autre chose à l'avenir, mais c'est un bon premier pas.- La configuration par défaut n'est pas particulièrement bonne (basse résolution, échantillons d'une seconde). Envisagez d'augmenter la résolution.
Une chose que je n'ai pas mentionnée est que sar ne traite que des métriques système - CPU, disques, mémoire, processus, pas des statistiques PostgreSQL. Vous devez également surveiller cette partie de la pile, bien sûr.
