*

Web, Ops, Data et Time Series - Juin 2021


30/06/2021 grafana postgresql terraform vector warp10 quasardb influxdb k6 telegraf warpstudio consul chronograf traefik lens

Automatisation

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é

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

Ma comptabilité, une série temporelle comme les autres - partie 5 - Les FEC et le compte 512


08/06/2021 warp10 timeseries comptabilité trésorerie banque fec

Suite de notre épopée :

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.

Le Fichier des Ecritures Comptables (FEC)

Le Fichier des Ecritures Comptables (FEC) est un format de fichier normalisé. Sa spécification est disponible et grosso modo, ce qu’il faut en savoir à ce stade :

  • C’est un fichier TSV (un CSV avec les champs séparés par des tabulations)
  • Il contient 18 champs permettant de décrire les différentes écritures comptables :
    • JournalCode
    • JournalLib
    • EcritureNum
    • EcritureDate
    • CompteNum
    • CompteLib
    • CompAuxNum
    • CompAuxLib
    • PieceRef
    • PieceDate
    • EcritureLib
    • Debit
    • Credit
    • EcritureLet
    • DateLet
    • ValidDate
    • Montantdevise
    • Idevise

En partant de ces informations et après quelques précisions fournies par mon expert-comptable Fabrice Heuvrard sur le fichier, nous avons convenu de commencer par l’analyse du compte 512 correspondant aux opérations bancaires. Facile à calculer (somme des crédits - somme des débits) et facile à vérifier, il me suffit de regarder mon compte en banque et/ou mon bilan en fin d’année.

Continuant à utiliser Warp 10 pour y stocker mes séries temporelles, j’ai réalisé un script en Go qui prend le fichier FEC en entrée et envoie les données dans Warp 10 avec le formalisme suivant : <société>.<bilan ou resultat>.<classe de compte>.<type d'opération: credit ou debit> :

  • <société> est juste le début de l’arborescence
  • <bilan ou résultat> : le Plan Comptable Général Francais défini que si les comptes de classe 1 à 5 sont des classes de bilan et les classes 6 et 7 sont des classes de compte de résultat. Je suis donc le même principe de séparation des comptes et défiinr la valeur bilan et resultat. Le compte 512 que nous allons étudier commençant par 5, c’est un compte de bilan. Il sera donc dans la série cerenit.bilan.*
  • <classe de compte> : le plan comptable général est normalisé sur ces trois premiers chiffres. Les trois suivants sont à la discrétion du comptable. Du coup, pour ne pas avoir une série par code comptable, je retrouve par classe du plan de compte. Ainsi, toutes les opérations ayant le code 512xxx se retrouvera dans la série cerenit.bilan.512.*
  • <type d'opération: crédit ou débit> : suivant si l’opération est un débit ou crédit, cela prend la valeur adéquat. Ainsi, toutes les opérations ayant le code 512xxx se retrouvera dans la série cerenit.bilan.512.credit ou ``cerenit.bilan.512.debit`
  • Le montant de l’écriture comptable sera la valeur associée à mon point dans la série.
  • Les autres informations seront mises sous la forme de labels (ie meta données de mon point) pour d’éventuelles analyses ultérieures. Il s’agit de couple clé/valeurs.

Ainsi, un crédit de 100€ avec une référence de pièce à 1234 sera représenté sous la forme :

<Timestamp de l'écriture comptable>// cerenit.bilan.512.credit{PieceRef=1234} 100

La modélisation est peut être un peu naive à ce stade, il sera toujours temps de la faire évoluer dans un second temps mais a priori :

  • J’ai ma séparation bilan / compte de résultat
  • J’ai ma séparation par classe de compte
  • J"ai ma séparation débit / crédit
  • au pire via les labels, j’ai des axes complémentaires de recherche / sélection.

Contrôle des données

Avant de commencer la moindre analyse, j’ai voulu vérifier l’intégrité de mes données.

"<readToken>" "readToken"  STORE

// Récupération des données de 2020 pour le compte 512
[ $readToken 'cerenit.bilan.512.credit' {} '2020-01-01T00:00:00Z' '2021-01-01T00:00:00Z' ] FETCH
// Fusion de l'ensemble des séries temporelles en une seule série
MERGE
// Calcul de la somme de l'ensemle des valeurs de la séries -
// MAXLONG permet de tout récupérer sans calculer la taille exacte de la liste (pour peu que votre liste soit plus petite que la valeur de MAXLONG)
// 1 permet de ne sortir qu'une valeur en sortie
[ SWAP mapper.sum MAXLONG MAXLONG 1 ] MAP
// C'est une liste avec une liste à 1 élément, on "applatit" tout ça
MERGE
VALUES
0 GET
// On stocke la valeur finale dans totalCredit
'totalCredit' STORE

