Monitoring vs Observability

The distinction, the three signals, and the impact ladder from infrastructure to customer experience.

In a distributed BSS/OSS environment, knowing that a system is “up” is not enough. Architects need to understand how services behave across applications, integrations and infrastructure.

The distinction, drawn as the questions each one can answer. Monitoring checks the failure modes you predicted; observability lets you ask about the one you did not.

Every system in the order chain has monitoring. The dashboard for each is green. And an order placed at 14:03 is still not activated at 17:00, and nobody can say why. That gap — every part healthy, the whole failing — is what observability exists to close, and it is the normal condition of a chain of eight systems from four vendors.

The three signals

Metrics, logs and traces as three views of the same failing order. The shape of each is what tells you which question it can answer.

Signal	What it is	Best at	Cost
Metrics	Numbers over time: counts, rates, latencies, aggregated	What is happening and since when; alerting	Cheap to store; loses the individual case
Logs	Timestamped events with detail, one per thing that happened	Why this one failed	Expensive at volume; useless without a shared id
Traces	One request followed across systems as a tree of spans	Where in the chain time went or failure occurred	Needs every system to propagate the trace id

The shared identifier is the whole game

A log line that says “decomposition failed” is only useful if it carries the order id, and a trace only joins across COM and SOM if both pass the same trace id in the request headers. Correlation is a design decision made when the interfaces are built, not a feature bought later.

From infrastructure to the customer

How one infrastructure fault becomes a customer problem, layer by layer — and why root cause is found by walking back up. At the top it is a full disk; at the bottom it is a call-centre queue.

A telecom operator is judged at the bottom of the ladder — late activations, faults that recur, bills that are wrong — and diagnoses at the top. Service observability is the discipline of connecting the two: every technical signal joinable to the service and the customer it affects. That join runs through inventory, which is why service assurance and observability are the same problem seen from two sides.

From fragmented and reactive to integrated and proactive

Most operators do not start from nothing; they start from too much. Each department chose its own monitoring, each vendor shipped its own console, and the CMDB — where one exists — was populated by a project that ended. The result is the state on the left. The state on the right is what the rest of this module is about.

Today — fragmented and reactive	Target — integrated and proactive
Multiple monitoring tools: one per department, one per vendor, none joined	One observability platform the whole estate emits into
Siloed teams: network operations, IT operations, digital channels and corporate IT each watching their own screens	Connected teams working one incident from one timeline
Fragmented CMDB and inventory: several partial copies, no single map of technology → service → owner	One ITSM platform and one CMDB as the system of record for operations, reconciled to service and resource inventory
A high volume of alerts, most of them noise, few of them owned	Automated event correlation: one incident per cause, with an owner
Reactive: issues found after they reach customers or the care queue	Proactive: detected from the signals, before the customer calls
Inconsistent processes: manual incident creation, escalation by phone, reporting per team	Standard incident, problem and change processes and one set of service reports

What the fragmented state costs — the six recurring findings

Different monitoring and ITSM tools across departments. No end-to-end visibility across network operations, IT, digital channels and corporate functions. Issues detected after they have affected operations or customers. Incidents created and escalated by hand. Unclear ownership between the network operations centre and IT operations. Inconsistent processes, reporting and service ownership. Each is an architecture finding as much as an organisational one: the join that is missing is in the data.

Key Takeaways

Monitoring answers the questions you predicted; observability answers the ones you did not. A distributed order chain needs both.
Metrics say what, logs say why, traces say where — and none of them join without a shared identifier designed into the interfaces.
Faults propagate down the ladder to the customer; root cause is found by walking back up, and the join is inventory.
The fragmented state — many tools, siloed teams, partial CMDBs, alert noise — is the normal starting point. The target is one platform, one CMDB and one process.