Cependant, cette approche pose un problème majeur lorsqu’on veut appliquer des pratiques d’ingénierie modernes :

• tests automatisés
• CI/CD
• reproductibilité
• validation avant déploiement

Contrairement aux microservices classiques, un flow NiFi est souvent défini visuellement, et non comme un artefact testable.

C’est précisément ce problème que j’ai voulu résoudre avec nifi-tester : un outil permettant de tester des flows NiFi de manière automatisée et reproductible.

Dans cet article, je détaille :

• le problème de test dans NiFi
• l’architecture de l’outil
• les choix techniques
• comment intégrer ces tests dans une pipeline CI/CD.

Le problème : les flows NiFi ne sont pas naturellement testables

Dans un projet classique, les tests sont une évidence :

• unit tests
• integration tests
• contract tests
• end-to-end tests

Mais avec NiFi, plusieurs difficultés apparaissent.

1. Les pipelines sont définis dans une interface graphique

Les flows NiFi sont généralement :

• créés dans le canvas web
• versionnés via un registry
• exportés sous forme de flow definitions

Cela signifie que le pipeline est une configuration runtime, pas du code directement exécutable.

Conséquences :

• difficile de tester localement
• difficile d’automatiser
• difficile de reproduire un bug.

2. Les pipelines sont fortement intégrés

Un flow NiFi interagit souvent avec :

• Kafka
• S3
• bases de données
• APIs REST
• systèmes legacy.

Le test devient alors un problème de simulation d’environnement.

Sans outil dédié, les équipes font souvent :

• des tests manuels
• des validations dans un environnement de staging
• des vérifications via la provenance NiFi.

Cela ralentit énormément les cycles de développement.

3. Les pipelines data doivent suivre les mêmes standards que les services

Aujourd’hui, dans une plateforme data mature, les pipelines doivent être :

• versionnés dans Git
• validés automatiquement
• déployés via CI/CD.

Autrement dit :

les pipelines doivent être traités comme du code.

C’est la philosophie derrière nifi-tester.

Objectif : rendre les flows NiFi testables

L’idée centrale du projet est simple :

un flow NiFi doit pouvoir être testé comme une fonction.

Conceptuellement :

Input Dataset
     │
     ▼
 NiFi Flow
     │
     ▼
Output Dataset

Un test doit donc définir :

• une entrée
• un flow à exécuter
• un résultat attendu.

Architecture de nifi-tester

L’outil repose sur trois composants principaux.

+-------------------+
| Test Definitions  |
+---------+---------+
          |
          v
+---------+---------+
|   Test Runner     |
+---------+---------+
          |
          v
+---------+---------+
| NiFi Execution    |
| Environment       |
+---------+---------+
          |
          v
+-------------------+
| Result Validator  |
+-------------------+

Chaque étape correspond à une responsabilité bien définie.

Définition des tests

Les tests sont définis avec Junit :

@Test
@DisplayName("Deploy Groovy script pipeline")
void testGroovyScriptPipeline() throws Exception {
    var result = tester.deployPipeline(
        new java.io.File("src/test/resources/pipelines/groovy-script-pipeline.yaml"),
        "root"
    );

    assertNotNull(result);
    assertTrue(result.isSuccess(), "Deployment failed: " + result.getMessage());

    if (result.isSuccess()) {
        String pgId = result.getProcessGroupId();
        var group = tester.getProcessGroup(pgId);
        assertNotNull(group);

        // Start the process group
        tester.startProcessGroup(pgId);

        // Stop LogResult so flow file stays in the queue before it
        String logResultId = tester.findProcessorIdByName(pgId, "LogResult");
        if (logResultId != null) {
            tester.stopProcessor(logResultId);
        }

        // Find the input port
        String inputPortId = tester.findInputPortIdByName(pgId, "Input");
        assertNotNull(inputPortId, "Input port not found");

        // Wait for port to start up before pushing data via Site-to-Site
        Thread.sleep(5000);

        // Inject "hello" into the input port
        tester.injectFlowFile(inputPortId, "hello");

        // Find the connection between AppendWorld and LogResult
        String connId = tester.findConnectionId(pgId, "AppendWorld", "LogResult");
        assertNotNull(connId, "Connection not found");

        // Wait for processing
        long start = System.currentTimeMillis();
        boolean found = false;
        while (System.currentTimeMillis() - start < 15000) {
            var contents = tester.getFlowFileContentsAsString(connId);
            for (String content : contents) {
                if (content.contains("hello world")) {
                    found = true;
                    break;
                }
            }
            if (found) break;
            Thread.sleep(500);
        }
        assertTrue(found, "Expected to find 'hello world' in flow file content");

        // Stop the process group
        tester.stopProcessGroup(pgId);

        // Cleanup
        tester.deleteProcessGroup(pgId);
    }
}

Et les flows, en Yaml

name: Groovy Script Pipeline
description: A pipeline that uses Groovy script to append 'world' to 'hello'
parentGroupId: root

inputPorts:
  - name: Input
    x: 100
    y: 100

processors:
  - name: AppendWorld
    type: org.apache.nifi.processors.groovyx.ExecuteGroovyScript
    x: 400
    y: 100
    schedulingStrategy: TIMER_DRIVEN
    schedulingPeriod: "1 sec"
    properties:
      Script Body: |
        import org.apache.nifi.flowfile.FlowFile
        import java.nio.charset.StandardCharsets
        
        FlowFile flowFile = session.get()
        if (flowFile != null) {
            String content = ""
            session.read(flowFile, { inputStream ->
                content = new String(inputStream.readAllBytes(), StandardCharsets.UTF_8)
            })
            content = content + " world"
            flowFile = session.write(flowFile, { outputStream ->
                outputStream.write(content.getBytes(StandardCharsets.UTF_8))
            })
            session.transfer(flowFile, REL_SUCCESS)
        }

  - name: LogResult
    type: org.apache.nifi.processors.standard.LogAttribute
    x: 700
    y: 100
    schedulingStrategy: TIMER_DRIVEN
    schedulingPeriod: "1 sec"
    properties:
      Log Level: info
      Log Prefix: "Result: "
    autoTerminatedRelationships:
      - success

connections:
  - name: Input to Groovy
    sourceId: ${Input}
    destinationId: ${AppendWorld}
    x: 250
    y: 100

  - name: Groovy to Log
    sourceId: ${AppendWorld}
    destinationId: ${LogResult}
    relationships:
      - success
    x: 550
    y: 100

Conclusion

Les pipelines de données sont aujourd’hui des composants critiques de l’infrastructure logicielle.

Pourtant, ils restent souvent moins testés que les applications classiques.

Avec nifi-tester, l’objectif est simple :

apporter aux pipelines NiFi les mêmes pratiques d’ingénierie que pour le code applicatif.

En introduisant :

• des tests automatisés
• des validations reproductibles
• une intégration CI/CD

il devient possible de traiter les dataflows comme des artefacts logiciels à part entière.

Pourquoi un autre outil CI/CD ?

Le secteur du CI/CD est déjà bien rempli. Jenkins, GitHub Actions, GitLab CI, CircleCI — la liste est longue. Mais chacun impose des compromis :

• Jenkins : Puissant mais lourd, avec une courbe d’apprentissage abrupte.
• GitHub Actions : Lié à GitHub, peut devenir coûteux pour les dépôts privés.
• GitLab CI : Excellent si vous utilisez GitLab exclusivement.
• CircleCI/Travis : Cloud uniquement, la facturation à l’usage peut vite grimper.

GiwiCD adopte une approche différente. Il est conçu pour les développeurs qui veulent une solution CI/CD simple, rapide et auto-hébergée qui fonctionne, tout simplement.

Qu’est-ce que GiwiCD ?

GiwiCD est une plateforme CI/CD open-source qui vous permet de :

• Créer des pipelines visuellement — Pas de fichiers YAML. Cliquez, glissez et configurez.
• Lancer des builds en temps réel — Suivez l’exécution de vos builds en direct grâce aux logs diffusés via WebSocket.
• Gérer vos identifiants en toute sécurité — Stockez vos clés SSH, jetons (tokens) et accès de notification de manière sécurisée.
• Être notifié automatiquement — Envoyez le statut des builds vers Telegram, Slack, Teams ou par Email.
• Déclencher des builds de n’importe où — Webhooks, scrutation (polling) de push, ou déclenchement manuel.

Screenshots

Landing	Login

Dashboard	Pipelines

Builds	Credentials

Caractéristiques principales

Constructeur de Pipeline Visuel

Créez des pipelines complexes avec plusieurs étapes. Glissez-déposez pour réordonner, ajoutez des étapes de notification et configurez des déclencheurs — le tout via une interface utilisateur intuitive.

Logs de Build en temps réel

Plus besoin de rafraîchir la page. Les logs de build sont transmis à votre navigateur en temps réel via WebSocket. Filtrez par niveau, effectuez des recherches dans la sortie et regardez les étapes se valider en direct.

Intégration Git

Fonctionne avec GitHub, GitLab, Bitbucket et n’importe quel serveur Git. Supporte l’authentification HTTPS et SSH. Détection automatique des commits via push polling.

Notifications Multi-plateformes

Gardez votre équipe informée grâce aux notifications de build vers :

• Telegram (Bot)
• Slack (Webhooks)
• Microsoft Teams (Connecteurs Webhook)
• Email (SMTP)