// Même opération sur les débits
[ $readToken 'cerenit.bilan.512.debit' {} '2020-01-01T00:00:00Z' '2021-01-01T00:00:00Z' ] FETCH
MERGE
[ SWAP mapper.sum MAXLONG MAXLONG 1 ] MAP
MERGE
VALUES
0 GET
'totalDebit' STORE

// Calcul du solde
$totalCredit $totalDebit -

Cela me donne : 27746.830000000075

Exploration de la trésorerie

"<readToken>" "readToken"  STORE

// Récupération des données de 2020 pour le compte 512
[ $readToken 'cerenit.bilan.512.credit' {} '2020-01-01T00:00:00Z' '2021-01-01T00:00:00Z' ] FETCH
// Fusion de l'ensemble des séries temporelles en une seule série
MERGE
// Tri des points par date
SORT
// Renommage de la série
'credit' RENAME
// Suppression des labels
{ NULL NULL } RELABEL
// Stockage dans une variable
'credit' STORE

// Même opération sur les débits
[ $readToken 'cerenit.bilan.512.debit' {} '2020-01-01T00:00:00Z' '2021-01-01T00:00:00Z' ] FETCH
MERGE
SORT
'debit' RENAME
{ NULL NULL } RELABEL
'debit' STORE

// Affichage des deux séries
$credit
$debit

// Création de la série de mouvements
$credit $debit -
'mouvements' RENAME

Cela nous donne ces courbes:

warp10 - exploration treso

Mais on voit bien à fin décembre qu’il y a des opérations de débit qui ne sont pas prises en compte dans le solde (la ligne orange s’arrête avant la verte).

En cherchant un peu, je me dis qu’il faudrait que je calcule une nouvelle série avec tous les éléments de crédit et débit et faire l’addition de tout cela. Je vois également que FLATTEN (doc)permet de fusionner plusieurs listes en une seule. Mais finalement, seul MERGE sera nécessaire.

Cela me donne la piste suivante :

"<readToken>" "readToken"  STORE

// Récupération des données de 2020 pour le compte 512
[ $readToken 'cerenit.bilan.512.credit' {} '2020-01-01T00:00:00Z' '2021-01-01T00:00:00Z' ] FETCH
MERGE
SORT
'credit' RENAME
{ NULL NULL } RELABEL
'credit' STORE

// Même opération sur les débits
[ $readToken 'cerenit.bilan.512.debit' {} '2020-01-01T00:00:00Z' '2021-01-01T00:00:00Z' ] FETCH
MERGE
SORT
'debit' RENAME
{ NULL NULL } RELABEL
// Je multiplie les debits par -1 pour pouvoir faire l'opération de solde ensuite
[ SWAP -1 mapper.mul 0 0 0 ] MAP
'debit' STORE

// Je fusionne les deux séries avec MERGE
[
  $credit
  $debit
] MERGE
// Je trie les éléments par date
SORT
'mouvements' RENAME

Cette fois-ci, mon solde prend bien en compte toutes les opérations de l’année.

warp10 - mouvements treso

Pour la version consolidée avec le solde du compte :

// Récupération des données de 2020 pour le compte 512
[ $readToken 'cerenit.bilan.512.credit' {} '2020-01-01T00:00:00Z' '2021-01-01T00:00:00Z' ] FETCH
MERGE
SORT
'credit' RENAME
{ NULL NULL } RELABEL
'credit' STORE

// Récupération des données de 2020 pour le compte 512
[ $readToken 'cerenit.bilan.512.debit' {} '2020-01-01T00:00:00Z' '2021-01-01T00:00:00Z' ] FETCH
MERGE
SORT
'debit' RENAME
{ NULL NULL } RELABEL
-1 *
'debit' STORE

// Fusion des débits/crédits comme vu précédemment
[
  $credit
  $debit
] MERGE
SORT
'mouvements' RENAME

