CérénIT

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 :

• Une instance InfluxDB peut contenir 1 à n bases de données (database),
• A chaque base de données InfluxDB, on peut définir une “retention policy” qui est la période maximale de conservation des données. Avec une retention policy de 7 jours par ex, seules les données des 7 derniers jours sont conservées. Les données les plus vieilles seront alors supprimées au fur et à mesure que les nouvelles données arriveront via un mécanisme de compaction.
• Les données d’une base de donneés InfluxDB sont réparties au sein de shards au niveau stockage ; chaque shard comprend les données sur une période de temps donnée. Si une base de données a une retention policy d’une semaine, alors chaque shard contiendra 1 jour de données. Nous aurons donc 7 shards pour cette base de données. Ce délai est appelé shard duration.
• Au sein de chaque shard, nous allons retrouver les données sous la forme d’un ou plusieurs fichiers TSM, le fichier d’index pour le shard, ainsi que le fichier de WAL et de cache.

Nous pouvons représenter la logique instance > database > shard(s) > tsm files de la façon suivante :

Par défaut, InfluxDB applique les shard duration suivantes en fonction des retention policy :

Source : InfluxData - Shard group duration

Dès lors, une base de données avec une retention policy infinie aura une shard duration de 7 jours. Ainsi, si cette base contient 10 ans d’hisorique (soit 10 * 52 semaines = 520 semaines), elle contiendra 520 shards.

Du coup, InfluxData recommande les valeurs suivantes (au moins en 1.x ; on peut supposer que cela reste valable en 2.x):

Source : Shard group duration recommendations

Selon cette perspective, la base de données avec 10 ans d’historique ne contiendra plus 520 shards mais 10 shards en prenant une shard duration de 52 semaines. L’écart entre la valeur par défaut et la valeur recommandée est plus que significatif.

Pour bien dimensionner vos shard duration, InfluxData recommande :

• La durée doit être égale à 2 fois la période d’analyse la plus longue et la plus fréquente ; si vos analyses les plus fréquentes portent sur 6 mois de données maximum, alors votre shard duration est d’un an
• Chaque shard doit contenir au moins 100.000 points
• Chaque shard doit contenir au moins 1.000 points par série (combinaison de measurement (~table) + combinaison des tags + clés des fields)

Pourquoi nous en arrivons là ? C’est assez simple :

• InfluxDB au lancement va découvrir l’ensemble de ses shards et les périodes qu’ils recouvrent
• InfluxDB cherche à mettre un maximum de données en mémoire par souci d’efficience et de performance
• Une requête sur des périodes longues va nécessiter de monter en mémoire tous les shards correspondants à la période

Dès lors, un nombre important de shards va augmenter d’autant plus la consommation mémoire et le nombre de fichiers ouverts pour manipuler les données associées.

Si on recoupe ces données avec les recommendations pour InfluxDB Entreprise, à savoir 30/40 bases par data nodes et 1.000 shards par node, le bon réglage des retention policy et des shard durations n’est pas à négliger pour la bonne santé de votre instance.

En outre, s’il est possible de mettre à jour la retention policy et la shard duration en 1.x, cela ne s’appliquera que pour les nouveaux shards. Les anciens shards ne seront pas “restructurés” en fonction des nouvelles valeurs.

Pour mettre à jour les shards existants, il faut :

• Arrêter les mécanismes d’ingestion de données
• Exporter les données sous la forme de points au format InfluxDB Line Protocol via influxd inspect export
• Supprimer les measurements (voir la base de données si vous voulez aller plus vite)
• Modifier la retention policy et la shard duration de la base de données (ou créer une nouvelle base de données avec les bonnes valeurs pour la retention policy et la shard duration)
• Importer les données par batch de 5000 à 10.000 points.
• Valider le bon fonctionnement de l’instance et l’intégrité des données
• Relancer les mécanismes d’ingestion et gérer le rattrapage.

Ultime question, la version 2.x OSS change-t-elle la donne sur le sujet :

• InfluxDB 2.x OSS recommande 20 buckets actifs (databases) par instancce
• Définir la shard duration n’est possible que via l’API ou via la CLI. Rien via l’UI
• Les outils d’analyse et d’inspection comme influx_inspect en 1.x n’étaient pas à niveau en 2.0 OSS mais le sont presque en 2.1 OSS. Manque encore les commandes report et report-disk.
• Les templates de monitoring InfluxDB2 OSS Metrics et InfluxDB 2 Operational Monitoring requiert d’envoyer les données dans une instance InfluxCloud pour avoir les données.
• La fonction influxdb.cardinality() n’est disponible en OSS que depuis la 2.0.9