Pile Technique

Prise en main

Démarrage rapide avec Docker

# Cloner le dépôt
git clone [https://github.com/Giwi/giwi-cd.git](https://github.com/Giwi/giwi-cd.git)
cd giwi-cd

# Lancer avec Docker Compose
docker-compose up --build

Ouvrez http://localhost:4200 et connectez-vous avec :

• Email : admin@giwicd.local
• Mot de passe : admin123

Installation manuelle

# Installer le backend
cd backend && npm install && npm run build

# Installer le frontend
cd ../frontend && npm install

# Lancer les deux services
cd backend && npm start  # Terminal 1
cd frontend && npm start  # Terminal 2

Prise en main

Démarrage rapide avec Docker

# Cloner le dépôt
git clone [https://github.com/Giwi/giwi-cd.git](https://github.com/Giwi/giwi-cd.git)
cd giwi-cd

# Lancer avec Docker Compose
docker-compose up --build
Ouvrez https://www.google.com/search?q=http://localhost:4200 et connectez-vous avec :

Email : admin@giwicd.local

Mot de passe : admin123

Installation manuelle
Bash
# Installer le backend
cd backend && npm install && npm run build

# Installer le frontend
cd ../frontend && npm install

# Lancer les deux services
cd backend && npm start  # Terminal 1
cd frontend && npm start  # Terminal 2

Cas d’utilisation

• Projets personnels : Déployez vos “side projects” sans payer pour du CI cloud. GiwiCD tourne sur un VPS à 5 $ et gère tout, des tests au déploiement.
• Petites équipes : Offrez à votre équipe une plateforme CI/CD partagée sans la complexité de Jenkins.
• Environnements éducatifs : Parfait pour enseigner les concepts de CI/CD grâce à son interface visuelle.
• Déploiements Edge/IoT : Assez léger pour fonctionner sur des appareils “edge” et déployer directement sur du matériel IoT.

Feuille de route (Roadmap)

GiwiCD est activement développé. Les fonctionnalités à venir incluent :

• Exécution d’étapes en parallèle
• Mise en cache des artefacts de build
• Support Docker-in-Docker
• Système de plugins pour des runners personnalisés
• Déploiements multi-environnements

Conclusion

GiwiCD comble un vide dans l’écosystème CI/CD. Ce n’est pas un remplaçant pour les monolithes d’entreprise, mais une alternative simple, rapide et auto-hébergée qui respecte votre temps et votre infrastructure.

Voir sur GitHub | Lire la Doc

En tant que développeur, OpenCode est devenu mon outil de prédilection pour automatiser les tâches ingrates directement depuis mon terminal ou mon IDE. Décryptage.

Qu’est-ce qu’OpenCode ?

OpenCode est un agent de codage autonome qui ne se contente pas de suggérer du code : il l’écrit, le teste et le déploie. Contrairement aux solutions verrouillées, OpenCode est agnostique. Vous pouvez y brancher n’importe quel LLM (Claude 3.5 Sonnet, GPT-4o, Gemini 1.5 Pro) ou même des modèles locaux via Ollama.

Pourquoi c’est un “Game Changer” :

• Multi-modèles : Changez de cerveau selon vos besoins.
• Mode Planification : Il propose une stratégie avant d’altérer vos fichiers.
• Support LSP (Language Server Protocol) : Il comprend la structure réelle de votre projet, pas seulement le texte.
• Vision : Vous pouvez lui envoyer des screenshots de bugs ou de maquettes.

Cas pratique : Créer une fonctionnalité de A à Z

Imaginons que je veuille ajouter un système de “Soft Delete” sur mon API Node.js. Au lieu de tout taper à la main, je lance OpenCode dans mon terminal.

Étape 1 : Le Mode Planification (Tab)

Je lui demande : “Ajoute une colonne ‘deletedAt’ à ma table Users et modifie le middleware de suppression pour faire un soft delete.”

OpenCode passe en mode Plan :

• Il analyse mon fichier schema.prisma.
• Il identifie le contrôleur userController.js.
• Il m’affiche une liste de modifications prévues sans toucher au code.

Étape 2 : L’exécution (Build)

Une fois le plan validé, OpenCode écrit le code. Voici ce qu’il génère par exemple :

// Avant : Modification automatique par OpenCode
export const deleteUser = async (id) => {
  // L'agent a remplacé 'delete' par 'update' intelligemment
  return await prisma.user.update({
    where: { id },
    data: { deletedAt: new Date() }
  });
};

Les fonctionnalités “Power User”

Le fichier AGENTS.md (ou rules)

Comme pour Cursor, vous pouvez créer un fichier .opencode/AGENTS.md pour donner des instructions persistantes.

Exemple : “Utilise toujours TypeScript”, “Préfère les fonctions fléchées”, “Génère des tests unitaires avec Vitest pour chaque nouvelle fonction”.

Le partage de session (/share)

Un bug vous résiste ? Tapez /share dans le terminal OpenCode. Il génère une URL unique (opencode.ai/s/...) contenant toute la conversation et le contexte du code. Envoyez-le à un collègue pour qu’il reprenne là où vous en êtes.

OpenCode Zen

Si vous ne voulez pas gérer 50 clés API différentes, OpenCode propose Zen, une passerelle unifiée qui donne accès aux meilleurs modèles optimisés pour le code avec une facturation centralisée.

Installation rapide

Pour tester l’outil, une simple commande suffit (si vous avez Node installé) :

# Installation globale
npm install -g opencode-ai

# Ou via le script officiel
curl -fsSL https://opencode.ai/install | bash

# Lancement dans votre projet
opencode

Le meilleur des deux mondes : L’extension VS Code

Bien qu’OpenCode brille dans le terminal par sa vélocité, son extension VS Code transforme l’éditeur en une véritable station de programmation assistée. Contrairement à d’autres extensions qui se contentent d’un simple chat latéral, l’intégration OpenCode est profondément ancrée dans l’éditeur.

Ce qui change dans votre flux de travail :

• Édition en ligne (Inline Diff) : Appuyez sur Cmd+K (ou Ctrl+K) et demandez une modification. OpenCode affiche les changements directement dans votre fichier avec un code couleur (rouge/vert), vous permettant d’accepter ou de refuser chaque ligne d’un clic.
• Contexte de fichier intelligent : Plus besoin de copier-coller votre code dans une fenêtre de chat. L’extension “voit” vos onglets ouverts et comprend les liens entre vos fichiers grâce au graphe de symboles de VS Code.
• Terminal intégré : L’extension peut lire la sortie de votre terminal VS Code. Si votre application crash avec une erreur de stack trace, OpenCode peut l’analyser automatiquement et vous proposer un patch.

Comment l’installer ?

1. Rendez-vous dans le Marketplace VS Code.
2. Recherchez “OpenCode”.
3. Une fois installée, cliquez sur l’icône OpenCode dans la barre latérale.
4. Connectez votre clé API ou utilisez votre session OpenCode Zen pour commencer à coder.

Astuce d’expert : Vous pouvez indexer l’intégralité de votre codebase via l’extension. Cela permet à l’IA de répondre à des questions complexes du type : “Où est gérée la logique de calcul de la TVA dans tout ce projet ?”

Conclusion : Pourquoi choisir OpenCode ?

Le choix est simple : si vous voulez le contrôle total sur votre contexte de données et la liberté de choisir votre modèle d’IA (sans être enfermé dans l’écosystème GitHub ou Anthropic), OpenCode.ai est l’outil qu’il vous faut.

C’est un pont entre la puissance brute des LLM et la réalité technique de nos dépôts Git.

Et vous, quel modèle allez-vous connecter à votre terminal ?

Des questions sur l’intégration ? N’hésitez pas à consulter la documentation officielle.

Pourquoi choisir HAProxy ?

Fonctionnement Technique

HAProxy repose sur un modèle de traitement non-bloquant. Contrairement à d’autres serveurs qui créent un processus ou un “thread” par connexion, HAProxy utilise une boucle d’événements unique, ce qui lui permet de rester performant même sous une charge CPU intense.

Note : Couche 4 vs Couche 7

• L4 (Transport) : L’aiguillage se fait sur l’IP et le Port. C’est ultra-rapide mais “aveugle” au contenu.
• L7 (Application) : HAProxy analyse les headers HTTP, les cookies ou l’URL pour décider du routage.

Configuration : Anatomie d’un fichier .cfg

La configuration de HAProxy ne se fait pas en YAML, mais via un format propriétaire structuré en quatre sections : global, defaults, frontend et backend.

Exemple : Routage Intelligent (Statique vs Dynamique)

global
    log /dev/log local0
    maxconn 4096
    user haproxy
    group haproxy
    daemon

defaults
    log     global
    mode    http
    option  httplog
    timeout connect 5s
    timeout client  50s
    timeout server  50s

frontend http_in
    bind *:80
    # Définition des ACL (Access Control Lists)
    acl is_static path_beg /static /images
    acl is_api    path_beg /api

    # Décisions de routage basées sur les ACL
    use_backend static_servers if is_static
    use_backend api_servers    if is_api
    default_backend app_servers

backend app_servers
    balance roundrobin
    # Persistence de session via cookie
    cookie SERVERID insert indirect nocache
    server node1 192.168.1.10:80 check cookie node1
    server node2 192.168.1.11:80 check cookie node2

Sécurisation avec SSL/TLS Termination

La SSL Termination permet à HAProxy de déchiffrer le trafic HTTPS. Cela libère vos serveurs backend de cette tâche lourde en calcul, leur permettant de se concentrer sur la logique applicative en HTTP simple.

Mise en place du HTTPS

• Préparation : HAProxy nécessite souvent que le certificat et la clé privée soient combinés dans un seul fichier .pem.
• Configuration du Frontend :

frontend https_in
    # On spécifie le certificat et on active le support HTTP/2 (alpn)
    bind *:443 ssl crt /etc/ssl/certs/mon-site.pem alpn h2,http/1.1
    
    # Redirection automatique du HTTP vers le HTTPS
    http-request redirect scheme https unless { ssl_fc }
    
    default_backend app_servers

Mise en place de la Persistence de Session (Cookie)

La méthode la plus propre consiste à demander à HAProxy d’insérer un cookie spécifique dans la réponse HTTP.

Configuration du Backend :

backend app_servers
    balance roundrobin
    # 'SERVERID' est le nom du cookie qui sera créé
    # 'insert' : HAProxy ajoute le cookie si absent
    # 'indirect' : Le cookie n'est pas envoyé au serveur backend
    # 'nocache' : Empêche les caches intermédiaires de stocker ce cookie
    cookie SERVERID insert indirect nocache

    # On ajoute 'cookie <nom>' à la fin de chaque ligne serveur
    server node1 192.168.1.10:80 check cookie node1
    server node2 192.168.1.11:80 check cookie node2
    server node3 192.168.1.12:80 check cookie node3

Comment ça marche ?

• Lors de la première visite, HAProxy choisit un serveur (ex: node1).
• Il ajoute un header Set-Cookie: SERVERID=node1 dans la réponse.
• Au prochain clic, le navigateur renvoie ce cookie.
• HAProxy lit SERVERID=node1 et sait qu’il doit renvoyer l’utilisateur précisément sur ce serveur.

Filtrage d’IP et Sécurité (White/Blacklisting)

HAProxy peut servir de première ligne de défense contre des adresses IP malveillantes ou pour restreindre l’accès à une interface d’administration.

Exemple : Restreindre l’accès à l’Admin

frontend http_in
    bind *:80
    
    # 1. Définition des ACLs
    acl is_admin_path path_beg /admin
    acl is_allowed_ip src 123.123.123.123  # Votre IP fixe
    
    # 2. Action : Bloquer si c'est l'admin MAIS PAS la bonne IP
    http-request deny if is_admin_path !is_allowed_ip
    
    default_backend app_servers

Exemple : Liste noire d’IP (IP Blacklist)

Si vous avez une liste massive d’IP à bloquer, utilisez un fichier externe pour ne pas alourdir votre config :

frontend http_in
    # Bloquer toutes les IP présentes dans le fichier 'blacklist.lst'
    acl restricted_ip src -f /etc/haproxy/blacklist.lst
    http-request deny if restricted_ip

(Le fichier blacklist.lst contient simplement une IP ou un réseau par ligne, ex: 1.2.3.4 ou 192.168.1.0/24).

Bonus : Le “Drain Mode” pour la maintenance

Un avantage énorme des Sticky Sessions est de pouvoir éteindre un serveur sans déconnecter personne.

• Vous passez le serveur en mode DRAIN via l’interface de stats ou la ligne de commande.
• HAProxy arrête d’envoyer de nouveaux clients sur ce serveur.
• Il laisse les clients existants (ceux qui ont déjà le cookie) finir leur session.
• Une fois que le compteur de connexions tombe à zéro, vous pouvez couper le serveur en toute sécurité.

Administration et Diagnostic

Avant de redémarrer le service, validez toujours votre syntaxe pour éviter de “casser” la production :

# Vérifier la syntaxe du fichier de configuration
haproxy -c -f /etc/haproxy/haproxy.cfg

# Recharger la configuration sans couper les connexions en cours
sudo systemctl reload haproxy

Le Dashboard de Statistiques

HAProxy inclut une interface web native pour surveiller vos flux. Ajoutez ceci à votre config pour l’activer :

listen stats
    bind *:8404
    stats enable
    stats uri /monitor
    stats refresh 5s
    stats auth admin:password123

L’architecture “Keepalived + VIP”

Le mode cluster (ou Haute Disponibilité - HA) pour HAProxy répond à une problématique simple : si votre équilibreur de charge tombe, toute votre infrastructure devient inaccessible, même si vos serveurs backend fonctionnent parfaitement. C’est ce qu’on appelle un SPOF (Single Point of Failure).

Pour éviter cela, on utilise généralement un couple de deux serveurs HAProxy travaillant de concert.

La méthode la plus courante pour “clustériser” HAProxy n’est pas une fonctionnalité native interne au binaire HAProxy lui-même, mais l’utilisation d’un outil complémentaire nommé Keepalived.

Le concept de l’IP Virtuelle (VIP)

• Vous avez deux serveurs HAProxy avec leurs propres adresses IP (ex: 10.0.0.1 et 10.0.0.2).
• Vous créez une IP Virtuelle (VIP) (ex: 10.0.0.100) qui “flotte” entre les deux.
• Vos clients (ou votre DNS) pointent uniquement vers cette VIP.

Fonctionnement : Actif / Passif

• Le Maître (Master) : Il détient la VIP et traite 100% du trafic.
• L’Esclave (Backup) : Il surveille le Maître via un protocole appelé VRRP (sorte de “battement de cœur”).
• Le Basculement (Failover) : Si le Maître ne répond plus, l’Esclave s’aperçoit de l’absence de battement de cœur et “arrache” la VIP pour l’assigner à sa propre interface réseau. Le trafic reprend en quelques millisecondes.

La synchronisation des sessions (Peers)

Un problème survient lors du basculement : si HAProxy gère des Sticky Sessions (via table de persistance en mémoire), l’Esclave ne connaît pas les sessions du Maître. L’utilisateur devra se reconnecter.

Pour corriger cela, on configure la section peers dans HAProxy pour que les nœuds partagent leurs tables d’états en temps réel.

peers mypeers
    peer haproxy1 10.0.0.1:1024
    peer haproxy2 10.0.0.2:1024

backend app_servers
    stick-table type ip size 1m expire 1h peers mypeers
    stick on src
    server node1 192.168.1.10:80 check

Configuration type de Keepalived

Voici à quoi ressemble la configuration sur le serveur Maître (/etc/keepalived/keepalived.conf) :

vrrp_script check_haproxy {
    script "killall -0 haproxy" # Vérifie si le processus HAProxy tourne
    interval 2
    weight 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101 # Priorité plus haute que le backup
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass secret
    }
    virtual_ipaddress {
        10.0.0.100 # L'IP Virtuelle
    }
    track_script {
        check_haproxy
    }
}

Actif / Actif (Pour les très grosses charges)

Dans certains cas extrêmes, on veut que les deux HAProxy travaillent en même temps. On utilise alors :

• DNS Round Robin : Le nom de domaine pointe vers deux VIP différentes (une sur chaque nœud).
• Anycast BGP : Une solution réseau plus complexe où les routeurs distribuent le trafic vers le nœud HAProxy le plus “proche”.

Résumé des bénéfices

• Zéro interruption : Maintenance transparente (on coupe le maître, le backup prend le relais).
• Mise à jour sans risque : On met à jour le nœud passif, on bascule, puis on met à jour l’ancien maître.
• Intégrité des données : Grâce aux peers, les informations de bannissement (Security) ou de session sont préservées.

Conclusion

HAProxy n’est pas seulement un outil de répartition de charge ; c’est un véritable couteau suisse pour la haute disponibilité. Sa rigueur et sa légèreté en font un choix incontournable pour toute architecture microservices ou web moderne.

Cependant, des fois, le favicon de notre site Web se marie mal avec un thème light ou un thème dark (voire les 2, mais là, je ne peux rien faire).

L’idée est de d’avoir un favicon dédié mode sombre et un dédié mode clair et d’utiliser celui qui est en phase avec le thème utilisé par notre internaute.

Ce se fait avec l’attribut média de la balise link :

<link rel="icon" type="image/png" href="/favicon-light.png" media="(prefers-color-scheme:light)">
<link rel="icon" type="image/png" href="/favicon-dark.png" media="(prefers-color-scheme:dark)">
<link rel="icon" type="image/png" href="/favicon-light.png" media="(prefers-color-scheme:no-preference)">

C’est aussi simple que ça.

Pour générer des favicons, vous avez l’embarras du choix :

• https://realfavicongenerator.net/
• https://favicon.io/
• https://www.favicon-generator.org/
• https://www.favicon.cc/

Nous allons exposer Discovery Explorer sous le path /dashboards.

Prérequis, Docker, DockerCompose et :

$ sudo apt install apache2-utils

D’abord, créons un fichier avec les users :

sudo htpasswd -c .htpasswd user1
sudo htpasswd .htpasswd user2

Cela vous crée un fichier .htpasswd dont il faudra retenir le path.

Créez un fichier de conf pour NginX, nginx.conf :

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
worker_connections 768;
}

