OpenTelemetry au plus près des machines

Mode de lecture

IngénieurDécideur

OpenTelemetry peut collecter les métriques et les logs d’un atelier aujourd’hui, mais pas seul. Le Collector, le relais qui reçoit les données et les réexpédie, ne parle encore ni OPC UA, ni MQTT, ni Modbus, les protocoles par lesquels les équipements industriels échangent leurs mesures : il faut lui construire un pont. Cet article décrit ce pont, de l’automate (le petit ordinateur qui pilote une machine) jusqu’à la sortie de zone, c’est-à-dire la frontière du réseau de l’atelier, avec ce qui existe réellement en octobre 2026 et ce qui reste à écrire.

La question n’est plus théorique. Les usines embarquent des conteneurs, des passerelles edge et maintenant des agents IA. Les équipes IT, celles de l’informatique de gestion, veulent les mêmes traces, métriques et logs que dans le cloud. Les équipes OT, celles qui exploitent les machines et les automatismes, veulent que rien ne touche au process. OpenTelemetry est, à mon sens, le format neutre le mieux placé pour servir les deux, à condition de respecter les contraintes de l’atelier.

Deux mondes de mesures

L’IT et l’OT mesurent des choses différentes, avec des règles différentes. Les confondre est la première cause d’échec des projets d’observabilité industrielle. Dans le tableau, un tag est une variable lue sur un automate (une température, une pression) et l’historian est la base qui archive ces mesures.

Dimension	IT (cloud-natif)	OT (atelier)
Unité de base	Requête, span, ligne de log	Tag (variable de process), événement d’alarme
Modèle	Traces, métriques, logs	Séries de valeurs échantillonnées, états, alarmes
Protocoles	OTLP, HTTP, gRPC, Prometheus	OPC UA, MQTT et Sparkplug B, Modbus, Profinet, EtherNet/IP
Stockage de référence	Backend d’observabilité	Historian (PI, Canary, Timebase et autres)
Horloge	Horodatage à l’émission	Horodatage source de l’automate, qualité de la valeur
Priorité	Disponibilité du service	Sûreté et continuité du process
Cycle de vie	Semaines	10 à 30 ans

Deux conséquences pratiques. D’abord, l’historian reste la référence process : OpenTelemetry ne le remplace pas, il observe ce qui l’entoure (passerelles, applications edge, réseau, qualité de la collecte). Ensuite, une valeur OT porte plus qu’un nombre : un horodatage source, un code de qualité (good, uncertain, bad) et une unité d’ingénierie. Un pont qui perd ces trois informations produit des données fausses qui ont l’air justes.

Où placer le Collector ?

La règle est simple : un Collector par zone et des flux qui ne font que monter. Le modèle Purdue et les zones et conduits de l’IEC 62443 donnent déjà la carte ; il suffit d’y poser les Collectors. Le modèle Purdue range le réseau d’une usine en niveaux, du capteur jusqu’à l’informatique de gestion. L’IEC 62443, la norme de cybersécurité industrielle, découpe ce réseau en zones reliées par des passages contrôlés, les conduits.

Le Collector de zone est la pièce centrale : il reçoit en local, enrichit, tamponne sur disque et ouvre le seul flux sortant vers la DMZ, la zone tampon entre l’usine et le reste de l’entreprise. Le Collector gateway de DMZ termine le TLS (il déchiffre les échanges), filtre ce qui peut quitter le site et route vers un ou plusieurs backends. Aucun composant du niveau 3.5 ou au-dessus n’initie de connexion vers la zone d’exploitation.

Ce découpage a un avantage souvent sous-estimé : il rend le conduit justifiable devant le RSSI (le responsable de la sécurité des systèmes d’information) et l’équipe OT. Un seul port, un seul sens, un seul protocole documenté.

Faire entrer les protocoles OT dans OpenTelemetry