En conclusion, ce qu’il faut retenir :

• La retention policy et la shard duration de vos bases InfluxDB ne sont pas à négliger et les valeurs par défaut ne sont surement pas adaptées à votre cas d’usage
• Il est possible de mettre à jour ses valeurs mais elles ne s’appliqueront qu’aux nouveaux shards - pour les anciens shards, il faut exporter les données sous la forme de points et les réimporter
• Il faut trouver la bonne taille de shard duration adaptée à votre cas d’usage ; trop de shards ou des shards trop gros ont chacun leur limites et auront des effets différents sur la consommation CPU/RAM/IOPS
• Pour InfluxDB (Entreprise), il est recommandé d’avoir maximum 1.000 shards et 30/40 bases par node.
• La version 2.x OSS n’apporte pas grand chose de plus sur le sujet - la version 2.1 permet d’être à peu près au niveau de la 1.x.

Mise à jour : le client reporte les gains suivants post restructuration des bases pour le serveur de recette et production :

• 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.

Cloud

• LCC 262 - Interview Cloud de Confiance avec Quentin Adam : Interview posée, pédagogue et claire sur les enjeux du cloud de confiance / cloud souverain mais pas que. A écouter absolument.
• Announcing Cloudflare R2 Storage: Rapid and Reliable Object Storage, minus the egress fees : après son billet vindicatif vis à vis des couts de transferts AWS, Cloudflaire sort son système de fichiers distribué qui se veut une alternative à S3 et avec un cout de migration depuis AWS marginal/progressif puisque apparemment seuls les fichiers appelés seront sortis de leur bucket d’origine pour aller sur R2 et être servi depuis R2 ensuite
• The Compelling Economics of Cloudflare R2 : quelques exemples des économies réalisées entre R2 et S3 ou R2 en mode proxy devant S3.

Container et Orchestration

• Docker is Updating and Extending Our Product Subscriptions : TL;DR: Docker Desktop requiert un abonnement Pro/Team/Business si vous êtes une organisation de plus de 250 employés et 10 Millions de Chiffre d’affaires. L’abonnement commence à 5$/mois/utilisateur. Ce changement démarre au 31/08/2021 avec une période de grâce jusqu’au 31/01/2022. Si certains crient au scandale, il faut bien voir tout ce que Docker Desktop fourni et le travail d’intégration que cela représente. Il faut bien que la société Docker vive pour maintenir ses produits. Tout cela se retrouve dans The Magic Behind the Scenes of Docker Desktop.
• Podman Release v3.3.0 : cette version apporte “podman machine” qui devrait notamment permettre un meilleur support de podman sous OSX avec une couche de virtualisation intermédiaire dans la même veine que Docker Desktop dans le but de proposer une intégration native. Cela ne semble pas fonctionner sur un Apple M1 à cause de l’incompatibilité actuelle de Virtual Box avec ces puces. Si Podman peut certes être une alternative à Docker (Desktop), cela montre aussi le travail d’intégration réalisé par Docker Inc notamment pour le support des Apple M1.
• Podman on Macs Update : statut sur le support de Podman dans un context MacOS/Intel, Windows/Intel et le reste à faire pour MacOS/M1. En attendant, podman machine est supporté nativement sur Linux et MacOS/Intel et en remote client sur Windows/Intel.
• How Docker broke in half : restrospective sur Docker de ses origines à aujourd’hui et quelques pistes pour le futur…
• Docker Compose V2.0.0 : L’outil a été réécrit en go plutôt qu’en python et se veut accessible via la docker cli en tant que sous système (ie docker compose xxx). Pour Windows & OSX, il est fourni avec Docker Desktop.
• Accelerating New Features in Docker Desktop où l’on parle de l’arrivée prochaine d’un Docker Desktop For Linux !!
• No, we don’t use Kubernetes : un billet rafraichissant qui rappelle que Kubernetes n’est pas l’alpha et l’omega de l’infrasatructure.

IoT

• CircuitPython 7.0.0 Released! : version majeure de CircuitPython qui apporte son lot d’améliorations matérielles et logicielles depuis la version 6.3
• tinygo 0.20 : principalement l’ajout du support de Go 1.17 et de nouveaux controlleurs.

