SysOps Pratique Hors-série N°

Numéro

47

Avez-vous déjà entendu parler des « digital native » ? Le terme désignerait toute personne née et élevée dans un environnement numérique, en gros un « enfant du numérique », né entre la fin des années 80 et le début des années 90. Selon Wikipédia, cette génération aurait « grandi pendant l'explosion du Web documentaire (Web 1.0) et l'avènement du Web social (Web 2.0) » et aurait ainsi des facilités avec les nouvelles technologies.

Réunir le code source ouvert des organismes publics français / GitHub publie son rapport annuel 2019 / Un guide sur la maîtrise du risque numérique / Adopter les bons réflexes en télétravail / Exercer votre droit au déréférencement / L’open source boosté par la transformation numérique

Développé par un roboticien, PlotJuggler a été pensé pour répondre à des besoins de tracés très utiles au débogage de drones. Lorsque vous avez de nombreuses données à analyser, parfois en temps réel, il peut être très commode d’afficher celles-ci sous forme de graphiques. Si vous pouvez le faire simplement et avez la possibilité de leur appliquer de nombreuses opérations directement, alors vous gagnez en efficacité, c’est ce que propose PlotJuggler.

Une application historique, puissante, populaire avec une base utilisateurs énorme, une compatibilité multiplateforme ultra-large, un code et une API quasi inmaintenables, dirigée par un Dictateur Bienveillant À Vie comme chef de projet et unique développeur : Vim présente toutes les caractéristiques d’un projet libre à succès. Et donc aussi tous les problèmes qui irritent ses utilisateurs et les contributeurs qui auraient le courage de participer à son développement. Dans cet article, nous allons découvrir Neovim, un fork de Vim né de la frustration d’utilisateurs de l’éditeur.

À grand pouvoir, grande responsabilité. Ceci est également vrai quand on gère beaucoup de serveurs. Heureusement, nous avons une arme pour gérer l’armée de problèmes qui peuvent nous assaillir : la supervision.

Les événements systèmes (aussi nommés logs dans la suite de l’article) sont des éléments déterminants pour la supervision du bon fonctionnement du système d’exploitation. Leur intérêt est souvent sous-coté aussi bien du point de vue maintenance du système que de sa sécurité. Cet article a pour ambition de poser les bases d’une bonne gestion des logs.

Bien avant les métriques et les graphiques de performances, les journaux système étaient la première source pour dépanner un système ou un service qui posait problème. Et ils le sont toujours : par défaut, sans aucune configuration, n’importe quel système Linux ou service journalise son activité et ses erreurs. Mais tout comme les métriques, si vous commencez à avoir à administrer plusieurs systèmes, la question se pose de centraliser ces journaux pour pouvoir les consulter simplement. Et quel stockage utiliser ? Des solutions, privées comme Splunk, ou libres comme Kibana sont déjà très populaires. Mais leur type de stockage (ElasticSearch pour Kibana), avec un indexage pour la recherche plein texte, prend beaucoup de place à l’utilisation et en sauvegarde, pour un intérêt limité dans la majorité des cas d’utilisation. Dans cet article, nous allons découvrir Loki, une solution toute récente, plus légère, pour gérer vos journaux.

Par défaut, votre système journalise dans différents fichiers les événements qui se passent vous permettant de déceler une activité anormale et autre plantage. Mais vous avez aussi besoin de collecter des métriques de votre système et de ses applications, et de générer les graphiques associés. Car c’est seulement grâce à ces données et graphiques que vous pourrez faire de l’analyse de performance pour détecter les goulots d’étranglement, ou faire de la gestion de capacité en prédisant la future charge système. Un des moyens les plus simples de collecter des données d’un serveur est d’utiliser le démon Collectd.

Un système ne manque pas d’avoir des problèmes matériels, de plantage système, de performances, au niveau utilisateur ou noyau. Et malheureusement, les systèmes Linux ne sont pas exempts de ces problèmes à dépanner. Mais heureusement, Linux n’est pas en reste d’outils pour vous aider à diagnostiquer les problèmes. Des outils simples comme top pour surveiller l’usage CPU, ou ps pour les processus. Vous voulez tracer un appel système d’un processus : strace est votre ami. tcpdump, ou tshark vous aideront à inspecter le trafic réseau en ligne de commandes. Vous avez donc beaucoup d’outils à disposition, dans l’esprit « un outil précis pour une tâche unique », cher à Linux. Le problème c’est que lorsque l’on dépanne un système, on n’a pas le temps de se souvenir de tous les outils à disposition et taper toutes ces commandes en live. Outils qui ont chacun une philosophie différente, une interface d’entrée et de sortie différentes, ce qui peut poser soucis dans des situations stressantes et créer de la confusion lors d’occasions qui demandent de réagir dans l’urgence. Surtout que la plupart de ces outils ne sont pas pensés et optimisés pour être utilisés dans des conteneurs, plateformes de plus en plus utilisées et répandues.

Cet article prolonge mon précédent article [1] et parle de la capacité à introduire de la haute disponibilité dans les environnements de conteneurs Docker, critère indispensable pour pouvoir utiliser ces technologies jusqu’à la production, ceci au travers de la notion de cluster et d’orchestration de conteneurs.

Vous avez une vie sociale bien remplie et il vous est impossible de retenir les anniversaires de vos amis ? Vous vivez en ermite et n’êtes même pas capable de vous souvenir du prénom de votre voisin de palier ? Alors Monica est fait pour vous et va vous aider à gérer vos contacts personnels.