http {
  sendfile on;
  tcp_nopush on;
  types_hash_max_size 2048;
  include /etc/nginx/mime.types;
  default_type application/octet-stream;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
  ssl_prefer_server_ciphers on;
  access_log /var/log/nginx/access.log;
  error_log /var/log/nginx/error.log;
  gzip on;

  server {
    listen 80 default_server;
    listen [::]:80 default_server;
    root /var/www/html;
    index index.html index.htm index.nginx-debian.html;
    server_name _;
    location / {
      try_files $uri $uri/ =404;
    }

    location /dashboards {
      auth_basic "Restricted Content"; 
      auth_basic_user_file /etc/nginx/.htpasswd;
      proxy_pass http://discovery-explorer:3000;
      rewrite /dashboards/api/(.*) /api/$1  break;
      proxy_set_header Host $host;
      proxy_redirect off;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
  }
}

Enfin créez un fichier docker-compose.yml :

version: "3.9"
services:
  discovery-explorer:
    image: warp10io/discovery-explorer:latest
    volumes:
      - /home/me/myDashboards:/data  # pointe vers l'endroit où vous avez vos dashboards Discovery
    environment:
      - BASE_HREF=/dashboards/
  nginx:
    image: nginx
    ports:
      - "80:80"
    volumes:
      - /home/me/nginx.conf:/etc/nginx/nginx.conf:ro # Fichier de conf créé plus haut
      - /home/me/.htpasswd:/etc/nginx/.htpasswd # fichiers des users créé plus haut
    links:
      - discovery-explorer:discovery-explorer

Et y’a plus qu’a :

$ docker-compose up

Vous pouvez admirer votre oeuvre sur http://localhost/dashboards.

/dev/urandom

$ dd if=/dev/urandom hexdump -Cv
0028cb40  17 9b d8 db 72 41 56 9a  d9 a2 9d 55 e9 5b e3 cf  ....rAV....U.[..
0028cb50  96 a4 48 b8 2d fe cc b4  bd 10 29 3a 74 8d aa 64  ..H.-.....):t..d
0028cb60  32 b3 35 f8 cd 4c 35 de  c9 df 3f b7 44 9e cc 51  2.5..L5...?.D..Q
0028cb70  67 86 b5 8a df ef 53 66  86 06 18 41 d9 5f a1 ca  g.....Sf...A._..
0028cb80  7e 4f 67 71 08 b2 21 47  85 f4 5c 2a d5 3b 8d 3a  ~Ogq..!G..\*.;.:
0028cb90  df b3 7f 29 79 75 75 dc  16 f3 3e b4 c8 78 41 e7  ...)yuu...>..xA.
0028cba0  54 d6 da 6a e5 8a 90 46  9f dd 7f 61 36 0c 81 bd  T..j...F...a6...
0028cbb0  a0 9e 6b 98 03 a0 c8 4d  31 27 19 4a be 23 93 05  ..k....M14.J..^C