Le Collector contrib (v0.162.0), la version qui rassemble les composants de la communauté, compte plus de cent receivers, les composants chargés de lire une source de données, mais aucun pour OPC UA, MQTT, Sparkplug B ou Modbus. Le plus proche du monde industriel est le receiver SNMP, utile pour les switchs et les équipements réseau de l’atelier, pas pour le process.

Trois chemins existent aujourd’hui.

Chemin	Principe	Avantages	Limites
Passerelle tierce vers OTLP	Un agent qui parle déjà OPC UA ou MQTT (Telegraf, par exemple) lit les tags et exporte en OTLP vers un Collector local	Opérationnel tout de suite, protocoles éprouvés	Deux agents à maintenir, mapping des attributs à surveiller
Receiver sur mesure	Un receiver Go (bibliothèques gopcua ou Paho) compilé dans une distribution maison avec le Collector Builder (ocb)	Un seul binaire, contrôle total du modèle de données	Code à maintenir, sécurité OPC UA à bien implémenter
Instrumentation native	Les applications edge (conteneurs, MES légers, agents) émettent directement en OTLP	Traces et logs applicatifs, pas seulement des métriques	Ne couvre pas les automates

En pratique, on combine le premier et le troisième chemin. On n’écrit un receiver que lorsque le volume de tags ou les exigences de sécurité le justifient. Avant d’en écrire un, consultez le catalogue communautaire tenu par l’initiative OpenTelemetry Industrial : il recense des receivers Modbus, OPC UA, MQTT et Sparkplug B ou EtherNet/IP développés hors de contrib, à des niveaux de maturité inégaux.

Sparkplug B mérite un mot à part. Il ajoute des règles à MQTT, un protocole de messagerie léger très répandu dans l’industrie, avec des messages de naissance (NBIRTH, DBIRTH) qui déclarent les métriques, leurs types et leurs alias (des numéros courts qui remplacent les noms), puis des messages de données qui n’envoient que les alias. Un pont qui ignore les messages de naissance ne peut pas décoder les données. Les messages de mort (NDEATH, DDEATH) sont précieux : ils deviennent des événements de disponibilité à exporter comme logs OpenTelemetry.

Modéliser sans trahir le process

Les conventions sémantiques OpenTelemetry ne définissent aucun domaine industriel. Les plus proches sont hw.* pour le matériel et messaging.* pour les flux MQTT. Il faut donc fixer ses propres règles et les écrire avant la première ligne de configuration.

Quatre règles tiennent dans la durée :

1. La ressource décrit l’emplacement, pas la variable. Site, zone, ligne, cellule et équipement vont dans les attributs de ressource, en suivant la hiérarchie ISA-95 déjà utilisée par l’usine. Un namespace préfixé (isa95.site, isa95.line) évite toute collision future avec les conventions officielles.
2. Le nom de métrique décrit une grandeur, pas un tag. equipment.temperature avec un attribut equipment.id vaut mieux que mille métriques nommées d’après des tags automate. Évitez le préfixe process.* : OpenTelemetry le réserve déjà aux processus du système d’exploitation. La cardinalité reste maîtrisée et les tableaux de bord se réutilisent d’une ligne à l’autre.
3. L’unité voyage avec la valeur. Le champ unit d’OpenTelemetry suit UCUM, un code standard pour les unités de mesure (Cel, bar, m3/h). Les unités d’ingénierie OPC UA doivent y être traduites, pas abandonnées.
4. L’horodatage et la qualité viennent de la source. Le timestamp d’un point de données doit être celui de l’automate, pas celui de la passerelle. La qualité OPC UA devient un attribut (opcua.status). Une valeur « bad » est exportée comme telle plutôt que filtrée en silence.

La cardinalité, c’est-à-dire le nombre de combinaisons différentes qu’une métrique doit stocker, est le risque principal. Une usine compte souvent des dizaines de milliers de tags. Mettre l’identifiant du tag en attribut sur chaque point fait exploser le coût de n’importe quel backend : le simulateur de cardinalité montre l’ordre de grandeur. On sélectionne donc les tags utiles à l’exploitation et on laisse l’historian garder le reste.

