Une des solutions les plus simples reste Monitorix. Zabbix et Nagios sont extrêmement puissants… mais particulièrement lourds. Munin est un choix intermédiaire et plus facilement cofigurable.

Une option en ligne de commande, mais qui permet de générer des graphiques est nmon associé à nmonChart (ex.). Nmon peut etre utilisé comme datalogger ou en mode interactif (ci-dessous).

apt-get install htop iotop iftop nmon

• htop vous permet d'observer la charge processeur et mémoire (les process les plus gourmands en premier)
• iotop vous permet d'observer les lectures/écritures disques
• iftop vous permet d'observer les transferts réseaux et la bande passante, ainsi que les connexion en cours (utilisez whois sur l'IP ou nslookup pour avoir davatange d'information si une connexion vous parait suspecte)
• nmon qui fait de tout, et que l'on peut lancer directement avec une configuration comme ceci NMON=cmdn nmon (cpu, memory, disk, network)

Ce sont des notions fondamentales et différentes lorsque vous cherchez à comprendre un ralentissament sur vos serveurs.

Il permettent aussi de vérifier l'activité d'un process, par exemple une installation un peu trop silencieuse… Pour ces dernières, vous pouvez aussi regarder l'évolution de l'espace disque avec df -hl ("h"= human readable, optionnel pour plus de finesse).

Enfin, iperf3 permet de mesurer la bande passante entre un serveur et un client. Côté serveur:

 sudo -u nobody /usr/bin/iperf3 -s -p 31304             # côté serveur
 iperf3 -c monserveur.com -p 31304 -f m -t 10 -b 500M   # côté client (m=Mbits/s, K=KO/s)

Pour info, 500Mbits/s correspond à 60Ko/s.

Pour moduler la charge d'une commande à exécuter sur le serveur, vous pouvez utiliser ces trois commandes

apt-get install nice ionice trickle

• nice permet de réduire la priorité d'une action (ex. nice tar cvzf …)
• ionice permet de réduire la priorité d'usage des disques durs (ex. ionice rsync …).
• trickle limite la bande passante utilisée par un process (ex. trickle -u 10 -d 20 … en KO/s).

Liste des services qui écoutent sur votre serveur:

netstat -tanp

ou un peu plus verbeux, et trié par utilisateur pour mieux s'y retrouver:

ss -puta | column -t | (read -r; printf "%s\n" "$REPLY"; sort -k7,7)

Il existe une liste très complète des ports sur le site officiel d'attribution IANA (et un exemple de recherche directe: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8118).

Le principe est:

• si vous voyez un service connu mais non nécessaire, désactivez-le (ou désinstallez-le)
• si vous voyez un service inconnu qui pointe vers un outil "louche", alors vérifiez doublement et éliminez le si possible, vous êtes peut être victime d'un rootkit (cheval de troie installé sur votre serveur à votre insu, cf. protection de vos serveurs).

Si votre serveur est lent à démarrer, voyez systemd-analyze critical-chain et ses variantes (dont le très pratique "plot" en SVG).

Journaux à regarder:

• /var/log/syslog: journal système principal
• /var/log/auth: qui s'identifie (ou essaye de s'identifier)
• /var/log/apache2/error.log: les erreurs générées par le serveur web Apache

Quelques lignes de commandes essentielles:

• tail -F <nomdufichier>
  • option utile qui se mettra a jour au fur et à mesure des ajouts dans le fichier
  • ex: tail -F /var/log/apache2/errors.log

• less <nomdufichier>: permet de parcourir vers le haut ou vers le bas le fichier avec les flêches, mais aussi de:
  • rechercher avec / suivi du texte, et de n (next) ou N (previous)
  • aller à une line donnée: 123G
  • aller en fin de document $G (end+goto)

Chaque utilisateur dispose d'une crontab dédiée.

On utilise souvent celle de root avec crontab -e (e=editer, l=lister), mais il est généralement plus propre et centralisé de créer une table /etc/cron.d/<ficherdédié> afin de séparer les tâches et de préciser l'utisateur qui doit les lancer (il existe une colonne de plus qu'avec crontab -e!).

Par exemple, /etc/cron.d/monbackup:

*/10 * * * * root /usr/local/bin/monbackup.sh » /var/log/monbackup.log 2>&1

Fera "tourner" le script mentionné toutes les 10 minutes, tous les jours, sous l'utilisateur root. Essayez d'utiliser tant que possible un utilisateur qui a le moins de droits possibles pour la tâche, là encore pour des raisons de sécurité. Les redirections > permettent de sauvegarder ce qui aurait été affiché dans la console (stdout). Le » permet d'ajouter au fichier déja existant. Enfin 2>&1 de rediriger stderr vers stdout (ce sont deux canaux différents!).

Attention, un piège classique est que cron ne définit pas de $PATH par défaut. Les chemins vers les exécutables doivent alors être spécifiés complètement (ex: /usr/local/bin/rdiffweb même si rdiffweb serait valable dans une session interactive). C'est sécurisant, mais on peut sinon lister les chemins habituels pour toute la table cron, via une ligne de ce type au début du fichier:

PATH=/usr/sbin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/bin

Un autre piège est que contrairement au crontab -e de l'utilisateur, les fichiers crons déposés dans le dossier /etc/cron.d interdisent certains caractères dans les commandes à lancer! C'est piégeux car aucune erreur ne sera fournie mais la commande ne sera pas exécutée (convention de nommage run-parts: pas de points, seulement des lettres, chiffres, souligné, tiret)

Cron a tendance à polluer /var/log/auth.log à chaque activation:

Sep  3 10:12:01 service CRON[32312]: pam_unix(cron:session): session opened for user root by (uid=0)
Sep  3 10:12:01 service CRON[32312]: pam_unix(cron:session): session closed for user root

On peut désactiver l'enregistrement des lignes de sessions non interactives via /etc/pam.d/common-session-noninteractive et y ajouter la ligne suivante, juste avant l'appel à pam_unix.so:

session [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid

Pour rediriger toute l'activité cron dans son propre journal, et l'empécher de polluer le syslog, il faut le retirer de la ligne catchall dans /etc/rsyslog.conf (dans la section RULES). Ensuite, on ajoute une règle qui lui est spécifique dans la section nommée "standard log files":

cron.* /var/log/cron.log

Enfin, redémarrer le système des journaux:

service rsyslog restart

On peut aussi/sinon filtrer directement par le contenu textuel du message, par exemlple ici api/stats.sh (faites attention à ne pas filtrer d'autres messages par inadvertance!), en modifiant /etc/rsyslog.conf pour y ajouter cette ligne en haut de la section RULES:

:msg, contains, "api/stats.sh" ~