// On applique mapper.sum sur l'ensemble des points précédents le point qui est considéré
// Le premier point ne va donc prendre que lui même
// Le 2nd point va prendre sa valeur et ajouter celle du précédédent
// Le 3ème point va prendre sa valeur et la somme des points précédents
// Et ainsi de quiste
[ SWAP mapper.sum MAXLONG 0 0 ] MAP

Et le résultat en images :

warp10 - mouvements treso

Et voilà !

Il ne me reste plus qu’à :

  • ingérer les FEC des autres années pour envisager des comparaisons entre les différents exercices comptables, voire du prédictif pour l’exercice en cours et à venir,
  • étendre ces analyses à d’autres comptes maintenant,
  • et à créer les dashboards adéquats avec Discovery.

Web, Ops, Data et Time Series - Mai 2021


26/05/2021 hashicorp nomad ovh time leap second gitlab-ci python dbt metabase datatask warp10 monitoring wasm sécurité spectre timescale sql cli readme bootstrap influxdata kapacitor chronograf

CI

Cloud

Conteneur et orchestration

  • Announcing General Availability of HashiCorp Nomad 1.1 : 10 nouvelles fonctionnalités au programme (7 en OSS, 3 en entreprise) : surallocation de mémoire (soft et hard limit), les CPU peuvent être réservés en tant que tel (et non plus uniquement via une fraction), amélioration d’UI, amélioration coté support CSI, distinction entre les “readyness checks” et “liveness checks” au niveau des health checks, exécution distante sur AWS Lambda et AWS ECS (tech preview). Pour la version entreprise : supper des namespaces consul, chargement automatique des licences lors du déploiement de nouveaux noeuds, amélioration de l’autoscaling.

Data

