Contexte Dans le cadre du maintien en condition opérartionnelle de sa plateforme et pour faire des analyses plus poussées de ses données, la SAFT souhaite mettre à jour sa stack InfluxDB 1.x OSS, Chronograf et Kapacitor vers InfluxDB 2.0 OSS. Fort des précédentes missions, la SAFT nous a confié cette mission, à laquelle s’ajoute une période de support post déploiement en production de la nouvelle plateforme. Notre réponse Montée de version InfluxDB OSS 1.x vers 2.x Migration des dashboards Chronograf vers InfluxDB2 Migration des alertes en TickScript vers des “custom checks” (tasks flux) Restructuration des données avec une shard duration conforme aux recommandations InfluxData Mise à jour de Telegraf et de sa configuration Mise à jour de la partie exploitation (backups, etc) Documentation Support post déploiement en production Bénéfices pour le client Expertise sur InfluxDB Connaissance prélable du contexte suite aux précécentes missions
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 (ce billet) Partie 6 - Les FEC et le compte de résultat Dans ce cinquième billet, nous allons parler de Fichier d’Ecritures Comptables (FEC) et d’un compte simple à analyser : le compte 512 qui correspond à votre compte en banque.
Suite et fin de ma réponse au code contest après la première partie. Dans ce billet, nous allons voir comment calculer les émissions de CO2 pour la partie de trajet sur la route 66. // Define points from the car journey on the US66 road [ // Here is the gts of the car datalogger @senx/dataset/route66_vehicle_gts // Here is the route 66 geoshape (+/- 20meters) @senx/dataset/route66_geoshape mapper.geo.within 0 0 0 ] MAP "onTheRoad" STORE $onTheRoad { 'timesplit' 60 s } MOTIONSPLIT 0 GET 'sectionOnTheRoad' STORE // Compute speed - result in m/s [ $sectionOnTheRoad mapper.hspeed 1 0 0 ] MAP // Convert in km/h so x3600 /1000 = 3.6 - mapper.mul expects a constant [ SWAP 3.6 mapper.mul 0 0 0 ] MAP 'speedFrames' STORE // Get distance between each points in km (first in meters, then in km) [ $sectionOnTheRoad mapper.hdist 0 1 0 ] MAP [ SWAP 0.001 mapper.mul 0 0 0 ] MAP 'distFrames' STORE // fuel consumption approximation is (8 liters/100km) × (speed (km/h) / 80) +1 // So it's Speed * 8 / 80 / 100 + 1 = V/10 + 1 // F = False => does not return the index $speedFrames <% 0.1 * 1.0 + %> F LMAP 'hundredKmFuelConsumption' STORE [ ] 'instantConsumption' STORE <% 'i' STORE // store index // Get each list and compute one by another // So we compute consumption for 100 km at given speed (computed previously) // with related distance // then we divide by 100 as first value is for 100 km $distFrames $i GET $hundredKmFuelConsumption $i GET * 100 / 'r' STORE $instantConsumption $r +! %> 'C' STORE 0 7 $C FOR CLEAR // For each GTS, compute fuel consumption as 1 point [ $instantConsumption mapper.sum MAXLONG MAXLONG 1 ] MAP // Sum all points to get total consumption 0 SWAP <% VALUES 0 GET + %> FOREACH // 1L = 2392g CO2 2392 * // Enjoy ! Le premier et le second bloc sont les mêmes que dans la premièr partie. Je vous y renvoie donc si besoin.
La société SenX a proposé un code contest suite à la publication de son article sur les formes géospatiales. L’objet du concours porte sur le trajet d’un véhicule aux USA et il consiste à déterminer : la distance réalisée sur la fameuse route 66 durant ce trajet, de déterminer les émissions de CO2 réalisées durant ce trajet sur la route 66. Maintenant que le gagnant a été annoncé (TL;DR: moi 😎🎉) et en attendant le corrigé officiel, voici ma proposition de solution. Distance parcourue sur la route 66 Les données de départ sont : @senx/dataset/route66_vehicle_gts : le trajet réalisé par le véhicule @senx/dataset/route66_geoshape : la route 66 // Define points from the car journey on the US66 road [ // Here is the gts of the car datalogger @senx/dataset/route66_vehicle_gts // Here is the route 66 geoshape (+/- 20meters) @senx/dataset/route66_geoshape mapper.geo.within 0 0 0 ] MAP "onTheRoad" STORE $onTheRoad { 'timesplit' 60 s } MOTIONSPLIT 0 GET 'sectionOnTheRoad' STORE // Compute distance for each GTS and output it as a single point [ $sectionOnTheRoad mapper.hdist MAXLONG MAXLONG 1 ] MAP // Sum all GTS 0 SWAP <% VALUES 0 GET + %> FOREACH // Convert to km 1000 / // Enjoy ! Explications :
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 (ce billet) Partie 5 - Les FEC et le compte 512 Partie 6 - Les FEC et le compte de résultat Nous allons voir aujourd’hui comment présenter ces données à l’aide de Discovery, la solution de Dashboard as Code pour Warp 10 fournie par SenX. Installation de Discovery Tout est décrit dans le billet Truly Dynamic Dashboards as Code
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 (ce billet) Partie 4 - Dashboards Partie 5 - Les FEC et le compte 512 Partie 6 - Les FEC et le compte de résultat A l’issue du précédent billet, depuis le WarpStudio et en stockant les données dans la sandbox, nous avons manipuler les données pour : refaire les précisions de juin à décembre 2020 à partir des données de 01/2017 à 05/2017 comparer ses prévisions avec les résultats réels faire les prévisions pour 2021. Cependant, cela n’est pas parfait :
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 (ce billet) 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 L’année dernière, nous avions travaillé sur Warp 10 et mes données de comptabilité et jouer un peu avec les algo de prévision. Les données comptables ayant été un peu ajustées entre temps et la librairie de prévision ayant aussi évolué coté SenX, les résultats ne sont plus tout à fait les mêmes. Nous allons donc reprendre tout ça.
Cloud Traefik Proxy 2.4 Adds Advanced mTLS, Kubernetes Service APIs, and More : Support du Proxy Protocol pour les services TCP, support avancé pour mTLS (et possible intégration Consul Connect) et support initial de la nouvelle API Service de Kubernetes pour les principales avancées. Le programme pour la 2.5 semble aussi alléchant : support HTTP/3, migration vers networking/v1 de Kubernetes et une nouvelle documentation (encore ?!). OVHcloud obtient le Visa de sécurité ANSSI pour sa qualification SecNumCloud : OVHCloud obtient la certification SecNumCloud de l’ANSSI pour sa solution “Hosted Private Cloud”. Code GitLab release feature report : le code qui permet de générer le rapport ce qui a changé entre les versions de Gitlab. SSH is the new GPG : les dernières versions d’OpenSSH permettent de signer un fichier. Une solution intermédiaire entre de la signature de fichiers à base de MD5 & co qui donnent des informations de conformité mais sans indiquer qui a signé le fichier et une solution GPG plus complexe à mettre en oeuvre ? Container et orchestration Using Podman and Docker Compose : podman, le “daemonless container engine” va permettre d’être utilisé avec docker-compose dans le cadre de la version 3.0. De quoi favoriser l’adoption de podman ? Infra as code New LibSSH Connection Plugin for Ansible Network Replaces Paramiko, Adds FIPS Mode Enablement : Ansible change de librairie pour les connexions ssh en remplaçant paramiko par libssh. Elle se veut plus performante et peut être requis dans un contexte demandant du FIPS. Pensez à installer le paquet libssh-dev(el) suivant votre distribution pour pouvoir installer ansible-pylibssh. Mes premiers essais ne notent pas une amélioration sensible des performances… à voir sur d’autres machines et dans la durée… IoT openHAB 3.0 Release et Release Notes : OpenHAB est une plateforme open source de gestion de périphétiques IoT et d’automatisation autour de ces périphériques. Elle est développée en Java, support 2000 “Things” (objets, équipements, protocoles). La version 3.0 apporte une refonte et l’unification de l’UI et des composants, le passage à Java 11 et plein d’autres choses. La migration depuis une version 2.x se fait assez simplement. Avec le nouveau moteur de règle, j’ai pu supprimer mon code spécifique. Reste encore la partie “Pages” à appréhender… J’avais préféré OpenHAB à Jeedom et Home Assistant Meet Raspberry Silicon: Raspberry Pi Pico now on sale at $4 : la fondation Raspberry Pi se lance dans les micro-controlleurs avec le Pico au prix de 4$. Raspberry Pi PICO la carte Microcontrôleur de la Fondation : un article très détaillé sur la prise en main du pico. Observabilité Métriques, monitoring, push vs pull, Riemann, Vector : Panorama sur le push/pull dans le monde du monitoring et tour d’horizon des solutions existantes pour arriver à Vector dont je vous parlais le mois dernier. Une introduction à Vector : Tout est dans le titre, mise en place de quelques outils remontant des métriques et des logs et ingestion des métriques dans InfluxDB via Vector. OVHCloud > Logs Data Platform > Using Elasticsearch API to send your logs - Use Case: Vector : Si vous utilisez l’offre Logs Data Platform d’OVHCloud pour vos logs, vous pouvez utiliser le sink elasticsearch de Vector pour envoyer vos logs vers Logs Data Platform. First-class Kubernetes Integration for Vector : Dans le cadre de la release 0.11, Vector a annoncé un support de Kubernetes avec une phase de collecte et d’enrichissement des logs. Cela mériterait d’être creusé… Système CVE-2021-3156: Heap-Based Buffer Overflow in Sudo (Baron Samedit) & Buffer overflow in command line unescaping: il est temps de patcher vos systèmes linux utilisant sudo - l’attaque permet de faire une élévation de privilèges si le fichier sudoers est présent sur le système (en général: /etc/sudoers). Les versions 1.8.2 à 1.8.31 et 1.9.0 à 1.9.5-p1 sont impactées, il faut passer en version 1.9.5-p2. Time Series Erlenmeyer and PromQL compatibility : OVHCloud, dans le cadre de leur offre OVH Metrics, a développé Erlenmeyer, un proxy qui permet de convertir différents format de séries temporelles (Promql, Influxql, OpenTSDB, etc) au format Warp 10 qui est utilisé pour stocker ces métriques. Le billet porte sur leur retour d’expérience sur l’utilisation du “PromQL compliance tester” pour valider qu’Erlenmyer supportait bien les requêtes PromQL. TimescaleDB 2.0 GA : User Defined Functions, Multi-Nodes, les fonctionnalités de la version Entreprise dans la version Communautaire et plein d’autres améliorations/corrections/optimisations. Cf TimescaleDB 2.0: A multi-node, petabyte-scale, completely free relational database for time-series Paris Time Series #9 : Comment gérer la labellisation des séries-temporelles et la détection d’anomalies grâce à InfluxDB ? : Présentation de Julien Muller d’ezako sur la labellisation de séries temporelles et de la détection d’aonomalies en s’appuyant sur InfluxDB pour le stockage de ces données temporelles. InfluxData closes 2020 with exponential cloud growth, expanding user base, and big new customers : bilan 2020 pour InfluxData avec quelques chiffres sur la croissance de leur offre cloud (x13), utilisateurs du free tier InfluxCloud (x5), Répartition des (nouveaux ?) cllients (OInfluxCloud) 55% USA et 45% Europe, 450K instances OSS actives, quelques grosses références et un développement à venir en Asie/Pacifique. Telegraf 1.17 : version pour laquelle je découvre le processeur Starlark. Ce processeur permet de définir une fonction sur les métriques permettant par exemple de ne remonter une valeur que si elle est différente de la précédente. Cela peut économiser des données dans des systèmes contraints. Infographic: What happened in 2020 for SenX? : retour de SenX sur l’actualité autour de Warp 10 (mais pas que) Parution des premiers tutoriels FLoWS : FLoWS Basic et FLoWS vs WarpScript Warp 10 2.7.2 : version de maintenance. Alerts are real time series : et si les alertes étaient elles-mêmes des séries temporelles ? S’il était assez évident de dissocier la partie génération de l’alerte (traitement) de la partie notification, on peut aller encore plus loin en matérialisant ces données d’alertes sous la forme d’une série temporelle. Une approche intéressante qui ouvre des possiblités de traitement et d’analyses complémentaires alors que les logiciels actuels ne persistent pas souvent/longtemps cette information. Utilisation des séries temporelles dans le cadre du Vendéee Globe : Vitesse et amures pour le bateau de Boris Herrmann - Seaexplorer Yacht Club de Monaco avec Warp 10 et l’ensemble des données du même bateau mise à disposition : Live data from Seaexplorer - Yacht Club de Monaco. Il y a des séries temporelles plus intéressantes que d’autres ! 😉 High Performance Sailing Monitoring for the Vendée Globe : le making-off du tweet ci-dessus et bien plus encore !
Routine habituelle de début d’année pour la clôture de ce 4ème exercice (déjà !). Bilan 2020 Au global, une bonne année au regard des conditions - les objectifs sont remplis. D’un point de vue comptable, cela donne : 2020 2019 2018 2017 Variation n/n-1 Chiffre d’affaires ~138 K€ ~150 K€ ~132 K€ ~100 K€ -8% Résultat après impôts ~8 K€ ~13.5 K€ ~10 K€ ~20 K€ -41% Jours facturés 175 197 178 160 -11% TJM 789€ 761€ 742€ 625€ +3.6% Contrairement aux autres années, les jours facturés ne prennent plus en compte des prestatations forfaitaires (comme l’infogérance, etc) pour lesquelles je faisais un équivalent jour. J’ai ajusté les valeurs de ce tableau mais je n’ai pas mis à jour les synthèses 2019, 2018 et 2017. Cela a pour conséquence d’améliorer sensiblement le TJM.
Contexte La société AIM45 est éditrice de la plateforme web M2 pour la course au large. Elle utilise la solution Warp 10 pour stocker ses séries temporelles. Pour étoffer son offre, elle doit intégrer les données d’un partenaire qui utilise quant à lui la solution InfluxDB. AIM45 nous a sollicité pour les accompagner dans cette intégration. Notre réponse Expertise sur la plateforme InfluxDB Bonne connaissance de la plateforem Warp 10 Accompagnement des équipes internes dans la définition des scénarios d’intégration avec le partenaire Accompagnement des équipes internes pour maitriser les concepts et les différences entre les produits Warp 10 et InfluxDB pour une meilleure appréhension du sujet Participation aux réunions avec le partenaire pour faciliter les échanges entre les équipes, expliciter les différences entre les produits et contribuer aux échanges sur la définition de la solution finale. Accompagnement à la carte en fonction des besoins des équipes AIM45. Bénéfices pour l’éditeur Expertise sur les solutions de séries temporelles Warp 10 et InfluxDB Prise en main facilitée et accélérée pour les équipes internes sur InfluxDB Facilitation pour les échanges avec le partenaire. Expertise en termes d’architure système et applicative. Bénéfices pour CérénIT Poursuite des projets sur les séries temporelles avec un nouvel usage : la série temporelle dans le monde de la course au large
On orchestre, on conçoit — et on code aussi. Parlons de votre plateforme, vos données ou votre projet IoT.
Contactez-nous →