OpenTelemetry for Energy

An energy company standardises on OpenTelemetry for its IT estate and the collection topology works well in the data centre and cloud. Then someone extends collection toward systems at the operational edge, and two problems appear at once. The collector needs outbound connectivity from a network segment that deliberately has very little, and the instrumentation library wants to be installed on hosts that sit inside a boundary where installing anything requires a change process measured in weeks. The standard is fine. The topology assumptions inside it were written for a data centre.

Collection topology assumes connectivity that operationally segmented networks deliberately do not have.

OpenTelemetry for energy means instrumenting the IT estate with collection topology designed for segmented networks, the OT boundary respected absolutely, asset context attached where useful, and cardinality controlled given high-volume telemetry.

Why Engineering Is Heading Toward Agent-to-Agent, Not Just AI-Assisted

Explore how connected agents reshape engineering beyond AI-assisted development.

Download Whitepaper

However, most adoptions design a topology for cloud and data centre connectivity and then discover that extending it toward the operational edge conflicts with the segmentation that exists for good reasons.

If you are a VP of Engineering or Head of Infrastructure at an energy company, the intent of this article is:

Define why collection topology is the hard part in a segmented estate
Show where the OT boundary stops instrumentation
Lay out how to control cardinality on high-volume telemetry

To do that, let's start with the basics.

What Is OpenTelemetry for Energy? The Basic Definition

At a high level, OpenTelemetry is a vendor-neutral standard for generating and collecting traces, metrics, and logs, with a collector layer that processes and exports. In an energy estate the interesting design work is topology rather than instrumentation. Networks are segmented deliberately, outbound connectivity from some segments is minimal by design, change processes on hosts near operational systems are long, and the OT boundary is a place where instrumentation should stop rather than be adapted. Designing collection to work within those constraints, rather than treating them as obstacles, is what makes adoption viable.

To compare:

Extending a data centre collection topology toward the operational edge is running a cable into a room that was deliberately built without a cable duct. The room is not badly designed; the absence is the design. Working within it means a different collection pattern rather than a longer cable and an exception request.

Why Does OpenTelemetry Matter for Energy?

Issues that it addresses or resolves:

Collection topology assuming connectivity that segmentation prevents
Instrumentation attempted where change processes make it impractical
High-volume telemetry cost growing without cardinality control

Resolved Issues by OpenTelemetry Done Well

Collection designed for segmented networks
The OT boundary respected as a stopping point
Cardinality controlled on high-volume signals

Core Components of OpenTelemetry Adoption in Energy

Collection topology designed for network segmentation
The OT boundary as an instrumentation limit
Asset context attached where it aids correlation
Cardinality limits applied at collection
Semantic conventions enforced centrally

Modern OpenTelemetry Tooling for Energy

Collector deployments with tiered aggregation
Store-and-forward for intermittent connectivity
Attribute normalisation and cardinality limiting
Asset identifier enrichment from the catalog
Per-source telemetry volume attribution

These tools work within segmentation. Tiered collectors with store-and-forward are what make collection viable where outbound connectivity is limited or intermittent.

Other Core Issues They Will Solve

Telemetry from segmented environments reaching the backend
Correlation between IT signals and asset context
Volume growth attributable and controllable

In Summary: OpenTelemetry for energy is a collection topology problem more than an instrumentation problem, and the OT boundary is where instrumentation stops rather than adapts.

Importance of OpenTelemetry for Energy in 2026

Energy estates are segmented, long-lived, and generate substantial telemetry. Four reasons explain why this matters now.

1. Segmentation is deliberate.

Limited outbound connectivity from certain segments is a control rather than an oversight, and topology must work with it.

2. Change processes near operations are long.

Installing agents on hosts inside a controlled boundary is measured in weeks, which changes what is practical.

3. The OT boundary is a stopping point.

Instrumentation should not extend into operational technology, regardless of how useful the telemetry would be.

4. Volume is high and cardinality compounds.

Traditional vs. Modern Energy Telemetry

