PROJET AUTOBLOG


Blog de dada

Site original : Blog de dada

⇐ retour index

Mise à jour

Mise à jour de la base de données, veuillez patienter...

Coronavirus, confinements solidaires

mardi 17 mars 2020 à 10:43

Je relaie modestement la dernière vidéo de DataGueule en espérant que le message touche plus de monde que le coronavirus.




Alors que l’épidémie de coronavirus continue de s’étendre en Europe, il est vital de rappeler un fait essentiel : le COVID-19 ne circule pas de lui-même, ce sont les hommes et les femmes qui le font circuler. Chacune et chacun d’entre nous peut donc agir pour limiter sa propagation et ralentir au plus vite l’engorgement dramatique de nos hôpitaux. La seule action cruciale, nécessairement collective, tient en trois mots : “Restons chez nous”.


De l'alerting à base de logs

mercredi 12 février 2020 à 07:42

Cela fait un moment que je cherche un moyen de déclencher des alertes à partir d'erreurs spécifiques dans les logs. En fait, ça fait depuis la sortie de Loki que j'en rêve.



Pour rappel, le couple Loki/Promtail, permet de centraliser des logs dans Grafana pour les visualiser calmement plus tard. En gros, ça peut donner un truc comme ça, ou comme ça.
Après avoir mis tout ça en place, je trouvais dommage de ne pas pouvoir continuer l'intégration jusqu'au bout : repérer un message d'erreur dans des logs et transformer l'écran de monitoring en sapin de Noël.

En fait, c'était déjà possible, j'avais juste raté l'information !

Préambule

Ce dont je vais parler dans la suite du billet nécessite d'avoir déjà la stack Loki + Promtail + Grafana + Prometheus + Alert-manager. Ça demande un peu d'huile de coude et de temps mais ça s'installe très bien.

Les Pipelines

Promtail, comme tout exporter, expose des metrics de toute sorte. De base, il fait des choses simples, mais avec les Pipelines, on peut pousser le truc plus loin : ajouter le timestanp à une ligne de log, modifier des labels, ajouter clairement le numéro de ligne du log et, on y est, créer une metric custom !

Créer une metric custom