# 128 : a0 9e 6b 98 03 a0 c8 4d  31 27 19 4a be 23 93 05 <- dernière ligne du dump par exemple

/proc/sys/kernel/random/uuid

$ cat /proc/sys/kernel/random/uuid  hexdump -Cv
00000000  37 64 61 30 64 61 64 38  2d 30 64 36 61 2d 34 65  7da0dad8-0d6a-4e
00000010  35 39 2d 62 63 62 38 2d  33 64 38 66 39 36 34 33  59-bcb8-3d8f9643
00000020  64 63 33 34 0a                                    dc34.
00000025

# 128 : 37 64 61 30 64 61 64 38  2d 30 64 36 61 2d 34 65 <- ici la première ligne

md5sum

Voici pour finir, la version la plus simple :

$date  md5sum  cut -d'-' -f 1
f332f2806519d8d0d3c37cead8997932

Si vous en connaissez d’autres, dites le moi.

En fait c’est facile.

D’abord, il faut une lib en C. Par exemple en voici une :

helloworld.h

char *hello(char* ch);

helloworld.c

#include "helloworld.h"
#include <stdlib.h>
#include <stdio.h>
#include <string.h>

char* hello(char* ch) {
    char prefix[] = "Hello ";
    char *res;
    res = malloc(strlen(prefix) + strlen(ch));
    strcpy(res, prefix);
    strcat(res,ch);
    return res;
}

Hey, mais, il y a un malloc sans free, ça craint. Bon, pas de soucis, on verra plus loi comment faire un free après l’appel.

Ok, maintenant, on compile :

$ gcc -c helloworld.c 
$ gcc -shared -dynamiclib helloworld.o -o ./helloworld.so

Maintenant, la partie Java. Il faut avoir la lib JNA dans son classpath, bien évidement.

CHelloWorld.java

package io.warp10.ext.test;

import com.sun.jna.Library;
import com.sun.jna.Native;
import com.sun.jna.Pointer;

public interface CHelloWorld extends Library {
  // On charge la lib
  CHelloWorld INSTANCE = Native.load("helloworld.so", CHelloWorld.class);
  // on décrit l'interface utilisée
  Pointer hello(String g);
  // Youpi, on pourra appeler free
  void free(Pointer p);  // JNA le fournit (et pas que ça)
}

Test.java

public class Test {
  public static void main(String[] args) {
    Pointer ptr = null;
    try {
      // on appelle notre fonction C
      ptr = CHelloWorld.INSTANCE.hello(args[0]);
      // on parse le résultat
      System.out.println(ptr.getString(0));
    } catch (Exception e) {
      throw e;
    } finally {
      // On libère la mémoire
      if (null != ptr) {
        CHelloWorld.INSTANCE.free(ptr); 
      }
    }
  }
}

On compile :