JVM

• Good-bye AdoptOpenJDK. Hello Adoptium! : le projet AdoptOpenJDK est repris sous le projet Eclipse Adoptium, qui vient de signer sa première release. Il faudra prévoir une migration vers leurs binaires et leurs dépots ultérieurement (date non définie à ce jour).

Recherche

• Nrtsearch: Yelp’s Fast, Scalable and Cost Effective Search Engine : nouvel entrant dans le monde de la recherche distribuée et opensource basée sur Lucene. Après ElasticSearch et OpenSearch, c’est au tour de Nrtsearch édité par Yelp qui a cherché à résoudre les problèmes qu’ils rencontraient avec ElasticSearch.

Sécurité

• GitHub security update: Vulnerabilities in tar and @npmcli/arborist : si vous utilisez le package tar de NodeJS directement (ou indirectement), il est judicieux de mettre à jour votre version de npm et node et de vérifier vos dépendances.
• Demon’s Cries vulnerability (some NETGEAR smart switches) : si vous avez des “smart switchs” de la marque Netgear, il est temps de patcher le firmware de votre équipement.
• Let’s Encrypt’s Root Certificate is expiring! : si vous avez de vieux équipements dans la nature et qu’ils utilisent ce certificat de Lets Encrypt, il y a des chances qie cela se passe mal à compter de demain…

Time Series

