Full Circle Magazine FR

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
**Welcome back learners, and a nod to those “just interested”. We are continuing from last issue with the very first topic, capacity planning. We are still busy with resource availability and troubleshooting. Last issue, we covered netstat and how you can use it to troubleshoot. This time, let us look at predicting the future... <queue spooky music>...

This is the final part of measuring and troubleshooting before we move on to the exciting topic of the kernel. The nice thing about Linux is that you are spoilt for choice, even if you don’t know it. There are many – yes, many – monitoring tools for Linux and that list grows each day. The LPI want you to know of some of them. You have to understand that the LPIC is a grooming certification for enterprise – so we look at enterprise products here. Usually, those with colourful dashboards. Therefore, I will start you off with some homework – you need to Google Cacti, Nagios, MRTG, and read the ‘about’ sections on their respective home pages. If you feel brave, you can install them at home to play with. (If I remember correctly, I botched my first Cacti install, but you don’t break anything).**

Chers apprenants, je salue votre retour, et je fais un coucou à ceux qui sont « juste intéressés ». Nous continuons la série suite au dernier numéro avec le tout premier sujet, la disponibilité des ressources. Nous nous occupons toujours de la gestion des ressources et le dépannage quand il y a un problème. Dans le dernier numéro, nous avons parlé de netstat et de la façon dont vous pouvez l'utiliser pour le « dépannage ». Cette fois-ci, examinons comment prédire l'avenir... <musique de //La quatrième dimension//>. 

Cette fois-ci, il s'agit de la dernière partie du chapitre sur les mesures et le dépannage avant d'attaquer le sujet passionnant du noyau. Ce qui est bien chez Linux, c'est que vous êtes gâté avec des choix, même si vous n'en êtes pas conscient. Il y a de nombreux - oui, de nombreux - outils de surveillance pour Linux et la liste s'allonge de jour en jour. Le LPI veut que vous en connaissiez quelques-uns. Il faut comprendre que la certification du LPI (LPIC) est une certification qui vous prépare pour les entreprises ; ainsi, nous examinons des produits d'entreprise ici. Généralement, ceux avec des tableaux de bord bien colorés. Je vais donc commencer en vous donnant des devoirs - il faudra chercher Cacti, Nagios, MRTG sur Google et lire les sections « about » sur leur page d'accueil respective. Si vous vous sentez courageux, vous pouvez les installer chez vous pour jouer avec. (Si mes souvenirs sont bons, j'ai bâclé ma première installation de Cacti, mais rien ne s'est cassé...)

**For the LPIC level2, we need to know about ‘collectd’. Collectd is used to collect statistics of a particular system. What it collects is governed by its plugins. As the name suggests, it is a collector. (I think the ‘d’ at the end of the name gives it away – it’s a daemon). It does not automatically display colourful graphs and charts like Cacti or Nagios. If you want to play with it, I suggest setting up an Ubuntu LAMP server. Installing collectd is as easy as:

sudo apt install collectd 

Once installed, head on over to: /etc/collectd, and open the ‘conf’-file:

sudo nano collectd.conf - please peruse the file. **

Pour le niveau 2 de la LPIC, nous devons connaître « collectd ». Collectd est utilisé pour recueillir des statistiques d'un système en particulier. Ses greffons gouvernent ce qu'il recueille. Comme son nom l'indique, c'est un collecteur. (Je trouve que le «d » à la fin de son nom le trahit, il s'agit d'un démon). Il n'affiche pas automatiquement des tableaux et graphiques colorés comme Cacti ou Nagios. Si vous voulez vous amuser avec, je vous conseille de configurer un serveur LAMP sous Ubuntu. L'installation de collectd est aussi facile que :

sudo apt install collectd 

Une fois l'installation terminée, allez à : /etc/collectd et ouvrez le fichier « conf » :

sudo nano collectd.conf  et ensuite examinez-le.

**If you find the ‘plugins’ section, you will see some lines uncommented and this is where you decide what you want. Just be aware that some of the plugins require additional setup. If you look further down this file, you will find the “Plugin configuration” section. There you will see templates for things like Apache, and what the plugin needs to work. In Apache’s case, a template with user / password and certificate is provided. Do not comment out the ‘rrd-tool’ as your reports are in “.rrd” format. If you look at the rrdtool configuration, you will see the path to where the rrd files will be saved (DataDir). Before you head off configuring, be aware that Ubuntu automatically starts the daemon after installation, so stop it with:

service collectd stop

but you know how to do this, right? As always, with services, double-check with:

service collectd status - it is a good habit.**

