One place for hosting & domains

      Comment configurer un cluster Mesosphere prêt pour la production sur Ubuntu 14.04


      Introduction

      Mesosphere est un système qui combine un certain nombre de composants afin de gérer efficacement la création de clusters des serveurs et des déploiements hautement disponibles au-dessus d’une couche de système d’exploitation existante. Contrairement aux systèmes comme CoreOS, Mesosphere n’est pas un système d’exploitation spécialisé mais plutôt un ensemble de paquets.

      Dans ce guide, nous allons découvrir comment configurer un cluster hautement disponible dans Mesosphere. Cette configuration nous permettra de nous doter d’une fonctionnalité de basculement dans le cas où l’un de nos nœuds maîtres tomberait en panne, ainsi qu’un pool de serveurs esclaves qui gère les tâches planifiées.

      Au cours de ce guide, nous utiliserons des serveurs Ubuntu 14.04.

      Conditions prélables et objectifs

      Avant de suivre ce guide, il est fortement recommandé de revoir notre introduction à Mesosphere. Il s’agit d’un excellent moyen pour vous de vous familiariser avec les composants dont le système est composé et de vous aider à identifier de quoi chaque unité est responsable.

      Au cours de ce tutoriel, nous utiliserons six serveurs Ubuntu. Cela satisfait à la recommandation Apache Mesos qui préconise l’utilisation d’au moins trois maîtres dans un environnement de production. Cela permet également d’avoir un pool de trois serveurs de travail ou esclaves, qui se verront attribués du travail lorsque les tâches seront envoyées au cluster.

      Les six serveurs avec lesquels nous travaillerons utiliserons zookeeper pour suivre le serveur maître leader actuel. La couche Mesos, intégré au-dessus, offrira une synchronisation et une manipulation des ressources distribuées Elle est responsable de la gestion du cluster. Marathon, le système d’init distribué du cluster, est utilisé pour planifier des tâches et travailler manuellement sur les serveurs esclaves.

      Dans le cas de ce guide, nous supposerons que nos machines ont la configuration suivante :

      Nom d’hôteFonctionadresse IP
      maître1Maître Mesos192.0.2.1
      maître2Maître Mesos192.0.2.2
      maître3Maître Mesos192.0.2.3
      esclave1Esclave Mesos192.0.2.51
      esclave2Esclave Mesos192.0.2.52
      esclave3Esclave Mesos192.0.2.53

      Ubuntu 14.04 devrait être installé sur chacune de ces machines. Vous devriez compléter les éléments de configuration de base répertoriés dans notre guide de configuration du serveur initial Ubuntu 14.04.

      Une fois que vous aurez terminé les deux étapes ci-dessus, poursuivez la lecture de ce guide.

      Installer Mesosphere sur les serveurs

      La première étape pour faire fonctionner votre cluser consiste à installer le logiciel. Heureusement, le projet Mesosphere conserve un dépôt Ubuntu avec des packages à jour faciles à installer.

      Ajouter les dépôts Mesosphere à vos hôtes

      Sur tous les hôtes (maîtres et esclaves), suivez les étapes suivantes.

      Tout d’abord, ajoutez le dépôt Mesosphere à votre liste de sources. Pour suivre ce processus, la clé du projet Mesosphere devra être téléchargée à partir du serveur de clés Ubuntu, puis l’URL applicable de notre version Ubuntu développée. Le projet vous offre un moyen pratique de le faire :

      sudo apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF
      DISTRO=$(lsb_release -is | tr '[:upper:]' '[:lower:]')
      CODENAME=$(lsb_release -cs)
      echo "deb http://repos.mesosphere.io/${DISTRO} ${CODENAME} main" | sudo tee /etc/apt/sources.list.d/mesosphere.list
      

      Installer les composants nécessaires

      Une fois le dépôt Mesosphere ajouté à votre système, vous devez mettre à jour votre cache de package local pour avoir accès à votre nouveau composant :

      sudo apt-get -y update
      

      Ensuite, vous devez installer les packages nécessaires. Les composants dont vous avez besoin dépendront du rôle de l’hôte.

      Pour vos hôtes maîtres, vous avez besoin du package de méta mesosphere. Cela inclut les applications zookeeper, mesos, marathon et chronos :

      sudo apt-get install mesosphere
      

      Pour vos hôtes slave, vous avez uniquement besoin du package mesos, qui extrait également zookeeper comme dépendance :

      sudo apt-get install mesos
      

      Configurer les informations de connexion de Zookeeper pour Mesos

      Dans un premier temps, nous allons configurer nos informations de connexion à zookeeper. Il s’agit de la couche sous-jacente qui permet à tous vos hôtes de se connecter aux bons serveurs maîtres, c’est pourquoi il est logique de commencer ici.

      Nos serveurs maîtres seront les seuls membres de notre cluster zookeeper, mais l’intégralité de nos serveurs devront être configurés pour pouvoir communiquer en utilisant le protocole. Le fichier qui définit cela est le suivant /etc/mesos/zk.

      Sur tous vos hôtes, procédez à l’étape suivante. Ouvrez le fichier avec les privilèges root :

      sudo nano /etc/mesos/zk
      

      À l’intérieur, vous trouverez l’URL de connexion configurée par défaut pour accéder à une instance locale. Cela ressemble à ce qui suit :

      zk://localhost:2181/mesos
      

      Vous devez la modifier afin qu’elle pointe vers nos trois serveurs maîtres. Pour cela, vous devez remplacer localhost par l’adresse IP de notre premier maître Mesos. Nous pouvons ensuite ajouter une virgule après la spécification du port et reproduire le format pour ajouter nos deuxième et troisième maîtres à la liste.

      Dans notre guide, les adresses IP de nos maîtres sont les suivantes : 192.0.2.1, 192.168.2.2 et 192.168.2.3. En utilisant ces valeurs, notre fichier ressemblera à ce qui suit :

      zk://192.0.2.1:2181,192.0.2.2:2181,192.0.2.3:2181/mesos
      

      La ligne doit commencer par zk:// et se terminer par /mesos. Entre deux sont spécifiées les adresses IP de vos serveurs maîtres et les ports zookeeper (2181 par défaut).

      Enregistrez et fermez le fichier lorsque vous avez terminé.

      Utilisez cette même saisie dans chacun de vos maîtres et esclaves. Cela aidera chaque serveur individuel à se connecter aux bons serveurs maîtres et pouvoir ainsi communiquer avec le cluster.

      Paramétrer la configuration de Zookeeper des serveurs maîtres

      Sur vos serveurs master, nous devrons procéder à une configuration supplémentaire de zookeeper.

      La première étape consiste à configurer un numéro d’identification unique, de 1 à 255 pour chacun de vos serveurs maîtres. Il se trouve dans le fichier /etc/zookeeper/conf/myid. Maintenant, ouvrez-le :

      sudo nano /etc/zookeeper/conf/myid
      

      Supprimez toutes les informations qui se trouvent dans ce fichier et remplacez-les par un seul numéro, de 1 à 255. Le numéro attribué à chacun de vos serveurs maîtres doit être unique. Par souci de simplicité, il est plus facile de commencer par 1 et de progresser. Dans notre guide, nous utiliserons 1, 2 et 3.

      Notre premier serveur contiendra uniquement ce qui suit dans le fichier :

      1
      

      Enregistrez et fermez le fichier lorsque vous avez terminé. Procédez ainsi sur chacun de vos serveurs maîtres.

      Ensuite, nous devons modifier notre fichier de configuration zookeeper pour cartographier nos ID zookeeper sur les hôtes en tant que tel. Vous aurez ainsi la garantie que le service est bien en capacité de résoudre correctement chaque hôte à partir du système d’ID qu’il utilise.

      Maintenant, ouvrez le fichier de configuration zookeeper :

      sudo nano /etc/zookeeper/conf/zoo.cfg
      

      Dans ce fichier, vous devrez cartographier chaque ID sur un hôte. La spécification de l’hôte inclura deux ports. Le premier servira à communiquer avec le leader. Le second se chargera des élections au moment où un nouveau leader sera nécessaire. Les serveurs zookeeper sont identifiés par le terme « server » suivi d’un point et de leur numéro d’ID.

      Dans notre guide, nous utiliserons les ports par défaut pour chaque fonction et nos ID vont de 1 à 3. Notre fichier ressemblera à ce qui suit :

      server.1=192.168.2.1:2888:3888
      server.2=192.168.2.2:2888:3888
      server.3=192.168.2.3:2888:3888
      

      Ajoutez ces mêmes cartographies dans chacun des fichiers de configuration de vos serveurs maîtres. Enregistrez et fermez chaque fichier lorsque vous avez terminé.

      Avec cela, notre configuration zookeeper est achevée. Nous pouvons commencer à nous concentrer sur Mesos et Marathon.

      Configurer Mesos sur les serveurs maîtres

      Ensuite, nous allons configurer Mesos sur les trois serveurs maîtres. Suivez ces étapes sur chacun de vos serveurs maîtres.

      Modifier le Quorum pour refléter la taille de votre cluster

      Tout d’abord, nous devons ajuster le quorum nécessaire à la prise de décision. Il déterminera le nombre d’hôtes nécessaires pour que le cluster soit en état de fonctionnement.

      Le quorum doit être configuré de manière à ce que plus de 50 pour cent des membres maîtres soient présents pour prendre des décisions. Cependant, il nous faut également établir une certaine tolérance de défaillance dans le cas où, si tous nos maîtres ne sont pas présents, le cluster puisse toujours fonctionner.

      Nous disposons de trois maîtres. Par conséquent, le seul réglage qui satisfait à ces deux exigences est un quorum de deux. Étant donné que la configuration initiale suppose un réglage de serveur unique, le quorum est actuellement défini à un.

      Ouvrez le fichier de configuration du quorum :

      sudo nano /etc/mesos-master/quorum
      

      Remplacez la valeur par « 2 » :

      2
      

      Enregistrez et fermez le fichier. Procédez ainsi sur chacun de vos serveurs maîtres.

      Configurer le nom d’hôte et l’adresse IP

      Nous allons ensuite spécifier le nom de l’hôte et l’adresse IP de chacun de nos serveurs maîtres. Pour le nom de l’hôte, nous utiliserons l’adresse IP afin que nos instances n’aient pas de difficultés à se résoudre correctement.

      Pour nos serveurs maîtres, l’adresse IP doit être placée dans ces fichiers :

      • /etc/mesos-master/ip
      • /etc/mesos-master/hostname

      Tout d’abord, ajoutez l’adresse IP individuelle de chaque nœud maître dans le fichier /etc/mesos-master/ip. N’oubliez pas de la modifier sur chaque serveur afin qu’elle corresponde à la valeur applicable :

      echo 192.168.2.1 | sudo tee /etc/mesos-master/ip
      

      Maintenant, nous pouvons copier cette valeur sur le fichier du nom de l’hôte :

      sudo cp /etc/mesos-master/ip /etc/mesos-master/hostname
      

      Procédez ainsi sur chacun de vos serveurs maîtres.

      Configurer Marathon sur les serveurs maîtres

      Maintenant que Mesos est configuré, nous pouvons procéder à la configuration de l’implémentation du système init en cluster de Mesosphere.

      Marathon s’exécutera sur chacun de nos hôtes maîtres. Cependant, seul le serveur maître principal pourra planifier des tâches. Les autres instances de Marathon transmettront les requêtes de manière transparente sur le serveur maîtres.

      Tout d’abord, nous devons à nouveau configurer le nom de l’hôte pour l’instance de Marathon de chaque serveur. Encore une fois, nous utiliserons l’adresse IP dont nous disposons déjà dans un fichier. Nous pouvons la copier dans l’emplacement du fichier dont nous avons besoin.

      Cependant, la structure du répertoire de configuration de Marathon dont nous avons besoin n’est pas automatiquement créée. Nous allons devoir créer le répertoire pour pouvoir ensuite y copier le fichier :

      sudo mkdir -p /etc/marathon/conf
      sudo cp /etc/mesos-master/hostname /etc/marathon/conf
      

      Ensuite, nous devons définir la liste des maîtres zookeeper auxquels Marathon se connectera pour obtenir des informations et une planification. Il s’agit de la même chaîne de connexion zookeeper que nous avons utilisée pour Mesos afin que nous puissions tout simplement y copier le fichier. Nous devons le placer dans un fichier appelé master :

      sudo cp /etc/mesos/zk /etc/marathon/conf/master
      

      Notre service Marathon pourra ainsi se connecter au cluster Mesos. Cependant, nous souhaitons également que Marathon stocke ses propres informations dans zookeeper. Pour cela, nous utiliserons l’autre fichier de connexion zookeeper comme base et modifierons tout simplement le point final.

      Tout d’abord, copiez le fichier dans l’emplacement zookeeper de Marathon :

      sudo cp /etc/marathon/conf/master /etc/marathon/conf/zk
      

      Ensuite, ouvrez le fichier dans votre éditeur :

      sudo nano /etc/marathon/conf/zk
      

      Le point final est la seule partie que nous ayons besoin de modifier. Nous allons remplacer /mesos par /marathon :

      zk://192.0.2.1:2181,192.0.2.2:2181,192.0.2.3:2181/marathon
      

      C’est tout ce qu’il faut faire pour configurer Marathon.

      Configurer les règles d’init des services et redémarrer les services

      Ensuite, nous allons redémarrer les services de serveurs maîtres pour utiliser les paramètres qui nous avons configurés.

      Tout d’abord, nous allons nous assurer que nos serveurs maîtres exécutent uniquement le processus maître Mesos et non pas le processus esclave. Nous pouvons arrêter tout processus esclave actuellement en cours d’exécution (cela peut échouer mais ce n’est pas un problème car il s’agit uniquement de vérifier que le processus est arrêté). Nous pouvons également que le serveur ne commence pas avec le processus esclave au démarrage en créant un fichier de remplacement :

      sudo stop mesos-slave
      echo manual | sudo tee /etc/init/mesos-slave.override
      

      Maintenant, il ne reste plus qu’à redémarrer zookeeper, qui configurera nos élections maîtresses. Nous pouvons ensuite démarrer nos processus Mesos maître et Marathon :

      sudo restart zookeeper
      sudo start mesos-master
      sudo start marathon
      

      Pour obtenir un pic dans ce que vous venez juste de configurer, consultez l’un de nos serveurs maîtres notre navigateur web au port 5050 :

      http://192.168.2.1:5050
      

      Vous devriez voir l’interface principale de Mesos. Vous serez éventuellement informé que vous êtes redirigé vers le master actif en fonction de si vous vous êtes connecté au leader ou pas. Dans tous les cas, l’écran ressemblera à ce qui suit :

      Principale interface de Mesos

      Il s’agit d’une vue de votre cluster actuel. Vous n’y voyez pas grand-chose car il n’y a aucun nœud esclave disponible et aucune tâche a été démarrée.

      Nous avons également configuré Marathon, le contrôleur de tâches longue durée de Mesosphere. Il sera disponible sur le port 8080 sur l’un de vos maîtres :

      Interface principale de Marathon

      Nous allons brièvement voir comment utiliser ces interfaces une fois que nous avons configuré nos esclaves.

      Configurer les serveurs esclaves

      Maintenant que nous avons configuré nos serveurs maîtres, nous pouvons commencer à configurer nos serveurs esclaves.

      Nous avons déjà configuré nos esclaves avec les informations de connexion zookeeper de nos serveurs maîtres. Les esclaves eux-mêmes n’exécutent pas leurs propres instances zookeeper.

      Nous pouvons arrêter tout processus zookeeper qui fonctionne actuellement sur nos nœuds esclaves et créer un fichier de remplacement afin qu’il ne démarre pas automatiquement lorsque le serveur redémarre :

      sudo stop zookeeper
      echo manual | sudo tee /etc/init/zookeeper.override
      

      Ensuite, nous voulons créer un autre fichier de remplacement pour s’assurer que le processus maître Mesos ne commence pas sur nos serveurs esclaves. Nous allons également nous assurer qu’il est actuellement arrêté (il se peut que cette commande échoue si le processus est déjà arrêté. Ceci n’est pas un problème) :

      echo manual | sudo tee /etc/init/mesos-master.override
      sudo stop mesos-master
      

      Ensuite, nous devons configurer l’adresse IP et le nom de l’hôte, tout comme nous l’avons fait pour nos serveurs maîtres. Cela implique la mise en place de l’adresse IP de chaque nœud dans un fichier, cette fois sous le répertoire /etc/mesos-slave. Nous utiliserons également le nom de l’hôte pour accéder facilement aux services via l’interface web :

      echo 192.168.2.51 | sudo tee /etc/mesos-slave/ip
      sudo cp /etc/mesos-slave/ip /etc/mesos-slave/hostname
      

      Encore une fois, utilisez l’adresse IP de chaque serveur esclave pour la première commande. Cela garantira qu’elle est bien liée à la bonne interface.

      Maintenant, nous avons tous les éléments pour démarrer nos esclaves Mesos. Il nous suffit juste d’activer le service :

      sudo start mesos-slave
      

      Procédez ainsi sur chacune de vos machines esclaves.

      Pour voir si vos esclaves s’enregistrent avec succès dans votre cluster, revenez à l’un de vos serveurs maîtres au port 5050 :

      http://192.168.2.1:5050
      

      Maintenant, vous devriez voir le nombre d’esclaves actifs afficher « 3 » dans l’interface :

      Trois esclaves Mesos

      Vous pouvez également voir que les ressources disponibles dans l’interface ont été mises à jour pour refléter les ressources pooled dans vos machines esclaves :

      Ressources Mesos

      Pour obtenir de plus amples informations sur chacune de vos machines, vous pouvez cliquer sur le lien « Slaves » en haut de l’interface. Ceci nous donnera un aperçu de la contribution en ressources de chaque machine, ainsi que les liens vers une page de chaque esclave :

      Page des esclaves Mesos

      Démarrer des services sur Mesos et Marathon

      Marathon est l’utilitaire Mesosphere permettant de planifier les tâches de longue durée. Il est facile de penser que Marathon est le système init pour un cluster Mesosphere car il prend en charge les services de démarrage et d’arrêt, tout en planifiant les tâches et en s’assurant que les applications remontent si elles descendent.

      Vous pouvez également ajouter des services et des tâches à Marathon de quelques manières différentes. Nous allons uniquement couvrir les services de base. Les conteneurs Docker seront traités dans un prochain guide.

      Démarrer un service via l’interface Web

      La manière la plus directe de lancer un service rapidement sur le cluster consiste à ajouter une application par le biais de l’interface Web Marathon.

      Tout d’abord, consultez l’interface Web de Marathon sur l’un de vos serveurs maîtres. N’oubliez pas que l’interface de Marathon se trouve sur le port 8080 :

      http://192.168.2.1:8080
      

      À partir de là, vous pouvez cliquer sur le bouton « New App » dans le coin supérieur droit. Cela fera apparaître une superposition dans laquelle vous pouvez ajouter des informaions sur votre nouvelle application :

      Nouvelle application Marathon

      Complétez les champs avec les exigences de votre application. Seules les champs suivants sont obligatoires

      • ID : un ID unique que l’utilisateur choisi pour identifier un processus. Vous pouvez utiliser ce que vous voulez, mais il doit être unique.
      • Command : il s’agit de la commande réelle que Marathon exécutera réellement. Il s’agit du processus qui sera surveillé et redémarré en cas d’échec.

      En utilisant ces informations, vous pouvez configurer un service simple qui imprime simplement « hello » et se met en veille pendant 10 secondes. Nous allons appeler ce « hello » :

      Application simple de Marathon

      Une fois que vous reviendrez à l’interface, le service passera de « Deploying » à « Running » :

      Application Marathon en cours d'exécution

      Environ toutes les 10 secondes, l’élément « Tasks/Instances » passera de « 1/1 » à « 0/1 » au fur et à mesure que la quantité de mise en veille passe et le service s’arrête. Ensuite, Marathon redémarre automatiquement la tâche. Nous pouvons voir ce processus plus clairement dans l’interface Web de Mesos sur le port 5050 :

      http://192.168.2.1:5050
      

      Ici, vous pouvez voir le processus se terminer et être redémarré :

      Tâche de redémarrage de Mesos

      En cliquant sur « Sandbox » et que « stdout » d’une des tâches, vous pouvez voir la sortie « hello » en cours de production :

      Sortie Mesos

      Démarrage d’un service via l’API

      Nous pouvons également soumettre des services via l’API Marathon. Pour cela, il vous faudra y transmettre un objet JSON contenant tous les champs que la superposition contenait.

      Il s’agit d’un processus relativement simple. Encore une fois, les seuls champs requis sont id pour l’identificateur de processus et cmd qui contient la commande réelle à exécuter.

      Donc, nous devons créer un fichier JSON appelé hello.json avec ces informations :

      nano hello.json
      

      À l’intérieur, la spécification minimum devrait ressembler à ce qui suit :

      {
        "id": "hello2",
        "cmd": "echo hello; sleep 10"
      }
      

      Ce service fonctionnera correctement. Cependant, si nous souhaitons réellement émuler le service que nous avons créé dans l’IU web, nous devons ajouter quelques champs supplémentaires. Ces valeurs seront configurées par défaut dans l’IU web et nous pouvons les répliquer ici :

      {
        "id": "hello2",
        "cmd": "echo hello; sleep 10",
        "mem": 16,
        "cpus": 0.1,
        "instances": 1,
        "disk": 0.0,
        "ports": [0]
      }
      

      Sauvegardez et fermez le fichier JSON une fois que vous aurez fini.

      Ensuite, nous pouvons le soumettre en utilisant l’API Marathon. La cible est l’un de nos services maître de Marathon sur le port 8080 et le point de terminaison est /v2/apps. La charge de données de notre fichier, que nous nous pouvons y lire curl en utilisant la balise -d avec la balsise @ pour indiquer un fichier.

      La commande ressemblera à ceci :

      curl -i -H 'Content-Type: application/json' [email protected] 192.168.2.1:8080/v2/apps
      

      Si nous regardons l’interface Marathon, nous pouvons voir que l’ajout à bien été effectué. Il semble avoir exactement les mêmes propriétés que notre premier service :

      Deux services Marathon

      Vous pouvez surveiller et accéder au nouveau service exactement de la même manière que le premier service.

      Conclusion

      À ce stade, vous devriez avoir un cluster Mesosphere qui fonctionne. Pour le moment, nous avons uniquement abordé la configuration de base. Vous devriez cependant être en mesure de voir les possibilités qu’offre le système Mesosphere.

      Dans les futurs guides, nous allons voir comment déployer des conteneurs Docker sur votre cluster et utiliser certains outils plus en profondeur.



      Source link

      Comment utiliser les instructions Break, Continue et Pass pour travailler avec des boucles en Python 3


      Introduction

      En utilisant les for loops et les while loops en Python, vous pouvez automatiser et répéter efficacement des tâches.

      Cependant, il arrive parfois qu’un facteur externe vienne influencer la façon dont votre programme fonctionne. Le cas échéant, vous voudrez éventuellement que votre programme quitte complètement une boucle, saute une partie d’une boucle avant de continuer, ou ignorer ce facteur externe. Pour cela, vous pouvez utiliser les instructions break, continue et pass.

      Instruction Break

      Sous Python, l’instruction break vous donne la possibilité de quitter une boucle au moment où une condition externe est déclenchée. Vous intégrerez l’instruction break dans le bloc du code qui se trouve en dessous de votre instruction de boucle, généralement après une instruction conditionnelle if.

      Examinons d’un peu plus près un exemple qui utilise l’instruction break dans une boucle for :

      number = 0
      
      for number in range(10):
          if number == 5:
              break    # break here
      
          print('Number is ' + str(number))
      
      print('Out of loop')
      
      

      Dans ce court programme, le number de variables est initialisé à 0. Ensuite, une instruction for créé la boucle à condition que le number de variables soit inférieur à 10.

      Dans la boucle for se trouve une instruction if qui présente la condition suivante : if le number de variables est équivalent à l’entier 5, then la boucle se brisera.

      Dans la boucle se trouve également une instruction print() qui s’exécutera avec chaque itération de la boucle for jusqu’à ce que la boucle se brise, étant donné qu’elle se trouve après l’instruction break.

      Pour savoir de quelle manière nous sommes en-dehors de la boucle, nous avons inclus une dernière instruction print() en dehors de la boucle for.

      Une fois que nous exécutons ce code, nous obtenons la sortie suivante :

      Output

      Number is 0 Number is 1 Number is 2 Number is 3 Number is 4 Out of loop

      Cela montre qu’une fois le nombre entier évalué comme équivalent à 5, la boucle se brise, car le programme est instruit de le faire avec l’instruction break.

      L’instruction break provoque la rupture d’une boucle d’un programme.

      Instruction Continue

      L’instruction continue vous donne la possibilité de passer la partie d’une boucle où une condition externe est déclenchée mais de tout de même passer à l’exécution du reste de la boucle. C’est-à-dire que l’itération actuelle de la boucle sera interrompue, mais le programme reviendra au haut de la boucle.

      L’instruction continue se trouvera dans le bloc de code sous l’instruction de boucle, généralement après une instruction conditionnelle if.

      En utilisant le même programme de boucle for que dans la section Instruction Break, nous utiliserons une instruction continue plutôt qu’une instruction break :

      number = 0
      
      for number in range(10):
          if number == 5:
              continue    # continue here
      
          print('Number is ' + str(number))
      
      print('Out of loop')
      
      

      La différence entre le fait d’utiliser l’instruction continue plutôt qu’une instruction break est que notre code se poursuivra malgré la perturbation lorsque le number de variables sera évalué comme équivalent à 5. Examinons le résultat que nous obtenons :

      Output

      Number is 0 Number is 1 Number is 2 Number is 3 Number is 4 Number is 6 Number is 7 Number is 8 Number is 9 Out of loop

      Ici, Number is 5 n’apparaît jamais dans la sortie, mais la boucle continue après pour imprimer des lignes des numéros 6 à10 avant de quitter la boucle.

      Vous pouvez utiliser l’instruction continue pour éviter un code conditionnel profondément imbriqué ou optimiser une boucle en supprimant les cas fréquemment répétés que vous souhaitez rejeter.

      L’instruction continue pousse un programme à sauter certains facteurs qui se trouvent dans une boucle, puis à continuer le reste de la boucle.

      Instruction Pass

      Au déclenchement d’une condition externe, l’instruction pass vous permet de gérer la condition sans toucher à la boucle. La lecture de l’intégralité du code continuera, à moins qu’un break ou une autre instruction ne se produise.

      Comme pour les autres instructions, l’instruction pass se trouvera dans le bloc de code en dessous de l’instruction de la boucle, généralement après une instruction conditionnelle if.

      En utilisant le même bloc de code que celui ci-dessus, remplaçons l’instruction break ou continue par une instruction pass :

      number = 0
      
      for number in range(10):
          if number == 5:
              pass    # pass here
      
          print('Number is ' + str(number))
      
      print('Out of loop')
      
      

      L’instruction pass qui se produit après l’instruction conditionnelle if indique au programme de continuer à exécuter la boucle et d’ignorer le fait que le number de variables est évalué comme étant équivalent à 5 pendant l’une de ses itérations.

      Nous allons exécuter le programme et examiner le résultat :

      Output

      Number is 0 Number is 1 Number is 2 Number is 3 Number is 4 Number is 5 Number is 6 Number is 7 Number is 8 Number is 9 Out of loop

      En utilisant l’instruction pass de ce programme, nous remarquons que le programme fonctionne exactement comme s’il n’y avait pas d’instruction conditionnelle. L’instruction pass indique au programme de ne pas tenir compte de cette condition et de continuer à exécuter le programme normalement.

      L’instruction pass peut créer des classes minimales, ou agir comme un espace réservé lorsqu’on travaille sur un nouveau code et l’on pense à un niveau algorithmique avant de mettre en place des détails.

      Conclusion

      Sous Python, les instructions break, continue et pass vous permettront d’utiliser des boucles for et des boucles while plus efficacement dans votre code.

      Pour vous exercer à travailler avec les instructions break et pass, vous pouvez suivre notre tutoriel de projet « Comment créer un Twitterbot avec Python 3 et la bibliothèque Tweepy. »



      Source link

      Comment utiliser Journalctl pour consulter et manipuler les journaux Systemd


      Introduction

      L’un des avantages les plus éloquents de systemd est la journalisation des processus et des systèmes. Lorsque vous utilisez d’autres outils, les journaux se retrouvent généralement dispersés dans le système, traités par différents daemons et processus et leur interprétation peut s’avérer difficile lorsqu’ils s’étendent sur plusieurs applications. Systemd tente de résoudre ces problèmes en offrant une solution de gestion centralisée pour la journalisation de tous les processus du noyau et de l’espace utilisateur. Le système qui collecte et gère ces journaux est ce que l’on nomme le journal.

      Le journal est implémenté avec le daemon journald, qui gère tous les messages produits par le noyau, initrd, services, etc. Dans ce guide, nous allons traiter de la façon d’utiliser l’utilitaire journalctl qui peut servir à accéder et manipuler les données contenues dans le journal.

      Concept général

      L’une des principales motivations du journal systemd consiste à centraliser la gestion des journaux, quelle que soit l’origine des messages. Comme une grande partie du processus de démarrage et de gestion des services est traitée par le processus systemd, il est logique de normaliser la méthode de collecte et d’accès aux journaux. Le daemon journald collecte des données de toutes les sources disponibles et les stocke sous un format binaire qui permet une manipulation facile et dynamique.

      Cela nous offre un certain nombre d’avantages importants. En interagissant avec les données à l’aide d’un seul utilitaire, les administrateurs peuvent afficher les données du journal de façon dynamique en fonction de leurs besoins. Vous pouvez tout simplement visualiser les données de démarrage sur les trois derniers démarrages ou combiner les entrées du journal de manière séquentielle à partir de deux services liés pour déboguer un problème de communication.

      Le stockage des données du journal sous un format binaire signifie également que vous pouvez afficher les données sous des formats de sortie arbitraires en fonction de ce dont vous avez besoin à un moment donné. Par exemple, pour assurer une gestion quotidienne des journaux, vous avez peut-être l’habitude de visualiser les journaux sous un format syslog standard, mais si vous décidez ultérieurement de présenter les interruptions de service sous forme de graphique, vous pouvez générer chaque entrée en tant qu’objet JSON pour que votre service de graphique puisse le prendre en charge. Étant donné que les données ne sont pas écrites sur le disque en texte clair, vous n’aurez besoin d’aucune conversion si vous avez besoin d’un format à la demande différent.

      Le journal systemd peut soit être utilisé avec une implémentation syslog existante, soit remplacer la fonctionnalité syslog en fonction de vos besoins. Bien que le journal systemd couvre la plupart des besoins de journalisation de l’administrateur, il peut également venir compléter les mécanismes de journalisation existants. Par exemple, il se peut que vous utilisiez un serveur syslog centralisé pour compiler des données à partir de plusieurs serveurs, mais vous souhaitez peut-être également pouvoir imbriquer les journaux de plusieurs services sur un seul système avec le journal systemd. Vous pouvez faire les deux en combinant ces technologies.

      Configurer l’heure du système

      L’un des avantages de l’utilisation d’un journal binaire pour la journalisation est la possibilité d’afficher les enregistrements de journaux en UTC ou à l’heure locale selon les besoins. Par défaut, systemd affichera les résultats en utilisant l’heure locale.

      Pour cette raison, avant de commencer à travailler sur le journal, nous veillerons à ce que le fuseau horaire soit correctement défini. En fait, la suite systemd est fournie avec un outil nommé timedatectl qui peut vous y aider.

      Tout d’abord, déterminez quels sont les fuseaux horaires disponibles avec l’option list-timezones :

      timedatectl list-timezones
      

      Cela répertoriera les fuseaux horaires disponibles sur votre système. Une fois que vous trouverez celui qui correspond à l’emplacement de votre serveur, vous pouvez le configurer en utilisant l’option set-timezone :

      sudo timedatectl set-timezone zone
      

      Pour vous assurer que votre machine utilise maintenant l’heure qui convient, utilisez la commande timedatectl seule ou avec l’option status. L’affichage sera le même :

      timedatectl status
      
            Local time: Thu 2015-02-05 14:08:06 EST
        Universal time: Thu 2015-02-05 19:08:06 UTC
              RTC time: Thu 2015-02-05 19:08:06
             Time zone: America/New_York (EST, -0500)
           NTP enabled: no
      NTP synchronized: no
       RTC in local TZ: no
            DST active: n/a
      

      La première ligne devrait afficher la bonne heure.

      Visualisation du journal de base

      Pour voir les journaux collectés par le daemon journald, utilisez la commande journalctl.

      Lorsqu’utilisée seule, chaque entrée de journal qui se trouve dans le système s’affichera dans un pager (généralement less) pour que vous puissiez y naviguer. Les entrées les plus anciennes seront les premières :

      journalctl
      
      -- Logs begin at Tue 2015-02-03 21:48:52 UTC, end at Tue 2015-02-03 22:29:38 UTC. --
      Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
      Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
      Feb 03 21:48:52 localhost.localdomain systemd-journald[139]: Received SIGTERM from PID 1 (systemd).
      Feb 03 21:48:52 localhost.localdomain kernel: audit: type=1404 audit(1423000132.274:2): enforcing=1 old_en
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
      Feb 03 21:48:52 localhost.localdomain kernel: input: ImExPS/2 Generic Explorer Mouse as /devices/platform/
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  8 users, 102 roles, 4976 types, 294 bools, 1 sens,
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  83 classes, 104131 rules
      
      . . .
      

      Vous aurez probablement des pages et des pages de données à consulter, ce qui peut représenter des dizaines ou des centaines de milliers de lignes si systemd est installé sur votre système depuis longtemps. Cela montre combien de données sont disponibles dans la base de données du journal.

      Le format sera familier pour ceux qui sont habitués à la journalisation standard des syslog. Cependant, les données collectées proviennent d’un nombre plus important de sources que ne le permettent les implémentations syslog traditionnelles. Cela inclut les journaux des premiers processus de démarrage, le noyau, l’initrd et l’erreur standard d’application. Tous ces éléments sont disponibles dans le journal.

      Vous remarquerez peut-être que toutes les heures affichées sont à l’heure locale. Maintenant que nous notre heure locale est configurée sur notre système, elle est disponible pour chaque entrée du journal. Tous les journaux sont affichés en utilisant cette nouvelle information.

      Si vous souhaitez afficher les heures en UTC, vous pouvez utiliser la balise --utc.

      journalctl --utc
      

      Filtrage des journaux par heure

      Même s’il est très pratique d’avoir accès à une série aussi grande de données, il peut s’avérer difficile, voire impossible, d’inspecter et de traiter mentalement une telle quantité de données. Par conséquent, ses options de filtrage font partie des fonctionnalités les plus importantes de journalctl.

      Affichage des journaux du démarrage en cours

      L’option la plus basique que vous utiliserez éventuellement quotidiennement est la balise -b. Elle affichera toutes les entrées qui ont été recueillies depuis le dernier démarrage.

      journalctl -b
      

      Vous pourrez ainsi identifier et gérer plus facilement les informations qui correspondent à votre environnement actuel.

      Dans les cas où vous n’utilisez pas cette fonctionnalité et affichez plusieurs jours de démarrages, vous verrez que journalctl a inséré une ligne qui ressemble à ce qui suit à chaque défaillance du système :

      . . .
      
      -- Reboot --
      
      . . .
      

      Vous pouvez utiliser cela pour vous aider à séparer logiquement les informations en sessions de démarrage.

      Démarrages précédents

      Bien que, de manière générale, vous souhaitez afficher les informations du démarrage en cours, il arrivera parfois que les démarrages passés vous soient également utiles. Le journal peut enregistrer des informations de nombreux démarrages précédents, de sorte que journalctl puisse être créé pour afficher les informations facilement.

      Certaines distributions permettent de sauvegarder les informations des démarrages précédents par défaut, d’autres désactivent cette fonctionnalité. Pour activer les informations de démarrage persistantes, vous pouvez soit créer le répertoire pour stocker le journal en saisissant ce qui suit :

      • sudo mkdir -p /var/log/journal

      Ou vous pouvez modifier le fichier de configuration du journal :

      • sudo nano /etc/systemd/journald.conf

      Sous la section [Journal], configurez l’option Storage= sur « persistent » pour activer la journalisation persistante :

      /etc/systemd/journald.conf

      . . .
      [Journal]
      Storage=persistent
      

      Lorsque la sauvegarde des démarrages précédents est activée sur votre serveur, journalctl intègre quelques commandes pour vous aider à travailler avec des démarrages comme unité de division. Pour voir les démarrages dont journald a connaissance, utilisez l’option --list-boots avec journalctl :

      journalctl --list-boots
      
      -2 caf0524a1d394ce0bdbcff75b94444fe Tue 2015-02-03 21:48:52 UTC—Tue 2015-02-03 22:17:00 UTC
      -1 13883d180dc0420db0abcb5fa26d6198 Tue 2015-02-03 22:17:03 UTC—Tue 2015-02-03 22:19:08 UTC
       0 bed718b17a73415fade0e4e7f4bea609 Tue 2015-02-03 22:19:12 UTC—Tue 2015-02-03 23:01:01 UTC
      

      Vous verrez s’afficher une ligne pour chaque démarrage. La première colonne représente la valeur offset du démarrage que vous pouvez utiliser pour facilement référencer le démarrage avec journalctl. Si vous avez besoin d’une référence absolue, l’ID de démarrage se trouve dans la deuxième colonne. Vous pouvez déterminer l’heure à laquelle la session de démarrage renvoie en utilisant les deux spécifications chronologiques listées vers la fin.

      Pour afficher les informations de ces démarrages, vous pouvez utiliser des informations provenant de la première ou de la deuxième colonne.

      Par exemple, pour consulter le journal du démarrage précédent, utilisez le pointeur relatif -1 avec la balise -b :

      journalctl -b -1
      

      Vous pouvez également utiliser l’ID de démarrage pour rappeler les données d’un démarrage :

      journalctl -b caf0524a1d394ce0bdbcff75b94444fe
      

      Fenêtres d’heures

      Bien que la consultation des entrées du journal par démarrage soit très utile, il se peut que vous souhaitiez demander des fenêtres d’heures qui ne s’alignent pas correctement sur les démarrages du système. Cela peut être particulièrement pratique lorsque vous travaillez avec des serveurs de longue durée avec un temps de disponibilité significatif.

      Vous pouvez filtrer par des périodes de temps arbitraires en utilisant les options --since et --until, qui limitent respectivement les entrées affichées à celles qui suivent ou précèdent l’heure donnée.

      Les valeurs de l’heure peuvent se présenter sous différents formats. Pour les valeurs de temps absolus, vous devez utiliser le format suivant :

      YYYY-MM-DD HH:MM:SS
      

      Par exemple, nous pouvons voir toutes les entrées depuis le 10 janvier 2015 à 17 h 15 en saisissant ce qui suit :

      journalctl --since "2015-01-10 17:15:00"
      

      Si les composants du format ci-dessus sont supprimés, certaines valeurs par défaut seront appliquées. Par exemple, si la date est omise, le système supposera qu’il s’agit de la date du jour. Si le composant de l’heure est manquant, « 00:00 » (minuit) sera remplacé. Le champ des secondes peut également être laissé à la valeur par défaut de « 00 » :

      journalctl --since "2015-01-10" --until "2015-01-11 03:00"
      

      Le journal comprend également certaines valeurs relatives, nommées raccourcis. Par exemple, vous pouvez utiliser les mots « yesterday », « today », « tomorrow » ou « now ». Vous pouvez indiquer des heures relatives en préfixant la valeur numérotée de « – » ou « + » ou en utilisant des mots comme « ago » dans une construction de phrases.

      Pour obtenir les données de la veille, vous pourriez taper :

      journalctl --since yesterday
      

      Si vous recevez des rapports indiquant une interruption de service qui commence à 9 h 00 et s’est achevée il y a une heure, vous pourriez taper :

      journalctl --since 09:00 --until "1 hour ago"
      

      Comme vous pouvez le voir, il est relativement facile de définir des fenêtres flexibles de temps pour filtrer les entrées que vous souhaitez voir.

      Filtrer par intérêt des messages

      Nous avons précédemment appris certaines des façons qui vous permettent de filtrer les données du journal en utilisant des contraintes de temps. Au cours de cette section, nous allons discuter de la façon de filtrer vos données en fonction du service ou du composant qui vous intéresse. Le journal systemd intègre différents moyens de le faire.

      Par unité

      La façon probablement la plus pratique de filtrer vos données est de le faire par l’unité qui vous intéresse. Nous pouvons utiliser l’option -u pour filtrer nos données de cette façon.

      Par exemple, pour consulter tous les journaux d’une unité Nginx sur notre système, nous pouvons taper :

      journalctl -u nginx.service
      

      Généralement, vous voudrez probablement filtrer vos données par heure afin d’afficher les lignes qui vous intéressent. Par exemple, pour vérifier comment le service fonctionne aujourd’hui, vous pouvez taper :

      journalctl -u nginx.service --since today
      

      Ce type de concentration peut s’avérer extrêmement utile si vous souhaiter profiter de la capacité du journal à imbriquer les enregistrements de différentes unités. Par exemple, si votre processus Nginx est connecté à une unité PHP-FPM pour traiter le contenu dynamique, vous pouvez fusionner les entrées des deux par ordre chronologique en spécifiant les deux unités :

      journalctl -u nginx.service -u php-fpm.service --since today
      

      Cela peut grandement faciliter la détection des interactions entre les différents programmes et les systèmes de débogages au lieu de processus individuels.

      Par processus, utilisateur ou ID de groupe

      Afin de fonctionner correctement, certains services génèrent tout un panel de processus enfants. Si vous avez mis en évidence le PID exact du processus qui vous intéresse, vous pouvez également filtrer vos données par cette valeur.

      Pour ce faire, nous pouvons appliquer notre filtre en renseignant le champ _PID. Par exemple, si le PID qui nous intéresse est 8088, nous pourrions taper :

      journalctl _PID=8088
      

      À d’autres moments, vous voudrez afficher toutes les entrées enregistrées par un utilisateur ou un groupe spécifique. Vous pouvez le faire avec les filtres _UID ou _GID. Par exemple, si votre serveur web fonctionne sous l’utilisateur www-data, vous pouvez trouver l’ID de l’utilisateur en tapant ce qui suit :

      id -u www-data
      
      33
      

      Ensuite, vous pouvez utiliser l’ID qui a été renvoyé pour filtrer les résultats du journal :

      journalctl _UID=33 --since today
      

      Le journal systemd intègre de nombreux champs qui peuvent être utilisés pour le filtrage. Certaines d’entre eux sont passés à partir du processus en cours d’enregistrement et d’autres appliqués par journald en utilisant les informations qu’il recueille à partir du système au moment de la journalisation.

      Le résultat principal indique que le champ _PID est de ce dernier type. Le journal enregistre et indexe automatiquement le PID du processus en cours de journalisation qui permet un filtrage ultérieur. Pour en savoir plus sur tous les champs disponibles des journaux, saisissez :

      man systemd.journal-fields
      

      Nous allons traiter de certains de ces éléments dans ce guide. Cependant, pour le moment, nous allons étudier une option plus utile liée au filtrage de ces champs. Vous pouvez utiliser l’option -F pour afficher toutes les valeurs disponibles pour un champ donné du journal.

      Par exemple, pour consulter pour quels groupes d’ID le journal systemd dispose d’entrées, vous pouvez saisir :

      journalctl -F _GID
      
      32
      99
      102
      133
      81
      84
      100
      0
      124
      87
      

      Cela affichera toutes les valeurs que le journal a stockées pour le champ de l’ID du groupe. Cela peut vous aider à construire vos filtres.

      Par chemin de composants

      Nous pouvons également filtrer nos données en renseignant un emplacement de chemin.

      Si le chemin mène à un exécutable, journalctl affichera toutes les entrées qui impliquent l’exécutable en question. Par exemple, pour trouver les entrées qui impliquent l’exécutable bash, vous pouvez taper :

      journalctl /usr/bin/bash
      

      Généralement, si une unité est disponible pour l’exécutable, cette méthode est plus propre et donne de meilleures informations (entrées des processus enfants associés, etc). Cependant, il arrivera parfois que cela ne soit pas possible.

      Afficher les messages du noyau

      Les messages du noyau, ceux qui se trouvent généralement dans la sortie dmesg peuvent également être récupérés dans le journal.

      Pour afficher uniquement ces messages, nous pouvons ajouter les balises -k ou --dmesg à notre commande :

      journalctl -k
      

      Par défaut, cela affichera les messages du noyau du démarrage actuel. Vous pouvez spécifier un démarrage alternatif en utilisant les balises usuelles de sélection de démarrage dont nous avons précédemment parlé. Par exemple, pour obtenir les messages des cinq derniers démarrages, vous pourriez taper :

      journalctl -k -b -5
      

      Par priorité

      L’un des filtres auxquels s’intéressent souvent les administrateurs de système est la priorité des messages. Bien qu’il soit souvent utile de consigner les informations à un niveau très verbeux, pour digérer les informations disponibles, les journaux de faible priorité peuvent être déroutants et confus.

      Vous pouvez utiliser journalctl pour afficher uniquement les messages d’une priorité spécifiée ou au-dessus en utilisant l’option -p. Cela vous permet de filtrer les messages de priorité inférieure.

      Par exemple, pour afficher uniquement les entrées enregistrées au niveau des erreurs ou au-dessus, vous pouvez taper :

      journalctl -p err -b
      

      Cela vous montrera tous les messages indiquant une erreur, un état critique, un avertissement ou une urgence. Le journal implémente les niveaux de messages syslog standard. Vous pouvez utiliser soit le nom de la priorité, soit la valeur numérique correspondante. En partant de la plus haute à la plus basse, les priorités sont les suivantes :

      • 0 : emerg
      • 1 : alert
      • 2 : crit
      • 3 : err
      • 4 : warning
      • 5 : notice
      • 6 : info
      • 7 : debug

      Vous pouvez utiliser les numéros ou noms ci-dessus de manière interchangeable avec l’option -p. En sélectionnant une priorité, vous afficherez les messages marqués au niveau indiqué et aux niveaux supérieurs.

      Modification de l’affichage du journal

      Précédemment, nous vous avons montré comment utiliser le filtrage pour sélectionner des données. Il existe cependant d’autres façons de modifier la sortie. Nous pouvons ajuster l’affichage journalctl en fonction de divers besoins.

      Tronquer ou étendre le résultat

      Nous pouvons ajuster la façon dont journalctl affiche les données en l’instruisant de réduire ou d’étendre la sortie.

      Par défaut, journalctl affichera l’intégralité du résultat dans un pager, ce qui permet aux entrées de se diriger vers la droite de l’écran. Pour accéder à cette information, appuyez sur la touche de flèche droite.

      Si vous souhaitez tronquer le résultat, en insérant une ellipse à l’endroit où les informations ont été supprimées, vous pouvez utiliser l’option --no-full :

      journalctl --no-full
      
      . . .
      
      Feb 04 20:54:13 journalme sshd[937]: Failed password for root from 83.234.207.60...h2
      Feb 04 20:54:13 journalme sshd[937]: Connection closed by 83.234.207.60 [preauth]
      Feb 04 20:54:13 journalme sshd[937]: PAM 2 more authentication failures; logname...ot
      

      Vous pouvez également aller dans la direction inverse et demander à journalctl d’afficher toutes les informations dont il dispose, qu’il inclut des caractères non imprimables ou pas. Nous pouvons le faire avec la balise -a :

      journalctl -a
      

      Sortie sur Standard

      Par défaut, journalctl affiche la sortie dans un pager pour faciliter la consommation des données. Cependant, si vous prévoyez de traiter les données avec des outils de manipulation de texte, vous voudrez probablement pouvoir produire une sortie standard sur la sortie.

      Vous pouvez le faire avec l’option --no-pager :

      journalctl --no-pager
      

      Vous pouvez immédiatement acheminer votre résultat dans un utilitaire de traitement ou le rediriger vers un fichier sur le disque, en fonction de vos besoins.

      Formats de sortie

      Si vous traitez des entrées de journaux, comme mentionné ci-dessus, il vous sera probablement plus facile d’analyser les données si elles sont dans format plus digeste. Heureusement, le journal peut s’afficher sous divers formats selon les besoins. Vous pouvez le faire en utilisant l’option -o et un spécificateur de format.

      Par exemple, vous pouvez générer les entrées du journal dans JSON en tapant :

      journalctl -b -u nginx -o json
      
      { "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635", "__REALTIME_TIMESTAMP" : "1422990364739502", "__MONOTONIC_TIMESTAMP" : "27200938", "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d", "PRIORITY" : "6", "_UID" : "0", "_GID" : "0", "_CAP_EFFECTIVE" : "3fffffffff", "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee", "_HOSTNAME" : "desktop", "SYSLOG_FACILITY" : "3", "CODE_FILE" : "src/core/unit.c", "CODE_LINE" : "1402", "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading", "SYSLOG_IDENTIFIER" : "systemd", "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5", "_TRANSPORT" : "journal", "_PID" : "1", "_COMM" : "systemd", "_EXE" : "/usr/lib/systemd/systemd", "_CMDLINE" : "/usr/lib/systemd/systemd", "_SYSTEMD_CGROUP" : "/", "UNIT" : "nginx.service", "MESSAGE" : "Starting A high performance web server and a reverse proxy server...", "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973" }
      
      . . .
      

      Très utile pour l’analyse avec les utilitaires. Vous pourriez utiliser le format json-pretty pour obtenir une meilleure maîtrise sur la structure des données avant de les passer au consommateur JSON :

      journalctl -b -u nginx -o json-pretty
      
      {
          "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635",
          "__REALTIME_TIMESTAMP" : "1422990364739502",
          "__MONOTONIC_TIMESTAMP" : "27200938",
          "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d",
          "PRIORITY" : "6",
          "_UID" : "0",
          "_GID" : "0",
          "_CAP_EFFECTIVE" : "3fffffffff",
          "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee",
          "_HOSTNAME" : "desktop",
          "SYSLOG_FACILITY" : "3",
          "CODE_FILE" : "src/core/unit.c",
          "CODE_LINE" : "1402",
          "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading",
          "SYSLOG_IDENTIFIER" : "systemd",
          "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5",
          "_TRANSPORT" : "journal",
          "_PID" : "1",
          "_COMM" : "systemd",
          "_EXE" : "/usr/lib/systemd/systemd",
          "_CMDLINE" : "/usr/lib/systemd/systemd",
          "_SYSTEMD_CGROUP" : "/",
          "UNIT" : "nginx.service",
          "MESSAGE" : "Starting A high performance web server and a reverse proxy server...",
          "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973"
      }
      
      . . .
      

      Les formats d’affichage disponibles sont les suivants :

      • cat : affiche uniquement le champ du message en lui-même.
      • export : un format binaire adapté au transfert ou à la sauvegarde de données.
      • json : JSON standard avec une entrée par ligne.
      • json-pretty : JSON formaté pour une meilleure lisibilité par l’homme
      • json-sse : résultat formaté sous JSON enveloppé pour que l’événement add server-sen soit compatible
      • short : la sortie de style syslog par défaut
      • short-iso :le format par défaut a été augmenté pour afficher les horodatages d’horloge murale ISO 8601
      • short-monotonic : le format par défaut avec des horodatages monotones.
      • short-precise : le format par défaut avec précision à la microseconde près
      • verbose : affiche chaque champ de journal disponible pour l’entrée, y compris ceux généralement cachés en interne.

      Ces options vous permettent d’afficher les entrées du journal dans le format le plus adapté à vos besoins actuels.

      Surveillance active des processus

      La commande journalctl imite le nombre d’administrateurs qui utilisent tail pour la surveillance d’une activité active ou récente. Cette fonctionnalité est intégrée dans journalctl et vous permet d’accéder à ces fonctionnalités sans avoir à vous diriger vers un autre outil.

      Affichage des journaux récents

      Pour afficher une quantité d’enregistrements définie, vous pouvez utiliser l’option -n, qui fonctionne exactement comme tail -n.

      Par défaut, les 10 entrées les plus récentes s’afficheront :

      journalctl -n
      

      Vous pouvez spécifier le nombre d’entrées que vous souhaitez consulter en ajoutant un numéro après le -n :

      journalctl -n 20
      

      Suivi des journaux

      Pour suivre activement les journaux à mesure de leur écriture, vous pouvez utiliser la balise -f. Encore une fois, cela fonctionne comme vous pouvez vous y attendre si vous déjà utilisé tail -f:

      journalctl -f
      

      Maintenance des journaux

      Vous devez éventuellement vous demander combien coûte le stockage de toutes ces données que nous avons vues jusqu’à présent. En outre, vous pourriez vouloir nettoyer certains journaux anciens et libérer de l’espace.

      Trouver l’utilisation actuelle du disque

      Vous pouvez trouver la quantité d’espace que le journal occupe actuellement sur le disque en utilisant la balise --disk-usage :

      journalctl --disk-usage
      
      Journals take up 8.0M on disk.
      

      Suppression des anciens journaux

      Si vous souhaitez réduire votre journal, vous disposez de deux façons différentes de le faire (disponibles avec les versions 218 et ultérieures de systemd).

      Si vous utilisez l’option --vacuum-size, vous pouvez réduire votre journal en indiquant une taille. Les anciennes entrées seront supprimées jusqu’à que l’espace de journal total occupé sur le disque atteigne la taille demandée :

      sudo journalctl --vacuum-size=1G
      

      Il existe une autre façon de réduire le journal, qui consiste à fournir une heure de calcul avec l’option --vacuum-time. Le système supprime toutes les entrées au-delà de cette heure. Vous pourrez ainsi conserver les entrées qui ont été créées après une heure spécifique.

      Par exemple, pour conserver les entrées de l’année dernière, vous pouvez taper :

      sudo journalctl --vacuum-time=1years
      

      Limitation de l’expansion du journal

      Vous pouvez configurer votre serveur de manière à ce qu’il place des limites sur la quantité d’espace que le journal peut prendre. Pour cela, vous devez éditer le fichier /etc/systemd/journald.conf.

      Vous pouvez utiliser les éléments suivants pour limiter l’expansion du journal :

      • SystemMaxUse= : Spécifie l’espace disque maximal qui peut être utilisé par le journal dans un stockage persistant.
      • SystemKeepFree= : Spécifie la quantité d’espace libre que le journal doit laisser lors de l’ajout d’entrées du journal au stockage persistant.
      • SystemMaxFileSize= : contrôle la taille que les fichiers journaux individuels peuvent atteindre dans le stockage persistant avant la rotation.
      • RuntimeMaxUse= : Spécifie l’espace disque maximal qui peut être utilisé dans le stockage volatile (dans le système de fichiers /run).
      • RuntimeKeepFree= : Spécifie la quantité d’espace à mettre de côté pour d’autres utilisations lors de l’écriture des données sur un stockage volatile (dans le système de fichiers /run).
      • RuntimeMaxFileSize= : Spécifie la quantité d’espace qu’un fichier de journal individuel peut prendre en charge dans un stockage volatile (dans le système de fichiers /run) avant la rotation.

      En configurant ces valeurs, vous pouvez contrôler la façon dont journald consomme et conserve l’espace sur votre serveur. Gardez à l’esprit que SystemMaxFileSize et RuntimeMaxFileSize cibleront les fichiers archivés pour atteindre les limites indiquées. Ceci est important à retenir lors de l’interprétation du nombre de fichiers après une opération de nettoyage.

      Conclusion

      Comme vous pouvez le voir, le journal systemd est très utile pour collecter et gérer les données de votre système et de l’application. Une grande partie de la flexibilité provient des métadonnées complètes automatiquement enregistrées et de la nature centralisée du journal. La commande journalctl permet de profiter des fonctionnalités avancées du journal et de faire une analyse et un débogage relationnel des différents composants de l’application.



      Source link