Tenir à l’edge

Un Collector d’atelier doit survivre à une coupure réseau, à un redémarrage et à une machine sous-dimensionnée, sans jamais gêner le process. Cinq mécanismes suffisent, tous disponibles dans le Collector actuel.

• File d’attente persistante. L’extension file_storage associée au sending_queue de l’exportateur écrit les données sur disque tant que la sortie est indisponible. Une coupure de plusieurs heures de la liaison WAN, le lien réseau qui relie le site au reste de l’entreprise, se résorbe sans perte, dans la limite de l’espace alloué.
• Limiteur de mémoire. Le processeur memory_limiter place le Collector en refus avant qu’il ne consomme la RAM d’une passerelle partagée avec d’autres applications.
• Flux sortants uniquement. Le Collector de zone pousse vers la DMZ, jamais l’inverse. Aucun port entrant n’est ouvert dans la zone de contrôle, ce qui simplifie la justification IEC 62443 du conduit.
• Distribution minimale. Une distribution construite avec ocb, l’outil qui assemble un Collector sur mesure, ne contient que les composants utiles. Moins de code embarqué, c’est moins de surface d’attaque et un binaire plus léger.
• Pilotage à distance maîtrisé. L’extension OpAMP et le superviseur opampsupervisor permettent de gérer une flotte de Collectors à distance. Dans une zone à egress contraint, où les connexions sortantes sont strictement limitées, la connexion OpAMP part de l’edge et chaque changement de configuration passe par une validation explicite.

Exemple : un tag OPC UA jusqu’à la DMZ

L’exemple suit le premier chemin : Telegraf, un agent de collecte open source, lit un serveur OPC UA et pousse en OTLP vers un Collector local, qui enrichit, met en tampon et exporte vers la passerelle de DMZ. Les extraits sont volontairement courts.

Côté passerelle, Telegraf lit un tag en mode chiffré et signé :

[[inputs.opcua]]
  endpoint = "opc.tcp://plc-l3-01:4840"
  security_policy = "Basic256Sha256"
  security_mode = "SignAndEncrypt"
  [[inputs.opcua.nodes]]
    name = "equipment_temperature"
    namespace = "2"
    identifier_type = "s"
    identifier = "Line3.Oven.Temperature"

[[outputs.opentelemetry]]
  service_address = "127.0.0.1:4317"

Le Collector local ajoute l’emplacement ISA-95, protège la mémoire et garde les données sur disque pendant une coupure :

extensions:
  file_storage:
    directory: /var/lib/otelcol/queue

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 127.0.0.1:4317   # local uniquement

processors:
  memory_limiter:
    check_interval: 1s
    limit_mib: 256
  resource:
    attributes:
      - { key: isa95.site,  value: site-a, action: upsert }
      - { key: isa95.line,  value: line-3, action: upsert }
  batch: {}

exporters:
  otlp/dmz:
    endpoint: otel-gw.dmz.example:4317
    tls:
      ca_file: /etc/otelcol/ca.pem
    sending_queue:
      storage: file_storage      # file persistante
    retry_on_failure:
      max_elapsed_time: 0        # ne jamais abandonner

service:
  extensions: [file_storage]
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, resource, batch]
      exporters: [otlp/dmz]

Trois détails comptent plus que le reste : le receiver n’écoute que sur la boucle locale (il n’accepte que les connexions venues de la machine elle-même), l’exportateur est le seul flux sortant de la zone et max_elapsed_time: 0 empêche l’abandon des données pendant une longue coupure. La taille de la file doit ensuite être dimensionnée sur la durée de coupure à couvrir.

Ce qui reste à construire

L’approche fonctionne, mais quatre manques ralentissent encore l’adoption.