Si vous trouvez la section des « plugins » (greffons ou extensions), vous verrez que certaines lignes sont non commentées ; c'est ici que vous décidez ce que vous voulez. Il faut cependant savoir que certains des greffons nécessitent un paramétrage supplémentaire. Si vous regardez plus bas dans ce fichier, vous trouverez la section « Plugin configuration ». Là se trouvent des modèles pour des choses comme Apache et ce dont le greffon a besoin pour fonctionner. Dans le cas d'Apache, un modèle avec utilisateur/mot de passe et certificat est fourni. Il ne faut pas commenter l'outil « rrd-tool », car les rapports sont dans le format « .rrd ». Si vous regardez la configuration du rrdtool, vous verrez le chemin vers l'endroit où les fichiers rrd seront sauvegardés (DataDir). Avant de quitter la configuration, sachez qu'Ubuntu démarre le démon automatiquement après l'installation ; aussi, il faut l'arrêter avec :

service collectd stop

mais vous savez déjà comment faire cela, non ? Comme toujours, avec les services, revérifiez avec :

service collectd status, c'est une bonne pratique.

**So where can we see these plugin’s are working? Head over to /usr/share/collectd and list the contents. You should see a .db file. However, this is not a binary database file, you can open it with a text editor. This makes it really nice if you need to pipe it through grep – if you want to find something quickly. Please look at the layout of how this works, the first column gives you the name, eg: “voltage”, and the second column tells you how it gets a measurement – mostly “value:GAUGE:<range>”. You will see lots of others too; this is the source types of information collectd can gather. Note that collectd can collect data from local and remote servers. Please remember that you need to provision reasonable disk space if you are going to start collecting from a lot of servers. The drive of your /var folder should have enough free space for you to add your collected data. 

Let us have a look at this – head over to /var/lib/collectd/rrd – the default path in the collectd.conf-file (you can change this). Each server you tagged will have its own folder here in the FQDN format, so there is no confusion. If you go into one of the listed folders, you will see sub-folders which match your uncommented plugins in the collectd.conf file. Nice! See I told you Linux was easy! If you do not see how this ties up, please install collectd on an Ubuntu server and follow along. I have warned you about space, but I also need to warn you about running your disk ragged. Collectd constantly collects data, but only writes that data once every ten minutes. You can change this, but you do not want to write to the disk all the time.**

Bon, où peut-on voir que ces greffons fonctionnent ? Allez à /usr/share/collectd et listez-en le contenu. Vous devriez voir un fichier .db. Toutefois, il ne s'agit pas d'un fichier binaire de base de données et vous pouvez l'ouvrir avec un éditeur de texte. C'est vraiment sympa si vous avez besoin de le passer par grep, quand vous voulez trouver quelque chose rapidement. Veuillez regarder le tableau qui en montre le fonctionnement : la première colonne vous donne le nom, à savoir « voltage » et la seconde colonne vous dit comment c'est mesuré, pour la plupart « value:GAUGE:<range> » (valeur:INDICATEUR:<plage>). Vous en verrez beaucoup d'autres aussi : ce sont les types de sources d'informations que collectd peut rassembler. Notez que collectd peut recueillir des données de serveurs locaux et distants. Rappelez-vous, s'il vous plaît, qu'il faut avoir un espace disque raisonnable si vous allez recueillir des données à partir de beaucoup de serveurs. Le disque où se trouve votre dossier /var devrait avoir assez d'espace libre pour pouvoir y ajouter les données recueillies.

Regardons cela : allez à /var/lib/collectd/rrd, le chemin par défaut dans le fichier collectd.conf (vous pouvez le changer). Chaque serveur étiqueté aura son propre dossier ici dans le format FQDN, afin que les choses soient bien claires. Si vous examinez l'un des dossiers listés, vous verrez des sous-dossiers qui correspondent aux greffons non commentés dans le fichier collectd.conf. Chouette ! Oui, je vous avais bien dit que Linux est facile ! Si vous ne comprenez pas comment cela se fait, veuillez installer collectd sur un serveur Ubuntu et suivez tout avec moi. Je vous ai averti au sujet de l'espace disque, mais je dois vous avertir également sur le fait que vous risquez de déborder le disque. Collectd recueille des données constamment, mais n'écrit ces données qu'une fois toutes les dix minutes. Vous pouvez modifier cela, mais vous ne voudrez pas écrire sans cesse sur le disque. 

**Gathering all this data is good and well, but how do you read .rrd-files or get an overview of what you have collected?

Obviously our lab LAMP server at home does very little, so you can use “stress” to stress the server a bit to get a bit of a spike in the data. The study guide walks you through getting the graphing up via a git repository (nethuis.nl), but know there are plugins for tools like Nagios for collectd too. I suggest following the tutorial as it is fun, but it is not important for the exam.

To understand the needs of your organisation, you need to interpret the graphs and output you get – over time. This is important, the longer your snapshot, the better you can predict where your IT infrastructure is going. Graphing for a month trumps a day, and so forth. If your graphs are always going up, you will soon reach capacity and will have to plan accordingly. That is precisely what is meant by “capacity planning”. Be sure you are measuring the right metrics though – you need to measure SQL on a SQL server, Apache on a web server, etc. Measuring things like temperature, can assist in troubleshooting your environment, so do not think those are not important.**

