Skip to content
MTTL, Mean Time To Learn

TechnicalBeginner9 min read

OpenTelemetry in industry: where things stand

Where does OpenTelemetry stand in plants in October 2026? What drives adoption, what it already observes, what holds it back, maturity component by component and where to start.

For: engineers and SREs · architects · team managers · executives and CIOsPrerequisites: Knowing what OTLP and the Collector are: see OpenTelemetry end to end.

Reading mode

In October 2026, OpenTelemetry is a settled standard on the IT side (business computing, servers, applications) and an open question on the plant floor, known as OT (operational technology: controllers, sensors, machine supervision). OpenTelemetry has been a CNCF graduated project since May 2026, meaning the foundation that hosts it recognises it as mature. The project itself now publishes on industrial environments and a session on standardizing IIoT (the industrial internet of things) observability was on the KubeCon Japan agenda in July. Yet there is still no official industrial receiver (the Collector component that can read a plant protocol) and no semantic conventions for OT, meaning shared names to describe the data.

This article takes stock: what drives adoption, what OpenTelemetry already observes in plants, what holds it back and where to start. It complements a more technical article on collection close to the machines: OpenTelemetry close to the machines.

Why now?

Section titled “Why now?”

Four trends are coming together and pushing industrial teams to face the question.

  • Plants are full of software. Edge gateways (servers installed near the machines), containers, light MES (the software that runs production execution) and vision applications fail like any IT service and must be observed as such. SCADA, the plant supervision system, does not see them.
  • The standard has matured. OpenTelemetry became a CNCF graduated project in May 2026. According to the CNCF, it brings together more than 12,000 contributions from more than 2,800 companies. For an industrial organization that thinks in decades, that is a durability signal proprietary formats cannot match.
  • Edge fleet management is standardizing. Margo, an initiative hosted by the Linux Foundation for the industrial edge, bases its observability on OpenTelemetry. Its specification, still at pre-draft stage, requires at least one Collector on every device and asks the applications that publish traces, metrics and logs to do so over OTLP.
  • AI is arriving on the shop floor. Agents and models deployed near machines need traces to be audited. OpenTelemetry already has semantic conventions for generative AI, still in development, which makes it a natural carrier for that traceability.

What OpenTelemetry already observes

Section titled “What OpenTelemetry already observes”

The use cases that work today do not observe the process itself. They observe everything that serves it.

Use caseSignalsComponentsMaturity
Health of edge gateways and serversMetrics, logshostmetrics, filelog, journaldProven
Containerized edge applicationsTraces, metrics, logsSDKs, OTLP, local CollectorProven
Shop-floor network (switches, routers)Metricssnmp receiverProven
Collection pipeline quality (loss, delay, disconnects)Metrics, logsCollector internal metrics and logsProven
MES chains and ERP integrationTracesSDKs, automatic instrumentationBeing adopted
Process variables from PLCsMetricsThird-party bridge or custom receiverExperimental
Traceability of AI agents on the shop floorTraces, logsGenAI conventionsEmerging

The dividing line is clear. Anything running on a general-purpose operating system can be observed with standard tools. Anything going through an industrial protocol still needs a bridge.

What holds it back

Section titled “What holds it back”

The obstacles are more organizational than technical. The OpenTelemetry project acknowledges this itself: its security guide for legacy environments, published in May 2026, starts from the observation that cloud-native assumptions do not hold in plants.

  • Safety comes before visibility. Any change in the control zone goes through strict change management. An agent on an automation workstation is often ruled out from the start.
  • Systems cannot be modified. Many devices support neither agents, modern TLS (encryption of network traffic) nor authentication. The OTel guide draws the consequence: the collection pipeline becomes the control point and Collector placement matters as much as its configuration.
  • Lifecycles are out of step. The Collector follows a two-week release cycle, a PLC can go a decade without an update. The guide recommends running the Collector as a bridge, outside the legacy perimeter, so it can be patched independently.
  • Sensitive data is not what you expect. Production recipes, machine configurations and plant yields are worth more than an IP address. Filter and minimize before data leaves the zone, not after.
  • Skills are scarce. OT teams know OPC UA (the standard exchange protocol for industrial equipment) and IEC 62443 (the cybersecurity standard for industrial systems), IT teams know OTLP and Kubernetes. Few people bridge the two.
  • The historian is already there. Plants often run a historian, the database that archives process measurements, already paid off and well mastered. OpenTelemetry must prove it brings more than a copy of the same data.

