The layers of observability

Reading mode

EngineerDecision-maker

Observability is spoken of as one topic, yet the automation engineer, the network engineer, the platform team, the developer, the data engineer and the ML team observe neither the same things, nor with the same signals, nor with the same tools. This diagram stacks them in the manner of the OSI model, from the industrial field up to AI models, with two bands that cross them all: security, and cost weighed against business value. The tools named are examples, open source and commercial, listed alphabetically with no ranking.

Follow an end-to-end example

Click a layer or a band, or walk through them with the keyboard (Tab, or up and down arrows). The example follows a fictitious shop-floor reading up to a failure prediction model; infrastructure carries the platform without being on the logical path.

• 1FieldIndustrial OT, PLCs, sensors, IoT, Layer 1 of 7
• 2Networklinks, protocols, latency, Layer 2 of 7
• 3Infrastructureservers, storage, GPUs, Layer 3 of 7
• 4Platformcontainers, cloud, high performance computing, Layer 4 of 7
• 5Applicationsservices, APIs, user experience, Layer 5 of 7
• 6Datapipelines, quality, freshness, Layer 6 of 7
• 7AI and modelsLLMs, agents, evaluation, Layer 7 of 7

Security, Cross-cutting bandCost and business value, Cross-cutting band

Try this

1. Follow the end-to-end example: a vibration reading from a fictitious shop floor crosses the field, the network, the platform, the monitoring application and the data before feeding a failure prediction model. At each step, ask which signal would warn you if it broke.
2. Compare two neighboring layers: open Infrastructure, then Applications. The USE method looks at resources, the RED method looks at requests; a slow service on idle servers points the investigation somewhere else than the reverse.
3. Open Field, then Data: in both cases a value can arrive on time and be wrong. The OPC UA quality code and data tests answer the same need at two different layers.
4. Open both bands: security and cost are not extra layers. Each asks every other layer a question: who has access, and what it costs compared with what it brings.

The rule to remember

A symptom is read with the layer below and the layer above. The layer below often gives the cause, the layer above measures the impact. An observability stack that covers a single layer answers “does it work here?” well, and “why doesn’t the business see what it expects?” badly.

Go further: the clickable architecture for an example stack that collects and stores these signals, the trace explorer for the application layer, and the LLM observability training for the AI layer.

BridgesWhat this page changes beyond the technical team.

BusinessValue, cost, risk

An incident is costed at the layer where it reaches the customer, not where it starts: a frozen sensor on the shop floor costs a wrong failure prediction and a missed maintenance intervention.

OrganizationWho decides, who owns

Each layer often has its own team (automation, network, systems, platform, development, data, ML) and its own tools: the diagram shows the boundaries where a signal changes owner, where incidents get lost between two ticket queues.

PeopleTeams, on-call, skills

An on-call engineer who only knows their own layer looks for the cause at home. Being able to read the layer below and the layer above saves hours of investigation and blame between teams.

Business linesProduct, finance, risk, customer

Production, maintenance and quality see why a shop-floor indicator such as OEE or a failure prediction depends on layers they cannot see, and whom to ask when the figure looks wrong.

Why bridges matter →