• Pas de receiver industriel officiel. Des receivers communautaires existent hors de contrib et l’initiative OpenTelemetry Industrial les recense : Modbus, OPC UA (en alpha, limité aux logs à cette date), MQTT et Sparkplug B, EtherNet/IP (expérimental). Aucun n’est intégré au Collector contrib : chaque projet doit encore choisir le sien, l’évaluer et le maintenir. Un receiver porté par le projet, avec une gestion correcte des messages de naissance et des politiques de sécurité OPC UA, éviterait des implémentations divergentes.
• Pas de conventions sémantiques industrielles. Sans vocabulaire commun pour l’emplacement ISA-95, la qualité d’une valeur ou l’état d’une machine, les tableaux de bord ne se partagent pas d’un site à l’autre. OpenTelemetry Industrial a ouvert ce chantier, encore au stade de l’exploration.
• Peu de retours sur les traces en OT. Les métriques et les logs passent bien. Les traces ont du sens pour les applications edge et les chaînes MES, beaucoup moins pour un cycle automate. Ce terrain reste à explorer.
• La gestion de flotte se standardise à peine. OpAMP existe, Margo définit déjà un Collector OpenTelemetry sur les équipements edge qu’il gère, mais les deux ne sont pas encore articulés pour des milliers de sites à egress contraint.

Conclusion

OpenTelemetry n’arrive pas dans l’usine pour remplacer l’historian ou le SCADA. Il arrive pour observer tout ce qui s’est ajouté autour : passerelles, conteneurs, applications edge et bientôt agents IA. Le point de départ tient en trois décisions : un Collector par zone, des flux uniquement sortants et un modèle de données écrit avant la configuration.

Le reste est un travail de communauté. Un receiver industriel porté par le projet et un début de conventions sémantiques pour l’OT feraient gagner plus de temps à la filière que n’importe quel produit. L’initiative OpenTelemetry Industrial s’y est attelée : c’est là qu’il faut contribuer.

Pour aller plus loin

• OpenTelemetry dans l’industrie : état des lieux : ce qui pousse l’adoption, ce qui freine, par où commencer.
• Le pipeline du Collector animé : le limiteur de mémoire, le filtrage et le regroupement en mouvement.
• Que surveiller, de l’usine au modèle d’IA ? : la couche terrain et le code de qualité OPC UA.
• Pourquoi un détail fait exploser la facture des métriques ? : le risque de cardinalité, chiffré.

Sources

Consultées le 11 octobre 2026.

• OpenTelemetry, liste des modules du Collector contrib, v0.162.0 : plus de cent receivers, aucun pour OPC UA, MQTT, Sparkplug B ni Modbus ; receiver SNMP, extension OpAMP et superviseur présents.
• OpenTelemetry, conventions sémantiques : domaines existants, dont hw.* et messaging.* ; aucun domaine industriel.
• OpenTelemetry, exporterhelper : file d’envoi persistante et paramètres de réessai, dont max_elapsed_time.
• InfluxData, Telegraf, greffons inputs.opcua et outputs.opentelemetry.
• Margo, spécification (pré-projet), collecte des données d’observabilité : au moins un Collector OpenTelemetry sur chaque équipement.
• Margo, sandbox : Collector OpenTelemetry côté équipement.
• OpenTelemetry Industrial, initiative communautaire indépendante : catalogue des projets et receivers et état de chacun.

PasserellesCe que cette page change au-delà de l'équipe technique.

BusinessValeur, coût, risque

Chaque tag exporté a un coût de stockage : choisir les tags utiles à l'exploitation et laisser le reste à l'historian évite de payer deux fois la même donnée.

OrganisationQui décide, qui possède

Un seul flux sortant par zone rend le conduit justifiable devant le responsable de la sécurité et l'équipe d'automatisme. Chaque changement de configuration du Collector passe par leur validation.

HumainÉquipes, astreinte, compétences

Les équipes d'automatisme veulent que rien ne touche au process : lecture seule, aucun port entrant et un pont hors du périmètre des équipements sont les conditions de leur accord.

MétiersProduit, finance, risque, relation client

Une température exportée sans son unité ni sa qualité peut fausser une décision de production : le modèle de données protège ceux qui lisent les tableaux de bord.

Pourquoi des passerelles →