Maturity, component by component

Section titled “Maturity, component by component”

The general-purpose foundation is ready; the industry-specific layer is still to be built.

The foundation is ready, the industrial layer is still to be built

ComponentStatus in October 2026What it enables in a plant
Traces, metrics, logsGenerally availableObserve gateways, edge applications and MES chains
ProfilesPublic alphaNo realistic industrial use yet
Collector and persistent queue (on-disk buffer)Used in production, custom distribution with ocbSurvive network outages, limit attack surface
OpAMP and supervisorAvailable in contribManage a Collector fleet from the edge
SDK declarative configurationSpecification and schema stable, support varies by languageConfigure edge applications consistently
Generative AI conventionsIn developmentTrace agents and models deployed on the shop floor
OPC UA, MQTT, Sparkplug B, Modbus receiversAbsent from contrib (v0.162.0); community receivers outside contribGo through a third-party bridge, a community receiver to assess or an in-house receiver
Industrial semantic conventionsAbsent; exploration opened by OpenTelemetry IndustrialEvery site invents its own model

In this table, contrib is the repository of the Collector’s community components and ocb is the tool used to assemble a custom distribution. The last two rows alone explain most projects stuck at proof-of-concept stage.

Who is moving the topic forward?

Section titled “Who is moving the topic forward?”

Four circles are moving, at different speeds.

  • The OpenTelemetry project. It now looks explicitly at traditional environments: a security guide dedicated to legacy and industrial settings (May 2026), a working group on mainframes and, on the KubeCon Japan agenda (28 to 30 July 2026), a session by Apple engineers titled “Standardizing Industrial IoT observability with OpenTelemetry”. I have not found its content online, so I cannot say what was proposed there.
  • OpenTelemetry Industrial. This community initiative grew out of a proposal made to the OpenTelemetry community in May 2026, which publicly raised the question of how to organize industrial protocol support. It keeps a catalog of existing receivers and bridges, publishes an experimental EtherNet/IP receiver, explores industrial semantic conventions, plans an industrial Collector distribution and works with Margo. Its roadmap is public and covers 2026 and 2027. It describes itself as independent: it is neither an official OpenTelemetry project nor one of its working groups.
  • Margo and the industrial edge. The Margo specification makes the OpenTelemetry Collector the collection point on edge devices. Its reference sandbox, a test environment provided by the project, deploys it on the device side, with Prometheus, Grafana, Jaeger and Loki on the orchestrator side. It is today the most concrete framework for an industrial organization that wants neutral edge observability.
  • Vendors. Most major observability platforms accept OTLP and several publish their own Collector distribution. Their industrial message focuses on IT/OT convergence; the protocol integration work is still largely left to projects.

The industrial receiver and OT conventions work therefore has an owner, yet no official place in the project. The next step depends on the place the project gives it.

Where to start?

Section titled “Where to start?”

The right entry point is one that does not touch the process and delivers visible value within a few weeks.

Start far from the process, move closer step by step

  1. Observe what already runs on servers. Edge gateways, virtualization hosts, containerized applications: hostmetrics, filelog and application instrumentation are enough.
  2. Place one Collector per zone, as a bridge. Outside the equipment perimeter, with a persistent queue and a single outbound flow to the DMZ, the buffer zone of the network between the plant and business IT.
  3. Write the data model before expanding. ISA-95 hierarchy (site, area, line, cell, equipment) as resource attributes, UCUM units (a standard code for units of measure), a closed list of useful tags, the variables read from the controllers. That document is worth more than the first configuration.
  4. Add process variables through a bridge, at small scale. A few dozen tags on a pilot line, read-only, validated with the OT team.
  5. Measure what was not visible. Collection loss, gateway disconnects, clock drift: this is often where the project proves its value against the historian.

Conclusion

Section titled “Conclusion”

OpenTelemetry is ready for the plant, provided you start with what it already does well: observing the systems around the process. CNCF graduation settles the durability question, Margo provides a neutral edge framework and the project is starting to look closely at IIoT.

What is missing is clear: an industrial receiver that is part of the project and semantic conventions for OT. OpenTelemetry Industrial has opened both. The manufacturers and integrators who take part in that work will weigh on the shape industrial observability takes.

Going further

Section titled “Going further”

Sources

Section titled “Sources”

Consulted on 11 October 2026.