On va commencer par un exemple très simple :
scrape_configs:
- job_name: system
  static_configs:
  - targets:
      - localhost
    labels:
      job: varlogs
      __path__: /var/log/*log
      hostname: diaspodon.fr
  pipeline_stages:
  - match:
      selector: '{job="varlogs"}'
      stages:
      - regex:
          expression: ".*(?P<error_message>error_message.*)"
      - metrics:
          error_total:
            type: Counter
            description: "total count of errors"
            source: error_message
            config:
              action: inc
Ceci est une partie de la configuration du Promtail en place sur mon serveur Mastodon. Ce n'est pas la plus propre du monde mais ça fera l'affaire.

Le job

On y voit la configuration qui permet de remonter les logs système de /var/log/*.log avec le label varlogs et un hostname forcé :
- job_name: system
  static_configs:
  - targets:
      - localhost
    labels:
      job: varlogs
      __path__: /var/log/*log
      hostname: diaspodon.fr

Le pipeline

On enchaîne ensuite avec le fameux pipeline, que je vais présenter en deux parties : le selector et les metrics 

- La partie selector
  pipeline_stages:
  - match:
      selector: '{job="varlogs"}'
      stages:
      - regex:
          expression: ".*(?P<error_message>error_message.*)"
Le selector permet de s'y retrouver. On va aller chercher à bidouiller les logs du job varlogs, pas ailleurs. Le stage permet de mettre en place une expression régulière en RE2, la version Google est regexp, pour filtrer l'information dont on a besoin.
Ici, je veux qu'une action soit déclenchée à chaque fois que error_message apparaît dans les logs. Celles et ceux qui ont une instance Mastodon savent de quoi je parle. Pour les autres, c'est quand un message ne peut pas atteindre son destinataire. C'est très courant.

- La partie metrics

Pour finir, la partie metrics est carrément celle qui nous intéresse le plus : elle va, comme son nom l'indique, créer une metric qui sera remontée à Prometheus.
      - metrics:
          error_total:
            type: Counter
            description: "total count of errors"
            source: error_message
            config:
              action: inc
On va lire la configuration lentement : La variable error_total sera de type Counter avec la description "total count of errors" et sera alimentée par error_message, défini dans la regexp précédente (entre les <>). De 0, la variable sera incrémentée de 1 à chaque match.

Prometheus

Vérifier la configuration

Vous voyez le truc ? On vient de mettre en place une metric custom qui sera remontée par Promtail vers Prometheus. À l'heure où j'écris ces lignes, cette metric ressemble à ça :
root@diaspodon ~ # curl -s http://localhost:9080/metrics   | grep custom
# HELP promtail_custom_error_total total count of errors
# TYPE promtail_custom_error_total counter
promtail_custom_error_total{filename="/var/log/daemon.log",hostname="diaspodon.fr",job="varlogs"} 92831
promtail_custom_error_total{filename="/var/log/syslog",hostname="diaspodon.fr",job="varlogs"} 50050
On retrouve bien la metric déclarée dans Promtail : error_total, avec son nom complet : promtail_custom_error_total.

Vous me direz que ce n'est pas très joli et vous aurez parfaitement raison. C'est un exemple, juste un exemple !

Mettre en place de l'alerting

Maintenant que vous avez des données dans Prometheus, rédiger une règle d'alerting est assez simple. On devrait s'en sortir avec ce type de chose :
  - alert: Error_total
    expr: promtail_custom_error_total > 1
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "Instance {{ $labels.instance }} is invaded by custom errors!"
Simple, rapide, efficace. Si une erreur apparaît, elle sera repérée et une alerte sera déclenchée. Y'a plus qu'à faut qu'on vérifier que votre installation spamme correctement les développeurs pour les mettre sur le coup rapidement.

Pour aller plus loin

Je viens de rapidement parcourir le sujet pour vous donner envie d'y mettre le nez. En l'état, la configuration proposée a un gros problème : une fois qu'une erreur est détectée, le Counter sera incrémenté et rien ne lui permettre de revenir à 0. C'est assez chiant.

J'ai deux façons de contourner le problème : la première avec les développeurs, la deuxième avec ses seuls moyens.

Si les développeurs sont adorables, ils peuvent mettre en place un petit bout de code qui va écrire dans les logs que tout est revenu à la normale. En passant du Counter à une Gauge, on peut dire à Promtail d'incrémenter la metric quand un souci est détecté puis de la décrémenter quand tout redevient fonctionnel. Ça permet de jongler entre 0 et 1 et pas plus.

Par contre, si vous êtes tout seul, vous pouvez tricher en décidant de mettre en place une règle d'alerting qui fait un rate() sur 1h, ou la durée que vous voulez, pour avoir des passages à vide et des périodes de souci. Ça permet d'éviter de passer d'un Counter à une Gauge mais ça demande à mettre un délai de retour au calme long et d'être assidu sur les chan/salon/mail d'alerting.

Bref, c'est encore un point sur lequel je réfléchis. Si vous avez des idées, je prends.

Enfin voilà.

Des bisous


Comment faire comprendre à quelqu'un qu'il a tort

samedi 25 janvier 2020 à 09:36

Maintenant que le titre vous a bien attiré par ici, le voici en entier : Comment faire comprendre à quelqu'un qu'il a tort (et pourquoi c'est une mauvaise question).

Nous devons cet incroyablement trop long titre de vidéo à Mr.Sam (Peertube, Youtube), vidéaste sceptique belge. Je suis encore dans une période de découverte de ce mouvement dit sceptique et je dois bien avouer que j'y trouve beaucoup de jus de cerveau. Du coup, je vous invite à vous y pencher aussi. L'instance Skeptikon est votre amie.

En prélude, le toot de Mathdatech qui me semble être une incroyablement bonne entrée en matière :


Il résume presque à lui tout seul ce que fait comprendre la vidéo de 2h ci-dessous. Presque, puisque Mr.Sam n'oriente absolument pas son discours autour du logiciel libre. Pas du tout même.

Bref, maintenant, la vidéo :


Si je vous en parle dans ce blog de libriste convaincu, c'est que je trouve que nous serions bien avisés de tous tirer des leçons de ce que ce vidéaste prend le temps de nous expliquer.

Se concentrer sur le logiciel libre, mettre de côté tout ce qui n'a pas la bonne licence, exclure l'achat d'outils qui ne respectent pas les libertés fondamentales : c'est une démarche impossible à faire comprendre dans un dialogue frontal. C'est un engagement qui peut être vu comme une fantaisie qui n'apporte que des contraintes si le ou la libriste s'y prend mal lors de son explication. Et c'est foutu. Définitivement.

Du coup, prendre le temps de s'intéresser à la rhétorique, à l'art oratoire et à la construction du dialogue avec son interlocuteur doit faire partie de notre bagage de compétences si nous voulons lutter à armes égales avec les discours des startups ou autres GAFAM. Ils ont le savoir "faire rêver", nous avons des choix de société : c'est un combat incroyablement délicat et difficile.

Bref, je vous encourage vraiment à aller voir le travail de Mr.Sam et bon week-end à vous.


Se faire un réveil 4.0 avec un Raspberry Pi

mercredi 15 janvier 2020 à 07:42

Je me suis toujours méfié des objets connectés. Ce n'est un secret pour personne : une grande partie des babioles vendues sous la bannière IoT ou objet connecté sont des machins non sécurisés, non maintenus, non écologiques et d'un intérêt plus que discutable.


Ceci dit, avec l'aide de la WebThings Gateway de Mozilla, il est possible de commencer à jouer avec son matériel existant pour le rendre connecté. Ce truc permet de garder le contrôle des-dits machins connectés puisque le cerveau de ces choses sera dans votre salon et pas sur des serveurs obscurs à l'autre bout du monde.

Un exemple que je vous propose : mettre de côté votre ancien réveil, qui marche très bien, pour le remplacer par un Raspberry Pi.

Les ingrédients

Pour ce faire, il vous faudra :

Le Raspberry Pi

Vous allez commencer par utiliser WebThings Gateway comme système d'exploitation de votre Raspberry Pi. C'est une Rasbpian, basée sur Debian donc, modifiée par Mozilla, rien de plus.
Je ne vais pas m'éterniser sur la procédure d'installation : c'est très simple.
Il suffit d'aller télécharger l'image disponible ici, de flasher la carte SD avec et de placer cette-dite carte dans l'ordinateur.

Une fois que la bête a démarré, un nouveau réseau Wifi va apparaître. Connectez vous y depuis votre PC et suivez la procédure de configuration :
L'attribution de l'URL peut prendre du temps, ne paniquez pas, ne touchez à rien : Mozilla vous enverra un lien par mail quand tout sera effectif.

Installer l'extension Radio

Par défaut, WTG ne fait pas grand chose. Tout comme pour Firefox, Mozilla s'appuie sur les gens pour fournir des extensions en pagaille. Et ça marche plutôt pas mal si j'en crois le dépôt officiel.

Je vous laisse cliquer dans les menus pour installer Radio : Settings > Add-ons > le + en bas à droite -> Internet radio. 

L'add-on vient avec quelques webradios inconnues au bataillon. Pas grave, on va installer celle qui nous intéresse : la radio d'État.


Pour récupérer l'adresse de streaming, je suis passé par ce lien qui m'a permis de trouver ça :
  • http://direct.franceinfo.fr/live/franceinfo-midfi.mp3
Il est possible que le flux change ou qu'il ne soit pas vraiment fonctionnel alors prenez le temps de le vérifier. L'autre jour, par exemple, j'avais bien un flux lu mais il ne contenait pas le moindre son : méfiez-vous.

Maintenant, vous devriez avoir WTG correctement configuré dans votre Raspberry Pi. Il ne reste plus qu'à créer la règle qui va permettre d'allumer tout ça aux heures voulues.

Mettre en place le réveil 4.0

WTG fonctionne, en gros, avec deux principes : les choses (things) et les règles (rules).

Les règles permettent de faire faire des choses à vos choses. Vous suivez ?


Dans le cadre du réveil, on va s'amuser à dire à WTG d'activer la chose radio, avec le volume qui va bien, à l'heure qui va bien. Le panneau de création d'une règle est coupé en deux :


On va remarquer la complexité relative de la règle puisqu'il faut :
- Deux choses Clock qui déclenchent deux événements à 7h du matin
- Une chose Radio qui allume la radio
- Une chose Radio qui fixe le volume

En une seule phrase, la logique ressemble à ça : À 7h du matin, tu allumes la radio et à 7h du matin, tu montes le volume à 75.
La partie volume de ma règle n'est pas obligatoire. Elle est présente dans mon exemple parce que le volume de base, 50, est trop faible à mon goût.

Aller un peu plus loin

Dans mon cas personnel, j'ai décidé d'ajouter une règle qui arrête la radio à 8h. Pourquoi ? Parce que je dois impérativement décoller à 8h sans quoi je rate mon train.


Si vous avez capté la logique, j'ai utilisé une chose Clock qui se déclenche à 8h et une chose Radio qui arrête la boucle d'informations du matin.

Et voilà !

Conclusion

Vous n'avez plus qu'à laisser votre imagination tourner. Avec WTG, vous pouvez avoir des objets connectés qui se contrôlent depuis un ordinateur dans votre salon que vous pouvez arrêter quand vous le voulez et qui est entièrement open-source.

C'est sans intérêt, donc indispensable ! Bonne année !


Le Blog de dada en 2019

mardi 24 décembre 2019 à 13:10

Comme en 2018, je vous propose de faire le tour rapide des statistiques que mon Matomo a récolté tout au long de l'année.

Pour l'histoire, j'ai décidé de ne plus analyser directement les logs du serveur. Je ne passe plus que part le script en JS chargé, ou non, par le visiteur. Du coup, les bloqueurs font leur boulot, rendant les stats à peine pertinentes. M'enfin, elles restent globalement marrantes à parcourir, et c'est déjà ça.

Les navigateurs



La famille Chrome regroupe 51% (34% bureau et 17% mobile) des navigateurs qui affichent mes bêtises. Firefox se cache derrière avec 22% des visites. Comme l'année dernière, même avec un lectorat très orienté logiciels libres, je n'arrive pas à faire passer Firefox devant la cochonnerie de Google.
Gageons que les récentes annoncent scandaleuses d'Alphabet inversent la tendance en 2020.

Les systèmes d'exploitation



Windows prend la première place avec 40% des visiteurs devant encore et toujours traîner ce boulet. Vient ensuite Android avec 22% puis GNU/Linux avec 21% et enfin MacOS avec 15%. On peut s'amuser à comparer avec les statistiques de 2018 qui affichaient clairement une domination de GNULinux. Faut croire que les linuxiens protègent bien plus leurs vie privée que les autres.

Les périphériques


Là, franchement, pas grand chose à raconter. Les gens sont devant leur PC quand ils lisent mes blablateries. En comparant à l'année dernière, on voit une augmentation des lecteurs sur Mobile. Bref.

Les moteurs de recherche


S'il vous fallait un dessin pour comprendre la domination de Google, vous l'avez.

Les réseaux sociaux.



Avec ses 61%, Twitter se balade en tête des réseaux sociaux qui m'apportent le plus de visiteurs. On trouve ensuite Facebook avec 30% et Mastodon avec 6%. Mon petit doigt me dit que le Journal du Hacker n'est pas innocent dans cette histoire. Personnellement, je ne suis utilisateur que de Mastodon et c'est là que vous devriez me suivre si ce que je raconte vous intéresse ;-)

Le top 3 des articles

1 - Bloquer les pubs : j'ai installé Pi-Hole derrière une Freebox
2 - Installer Grafana, Prometheus et Node Exporter
3 - Nextcloud, PHP-FPM, Nginx et Kubernetes

Le reste du classement reflète ce que j'ai le plus bidouillé cette année : Kubernetes. Je regrette que mes articles de réflexion ne soient pas plus mis en avant mais les moteurs de recherche n'en ont visiblement rien à foutre. Tant pis.

Plus de chiffres

Matomo compte pas moins de 52 000 visites, bien loin des 1 900 000 recensées en 2018.
Pas loin de 70 000 pages vues.
J'ai réussi à pondre 22 billets.
Vous avez pondu de 128 commentaires.

Enfin voilà. Je vous laisse sur ces chiffres et vous souhaite de joyeuses fêtes de fin d'année à tous !

Merci et des bisous !