• Industrie du futur : les données sur le chemin critique, Industrie du futur : les données sur le chemin critique – Partie 2 et Industrie du futur : les données sur le chemin critique – Partie 3 : Suite d’un premier article “Les séries temporelle : le futur de la donnée qui continue à poser les enjeux de l’industrie du futur et les évolutions que cela va apporter pour permettre une maintenance analytique (version optimisée de la maintenance préventive et réactive/conditionelle), la data pour la création de nouveaux services et générateurs de revenus (directs ou indirects), les jumeaux numériques et sur un fond de synergies entre l’informatique technique et celle de gestion pour une optimisation des process.
• Server monitoring with Warp 10 and Telegraf : Premiers pas pour la mise en place d’une stack de monitoring avec Telegraf / Warp 10 et Discovery ; manque plus que la suite à Alerts are real time series pour avoir la partie alerting (et notifications ?).
• Discovery : la documentation de la solution de Dashboard as Code pour Warp 10 est (enfin) arrivée !
• winedarksea/AutoTS : tout est dans la description : “AutoML for forecasting with open-source time series implementations.” ; c’est en Python et cela embarque beaucoup de classes / modèles / transformations / …
• Anomaly Detection Toolkit (ADTK) : un framework de détéction d’anomalies en python.
• QuestDB 6.0.5 & QuestDB 6.0.5 September release, geospatial support : la géotimeseries devient tendance : après InfluxDB qui l’a introduit il y a un an environ, et bien longtemps après Warp 10, c’est au tour de QuestDB d’introduire le support des données géospatiales. La version apporte aussi des améliorations sur first() et last() ainsi que les nouvelles fonctions timestamp_floor() et timestamp_ceil() pour gérer les arrondis inférieurs/supérieurs. Enfin, l’API HTTP accepte des paramètres liés au “Out Of Order”.
• QuestDB 6.0.6 : version de maintenance
• QuestDB 6.0.7 : la version 6.0.6 introduit un bug dans le cadre de la migration depuis une version antérieure. La version 6.0.7 apporte un correctif sur le sujet. Si vous êtes en en 6.0.6, mettre à jour * [en 6.0.7 - si vous êtes dans une version inférieure à 6.0.6, passez à la version 6.0.7 sans passer par la case 6.0.6
• QuestDB 6.0.7.1 : en espérant que cette version soit enfin la bonne pour les migrations.
• TimescaleDB 2.4.2 : version de maintenance
• InfluxDB’s Checks and Notifications System : un billet très détaillé sur le fonctionnement des checks et des notifications sous InfluxDB v2 pour mettre en place vos alertes.
• New in Grafana 8.1: Gradient mode for Time series visualizations and dynamic panel configuration : un mode gradient pour les time series qui permet d’appliquer des couleurs sur ses graphs en fonction de seuils.

Conteneurs et orchestration

• Engineering Update: BuildKit 0.9 and Docker Buildx 0.6 Releases : diverses améliorations au niveau du format Dockerfile, de buildtkit et de docker-buildx. Le changement le plus visible et apprécié sera surement le support de la syntaxe “Here-Documents”
• Rook v1.7 Storage Enhancements : Possibilité d’installer un cluster Ceph via un chart Helm (plutôt que via les manifests), des options d’amélioration de la résilience d’un cluster (file mirroring, resource protection from delettion, “stretch cluster” passe en stable) et d’autres améliorations diverses (mise à jour des CRD, etc). A noter que le driver flex va disparaitre en 1.8 au profit du driver CSI.
• Announcing Traefik Proxy 2.5 : Support de Kubernetes 1.22 (et mise à jour des CRD associées, ainsi que des API dépréciées), support de Consul Connect (le service mesh fourni par consul), gestion des plugins locaux et possibilité de créer ses propres providers (dans la même veine que Docker, Kubernetes, etc), support expérimental d’HTTP/3 et enfin ajout des middleware au niveau TCP (et pas uniquement HTTP)
• Integrating Consul Connect Service Mesh with Traefik 2.5 : ex d’intégration Traefik 2.5 avec Consul Connect.
• Beta Support for CRDs in the Terraform Provider for Kubernetes : la resource kubernetes_manifest permet de définir ses propres manifests et donc permet d’utiliser des CRD non disponibles dans le provider officiel. Plus pratique que de générer les manifests via des templates et de faire du kubectl apply par dessus.

Go

• Learning Go by examples : Les parties 4 à 7 sont arrivées avec du CLI, du Bot, du jeu, des app Desktop/GUI, etc.

Monitoring & Observabilité

• Grafana Labs Raises $220 Million Round at $3 Billion Valuation : Grafana Labs continue sur sa lancée avec une 3ème levée de fonds de 220 M$ quasiment un an jour pour jour après leur série B. Soit un total de 295 M$ et une valorisation de 3 Mds $. Ils avaient annoncé il y a quelques années vouloir batir une solution à 360° de l’observabilité, c’est en train de se réaliser. Avec l’intelligence de pouvoir utiliser tout ou partie de leurs produits en fonction de nos besoins.
• Vector v0.16.0 release notes : Ajout d’une source nats, support des proxys HTTP, amélioration du rate limiting des sinks faisant des appels HTTP, chart helm en beta et d’autres améliorations.

Time Series

• Release Announcement: InfluxDB OSS & Enterprise 1.8.9 : version de maintenance de la branche 1.8 OSS & Entreprise - les versions les plus récentes en 0SS étant 2.0.8 et en Entreprise 1.9.3
• Release Announcement: InfluxDB OSS 2.0.8 : passage à Go 1.16, mise à jour de Flux, d’Influx-UI et de flux-lsb-browser. Il est également possible de ne plus lancer l’UI Web. Cette version est la dernière qui aura le client influx fourni avec le binaire du serveur. A compter la version 2.1.0, il faudra télécharger le client indépendamment. Il faudra le récupérer depuis le projet github influx-cli ou la page de téléchargement InfluxData
• Move fast, but don’t break things: Introducing the experimental schema (with new experimental features) in TimescaleDB 2.4, TimescaleDB 2.4.0 et TimescaleDB 2.4.1 : Comme annoncé précédemment, Postgresql 11 n’est plus supporté pour pouvoir apporter certaines nouvelles fonctionnalités. Cette version apporte le “schéma experimental” qui permet de tester des fonctionnalités en avance de phase, sans impacter ceux qui n’en ont pas besoin. Cela apporte aussi des fonctions comme time_bucket_ng qui permet de faire de nouvelles aggrégations et d’avoir prochainement un support des timezones. La seconde fonctionnalité expérimentale porte sur la capacité à bouger de la donnée entre plusieurs nodes en mode cluster.

Automatisation

• Announcing HashiCorp Terraform 1.0 General Availability : Terraform 1.0 est (enfin) GA.
• Announcing Consul 1.10 GA : des améliorations surtout sur la partie “Service Mesh” aka Consul Connect, ainsi que coté UI.

Conteneurs et orchestration

• Lens 5 Released - Release Notes : le “Kubernetes IDE” passe en version 5 avec diverses améliorations dont notamment du collaboratif avec du partage de contexte kubernetes.
• Traefik 2.5, quoi de neuf ? : actuellement en RC2, la version 2.5.0 de Traefik devrait apporter un support expérimental d’HTTP/3, le support des plugins privés, la mise à jour des CRD Kubernetes et les métriques par routeur (désactivé par défaut)

Monitoring & Observabilité

• Grafana 8.0: Unified Grafana and Prometheus alerts, live streaming, new visualizations, and more! : Grafana dans sa version 8.0 avec son lots d’amélioration.
• GrafanaCONline 2021: Your guide to the newest announcements from Grafana Labs : Résumé de la 1ère journée de GrafanaCon avec Grafan 8, Tempo 1.0, etc.
• What’s new in Grafana v8.0 : une version plus détaillée des apports de la version 8.0 de Grafana
• Vector v0.14.0 Release Notes : Vector permet maintenant d’exécuter des scripts externes via la source exec.
• Release Announcement: Telegraf 1.19.0 : version incrémentale avec son lot d’améliorations et de corrections.
• Grafana Labs Brings Modern Open Source Load Testing to Observability with Acquisition of k6 : Grafana Labs étend son offre d’observabilité avec l’acquisition de k6, un outil de test de charge et de performance.

Postgresql

• PostgreSQL as a Microservice : on pense souvent qu’une base de données permet la persistence des données. Ce n’est pas le principal enjeu d’une base de données mais la gestion de la concurrence.

Time Series

• Release Announcement: InfluxDB OSS 2.0.7 : version de maintenance avec des correctifs et la mise à jour de Flux.
• Release Announcement: Chronograf 1.9.0 : Version 1.9 de Chronograf, l’outil de dasboard et exploration des données d’InfluxData pour InfluxDB 1.x et 2.x. Cette version apporte un meilleur support de Flux (template variable, etc), le support au niveau UI du support TickScript & Flux de Kapacitor 1.6 (release à venir), un mode HA et pleins d’autres améliorations. Une version qui peut être utile dans le cadre d’une migration progressive d’InfluxDB 1.x vers 2.x
• influxdata/influxdb-stack-manager : pour gérer plus efficacement vos “stacks” InfluxdB (dashboard, tasks, etc). Requiert la cli influx.
• TSFR Edition #11 - Récapitulatif InfluxDays EMEA 2021 : Edition un peu particulière du meetup - n’ayant pas pu l’organiser dans les temps mais l’ayant préparé, voici sous forme vidéo le résumé des annonces produits d’InfluxData dans le cadre des InfluxDays EMEA 2021.
• TSFR Edition #12 - Le Bateau Qui Vole - Exploiter des données de navigation pour remporter les courses au large : un retour pragmatique et assez complet sur la mise en place d’un process de collecte / traitement / analyse des données d’un trimaran et des problématiques rencontrées.
• Interacting with Git repositories from Warp 10 : dans le cadre de la version 2.8 de Warp 10, des nouvelles capacités autour de l’interaction avec des dépots git sont disponibles. L’article présente des interactions de base mais j’ai encore du mal à voir les cas d’usage auxquels cela semble vouloire répondre.
• Protecting your Macros and Functions with Capabilities : Avec Warp 10 2.8, il est désormais possible de définir des “capacités” et de contrôler plus finement les actions des utilisateurs au travers de ces capacités.
• WarpStudio v2: What’s new in our Web IDE? : nouvelle version du WarpStudio de SenX, l’IDE Web prévue pour Warp 10 : support de FLoWS, documentation intégrée, intégration git, support de Disocvery (Dashboard as code), snippets, etc.
• Ma comptabilité, une série temporelle comme les autres - partie 5 - Les FEC et le compte 512 : si vous l’avez raté, nouvelle partie sur la comptaiblité, une série temporelle comme les autres avec cette fois-ci l’ingestion des fichiers d’écritures comptables (FEC) et l’analyse du compte 512 (banque)
• Don’t write your own persistence layer: why we chose RocksDB : retour d’exéprience de QuasarDB sur le choix de la couche de persistence entre batir sa propre solution (spoiler : mauvaise isée), utiliser LevelDB (comme Warp 10) ou faire le choix de RocksDB.
• Meet Kats — a one-stop shop for time series analysis - facebookresearch/Kats - Kats - One stop shop for time series analysis in Python : Facebook vient de sortir une librairie en python qui veut fournir un “tout en un” de la manipulation de séries temporelles. On y retrouve notamment Prophet pur la partie prédiction.

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 !