Data centre topology extended vs. topology designed for segmentation
Agents everywhere vs. instrumentation bounded by practicality and policy
Cardinality unmanaged vs. limited at collection
Asset context absent vs. enriched from the catalog

In summary: A modern energy approach designs collection for the network that exists and stops instrumentation at the boundary.

Details About the Core Components of OpenTelemetry Adoption in Energy: What Are You Designing?

Let's go through each component.

1. Topology Layer

Working with segmentation.

Topology decisions:

Tiered collectors within segments
Store-and-forward for intermittent links
Egress paths designed rather than requested

2. Boundary Layer

Where instrumentation stops.

Boundary decisions:

OT excluded from instrumentation entirely
Operationally adjacent hosts assessed individually
Change process cost factored in

3. Enrichment Layer

Asset context.

Enrichment decisions:

Asset identifiers added from the catalog
Enrichment at collection rather than in code
Context useful for correlation only

4. Cardinality Layer

Controlling volume.

Cardinality decisions:

Limits applied at collection
High-cardinality asset attributes assessed
Cost attributed per source

5. Convention Layer

Consistency across teams.

Convention decisions:

Semantic conventions enforced at collection
Drift normalised centrally
New sources validated

Benefits Gained from OpenTelemetry in Energy

Telemetry from segmented environments reaching the backend
Correlation between IT signals and asset context
Volume growth controlled and attributable

How It All Works Together

The energy engineering team designs the collection topology around the network that exists rather than requesting exceptions to it. Tiered collectors sit within segments, aggregating locally and forwarding through designed egress paths, with store-and-forward handling intermittent links so a connectivity gap produces delayed telemetry rather than lost telemetry. Instrumentation stops at the OT boundary absolutely, and operationally adjacent hosts are assessed individually with the cost of their change process factored in, because an agent that takes six weeks to approve may not be worth the signal. Asset identifiers are added at collection from the catalog rather than being attached in application code, which keeps enrichment consistent and lets it change without redeployment. Cardinality limits are applied at collection because asset-related attributes can generate very high cardinality, and cost is attributed per source. Semantic conventions are enforced and drift normalised centrally.

Common Misconception

If we can reach it on the network, we should instrument it.

Reachability is not the test. The relevant questions are whether the host sits inside a boundary where instrumentation should not extend, whether the change process to install anything makes the signal uneconomic, and whether the telemetry would actually be used. In an energy estate all three frequently point the other way for hosts near operational systems, and the useful position is to stop at a defined line and design collection so everything on the IT side works well. Extending toward operations because it is technically possible produces exception requests, long approval cycles, and an eventual boundary crossing nobody intended.

Key Takeaway: Reachability is not the criterion. Stop at the boundary and make everything on the IT side work properly.

Real-World OpenTelemetry for Energy in Action

Let's take a look at how it operates with a real-world example.

We worked with an energy engineering team whose collection topology conflicted with network segmentation, with these constraints:

Design collection for the segmented network
Stop instrumentation at the OT boundary
Control cardinality on high-volume asset telemetry

Step 1: Design for Segmentation

Not around it.

Tiered collectors within segments
Store-and-forward for intermittent links
Egress paths designed

Step 2: Stop at the Boundary

Absolutely.

OT excluded from instrumentation
Adjacent hosts assessed individually
Change process cost factored in

Step 3: Enrich at Collection

Not in code.

Asset identifiers from the catalog
Enrichment centrally applied
Changeable without redeployment

Step 4: Limit Cardinality

Before the bill.

Limits at collection
High-cardinality attributes assessed
Cost attributed per source

Step 5: Enforce Conventions

Centrally.

Conventions enforced at collection
Drift normalised
New sources validated

Where It Works Well

IT estates with segmented networks and designed egress
Environments with intermittent connectivity handled by store-and-forward
Programmes controlling cardinality centrally

Where It Does Not Work Well

Topologies assuming data centre connectivity everywhere
Instrumentation extended toward operational technology
High-cardinality asset attributes left unmanaged

