Voyez aussi: protéger votre serveur.

Une des solutions les plus simples pour surveiller l'usage et la charge d'un serveur reste Monitorix. Zabbix et Nagios sont extrêmement puissants… mais particulièrement lourds. Enfin, Munin est un choix intermédiaire et plus facilement configurable, et moins joli.

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 est plus moderne):

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)

Plutot que d'abuser de cron, il est souvent préférable d'utiliser systemd (voyez cet exemple pour mattermost).

Dans la version la plus simple, vous pouvez faire un less ou un grep sur /var/log/syslog et autres fichiers, mais c'est généralement difficile d'extraire la bonne information car ces journaux sont souvent détaillés et redondants, ce qui est bien pour diagnostiquer un problème.

En ligne de commande on peut se référer à deux outils chargés de vous faire des rapports synthétiques: logcheck -p (p pour paranoid), et logwatch qui est déjà plus verbeux.

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 la référence à 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 section catch-all 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 filtrer par le contenu "textuel" du message, toujours dans /etc/rsyslog.conf, en ajoutant cette ligne en haut de la section RULES. Par exemple pour ne plus voir l'éxécution des scripts cron dans le log auth.log

:msg, contains, "pam_unix(cron:session)" stop

Faites attention à ne pas filtrer d'autres messages par inadvertance.

Pour vérifier le sérieux d'une adresse IP qui a laissé une trace sur votre serveur: https://viz.greynoise.io/

Pour faire des statistiques sur l'obsolescence des fichiers : agedu.