Je l’évoquais dans le billet “Bilan 2021 et perspectives 2022”, je peux en parler maintenant officiellement : j’ai été contacté par Flovea pour piloter le projet Flowbox Interactive et mettre en place l’équipe projet associée. Après trois mois environ de mission permettant de faire connaissance, d’auditer la solution existante, de définir une roadmap et de mettre en place l’équipe projet, mon recrutement en tant que DSI/CIO de Flovéa est acté depuis début avril. J’ai le plaisir de rejoindre une belle équipe pour réaliser un beau projet tant d’un point de vue technique que d’un point de vue du sens et de son utilité. La seule ombre au tableau étant le contexte de pénurie de composants qui illustre bien la dimension “hard” d’un projet “hardware”.
Routine habituelle de début d’année pour la clôture de ce 5ème exercice (déjà !). Bilan 2021 Au global, une année mitigée qui se termine un peu sur le fil du rasoir au niveau comptable. Pour la partie positive, j’ai l’impression que cette année a été “l’année des possibles” où les efforts commencés les années précédentes commencent à payer. Des premiers projets en Go, des missions Time Series intéressantes et ambitieuses par certains aspects et un projet annexe en Python/Django sur la fin d’année qui consolide différents éléments permettant de gagner en confiance et de réduire un peu ce cher syndrome de l’imposteur avec lequel j’apprends à composer et à dépasser parfois.
Contexte Flovéa travaille depuis plusieurs années sur une solution de plomberie connectée. Elle souhaite maintenant passer à une échelle industrielle en terme de fabrication et de déploiement, commercialiser son service Predictive FLOWBOX et l’enrichir de fonctionnalités liées à du marchine learning. Sa solution doit permettre de contrôler à distance un circuit d’eau, de suivre sa consommation et d’identifier des consommations anormales, ainsi que de détecter des fuites. Flovéa souhaite se doter des compétences techniques en interne pour concevoir, piloter et réaliser le projet. Elle cherche donc à recruter le responsable du projet. C’est dans ce contexte que CérénIT a été contacté. Après 3 mois de missions, l’embauche de Nicolas Steinmetz en tant que DSI/CIO de Flovea est actée.
Containers & Orchestration Announcing General Availability of HashiCorp Nomad 1.2 : Arrivée des “system batchs jobs” prévu pour gérer des jobs à destination du cluster nomad en lui même (purge, backup, etc) et non des clients. Cette version apporte également des améliorations au niveau de l’interface, ainsi que les “nomad pack”, format de distribution de vos applications à destination de nomad. IoT Sortie de Raspberry Pi OS Bullseye et Raspberry Pi 4 à 1,8GHz : Première version de Raspberry Pi OS basée sur Debian 11 et possible overclocking du CPU des RPi4 à 1.8 Ghz (au lieu de 1.5 Ghz) Monitoring & Observabilité Vector v0.18.0 release notes : une version avec beaucoup de changements - je vous laisse aller voir les release notes. Time Series Annonces & Produits :
Suite de notre épopée : Partie 1 - Premier pas avec Warp 10, comptabilité et prévisions de fin d’année Partie 2 - Remise à jour des données, comparaison des données prévues vs réelles, prévisions 2021 Partie 3 - Récupération des données de la Sandbox dans notre instance locale Partie 4 - Dashboards Partie 5 - Les FEC et le compte 512 Partie 6 - Les FEC et le compte de résultat (ce billet) Dans ce sixième et dernier billet pour cette série, nous continuons avec les Fichier d’Ecritures Comptables (FEC) pour produire le compte de résultat et déterminer ainsi le bénéfice de l’exercice en cours. Il faut donc prendre toutes les opérations en classe 6 (charges) et 7 (produits). Pour chaque classe de compte, il peut y avoir des crédits ou des débits (ex pour un compte de classe 7 : un avoir sur une facture émise). C’est donc un chouilla plus compliqué que le compte de trésorerie.
BI Smart Data Analytics : Exploration des données comptables : pour changer des outils de séries temporelles, je me suis livré au même exercice d’ingestion et de traitement des FEC avec la Smart Data Analytics (SDA) de DataTask. Basée sur singer, dbt et metabase, la SDA permet via une Web UI de définir son flow d’ingestion et de transformation. Une fois ces transformations réalisées, il ne reste plus qu’à explorer les données avec Metabase et produire ses dashboards. Code vscode.dev : l’ère de l’IDE dans le navigateur continue après gitpod ou githuab codspaces, c’est au tour de vscode.dev qui permet d’avoir une IDE dans son navigateur. Affaire à suivre… Observabilité et monitoring Vector 0.17.0, Vector 0.17.1, Vector 0.17.2 & Vector 0.17.3 avec l’adaptive concurrency qui permet de gérer le “back pressure” pour les destinations accessibles via HTTP, et pour les sources une gestion simplifiée pour le décodage d’éléments et leur “framing”. Vector Remap Language : extension Vector pour VSCode Orchestration & conteneurs damon, un dashboard pour nomad en ligne de commande. Announcing HashiCorp Nomad 1.2 Beta : ajout des “System Batch” qui sont des (petits) jobs globaux au cluster, des améliorations de l’interface et l’ajout des Nomad Pack, une sorte de catalogue d’applications prêtes à être déployées dans votre cluster. SQL PostgreSQL 14 Released! ou en français PostgreSQL 14 ou un thread twitter pour découvrir les nouveautés de cette version : amélioration du support de JSONB, type multirange, fonctions autour des dates, etc. Sécurité Popular NPM library hijacked to install password-stealers, miners : analyse de la librairie ua-parser-js compromise dans ses version 0.7.29, 0.8.0 et 1.0.0 avec l’ajout un mining de crypto et un voleur de mot de passes. Le passage en version 0.7.30 / 0.8.1 et 1.0.1 est à faire dans les plus brefs délais. Pour les dépendances indirectes, il est possible d’ajouter dans son fichier package.json: "resolutions": { "ua-parser-js": "^0.7.30" } via Security issue: compromised npm packages of ua-parser-js (0.7.29, 0.8.0, 1.0.0) - Questions about deprecated npm package ua-parser-js Time Series Annonces & Produits :
Il y a quelques temps et sachant que j’utilisais n8n pour automatiser la génération des brèves du BigData Hebdo, Mathias m’a demandé s’il était possible de faire la même chose entre n8n et Warp 10 qu’avec node-red et Warp 10. La réponse est oui mais voyons comment faire cela. Pour ceux qui ne connaissent pas n8n, c’est un clone open source (sous licence fair-code) à des services comme Zapier ou IFTTT. Il permet d’automatiser des processus via la création de workflows. Ces workflows sont composés d’étapes et d’actions. n8n dispose d’un grand nombre de connecteurs vers les différents services existants, des opérateurs génériques (faire un appel http, appliquer une fonction), des opérateurs logiques (si, etc), des opérateurs de transformation de données, etc. Chacun de ces éléments est implémenté via une node. A chaque étape du workflow, une node est instanciée puis paramétrée. Les nodes peuvent être reliées entre-elles et la sortie d’une node peut alimenter la suivante.
CérénIT vient de finaliser la migration pour un de ses clients d’un socle InfluxDB/Chronograf/Kapacitor vers InfluxDB2. Ce billet est l’occasion de revenir sur la partie alerting et de la migration de Kapacitor vers des alertes dans InfluxDB2. Dans le cadre du socle InfluxDB/Chronograf/Kapacitor, le fonctionnement était le suivant : Les utilisateurs créent une alerte via l’application métier en définissant un à plusieurs critères d’alertes ; ex: est-ce que l’unité est opérationnelle et est-ce que l’humidité est supérieure à tel taux ou la température supérieure à telle valeur. L’application métier traduisait l’alerte en TickScript et enregistrait l’alerte auprès de Kapacitor via son API HTTP Kapacitor, en mode streaming, évalue si l’alerte doit être levée ou pas au fur et à mesure de l’arrivée des données En cas de seuil franchi, Kapacitor envoie un message à l’application métier via l’API HTTP de cette dernière. L’application métier envoie ensuite un mail et/ou un SMS à l’auteur de l’alerte. Avant d’envisager la migration InfluxDB2, un point de vocabulaire :
CérénIT a été contacté pour mener l’audit d’une instance InfluxDB 1.8 OSS utilisée dans un projet IoT lié à l’énergie. L’audit avait plusieurs objectifs : Comprendre la consommation mémoire de l’instance (48Go / 64Go de la VM) Faire un état de santé de la plateforme et estimer sa capacité à stocker et procésser des données supplémentaires dans le cadre de l’ouverture d’une application métier Expliquer la raison des problèmes observés par le passé et évaluer les solutions apportées Etablir des recommendations et éventuellement les implémenter. De l’audit, on notera que : L’instance contient ~35.000 shards / ~36.000 tsm files pour environ 200 bases permanentes et des dizaines de bases éphémères permettant de calculer des indicateurs ou de recalculer des historiques de données suite à des changements de paramètres de l’application métier (plusieurs dizaines de milliers de bases temporaires par semaine, avec des profondeurs de données variables) Les recommendations pour InfluxDB Enterprise sont d’avoir 30/40 bases par data nodes et 1.000 shards par data node Avant d’aller plus loin, précisons un peu cette notion de shard et les notions liées pour bien appréhender le sujet :
Contexte Axens, filiale de l’IFPEN, a développé le projet Connect’In qui récupère les données de ces équipements, les enrichis et les mets à disposition de ses clients. Dans le cadre du déploiement de la V3 du produit, des problèmes de performance et de stabilité de la plateforme ont été rencontrés. Axens a contacté CérénIT pour faire un audit de la plateforme et idenfifier les axes d’améliorations avant de pouvoir ouvrir l’application à ses utilisateurs. Suite à l’audit, il a été demandé à CérénIT d’accompagner Axens dans l’implémentation de ces recommendations. Notre réponse Audit de l’instance InfluxDB OSS 1.x Audit de la VM hôte de l’instance InfluxDB Recommendations et définition d’un plan d’action Implémentation et suivi du plan d’action. Bénéfices pour le client Expertise sur InfluxDB Résultats constatés : Les dashboards simples sont entre 15% et 30% plus rapides pour leur affichage Les dashboards complexes sont entre 3 et 10 fois plus rapides pour leur affichage La consommation mémoire reste stable autour de 6/8 Go Des changements sur la shard duration de certaines bases ont permis de descendre jusqu’à 600 shards environ. (recomendation éditeur en version Entreprise d’avoir 1.000 shards maximum par node) Bénéfices pour CérénIT Expérience appronfondie sur le moteur de stockage InfluxDB
On orchestre, on conçoit — et on code aussi. Parlons de votre plateforme, vos données ou votre projet IoT.
Contactez-nous →