Technologies informatiques,
Recherche et développement

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.
[[public:services_en_ligne:herberger_ses_services_formation|< Retour à l'index]]

====== Observer vos serveurs ======

Voyez aussi: [[doc:formations:hebergement:serveur:proteger|protéger]] votre serveur.
===== Observer à distance =====

Une des solutions les plus simples pour surveiller l'usage et la charge d'un serveur reste [[doc:formations:hebergement:serveur:monitorix|Monitorix]]. [[https://www.zabbix.com|Zabbix]] et [[https://www.nagios.org/|Nagios]] sont extrêmement puissants... mais particulièrement lourds. Enfin, [[http://munin-monitoring.org/|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 [[http://nmon.sourceforge.net/pmwiki.php|nmon]] associé à ''nmonChart'' ([[http://nmon.sourceforge.net/docs/sampleC31.html|ex.]]). Nmon peut etre utilisé comme datalogger ou en mode interactif (ci-dessous).

===== Charges CPU et bande passante =====

  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.

===== Moduler la charge d'une tâche sur le serveur =====

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).

===== Services en place sur le serveur =====

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 [[http://www.iana.org/assignments/port-numbers|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. [[doc:formations:hebergement:serveur:proteger|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 intéressants =====

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)

===== Cron: lancer une commande régulièrement =====

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 [[doc:formations:hebergement:serveur:mattermost:installation|mattermost]]).
===== Filtrage des entrées de log =====


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.

==== Pollution par "cron" ====

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

==== Filtrer des lignes spécifiques ====

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.

====== Outils divers ======

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 : [[https://www.admin-magazine.com/HPC/Articles/How-Old-is-That-Data|agedu]].