Key Takeaway: Design topology for the network that exists, stop at the boundary, enrich centrally, and limit cardinality.

Common Pitfalls

i) Extending data centre topology

Assuming outbound connectivity that segmentation deliberately prevents produces exception requests rather than telemetry. Use tiered collectors and designed egress.

Collection fails from segmented environments
Exception requests accumulate
The segmentation was correct

ii) Instrumenting because it is reachable

Reachability is not the test, and change process cost plus boundary policy frequently point the other way. Stop at a defined line.

iii) Enrichment in application code

Asset context attached in code cannot change without redeployment across many services. Enrich at collection instead.

iv) Unmanaged cardinality on asset attributes

Asset identifiers can produce very high cardinality, which dominates cost quietly. Limit at collection and attribute cost per source.

Takeaway from these lessons: The design problem is topology and boundary, and both are decided by the network and the policy rather than by the instrumentation.

OpenTelemetry Best Practices for Energy: What High-Performing Teams Do Differently

1. Design collection for segmentation

Use tiered collectors and store-and-forward so limited or intermittent connectivity produces delay rather than loss.

2. Stop instrumentation at the OT boundary

Treat it as a line rather than a constraint to negotiate, and assess adjacent hosts individually against change cost.

3. Enrich asset context at collection

Keep enrichment out of application code so it can change without redeploying many services.

4. Limit cardinality on asset attributes

Assess which asset identifiers are worth their cardinality cost and attribute telemetry spend per source.

5. Enforce conventions centrally

Normalise drift at collection, since new sources arrive continually in a long-lived estate.

Logiciel's value add is helping energy engineering teams design collection topology for segmented networks and control cardinality on high-volume telemetry.

Takeaway for High-Performing Teams: Design for segmentation, stop at the boundary, enrich centrally, limit cardinality, enforce conventions.

Signals You Are Doing OpenTelemetry Well in Energy

How do you know it is working? Not by coverage, but by whether segmented environments report reliably. These are the signals that separate workable topology from exception requests.

Segments report. Telemetry arrives from constrained networks without exceptions.

Gaps delay rather than lose. Store-and-forward handles intermittent links.

The boundary holds. No instrumentation extends into operational technology.

Cardinality is controlled. Asset attributes do not dominate cost.

Conventions are enforced. Drift is normalised at collection.

Adjacent Capabilities and Connected Work

This work does not exist in isolation. OpenTelemetry adoption depends on, and feeds into, the surrounding platform. Ignoring the adjacencies is the most common scoping mistake.

AIOps consumes the telemetry and depends on asset and IT signals being separable. Master data management supplies asset identifiers for enrichment. AI-assisted SRE assembles context from it. FinOps guardrails supply cost discipline. Naming these adjacencies upfront keeps the work scoped and helps leadership see topology as the design problem.

The common mistake is treating each adjacency as someone else's problem. The topology design is your problem. The boundary discipline is your problem. The cardinality control is your problem. Pretend otherwise and you will file exception requests against segmentation that exists for good reasons. Own the adjacencies you depend on, partner with the teams that hold them, and share the topology.

Conclusion

OpenTelemetry in an energy estate is a topology exercise more than an instrumentation one. Networks are segmented deliberately, outbound connectivity from some segments is minimal by design, and change processes on hosts near operational systems make agent installation slow enough to change the economics of the signal. Design tiered collectors within segments with store-and-forward for intermittent links so gaps produce delay rather than loss. Stop instrumentation at the OT boundary absolutely, and assess adjacent hosts individually against their change cost. Enrich asset context at collection rather than in code, and limit cardinality on asset attributes before they dominate the bill.

Key Takeaways:

Collection topology, not instrumentation, is the hard part in a segmented estate
Reachability is not the criterion for whether to instrument something
Asset attributes can produce very high cardinality that dominates cost quietly

Adopting OpenTelemetry well requires designing for the network. When done correctly, it produces:

Telemetry arriving from segmented environments reliably

The Architecture Layer That Decides If Your AI Product Survives Production

Build the architecture layers that make AI products production-ready.