Docs

  • readme.so (via MACI #42) : Vous ne savez pas quoi mettre dans votre README ? Ce site est fait pour vous et peut aussi vous aider à réorganiser vos fichiers.

Europe

  • Souveraineté et cloud, quel rapport ? : remise en perspective du cloud souverain et implications des décisions européenes. La remise en cause du Privacy Shield et les clauses contractuelles font qu’au final : “tout transfert de données personnelles sous juridiction américaine est illégal.". La reglementation européene, centré sur le respect des droits des personnes permettrait de fiare un protectionnisme reglementaire dans l’idée de développer un écosystème numérique européen et conforme aux valeurs européennes. A lire et méditer !

License

Système

  • negative leap second news! : une seconde est intercallée de temps à autre pour se resynchroniser avec la rotation terrestre. En général, on ajoutait une seconde. Là, on va retirer une seconde - c’est apparemment la première fois que cela se passe.

Sécurité

Time Series

  • $40 million to help developers measure everything that matters : Timescale annonce une levée en série B de 40 Millions de dollars - environ 2 millions d’instances actives et une dizaine de sorties produits pour le mois de Mai.
  • How we made DISTINCT queries up to 8000x faster on PostgreSQL : dans le cadre de la sortie de TimescaleDB 2.2.1, l’arrivée de “Skip Scan” permet d’accélérer les SELECT DISTINCT entre 28x et 8000x. Cela est valable tant pour les données Timescale que les données natives Postgres. Une contribution upstream est prévue.
  • TimescaleDB 2.3: Improving columnar compression for time-series on PostgreSQL : Après le rajout des ALTER/RENAME des colonnes compressées en 2.1 - le rajout des INSERT avec une compression en deux temps (compression de l’insert en lui même puis recompaction des données au niveau du chunk)
  • QuestDB 6.0 : implémentation de la gestion du Out Of Order, amélioration sur le InfluxDB Inline Protocol ainsi que sur l’UI et la couche SQL.
  • How we achieved write speeds of 1.4 million rows per second : retour plus détaillé sur la gestion du Out Of Order dans QuestDB.
  • InfluxDB OSS and Enterprise Roadmap Update from InfluxDays EMEA : InfluxData juge qu’à partir de la version 2.0.6, la mise à jour depuis une version 1.8 est stable. La version 1.8 sera donc maintenue jusqu’à la fin d’année. Au-delà de cette date, les correctifs ajoutés seront dans la branche master mais il n’y aura plus de packaging de la version 1.8 OSS. Seule la version 1.8 Entreprise aura de nouveaux binaires. Abandon des binaires en 32 bits pour InfluxDB 2.x. Concernant la version Entreprise, InfluxDB 1.9 va apporter des améliorations notamment concernant le support de Flux. Par ailleurs Chronograf 1.9 et Kapacitor 1.6 vont sortir en juin avec diverses améliorations. Ces deux produits seront compatibles avec InfluxDB 2.x pour aider à la montée de version vers InfluxDB 2.x. Enfin, InfluxDB 0SS 2.1 va sortir aussi en juin avec notamment l’ajout des notebooks, les annotations sur les dashboards et des améliorations de Flux.
  • Release Announcement: InfluxDB OSS and InfluxDB Enterprise 1.8.6 : version de maintenance avec une faille de sécurité pour la version Entreprise.
  • Monitorer son infra avec Warp 10 - Partie 1, Partie 2, Partie 3 : Mise en oeuvre des outils de la plateforme Warp 10 pour monitorer son infrastructure. Cela couvre l’installation, la collecte des métriques, l’exploration des données et calcul des premiers métriques, et pour finir la création des dashboards.
  • Mon Linky dans Warp 10 avec un joli dashboard : Ingestion des données issues du Linky dans Warp 10 et présentation de ces données dans un Dashboard Discovery.
  • May 2021: Warp 10 releases 2.8.0 and 2.8.1 - SenX : En résumé (liste non exhaustive, va falloir qqs billets plus détaillés pour comprendre toutes les nouveautés) : Gestion plus fine des “capabilities” au niveau des tokens, Utilisation de FLoWS simplifié, Intégration avec la blockchain Ethereum, Des fonctions de crypto / signature / …, Des améliorations sur la manipulation de JSON, Une fonction HTTP pour permettre des appels distants, Ajout de mapper.geo.fence pour voir si un point est dans/en dehors d’une zone, Des choses autours des MACRO et plein d’autres améliorations/corrections.
  • Working with GEOSHAPEs: code contest results : le corrigé du concours lancé par SenX autour des GEOSHAPEs dans Warp 10. Concours que j’ai remporté et voici mes réponses : partie 1 & partie 2
  • Wikipedia / Warp 10 : Warp 10 dispose de sa page Wikipedia
  • « Le bateau qui vole » : l’analytique en temps réel au service d’un skipper : de l’utilité des séries temporelles dans le monde de la course au large pour une meilleure appréhension du fonctionnement du bateau et de ses performances. Ce retour d’expérience sera le thème d’une prochaine édition du Time Series France !

Web

  • Bootstrap 5 : nouvelle version majeure du framework Boostrap avec la suppression de la dépendance à JQuery et la fin de support de plein de vieux navigateurs notamment.

Ma solution pour le Warp 10 Code Contest - partie 2


18/05/2021 timeseries warp10 geospatial challenge

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.

A ce stade, nous avons une liste de 8 séries correspondant à chaque section passée sur la route 66. Chaque série comporte un liste de timestamps et de points géospatiaux (lattitude, longitude, élévation).

Concernant le troisième bloc :

  • il s’agit de calculer la vitesse en m/s entre chaque point de la série (ce qui explique le 1 0 0 pour prendre le point précédent, aucun point suivant et appliquer cette opération sur l’ensemble de la liste - voir la tips 3 de 12 tips to apply sliding window algorithms like an expert). Pour cela, on utilise mapper.hspeed (doc) qui consomme une série et calcule la vitesse en m/s en tenant compte de la longitude/lattitude/élévation.
  • Ce résultat, on le convertit en km/h dans la foulée en utilisant mapper.mul (doc) en notant au passage qu’il lui faut une constante (on ne peut pas mettre 3600 * 1000 / mais 3.6)
  • On a donc une liste de 8 séries temporelles avec chacune un timestamp, les données géospatiales et une vitesse entre chaque point. C’est stocké dans la variable speedFrames.

Concernant le 4ème bloc :

  • Sur le même modèle que pour la vitesse, on calcul la distance entre chaque point des 8 séries via mapper.hdist que l’on a vu dans le premier billet. Cette fois-ci, plutôt que de calculer la distance totale, on la distance entre le point et le point suivant et on le fait pout tout les points de la liste, d’où le 0 1 0
  • La distance étant en mètres, on la divisie par 1000 pour avoir des kilomètres. Mais comme il n’y a pas de mapper de division, alors on utilise mapper.mulet la valeur 0.001
  • On a donc une liste de 8 séries temporelles avec chacune un timestamp, les données géospatiales et une distance entre chaque point. C’est stocké dans la variable distanceFrames.

Concernant le 5ème bloc :

  • j’ai voulu calculer la consommation d’essence sur la base de la formule:

(8 liters/100km) × (speed (km/h) / 80) +1

  • Cela se simplifie en Speed/10 + 1.
  • Si on multiplie ce coefficient par les vitesses entre deux points obtenues précédemment (dans speedFrames), on obtient une consommation pour 100km avec chaque vitesse. Il faudra dans un second temps le pondérer par la distance parcourue entre deux points (distanceFrames) pour avoir un instantané de consommation pour la vitesse et la distance parcourue.
  • Pour faire cette consommation au 100km non pondérée, on utilise LMAP (doc)pour appliquer une MACRO à chaque élément de la liste. Cette macro contient le coefficient de consommation d’essence. LMAP retourne normalement l’index et la valeur associée. Or l’index ne nous sert à rien, on met donc l’argument concernant l’index à False (abrégé F) pour qu’il ne soit pas retourné.
  • On stocke le résultat dans hundredKmFuelConsumption et on a donc une liste de 8 series avec la consommation pour 100km à la vitesse donnée. Il nous faut maintenant pondérée cette liste par la distance pour avoir un instantané de consommation.

Concernant le 6ème bloc :

  • On commence par créer une liste vide appelée instantConsumption.
  • On sait que l’on a une liste de 8 éléments, donc on peut faire un boucle FOR (doc) dessus avec un indice allant de 0 à 7. FOR prend comme dernier argument une MACRO que j’ai nommé C
  • Dans la MACRO définie au dessus, je commence par stocker l’index de la boucle. Mes deux listes de 8 séries temporelles sont identiques en terme de points, avec l’une contenant les consommations pour 100km hundredKmFuelConsumptionet la seconde les distances entre chaque point distFrames. L’idée est donc de multiplier chaque série de hundredKmFuelConsumption par la série équivalente dans distFrames et de diviser par 100 pour finir notre proportionnalité.
  • On stocke cet consommation instantanée dans la variable r.
  • On ajoute ce résultat r dans la liste instantConsumption, ce qui permet de reconstituer notre liste de 8 séries mais ayant pour valeur cette fois ci les instantanés de consommation entre chaque point de chaque série.

Un petit interlude visuel avant le dernier bloc :

warp10 - instantané de consommation

Concernant le 7ème bloc :

  • Le but est de faire la somme de chaque instantanné de consommation pour avoir la consommation totale.
  • Comme dans la première partie, on utilise cette fois-ci mapper.sum (doc) en prenant l’ensemble des données des listes capturées via MAXLONG et on récupère 1 seule valeur qui s’avère être le total. On a donc la consommation totale de chaque série
  • Comme vu aussi en fin de première partie, on fait alors la somme de chaque liste pour avoir la consommation totale (9.823366576601234)
  • On sait que 1L = 2392g CO2, il nous reste donc à faire cette multiplication.
  • On obtient alors : 23497.492851230152 ou 23,497 kg de CO2.

J’espère avoir été clair dans ces explications - si ce n’est pas le cas - dites le moi (via Twitter, Mail, LinkedIn, etc) et je préciserai les choses.

Bilan personnel de ce code contest :

  • Opportunité de découvrir une partie des fonctionnalités géospatiales de Warp 10 que je n’avais pas encore utilisé
  • Améliorer mon usage autour de MAP, les mapper, les MACRO et LMAP et plein de petites choses ici ou là.
  • MAP s’applique sur des GTS mais aussi des listes de GTS sans rien avoir à faire. Pas besoin de se rajouter des boucles supplémentaires !
  • MAXLONG utilisé dans les MAP permet de ne pas avoir à se soucier de la taille de l’élément sur laquelle on applique MAP. Cela ne fait pas non plus une erreur du style index out of range.
  • en bonus, obtenir quelques lots sympathiques 😎

warp10 - goodies recto

warp10 - goodies verso

J’espère néanmoins apprendre des choses du corrigé officiel : Working with GEOSHAPEs: code contest results.

Syndication

Restez informé(s) de notre actualité en vous abonnant au flux du blog (Atom)

Nuage de tags

kubernetes docker influxdb timeseries warp10 traefik grafana ansible kafka postgres elasticsearch python sécurité terraform aws mysql redis ovh tick cassandra cloud docker-compose git hashicorp helm telegraf timescaledb chronograf ptsm swarm dashboard rancher résilience test vector flux gcp gitlab log machine-learning monitoring podman prometheus spark architecture arm confluent devops gitlab-ci iac java kapacitor ksql microservice raspberrypi s3 serverless service-mesh sql timescale vscode angularjs api bilan cert-manager cncf comptabilité consul container cérénit dns gke graphql influxdata ingress javascript nomad opensource operator optimisation perspective pipeline rook scaleway ssh stream vault warpscript windows cli containerd csp documentation elastic flows forecast geospatial golang hpkp influxace iot jenkins kafka-streams kibana kubedb lambda lean licence maesh maintenance mariadb microsoft mobile nginx npm orientdb performance postgresql redhat registry rest rethinkdb reverse-proxy sauvegarde agile apm arima automatisation azure bash big-data bigdatahebdo ceph certificat challenge ci/cd cluster continous-delivery continous-integration cookie data dataviz deployment diff facebook fluxlang framework gdpr grav hsts http/3 https hypriot hébergement ia influxdays istio jq json k3s lets-encrypt linux load-balancer longhorn meetup molecule mongodb nosql nvidia openebs openssh ovhcloud percona php pip quasardb reaper replication rootless rpi rsyslog runc scale secrets société solr sre systemd tempo timezone tls virtualenv vitess vue.js wagtail warpfleet warpstudio yarn accessibilité acme agpl akka alerte alibaba amazon-emr amqp anomalie anonymisation anthos apache-pulsar ara arrow artefact audit banque bastion beam beat bme680 bootstrap bounded-context branche brigade browser buildah buildkit cahier-des-charges calico cassandra-reaper cd cdc cdk centos centralisation-de-logs certificats cgroups chart checklist chrome ci cilium cloud-init cloud-native cloud-storage clusterip cnab cni co2 cockroachdb code codeurs-en-seine commit confluence conftest consul-connect context continous-deployment conventional-commit coreos cors covid19 cqrs crash cri cron crontab csi csrf css curl d3.js daemonset data-engineer data-pipelining data.gouv.fr databricks datacenter datatask date date-scientist dbt ddd debezium debian delta deprek8 desktop devoxx dig discovery distributed-systems dive docker-app docker-hub docker-registry docker-swarm dockershim documentdb dog dokcer données-personnelles draft drop-in duration déploiement développement-du-site e-commerce ebs ec2 edge elassandra electron elk engineering entreprise ergonomie etcd euclidia event-sourcing faas faisabilité falco falcor feature-policy fec fedora feed filebeat firebase firefox fish flash flask fleet flink fluentd formation foundation frenchtech frontend fsync fullstack git-filter-repo github gitignore glacier glowroot go google google-cloud-next gpg gpu grid géospatial hacker hadoop haproxy harbor hdfs header holt-winters html html5 http hue iaac ibm immutable incident index indluxdata influxcloud infrastructure-as-code ingénierie inspec jquery jwt k3d k6 k8s k9s kaniko katz kotlin kubeadm kubecon kubectl label laravel leap-second lens letsencrypt libssh linky linter liste-de-diffusion lmap loadbalancer logstash logstatsh loi loki lstm mailing-list management maturité mesh mesos message metabase metallb micro-service minio mot-de-passe mqtt multi-cloud médecine métrique network newsletter nodeport notebook null object-storage observability observabilité opa opendata openhab openmetrics openshit openstack openweb opnsense over-engineering packaging pandas parquet partiql password persistent-volume-claim pico pipenv pod portainer portworx prediction prescience production promql prophet prévision psp ptyhon publicité pubsub pulsar push pyenv pérénnité qualité quay questdb queue quic ram rambleed raml react readme recaptcha recherche redistimeseries reindex reinvent reliability remote-execution repository responsive revocation revue-de-code rexec rgpd rhel rkt rolespec root rpo rto rust rwd safe-harbor sarima scalabilité scanner schema scp sdk search select serverless-architecture service service-account service-worker setuptools sftp sha1 sharding shell shipyard sidecar souveraineté-numérique spectre spinnaker spécifications sqlite sri ssh-agent ssl stabilité stash statistique storage sudo superset suse sympa sysdig syslog-ng sérénité template terracost terrascan test-unitaire tidb tiers time timer timestream training transformation travail trésorerie tsfr tsl ubuntu unikernel unit ux velero vendredi victoria-metrics vie-privée virtualbox virtualisation vm vnc volume voxxeddays vpc wasm web wireguard yaml yq yubikey