Ceci est une ancienne révision du document !
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 châpitre sur les mesures et le dépannage avant d'attaquer le sujet passionnant du noyau. Ce qui est bien chez Linux est que vous êtes gâtés avec des choix, même si vous n'en est 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 LPU veut que vous en connaissiez quelques-uns. Il faut comprendre que la certification du LPI 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 respectif. 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 utiliser pour collecter des statistiques d'un système en particulier. Ses greffons gouvernent ce qu'il collecte. 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 l'examinez.
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 où 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 ». C'est ici que se trouvent des modèles pour de 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 regarder 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 habitude.
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.
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.
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.
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!
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.