Rassembler toutes ces données, c'est bien mais comment lire des fichiers .rrd ou avoir une vue d'ensemble de ce qui a été recueilli ?

Bien évidemment, le serveur LAMP du laboratoire domestique ne fait pas grand chose et vous pouvez utiliser « stress » pour le stresser un peu et créer une petite hausse dans les données. Le guide d'études vous amène pas à pas dans la création de graphiques via un dépôt git (nethuis.nl), mais il faut savoir qu'il existe aussi des greffons pour des outils comme Nagios pour collectd. Je vous conseille de suivre le tutoriel, car c'est amusant, mais ce n'est pas important pour l'examen.

Pour comprendre les besoins de votre organisation, vous devrez interpréter les graphiques et les sorties que vous obtenez au fil du temps. Cela est important, car, plus votre instantané sera long, mmeilleures seront vos prédictions concernant les orientations de votre infrastructure IT. Faire des graphiques sur un mois est meilleur que sur un jour, et ainsi de suite. Si vos graphiques ne font que monter, vous atteindrez bientôt la pleine capacité et allez devoir planifier en conséquence. C'est précisément ce que signifie la « planification des capacités ». Assurez-vous toutefois de faire les bonnes mesures - il faut mesurer SQL sur un serveur SQL, Apache sur un serveur Web, etc. La mesure de trucs comme la température peut vous aider à résoudre des problèmes dans votre environnement ; aussi, ne pensez pas qu'ils soient sans importance.

**Before you tell me about all the other wonderful tools out there, I know, but you need to know this for your LPIC2 exam. 

Now for a quick exam-type question:

When is historical data of resource usage important? (select THREE correct answers)?:
A. Predicting when resources will need to be increased.
B. Selecting a computer vendor.
C. Identifying processes killed during out-of-memory occurrences.
D. Diagnosing capacity problems.
E. Troubleshooting a software problem.**

Avant que vous ne me décriviez tous les autres merveilleux outils qui existent, je le sais, mais c'est celui-ci qu'il faut connaître pour l'examen LPIC2.

Maintenant, voici une question rapide de type examen :

Quand les données historiques de l'utilisation des ressources sont-elles importantes ? (choisissez TROIS reponses correctes) :

A. La prédiction du moment où les ressources devront être augmentées.
B. Le choix d'un vendeur d'informatique.
C. L'identification des processus tués pendant des instances de mémoire insuffisante.
D. Le diagnostic des problèmes de capacité.
E. La résolution d'un problème de logiciel.

**Did you have any difficulty in finding the correct answers immediately? (It is A,D,E). Then read the chapter in your study guide again please!

What mechanism does collectd use to gather monitoring information on systems?
A. It uses a library of plugins
B. A master server connects to a collectd service on each machine to collect information
C. It collects its own information on each server and sends it to a master server
D. It makes SNMP queries to the clients being monitored.

You KNOW this answer!**

Vous n'avez pas trouvé les réponses exactes tout de suite ? (C'est A, D, E). Alors, prière de relire le chapitre dans le guide d'études ! 

Quel mécanisme collectd utilise-t-il pour recueillir des informations de surveillance des systèmes ?
A. Il se sert d'une bibliothèque de greffons.
B. Un serveur maître se connecte à un service collectd sur chaque machine pour recueillir des informations.
C. Il recueille ses propres données sur chaque serveur et les envoie à un serveur maître.
D. Il envoie des questions SNMP aux clients sous surveillance.

Vous CONNAISSEZ  cette réponse !

**If you would like to jump ahead, or test your skills at an LPI exam, do a test paper here: https://www.itexams.com/exam/117-201. (These were once valid LPI questions and will ease you into the format).
• The new exam number is 201-400, 117-201 was the old one.
• The site does require signing up, but sign up with temporary email – not your real email.
• DO NOT learn these questions parrot fashion, as they are probably not real exam questions.

Let us know how you did – good or bad, it does not matter. Good, means you are ready to write and confident in your skills. Bad means you will be learning new stuff!! Yay! There is no downside here. If you do not know why an answer is the way it is, contact us.**

Si vous êtes impatient, ou voulez tester vos compétences face à un examen LPI, passez un test ici : https://www.itexams.com/exam/117-201. Ces questions faisaient autrefois partie de l’examen LPI et donc cela pourra vous être utile : 
• La nouvelle référence de l’examen est 201-400, l’ancienne était 117-201. 
• Le site nécessite une inscription, mais inscrivez-vous à l'aide d'une adresse mail temporaire, pas votre adresse principale. 
• N'APPRENEZ PAS ces questions par cœur, car ce ne sont probablement pas les vraies questions de l'examen. 

Dites-nous comment vous vous en êtes sorti, bien ou mal, peu importe. Bon signifie que vous êtes prêts pour l’examen et que vous avez confiance en vos compétences. Mauvais veut dire que vous devez encore apprendre de nouvelles choses !! Chouette ! Et ce n’est pas un problème. Si vous ne comprenez pas le sens d’une réponse alors, contactez-nous.