$ javac -cp ./jna-5.10.0.jar ./*.java

On exécute :

$ java -cp /opt/jna-5.10.0.jar:./* mon.package.Test Kitty
Hello Kitty

Et voilà.

Pour accéder aux données du Linky collectées par Enedis, il n’y a pas 36 solutions :

• Aller sur votre espace perso et cliquer sur un bouton pour télécharger un CSV avec ses données (pas pratique)
• Utiliser une lib qui scrappe ce site pour récupérer ces données au format CSV. Sauf que depuis des mois, ils ont changé la façon de se loguer et ont ajouté un captcha. Il n’y a plus aucune lib de fonctionnelle (dommage, ça marchait bien)
• Avoir un numéro de Siret, contractualiser avec Enedis, recueillir son propre consentement (oui, je sais, c’est con) et suivre une procédure très lourde pour se connecter à leur SGE.
• Avoir un numéro de Siret, contractualiser avec Enedis, bâtir une app déclarée et se connecter sur leur DataHub.
• Utiliser la connexion TéléInfo directement sur le Linky, ce qui fera l’objet d’un prochain post.

Bref, pour les particuliers qui, comme moi, veulent geeker un peu avec leurs propres données, c’est pas possible. Cependant, autour du DataHub, il y a quelques initiatives de tiers permettant de s’y connecter (via le tiers) comme :

• https://gitlab.com/aeneria/enedis-data-connect
• https://wiki.consometers.org/projets:dataconnect

C’est sur cet axe, à défaut d’avoir accès à une vraie API en direct, que je suis parti.

Attention, pensez à vous autoriser à collecter vos données horaires dans votre espace client!

Pour commencer, il vous faut un Warp 10. Facile à installer en local ou sur un serveur (il y a même un Docker), vous pouvez même tester dans le cloud avec leur SandBox. Ici, on va le faire avec la SandBox (mais dans la vraie vie, j’utilise une instance hébergée sur un Pi, oui, oui, ça tourne bien sur un Pi).

Préparation de Warp 10

Direction https://sandbox.senx.io/ pour se créer son espace et ses tokens. C’est pas compliqué, un clic suffit :

La puissance à portée d’un clic

Bon, ça nous laisse soit 2 jours (délai de rétention des données), soit 14 jours (délai des tokens mais il faut ré-uploader les données) pour jouer avec. (Plus d’info ici)

Copiez les 3 tokens quelque part et gardez les précieusement.

Récupération des données

Pour se faire, je vais m’appuyer sur cette librairie NodeJS : bokub/linky

Rien de bien sorcier, si ce n’est qu’on va devoir récupérer des jetons d’OAuth via https://conso.vercel.app/, un fameux tiers qui se connecte au DataHub Enedis. Suivez ce qui est écrit sur ce site, rien de bien sorcier. Vous aurez à autoriser cette app à se connecter à votre espace perso. Notez également quelque part, les jetons générés et gardez les au chaud.

Ouvrez un terminal, on va créer un nouveau projet javascript monstrueux :

$ mkdir linky2warp10
$ cd linky2warp10
$ npm init
$ npm install @senx/warp10 dayjs linky node-cron

Créez un fichier conf.json dans lequel vous renseignerez les jetons Linky, votre n° de PDL (n° de compteur Linky, quoi, dispo dans votre espace client) et les tokens Warp 10:

{
  "accessToken": "xxxxxxxxxxxxxxxxxxx", 
  "refreshToken": "xxxxxxxxxxxxxxxxxxx",
  "usagePointId": "n° de PDL",
  "warp10": {
    "w10URL": "https://sandbox.senx.io/api/v0",
    "rt": "lK8M3_ixxxxxxxxxxxx3AsTc2ojYk",
    "wt": "hHo5qxxxxxxxxxc7PRUeHa",
    "dt": "ttIb7TxxxxxxxxxxxxxxxWir4YynF"
  }
}

• w10URL.rt : Read Token
• w10URL.wt : Write Token
• w10URL.dt : Delete Token (on sait jamais, ça peut servir)

Créez un fichier index.js :

D’abord les imports

const linky = require('linky');
const fs = require('fs');
const dayjs = require('dayjs');
const Warp10 = require('@senx/warp10');
const cron = require('node-cron');

const conf = JSON.parse(fs.readFileSync('conf.json', 'utf-8'));
const w10 = new Warp10.Warp10(conf.warp10.w10URL)

Ensuite, il faut créer une session Linky avec la gestion du refresh token :

const session = new linky.Session({
  accessToken: conf.accessToken,
  refreshToken: conf.refreshToken,
  usagePointId: conf.usagePointId,
  onTokenRefresh: (accessToken, refreshToken) => {
    fs.writeFileSync('conf.json-bak-' + dayjs().valueOf(), JSON.stringify(conf), 'utf-8')
    conf.accessToken = accessToken;
    conf.refreshToken = refreshToken;
    // Cette fonction sera appelée si les tokens sont renouvelés
    // Les tokens précédents ne seront plus valides
    // Il faudra utiliser ces nouveaux tokens à la prochaine création de session
    fs.writeFileSync('conf.json', JSON.stringify(conf), 'utf-8')
  },
});

Ensuite on va se coder la fonction de récupération de l’historique :

// à partir d'une date dans le passé et de step en step
function updateHistory(startDate, step) { 
  const now = dayjs().subtract(1, 'day');
  return getBetween2Dates(startDate, now.format('YYYY-MM-DD'), step)
}

// entre 2 dates et de step en step
function getBetween2Dates(startDate, endDate, step = 1) {
  let start = dayjs(startDate, 'YYYY-MM-DD'); 
  let end = dayjs(endDate, 'YYYY-MM-DD');
  return new Promise(async (resolve, reject) => {
    let sum = 0; // le nombre de données que l'on va récupérer
    // Zou! on boucle de step en step pour aller du début à la fin de la période temporelle
    while (end.isAfter(start) && !!session) { 
      const next = end.subtract(step, 'day');
      try {
       // On récupère notre courbe de charge qui offre un point toutes les 30 minutes
        const data = await session.getLoadCurve(next.format('YYYY-MM-DD'), end.format('YYYY-MM-DD'));
        let inputFormat = [];
        data.data.forEach(d => {
          // On converti au format Warp 10
          const ts = dayjs(d.date, 'YYYY-MM-DD HH:mm:ss').valueOf() * 1000;
          if (d.value) {
            // Pensez à modifier subscribed avec votre puissance souscrite
            inputFormat.push(`${ts}// enedis.linky{unit=W,subscribed=9,pdl=${conf.usagePointId}} ${d.value}`);
          }
        });
        // on pousse notre buffer dans Warp 10
        await w10.update(conf.warp10.wt, inputFormat);
        sum +=  data.data.length;
      } catch (e) {
        console.error(start.format('YYYY-MM-DD'), e);
      }
      end = next;
    }
    resolve(sum);
  });
}

Parfait, maintenant on peut récupérer notre historique complet (ou presque) entre le premier Janvier 2015 et maintenant.

updateHistory('2015-01-01', 1).then(r => console.log(r))

Il arrive que certains jours, Enedis n’ait pas collecté de données, (il y aura des 404 et pas des Peugeots) et si vous tapez trop loin dans le passé, vous aurez un 500 (de mémoire) pour vous dire qu’Enedis n’a pas collecté de données avant que vous ayez activé votre collecte de votre conso horaire, donc soyez raisonnable quant au choix dans la date (arf).

Une fois fini, vous avez un historique quasi complet. Mais il faut le faire tourner tous les jours :

cron.schedule('0 1 * * *', () => { // 1 h du mat tous les jours
  const start = dayjs().subtract(5, 'day'); // les 5 derniers jours
  updateHistory(start.format('YYYY-MM-DD'), 1).then(r => console.log(r));
});

Y’a plus qu’à déployé ce script sur un Raspberry (ou ce que vous voulez), le lancer et il collectera quotidiennement vos données.

Afficher mes données

Pour ce faire, allez sur http://studio.senx.io/ et sélectionnez la Sandbox dans la liste des endpoints.

WarpStudio

Codons notre premier scripte pour afficher 30 jours d’historique. (remplacez bien les textes par vos infos ;) )

'votre token de lecture' 'token' STORE
'n° de PDL' 'pdl' STORE
[ $token 'enedis.linky' { 'pdl' $pdl } NOW 30 d ] FETCH

Cliquez sur l’onglet ‘Dataviz’ et admirez en bavant votre courbe de charge exprimée en W :

Ma conso à moi

Déjà, c’est cool, mais j’en veux plus, je veux un vrai dashboard qui claque!

On va utiliser Discovery (décrit ici). D’abord, le squelette. Créez un fichier index.html :

<html>
<head>
  <title>Linky dashboard</title>
</head>
<body>
  <discovery-dashboard url="https://sandbox.senx.io/api/v0/exec" cols="12" cell-height="160">
// Le WarpScript va ici
  </discovery-dashboard>
<!-- Les imports -->
  <script nomodule src="https://unpkg.com/@senx/discovery-widgets/dist/discovery/discovery.js"></script>
  <script type="module" src="https://unpkg.com/@senx/discovery-widgets/dist/discovery/discovery.esm.js"></script>
</body>
</html>

Et maintenant le code WarpScript :

Pour les tuiles (à ajouter dans tiles), on va récupérer souvent un an, un mois et 24 heures d’historique, la dernière conso et la dernière date de synchro. Plutôt que de faire un accès à la BDD à chaque tuile, on va mutualiser cette récupération et on va présenter l’info différemment par tuile.

'n° de PDL' 'pdl' STORE
'votre read token' 'token' STORE
// on récupère 1 an qu'on met dans '1y'
[ $token 'enedis.linky' { 'pdl' $pdl } NOW 365 d ] FETCH '1y' STORE 
// on coupe pour ne garder que 30 jours, stoké dans '30d'
$1y NOW 30 d TIMECLIP '30d' STORE 
// on récupère la dernière date connue
$30d 0 GET LASTTICK 'lasttick' STORE 
// la dernière valeur connue
$30d $lasttick ATTICK 0 GET REVERSE 0 GET 'lastvalue' STORE
// et les dernières 24 heures connues que l'on place dans '24h'
$30d $lasttick 24 h TIMECLIP '24h' STORE 

Ensuite la coquille du dashboard :

{
  'title' 'Linky'
  'description' 'Personal electric consumption'
  'options' { 'scheme' 'CHARTANA' }
  'tiles' [
// ... les tuiles ici
  ]
}

Enfin, les tuiles.

La moyenne annuelle

{
   'title' '1 year average'
   'x' 2 'y' 0 'w' 2 'h' 1
   'type' 'display' 'unit' 'kW'
   'data' [ $1y bucketizer.mean 0 0 1 ] BUCKETIZE 0 GET 'gts' STORE // calcul de la moyenne
                // récupération de la valeur et conversion/arrondi en kW
                $gts VALUES 0 GET 1000.0 / 1000.0 * ROUND 1000.0 / 
}

La dernière conso connue

{
  'title' 'Last known consumption'
  'x' 4 'y' 0 'w' 2 'h' 1
  'type' 'display' 'unit' 'kW'
  'data' $lastvalue 1000.0 / 1000.0 * ROUND 1000.0 / // conversion/arrondi en kW
 }

La date de dernière synchro

{
  'title' 'Last sync date'
  'x' 0 'y' 0 'w' 2 'h' 1
  'type' 'display'
  'data'  { 'data' $lasttick 'globalParams' { 'timeMode' 'duration' } }
 }

Les dernière 24 heures connues

{
  'title' 'Last 24h of data '
  'x' 6 'y' 0 'w' 4 'h' 1
  'type' 'bar'
   // On ne garde que le max horaire
   'data' [ $24h bucketizer.max 0 1 h 0 ] BUCKETIZE 
 }

Le Max sur les derniers 30 jours

{
  'title' 'Max 1 month'
  'x' 10 'y' 2 'w' 2 'h' 1
  'type' 'display' 'unit' 'kW'
  'data' [ $30d bucketizer.max 0 0 1 ] BUCKETIZE 0 GET 'gts' STORE // recherche du max
     // récupération de la valeur et conversion/arrondi en kW
    $gts VALUES 0 GET 1000.0 / 1000.0 * ROUND 1000.0 / 'data' STORE 
    // récupération de la puissance souscrite (en kW)
    $gts LABELS 'subscribed' GET TODOUBLE 'subscribed' STORE 
      {
        'data' $data
        'globalParams' {
          // Si votre conso est > à la puissance souscrite alors la tuile aura un fond rouge. 
          // elle sera verte sinon
          'bgColor' <% $data $subscribed <= %> <% '#32cb0099' %> <% '#ff616f99' %> IFTE
          'fontColor' '#ffffff'
        }
    }
}

La max sur un an

{
  'title' 'Max in 1 year'
  'x' 10 'y' 1 'w' 2 'h' 1
  'type' 'display' 'unit' 'kW'
  'data' [ $1y bucketizer.max 0 0 1 ] BUCKETIZE 0 GET 'gts' STORE
    // récupération de la valeur et conversion/arrondi en kW
    $gts VALUES 0 GET 1000.0 / 1000.0 * ROUND 1000.0 / 'data' STORE
    $gts LABELS 'subscribed' GET 'subscribed' STORE
    { 'data' $data 'globalParams' {
      'bgColor' <% $data $subscribed TODOUBLE <= %> <% '#32cb0099' %> <% '#ff616f99' %> IFTE
      'fontColor' '#ffffff'
      }
   }
}

Le max sur 24 heures

{
  'title' 'Max in 24 h'
  'x' 10 'y' 0 'w' 2 'h' 1
  'type' 'display' 'unit' 'kW'
  'data' [ $24h bucketizer.max 0 0 1 ] BUCKETIZE 0 GET 'gts' STORE
   // récupération de la valeur et conversion/arrondi en kW
  $gts VALUES 0 GET 1000.0 / 1000.0 * ROUND 1000.0 / 'data' STORE
  $gts LABELS 'subscribed' GET 'subscribed' STORE
  { 'data' $data 'globalParams' {
    'bgColor' <% $data $subscribed TODOUBLE <= %> <% '#32cb0099' %> <% '#ff616f99' %> IFTE
    'fontColor' '#ffffff'
    }
  }
}

La consommation sur les 30 derniers jours

{
  'title' 'Last month consumption'
  'x' 0 'y' 1 'w' 5 'h' 2
  'type' 'line'
  // on calcule le max par tranche de 3 heures
  'data' [ $30d bucketizer.max NOW 3 h 0 ] BUCKETIZE 0 GET 'conso' STORE
  // on récupère la puissance souscrite 
  $conso LABELS 'subscribed' GET TOLONG 1000 * 'subscribed' STORE
  // On récupère les bornes temporelles min et max
  $conso TICKLIST REVERSE 0 GET 'first' STORE
  $conso LASTTICK 'last' STORE
  // on se crée une courbe pour afficher une ligne correspondant à la puissance souscrite
  NEWGTS 'subscribed' RENAME 'psGTS' STORE
  // min
  $psGTS $first NaN NaN NaN $subscribed ADDVALUE DROP
  // max
  $psGTS $last NaN NaN NaN $subscribed ADDVALUE DROP
  // On met en forme avec des couleurs
  { 'data' [ $conso $psGTS  ] 'params' [ { 'type' 'area' } { 'datasetColor' '#ef5350' } ] }
}

La consommation annuelle

Pareil que précédemment.

{
  'title' 'Last year consumption'
  'x' 5 'y' 1 'w' 5 'h' 2
  'type' 'line'
  'data' [ $1y bucketizer.max NOW 1 d 0 ] BUCKETIZE 0 GET 'conso' STORE
    $conso
    $conso LABELS 'subscribed' GET TOLONG 1000 * 'subscribed' STORE
    $conso TICKLIST REVERSE 0 GET 'first' STORE
    $conso LASTTICK 'last' STORE
    NEWGTS 'subscribed' RENAME 'psGTS' STORE
    $psGTS $first NaN NaN NaN $subscribed ADDVALUE DROP
    $psGTS $last NaN NaN NaN $subscribed ADDVALUE
    2 ->LIST  'data' STORE
    { 'data' [ $conso $psGTS  ] 'params' [ { 'type' 'area' } { 'datasetColor' '#ef5350' } ] }
}

Le résultat

Et donc, en ajoutant un peu de CSS à notre page Web :

@import url('https://fonts.googleapis.com/css2?family=Kanit:wght@200&display=swap');

* {
    box-sizing: border-box;
}

:root {
    --wc-split-gutter-color: #404040;
    --warp-view-pagination-bg-color: #343a40 !important;
    --warp-view-pagination-border-color: #6c757d;
    --warp-view-datagrid-odd-bg-color: rgba(255, 255, 255, .05);
    --warp-view-datagrid-odd-color: #FFFFFF;
    --warp-view-datagrid-even-bg-color: #212529;
    --warp-view-datagrid-even-color: #FFFFFF;
    --warp-view-font-color: #FFFFFF;
    --warp-view-chart-label-color: #FFFFFF;
    --gts-stack-font-color: #FFFFFF;
    --warp-view-resize-handle-color: #111111;
    --warp-view-chart-legend-bg: #000;
    --gts-labelvalue-font-color: #ccc;
    --gts-separator-font-color: #FFFFFF;
    --gts-labelname-font-color: rgb(105, 223, 184);
    --gts-classname-font-color: rgb(126, 189, 245);
    --warp-view-chart-legend-color: #FFFFFF;
    --wc-tab-header-color: #FFFFFF;
    --wc-tab-header-selected-color: #404040;
    --warp-view-tile-background: #40404066;
}

body {
    font-family: 'Kanit', sans-serif;
    font-size: 12px;
    line-height: 1.52;
    color: #1b1b1b;
    background: #FAFBFF linear-gradient(40deg, #3BBC7D, #1D434C) fixed;
    padding: 1rem;
    height: calc(100vh - 2rem);
}


discovery-dashboard {
    color: transparent;
}

On obtient :

et hop

Prenant mon courage à deux bras, j’ai développé une petite librairie NodeJS pour pouvoir le piloter depuis un bout de code, récupérer les données de vol en temps réel et stream la vidéo de la caméra. Après plusieurs heure et litres de café, j’y suis parvenu, vous la trouverez là. J’ai des enfants et le but principal était de les faire développer en Javascript en s’amusant. En fait, mes enfant n’y ont prêté aucun intérêt et le seul enfant qui joue avec, c’est moi.

Si vous possédez ce drone, vous pouvez bien sûr utiliser cette lib. Ce petit drone communique en UDP. Il expose un serveur pour recevoir des commandes et a un client pour transmettre ses données de vol à un serveur UDP tiers.

Les données de télémétrie disponibles sont :

données de télémétrie de vol

https://fr.wikipedia.org/wiki/Pilotage_d%27un_avion

Warp 10

Warp 10 est une plateforme formidable, à la fois une base de données de séries temporelles (TSDB), un moteur d’analyse avec son langage de script (on verra plus tard) mais surtout une plateforme avec plein de plugins dont un permettant d’instancier un serveur UDP.

Plugin UDP

Je pars du postulat que vous avez installé Warp 10 dans /opt/warp10 (pas dans une image docker hein ;o) ), on va activer le plugin UDP. Dans /opt/warp10/etc/conf.d/80-udp-plugin.conf :

// activate the UDP plugin
warp10.plugin.udp = io.warp10.plugins.udp.UDPWarp10Plugin
udp.dir = ${standalone.home}/udp
udp.period = 5000

Il serait bien d’activer l’extension Debug :

warpscript.extension.debug = io.warp10.script.ext.debug.DebugWarpScriptExtension

Ensuite, il faut créer un répertoire /opt/warp10/udp et y placer un fichier tello.mc2 :

'Loading Tello telemetry' LOGMSG
{
  'mode' 'server'
  'host' '0.0.0.0'
  'port' 8890
  'timeout' 5000
  'macro' <% 
      'datagramLIST' STORE
    <% $datagramLIST ISNULL %>
    <%
      'timeout reached, nothing received' LOGMSG
    %>
    <%
      $datagramLIST
      <%
        'datagram' STORE
        $datagram 2 GET 'utf-8' BYTES-> 'dataFrame' STORE
        $dataFrame LOGMSG
        'Your write token' 'token' STORE // Insert your write token here
        $dataFrame ';' SPLIT <%
        // For each data in the dataframe 
        TRIM 'data' STORE
        <% $data '' != %> // manage the trailing ';'
        <% 
            // extract key and value
            $data ':' SPLIT LIST-> DROP [ 'key' 'value' ] STORE
            NEWGTS 'tello.telemetry.' $key + RENAME // create a new GTS
            NOW NaN NaN NaN $value TODOUBLE ADDVALUE // Add the new datapoint
            $token UPDATE
        %> IFT
        %> FOREACH
      %> FOREACH
    %> IFTE
  %>
}

Script de pilotage

Ensuite vous pouvez redémarer Warp 10. Connectez le drone via le WiFi et utilisez ce petit javascript pour le piloter :

import {Tello} from "@giwisoft/ryze-tello-sdk";
const tello = new Tello();
(async () => {
  // Start the engine and play "Ride Of The Valkyries"
  await tello.start();
  await tello.takeoff();
  // Go up
  await tello.up(50);
  // Perform a forward flip
  await tello.flip('f');
  // Go forward
  await tello.forward(50);
  await tello.right(20);
  // Go backward
  await tello.backward(100);
  await tello.rotateCW(360);
  // Finally land
  await tello.land();
  // And then shut down the engine
})().then(() => tello.stop());

Vous pouvez également streamer la vidéo via mplayer :

await tello.startStream();
[...]
await tello.stopStream();

Balancer la télémétrie en direct sur Warp 10 :

await tello.startTelemetry({
  withWarp10: true,
  warp10Params: {
    url: 'http://localhost:8080/api/v0/exec',
    writeToken: 'Token d\'écriture'
  }
});

Balancer la télémétrie en direct sur du MQTT

await tello.startTelemetry({
  withMqtt: true,
  mqttParams: {
    url: 'http://localhost:1883',
    clientId: 'tello'
  }
});

Voici un petit serveur MQTT en JavaScript pour tester :

const aedes = require('aedes')();
const server = require('net').createServer(aedes.handle);
server.listen(1883, () => console.log('server started and listening'));

Et un client pour afficher les traces :

const mqtt = require('mqtt');
const client = mqtt.connect('mqtt://127.0.0.1:1883', { 'clientId': 'PC' });
let connected = false;
client.on('connect', () => {
    console.log("connected")
    client.subscribe('ryze.tello');
    connected = true;
});
client.on('message', (topic, message) => {
    if (topic === 'ryze.tello') {
        console.log(message.toString());
    }
});

Mais bon, le plus fun c’est quand même d’utiliser la com UDP directement avec Warp 10.

Normalement, dès que le drone démarre ses moteurs, les données sont transmises à Warp 10 et en faisant tail -f /opt/warp10/logs/warp10.log, vous devriez voir :

[1616403713307] pitch:0;roll:0;yaw:-156;vgx:0;vgy:0;vgz:0;templ:79;temph:81;tof:10;h:0;bat:82;baro:-99.61;time:31;agx:1.00;agy:-10.00;agz:-998.00;[1616403713409] pitch:0;roll:0;yaw:-156;vgx:0;vgy:0;vgz:0;templ:79;temph:81;tof:10;h:0;bat:82;baro:-99.83;time:31;agx:1.00;agy:-10.00;agz:-1002.00;[1616403713511] pitch:0;roll:0;yaw:-156;vgx:0;vgy:0;vgz:0;templ:79;temph:81;tof:10;h:0;bat:82;baro:-99.87;time:31;agx:1.00;agy:-11.00;agz:-1003.00;

Première analyse de la télémétrie

Et pour visualiser les données, allez sur WarpStudio et affichons la distance au sol (par exemple) :

[ 2021 03 22 10 18 ] TSELEMENTS-> 'start' STORE
[ 2021 03 22 10 15 ] TSELEMENTS-> 'end' STORE
[
  "your read token"
  'tello.telemetry.tof' {}
  $start ISO8601
  $end ISO8601
] FETCH 500 LTTB

Le flip

Et hop, je vous laisse vous amuser à explorer les données.

Aller plus haut, aller plus hauuuuuauuut

Après avoir niqué votre journée en vous ayant collé une chanson dans la tête, je vous encourage à aller lire l’article original qui vous permettra de faire de la détection d’anomalie ainsi que réaliser un dashboard.

Article original

Code source

J’accède à mon media center en ssh, sur mon media center, mon vieux disque est en /dev/sda (fdisk -l pour vous en assurer).

Mon nouveau disque est branché en USB sur mon laptop en /dev/sdb (faites attention, je ne veux pas être tenu pour responsable d’une fausse manip!)

Pour copier le distant sur le local :

ssh user@<serveur distant> "sudo dd if=/dev/sda"  sudo dd of=/dev/sdb

Et pour connaître la progression, logguez vous en ssh sur le serveur distant dans un autre terminal et tapez :

sudo pkill -USR1 dd

Vous verrez la progression dans le premier terminal.

Par conséquent, comprendre le modèle GTS est la première étape de la maîtrise de la plateforme Warp 10. Heureusement, ce modèle est assez simple, mais puissant, et cet article passera en revue la plupart de ses aspects.

Que sont les Geo Time Series?

Geo Time Series est un modèle pour représenter des données de séries temporelle avec des informations de localisation facultatives pour chaque point.

Si vous préférez un exemple, imaginez un capteur de pollution atmosphérique sur un bus couplé à un GPS. Ce capteur mesure des niveaux d’ozone de temps en temps pendant que le bus se déplace. La séquence de lectures, chacune composée d’un horodatage, d’une latitude, d’une longitude, d’une élévation et d’un niveau d’ozone, forme une série.

Comme nous allons indexer le temps, nous les appelons séries temporelle et comme nous aurons non seulement la valeur du capteur mais aussi sa géolocalisation, nous les appelons Geo Time Series.

Séquence des enregistrements: horodatage en noir, latitude en bleu, longitude en vert, élévation en jaune et valeur en rouge.

Les GTS sont indexés par le temps afin que vous puissiez facilement sélectionner une plage de temps et obtenir les valeurs et les positions associés. Vous pouvez également indexer des positions, mais cela n’est pas fait par défaut. L’index au temps est utilisé lors de l’obtention des données d’un stockage (LevelDB, HBase, mémoire, HFile, S3, etc.) mais aussi lors de la manipulation du GTS, notamment avec des frameworks.

Valeur en fonction de l’espace et du temps

Vous devez vous demander: pourquoi regrouper les positions et les valeurs dans un seul modèle? Il est en effet possible d’avoir une série temporelle de latitudes, une de longitudes, une d’élévations et une de valeurs. L’avantage du modèle GTS est triple.

Premièrement, cela contextualise la valeur mesurée. Si l’on garde le même exemple de pollution de l’air que ci-dessus, il est évident que le niveau d’ozone est fortement dépendant du temps, mais aussi de l’emplacement du capteur. Mathématiquement, nous pouvons voir les enregistrements comme des échantillons d’une fonction f (temps, lieu) = ozone, qui sont tous, commodément, dans le même modèle.

Deuxièmement, cela rend les données plus compactes. Le fractionnement des données en plusieurs séries temporelles nécessiterait la duplication des horodatages. Si vous multipliez cela par des milliards ou des billions d’enregistrements, le gain peut être important. Attention cependant, vous ne pouvez généraliser cela à aucune valeur. Par exemple, si nous avions un modèle tabulaire, factorisant l’horodatage pour plusieurs capteurs, les capteurs pourraient avoir des fréquences d’échantillonnage très différents, disons 1Hz et 100Hz, cela conduirait à des tables presque vides. Même si une solution pour éviter de perdre de l’espace peut être trouvée, la manipulation d’une telle table ne serait pas pratique.

Troisièmement, cela rend l’analyse beaucoup plus facile. Avoir toutes ces informations dans le même modèle est bien plus pratique que d’avoir à combiner plusieurs structures. Vous pouvez facilement analyser l’influence de l’altitude sur la pollution ou restreindre votre analyse à une zone spécifique.

Les Geo Time Series sont un sur-ensemble de séries temporelles

Pour les capteurs fixes, ce n’est évidemment pas une bonne idée de stocker leurs positions pour chaque valeur. Bonne nouvelle, le couple latitude / longitude et l’élévation sont tous deux optionnels! Ce cas est bien géré par Warp 10 et stocker les GTS sans emplacement et les charger en mémoire ne prend pas de place pour représenter les emplacements «manquants». Il n’y a aucun inconvénient à utiliser Geo Time Series sans emplacement.

En ce sens, les Geo Time Series sont un sur-ensemble de séries temporelles, car une GTS peut à la fois associer des horodatages pour représenter des valeurs ou des couples valeurs / position. Très souvent, un bon modèle de GTS mélange les deux types de GTS. Par exemple, lorsque vous avez un capteur à très haute fréquence sur un objet à déplacement lent, comme la fibre optique dans un yacht, stocker la position est une mauvaise idée car l’emplacement sera à peu près le même pour des milliers d’enregistrements consécutifs. Si vous avez besoin de combiner ces capteurs haute fréquence avec des données de localisation pendant l’analyse, c’est en effet possible.

Les Geo Time Series sont le modèle de données principal de Warp 10. Il répond à la plupart des besoins de modélisation de séries chronologiques, avec des informations de localisation facultatives.

Valeurs dans les Geo Time Series

Jusqu’à présent, nous nous sommes concentrés sur l’aspect spatial et temporel d’une GTS, mais il est temps de se concentrer sur les valeurs. Une GTS peut stocker 4 types principaux de valeurs: booléens, entiers longs, doubles et chaînes de caractères. Ces types suffisent à couvrir n’importe quel cas d’utilisation.

Les booléens sont les valeurs les plus simples qu’une GTS puisse stocker: vrai ou faux, c’est tout. Même si elles sont très simples, elles sont extrêmement utiles: une alerte est-elle déclenchée? Les trains d’atterrissage sont-ils au sol? Ils ont également un très faible encombrement disque et mémoire, ce qui les rend parfaits pour optimiser certains calculs.

Ensuite, probablement les types les plus courants: les GTS numérique. Un grand nombre de capteurs donnent des nombres à virgule flottante ou entiers, comme la température, les codes de squawk, le nombre d’écriture, etc…. Ils prennent plus de place que les GTS booléennes, mais le stockage est optimisé pour les entiers longs et les doubles.

Enfin, les chaînes de caractères sont le type le plus polyvalent mais n’est pas optimisé comme les autres types. Les valeurs de chaîne peuvent stocker des annotations ou des messages de journal par exemple. Elles peuvent également être utilisées pour stocker des structures plus complexes comme les chaînes JSON ou base64 qui rendent possible la sérialisation et la désérialisation des objets stockés dans GTS.

Pour aller plus loin, Warp 10 permet le stockage de valeurs binaires dans les GTS, qui sont représentées par GTS de chaînes de caractères codées ISO8859-1. Pour aller encore plus loin, Warp 10 permet le stockage de GTS encodées sous forme de valeurs binaires dans une GTS: le multi-valeurs. Cela rend possible des modèles de données très complexes qui ont à la fois d’excellentes performances et sont faciles à utiliser.

Organisation des Geo Time Series

Nommez votre Geo Time Series

Maintenant que nous avons défini précisément le contenu d’une GTS, il est temps de voir comment nous identifions une seule GTS ou un sous-ensemble spécifique de GTS. Chaque GTS est identifiée de manière unique par un nom de classe et des paires clé-valeur facultatives appelées label. C’est exactement le même principe que Prometheus avec son nom de métrique et ses labels et OpenTSDB avec son nom de métrique et ses tags, ce n’est pas une surprise puisque tous ces outils ont été inspirés par le modèle utilisé dans le Borgmon de Google. Il est très important de comprendre que le nom de la classe et les labels forment un identifiant unique. Changez quoi que ce soit, une valeur de label par exemple, et vous faites référence à une autre GTS.

Prenons un exemple. Imaginez que vous ayez installé 2 capteurs de vitesse du vent sur un pétrolier. Le nom de classe définit généralement la valeur mesurée. Dans notre cas, pour les deux GTS, le nom de classe serait com.company.fleet.aws car AWS signifie Vitesse du vent apparent. Ensuite, nous utilisons les labels pour définir précisément le capteur. Nous pouvons utiliser presque autant de labels que nous le souhaitons, mais deux suffiront: le nom du navire et le côté. Enfin, nous sélectionnons des valeurs pour les labels, mybigtanker sera associé à shipname et un capteur aura le port associé au côté tandis que l’autre aura le tribord.

Vous pouvez voir comment com.company.fleet.aws {shipname = mybigtanker, side = port} identifie de manière unique un seul capteur. Vous devez faire très attention à ne pas ajouter de label qui pourrait changer pendant la durée de vie de la métrique. Dans ce cas, ajouter quelque chose comme la marque du capteur ou la destination du bateau est probablement une mauvaise idée car le capteur pourrait être remplacé et la destination est appelée à changer. Les GTS sont déjà indexées au temps, il n’y a donc guère d’avantages à ajouter un label dépendante du temps.

Sélectionnez votre Geo Time Series

La façon dont les GTS sont nommées permet la définition d’ensembles de GTS à l’aide de sélecteurs. Vous voulez tous les GTS AWS sur le navire? Interrogez com.company.fleet.aws {shipname = mybigtanker}, les labels non spécifiés peuvent prendre n’importe quelle valeur. Vous voulez tous les GTS sur votre pétrolier? Requête ~com.company.fleet.*{Shipname=mybigtanker}, ~ signifie que le nom de classe suivant est une expression régulière. Vous pouvez également utiliser la même logique sur les valeurs de label pour sélectionner plusieurs bateaux avec com.company.fleet.aws{shipname~my(bigsmall)tanker}.

Auriez-vous besoin d’ajouter des informations supplémentaires à une GTS qui ne sont pas essentielles à son identification? Vous pouvez ajouter des attributs. Les attributs sont également des paires clé-valeur mais sont modifiables. Vous pouvez ajouter l’attribut {class = tanker} à votre GTS, ce qui vous permettrait de sélectionner facilement tous les pétroliers de la même manière que vous utilisez les labels dans les sélecteurs.

Une GTS complete avec nom de classe, étiquette et valeur d’étiquette en haut, attributs en bas et points de données au milieu. Notez que l’élévation est manquante car elle est probablement inutile pour un navire.

Manipulation des Geo Time Series

Il serait trop long de lister toutes les manipulations possibles qui peuvent être faites sur des GTS, mais nous allons vous donner quelques pointeurs vers des ressources utiles. Comme nous manipulons des séries temporelles, le temps est de la plus haute importance dans presque toutes les fonctions liées aux GTS. Par exemple, le framework MAP vous permet d’appliquer une fonction sur une fenêtre glissante sur une GTS. REDUCE combine des points de différentes GTS partageant le même horodatage, etc.

Ces deux fonctions font partie des frameworks qui sont presque toujours au cœur même de chaque script que vous allez écrire. Ce sont des fonctionnalités très puissantes et polyvalentes qui peuvent, par exemple, synchroniser les horodatages entre GTS ou rendre les horodatages de données irrégulières, uniformément espacés.

En savoir plus sur tous les frameworks disponibles dans WarpScript

Outre les frameworks, d’autres fonctions plus spécialisées facilitent considérablement l’analyse des données de séries temporelles. Certaines fonctions permettent le découpage d’une GTS selon différents paramètres: temps ou distance entre points consécutifs ou détection d’arrêt plus complexe. Il est également possible de détecter des anomalies dans des GTS à l’aide de différents algorithmes.

Toutes ces fonctions évitent d’avoir à réécrire du code complexe chaque fois que vous devez concevoir un script pour l’analyse de séries temporelle. Cela vous fait gagner du temps de développement et vous permet de vous concentrer sur la logique de votre analyse.

Plier les Geo Time Series à votre volonté

Cet article ne serait pas complet si nous ne parlions pas de la manière de corrompre ce modèle GTS. Attention, cette section concerne la modélisation et la manipulation très avancées des GTS.

Premièrement, les positions dans une GTS sont codées en tant que codes HHC 64 bits. Donc, pour le dire franchement, une GTS est une séquence d’enregistrements, chacun composé de 1 entier long, 2 entiers longs optionnels et un Boolean, un entier Long, un Double ou une chaîne de caractères. Vous utilisez normalement les 3 Longs pour représenter l’horodatage, l’emplacement HHCode et l’élévation, mais on peut en fait représenter n’importe quoi.

Si vous souhaitez stocker une GTS, les horodatages doivent être uniques dans une GTS. Vous pouvez stocker un identifiant unique dans des horodatages, par exemple, un MMSI, identifiant unique d’un navire, un ID de voie OSM ou même un HHCode. Cela vous permet de récupérer rapidement les informations dont vous avez besoin sans avoir besoin d’une base de données supplémentaire pour stocker ce type d’informations.

Si vous avez besoin que votre GTS stocke 3 Longs par point de données, vous pouvez les stocker dans la position, l’élévation et la valeur. Par défaut, l’entier long de la position est interprété comme un HHCode 64 bits et converti en latitude / longitude. Vous pouvez facilement récupérer la représentation Long avec la fonction [->GTSHHCODELONG](https://www.warp10.io/doc/AIt6K4C7H3CEG3KBIot6). Attention, le HHCode 91480763316633925 est réservé et signifie «pas de position», vous ne devez donc pas l’utiliser.

En résumé

Une Geo Time Series est un modèle polyvalent pour représenter des données de séries temporelles, bien adapté aux données provenant de capteurs et de métriques d’un large éventail de domaines. Les Geo Time Series peuvent éventuellement stocker un emplacement et une altitude pour chaque point, mais il n’y a pas d’inconvénient à utiliser une Geo Time Series sans localisation.

Elles peuvent stocker des booléens, des longs, des doubles et des chaînes de caractères, ce qui offre à la fois des performances et une compatibilité avec presque tous les types de données. Pour interroger les Geo Time Series, elles sont identifiées de manière unique par un nom de classe et des paires clé-valeur facultatives appelées labels. Cela permet de sélectionner une série unique ou un groupe d’entre elles pour les combiner et les analyser.

Enfin, les fonctions WarpLib offrent un large éventail de fonctionnalités pour manipuler les Geo Time Series. Le but de ces fonctions est de vous faire gagner du temps de développement et vous permettre de vous concentrer sur la logique de votre analyse.

Article Original : https://blog.senx.io/all-about-geo-time-series-model/

cat monfichier.txt | wc -l
wc -l monfichier.txt

Mais quand le fichier est monstrueux, c’est la misère, voici un script qui permet de faire une estimation :

# wcle – word count line estimate
# Fast line-count estimate for huge files
file=$1
nsample=1000
headbytes=`head -q -n $nsample $file | wc -c`
#tailbytes=`tail -q -n $nsample $file | wc -c`
filesize=`ls -sH --block-size=1 $file | cut -f1 -d" "`
echo -n $((filesize / (headbytes) * $nsample))
echo " (" $((filesize / headbytes )) "K;" $((filesize / headbytes /1000 )) "M )"

./wcle.sh mon-gros-fichier.txt

#!/usr/bin/env node
const { execSync } = require('child_process');
let repo = '';
let md =
  `TITRE DE VOTRE CHANGELOG
---

`;
// changez 'head -n 10' pour avoir autre chose que les 10 derniers tags
let tagList = execSync('git tag --sort=-committerdate | head -n 10').toString().split('\n'); 
let lastTag = tagList[0];
tagList = tagList.slice(1, -1);
tagList.forEach(tag => {
  md += `## ${lastTag}

`;
 execSync(`git log --no-merges --date=iso --format="> +  ts%ct  | %s %N (*[%cN](%ce) | [view commit](${repo}/commit/%H)*)" ${tag}..${lastTag}`)
    .toString().split('\n').forEach(l => {
    let timestamp = /ts([0-9]+)/.exec(l);
    if (timestamp) {
      l = l.replace('ts' + timestamp[1], new Date(timestamp[1] * 1000).toISOString().split('T')[0].replace(/\-/gi, '/'));
    }
    let issue = /#([0-9]+)/.exec(l);
    if (issue) {
      l = l.replace('#' + issue[1], `[#${issue[1]}](${repo}/issues/${issue[1]})`);
    }
    md += l + '\n';
  });
  lastTag = tag;

});
console.log(md);

Usage :

node changelog.js > CHANGELOG.md