Add Hugo migration

content/a-blog-life/2024-02-23-to-hugo/index.md

@@ -0,0 +1,9 @@
+---
+title: Hugo
+---
+
+Cela faisait presque 3 ans que ce blog tournait avec [Zola](https://www.getzola.org/).
+En soi, je pouvais totalement continuer avec ce moteur-là sans que cela n'engendre le moindre problème.
+Je suis cependant tombé sur le thème [Blowfish](https://blowfish.page/) pour [Hugo](https://gohugo.io/), qui m'a un peu tapé dans l'oeil : pas spécialement pour son esthéthique (il y a quelques points qui ne me conviennent pas), mais plutôt pour son côté (très) fonctionnel.
+
+La migration ne m'a demandé qu'une petite heure de travail pour tout basculer : toute ma structure de pensée était totalement reconnue, ainsi que les images de couverture (que je nomme `cover.{png|jpg|webp}`) correctement interprétées (beaucoup de thèmes considèrent obligatoire d'avoir des images ou une structure comme eux l'attendent, alors que je pense l'inverse : le thème doit être le plus laxiste possible pour que le contenu puisse s'y fondre sans avoir à y penser).

content/technologeek/systems/2021-08-23-zorin-os/index.md

@@ -0,0 +1,29 @@
+---
+title: ZorinOS
+description: Plein de bonnes idées basées sur Ubuntu et Gnome 3.38
+tags: [Linux, Ubuntu, Zorin]
+---
+
+J'ai pu essayer pendant quelques minutes la distribution [ZorinOS](https://zorin.com/os/), basée sur Ubuntu et GNOME 3.38.
+Le moins que je puisse dire, c'est qu'elle propose une intégration très intéressante (= pas bêtement du copié/collé d'autres environnements) et qu'elle vient avec ses propres spécificités, implémentées de manière très propre :
+
+* Le nouvel utilisateur est bien guidé,
+* Le thème est super propre,
+* Le menu principal se rapproche d'un menu sans publicités ni Candy Crush (= top 👍),
+* Plusieurs outils sont préinstallés (Connexion RDP, ...).
+
+La distribution est donc particulièrement bien faite, propose deux versions :
+
+* Une version "light", suffisante, et qui peut s'apparenter à n'importe quelle autre distribution "grand public",
+* Ainsi qu'une version "pro", payante - mais pas trop 😉 (49€), qui propose quelques fonctionnalités (principalement esthétiques) en plus, ainsi que quelques applications préinstallées - des captures d'écran, j'ai remarqué Audacity, Blender, ainsi que d'autres que je ne connaissais pas ([Planifiy](https://github.com/alainm23/planify), une application de gestion de tâches compatible avec NextCloud ; [Xournal++](https://xournalpp.github.io/) pour la prise de notes ; ... et [pas mal d'autres applications](https://zorin.com/os/pro/), que l'on peut sans doute installer sur n'importe quelle machine après un peu de recherche).
+
+{{< carousel images="gallery/*" >}}
+
+J'aime assez bien cette distinction "light / pro", puisqu'elle permet de disposer d'une machine configurée, où une maigre obole permet sans doute de participer aussi au développement de la distribution.
+J'aime assez bien les modèles "libres", où vous avez le choix entre vous débrouiller vous-même, participer au développement de l'application et payer (un peu) pour profiter d'un support parfois bienvenu.
+A côté de cela, une licence Windows 11 Home ou Pro, c'est entre
+
+J'ai vu (par la suite) que Zorin proposera bientôt [Zorin Grid](https://zorin.com/grid/), qui est un gestionnaire de parc informatique (sous Zorin aussi, du coup).
+J'imagine qu'il s'agit d'une architecture de type "Flight Control", avec un gestionnaire central et un agent installé sur chaque machine (et donc potentiellement extensible à d'autres distributions 😉).
+
+Pour une utilisation bureautique, Zorin semble clairement être une très bonne distribution, jolie, fonctionnelle et basée sur des standards reconnus (et généralement stables).

content/technologeek/systems/2023-08-24-slow-and-periodic-feedback/index.md

@@ -0,0 +1,155 @@
+---
+title: Slow and periodic feedback kills
+tags: [monitoring, alerting, feedback]
+---
+
+Les notes ci-dessous sont tirées du [DevOps Handbook](https://itrevolution.com/product/the-devops-handbook-second-edition/), dont j'avais déjà parlé il y a quelques temps, et touchent principalement à l'agrégation des journaux et des métriques.
+
+    In short, slow and periodic feedback kills.
+    – The Principles of Flow
+
+La récupération de métriques augmente la confiance que l'on peut avoir dans la solution.
+L'analyse de ces métriques garantit un juste retour d'informations, sous réserve qu'elles soient exploitées correctement.
+Ceci peut être réalisé en deux étapes:
+
+* La première étape consiste à agréger ces données dans un dépôt centralisé,
+* La seconde étape exigera une structuration correcte des données envoyées.
+
+## Collecte des données
+
+La collecte des données doit récupérer des données des couches métiers, applicatives et d'environnement.
+Ces données couvrent les évènements, les journaux et les métriques - indépendamment de leur source - le pourcentage d'utilisation du processeur, la mémoire utilisée, les disques systèmes, l'utilisation du réseau, ...
+
+
+* **Métier** : Le nombre de ventes réalisées, le nombre de nouveaux utilisateurs, les résultats de tests A/B, ...
+* **Application** : Le délai de réalisation d'une transaction, le temps de réponse par utilisateur, ...
+* **Infrastructure** : Le trafic du serveur Web, le taux d'occupation du CPU, ...
+
+Côté client, il convient de récupérer les erreurs applicatives, les transactions que l'utilisateur effectue, ...
+
+Au niveau du développement, on est parti pour agréger les informations liées aux pipelines de déploiement: statuts des builds, temps de mise à disposition d'une fonctionnalité, fréquence des déploiements, statuts des environnements, ...
+
+## Outil d'agrégation
+
+Le choix de l'outil d'agrégation doit permettre de collecter, enregistrer, visualiser, alerter, détecter des anomalies et appliquer des transformations statistiques.
+**Par exemple** : Nagios, Zabbix, LogStash, Datadog ou Riemann.
+Il faut aussi voir aussi du côté de StatsD, Grafana et Graphite.
+
+> As Adrian Cockcroft pointed out, "Monitoring is so important that our monitoring systems need to be more available and scalable than the systems being monitored.
+>
+> – Part IV - The Technical Practice of Feedback - **Create Telemetry to enable seeing and solving problems** (page 200)
+
+Par exemple, si un serveur Nginx arrête de répondre aux requêtes, il serait possible de corréler cet incident avec d'autres métriques : augmentation du temps de réponse (**Application**), mémoire disponible en baisse sur le serveur (**Infrastructure**) ou temps nécessaire à la réalisation d'une transaction sur la base de données.
+
+Histoire de schématiser, toute équipe se retrouve à un moment où un autre dans la situation suivante : personne ne veut appuyer sur le gros bouton rouge issu de l'automatisation de la chaîne de production et qui dit "Déploiement" (en clignotant).
+Et pour cause : une fois que nous aurons trouvé une joyeuse victime qui osera braver le danger, il y aura systématiquement des imprévus, des petits détails qui auront été oubliés sur le côté de la route, et qui feront lâchement planter les environnements.
+Et puisque nous n'aurons pas (encore) de télémétrie, le seul moment où nous comprendrons qu'il y a un problème, sera quand un utilisateur viendra se plaindre.
+
+D'où l'intérêt d'avoir une source de données mettant à disposition une agrégation de données de télémétrie.
+
+## Métriques, monitoring & alerting
+
+Les métriques, le monitoring et l'alerting sont trois concepts interconnectés qui forment ensemble la base d'un système de monitoring.
+Ils fournissent un aperçu sur la santé des systèmes et permettent de comprendre :
+
+* Les tendances d'usage et de comportement
+* L'impact sur les changements effectués.
+* Si une métrique tombe en dehors des valeurs de seuils normales, le système peut transmettre une notification pour accélérer la prise en charge par un opérateur.
+
+Pour résumé, les métriques sont des données brutes, non-interprétées et non traitées, tandis que le monitoring consiste à ajouter une couche d'informations sur ces métriques.
+
+### Métriques
+
+Les métriques représentent les mesures brutes pouvant être observées et collectées. Ces mesures peuvent être des ressources de bas-niveau (RAM, CPU, espace de stockage, utilisation de l'espace de swap, ...) ou plus haut-niveau (unité de travail, fonctionnalités spécifiques, nombre de requêtes services par seconde, ...).
+
+### Monitoring
+
+Les métriques représentent les données de nos systèmes ; le monitoring consiste à collecter, agréger, visualiser et analyser ces valeurs récupérées, en vue d'améliorer la compréhension de nos composants, ainsi que leurs caractéristiques, puis d'initier l'envoi automatique d'informations lorsque certaines valeurs atteignent des seuils spécifiques.
+
+La différence entre les métriques et le monitoring revient à différencier les données des informations.
+
+Le système de monitoring doit permettre :
+
+* De récolter des données à partir de plusieur sources,
+* D'ajouter des paramètres de visualisation, afin que les administrateurs puissent reconnaître des motifs particuliers
+
+Dans le cas d'un système de type **push**, la récolte a besoin d'autant d'agents installés sur chacune des ressources à surveiller.
+Idéalement, l'installation d'un agent doit se passer sans douleur et être la plus simple possible.
+Comme les évènements se passent en continu, le système de réception doit être le plus robuste possible : il doit être capable de supporter la charge de toutes les données que chacune des ressources envoie vers lui.
+
+Dans le cas d'un système **pull**, le serveur doit pouvoir contacter chaque ressource et récupérer les mêmes métriques que s'il s'agissait d'un agent indépendant.
+Certaines responsabilités d'agrégation sont inversées, mais un certain niveau de complexité subsiste, surtout sur certaines ressources nécessitent des mécanismes d'authentification.
+
+### Alerting
+
+> L'objectif premier de l'alerting est d'amener l'attention d'un opérateur sur le statut d'un des systèmes.
+
+L'alerting consiste à interpréter des changements dans les métriques.
+Une alerte est composée de deux éléments :
+
+* La définition d'un seuil ou d'une condition,
+* Une action à réaliser lorsque la valeur d'une métrique tombe en dehors de valeurs acceptables (= ne répondant pas aux conditions définies et/ou valeurs de seuils).
+
+## Informations à tracer
+
+Les informations que l'on collectera suivront les évolutions de notre infrastructure.
+Pour schématiser, on peut placer des métriques à plusieurs niveaux :
+
+* **Hôte**: est-ce que la machine qui héberge les services a tout le confort dont elle a besoin ?
+* **Application** : est-ce que l'application tourne correctement ?
+* **Couche réseau** : est-ce que tous les paquets passent bien ?
+* **Pool de serveurs** (en cas de mise à l'échelle horizontale) : est-ce qu'une nouvelle instance peut être démarrée sans embarquer toute la ferme ?
+* **Dépendances** : est-ce que tous les services (internes ou externes) dont dépendent nos applications tournent correctement ?
+* **Expérience utilisateur** : est-ce que nos utilisateurs ont toute la réactivité dont ils peuvent avoir besoin ?
+
+Dans le livre Google SRE (Site Reliability Engineering), il est question des *four golden signals of monitoring* :
+
+* **La latence**, qui consiste à mesurer le temps que met un service à répondre à une interrogation
+* **Le trafic**, qui s'assure du taux d'occupation du service, et qui capture la charge ou la demande du service, ce qui permet de savoir ce sur quoi il est occupé (ou ce qui prend du temps à être traité).
+* **Le nombre d'erreurs** (d'où l'importance de catégoriser correctement les alertes
+* **La saturation**, qui mesure combien une ressource est utilisée - cette mesure dépend généralement de la latence et du trafic, puisqu'une augmentation de ces deux valeurs tend à augmenter la saturation de la ressource.
+
+### Métrique du système hôte
+
+* Charge CPU
+* Mémoire : utilisation du swap, nombre d'évènements de type OOM killer
+* Espace disque et réactivité des espaces de stockage
+* Nombre de processus
+
+### Métriques applicatives
+
+Il s'agit de métriques associées litérallement au bon fonctionnement de l'application :
+
+* Temps nécessaire à compléter les requêtes
+* Nombre de requêtes par seconde
+* Défaillances applicatives ou redémarrages des services
+* Utilisation des ressources disponibiles
+* Métriques de connectivité
+
+Pour la plupart des infrastructures, la connectivité réseau est un ensemble de données à explorer : il s'agit de jauges quant à la disponibilité des services, permettant également de s'assurer que les systèmes restent accessibles.
+Le réseau doit être vérifié pour assurer les performances requises :
+
+### Connectivité
+
+* Taux d'erreur et/ou de pertes de paquets
+* Latence
+* Utilisation de la bande passante
+
+Ceci autant pour les services internes qu'externes.
+
+### Pool/collections de serveurs
+
+(Ce point concerne surtout la mise à l'échelle horizontale d'un parc de serveurs). Pour résumer, il s'agit de l'utilisation du parc de ressources, des indicateurs d'ajustements et du nombre d'instances dégradées.
+
+### Dépendances externes
+
+L'idée ici est simplement d'utiliser les endpoints d'API pouvant être disponibles (statuts d'un service et disponibilité, etc.).
+
+### Expérience utilisateur
+
+Ici, on est surtout sur la réactivité d'une interface, et donc sur la couche la plus élevée/proche de l'utilisateur.
+
+## Conclusions
+
+J'avoue être encore un peu perdu sur le ou les outils à déployer pour arriver à un tel résultat.
+Sentry + Zabbix devraient former un bon duo, mais je ne suis pas sûr qu'ils arrivent à un résultat aussi complet que toute la documentation que j'ai pu trouver ci-dessus.