Monitoring vs Observability
Last updated 12 Oct 2026
At a glance
Monitoring checks the failure modes you predicted; observability lets you ask about the ones you did not. In a BSS/OSS order chain of many systems from several vendors, every dashboard can be green while an order stalls, and closing that gap depends on shared identifiers and inventory, not on another tool.
The picture
How it works
Every part healthy, the whole failing
Every system in the order chain has monitoring, and the dashboard for each is green. Yet an order placed at 14:03 is still not activated at 17:00, and nobody can say why. That gap is what observability exists to close, and it is the normal condition of a chain of eight systems from four vendors.
The three signals
| 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 |
From infrastructure to the customer
One infrastructure fault becomes a customer problem layer by layer: at the top it is a full disk, at the bottom a call-centre queue. An operator is judged at the bottom of that ladder (late activations, recurring faults, wrong bills) and diagnoses at the top. Service observability connects the two by making every technical signal joinable to the service and customer it affects.
That join runs through inventory, which is why service assurance and observability are the same problem seen from two sides: assurance from the network up, observability from the application down.
From fragmented and reactive to integrated and proactive
| Today: fragmented and reactive | Target: integrated and proactive |
|---|---|
| One monitoring tool per department or vendor, none joined | One observability platform the whole estate emits into |
| Network operations, IT operations, digital and corporate IT each watching their own screens | Connected teams working one incident from one timeline |
| Several partial CMDB and inventory copies, no single map of technology → service → owner | One ITSM platform and CMDB as the operational record, reconciled to service and resource inventory |
| A high volume of alerts, mostly noise, few owned | Automated event correlation: one incident per cause, with an owner |
| Issues found after they reach customers or the care queue | Detected from the signals, before the customer calls |
| Manual incident creation, escalation by phone, reporting per team | Standard incident, problem and change processes and one set of service reports |
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Metrics, logs and traces | Observability platform | Dashboards and search | — | Emitted by each system; the platform is the store, not the author |
| Trace and order identifiers | The interfaces between systems | — | Observability platform | Set by design when integrations are built; cannot be added by the platform later |
| Network alarms | OSS fault management | — | Observability platform, ITSM | Usually raised by EMS/NMS and handled in assurance |
| Configuration items and service mapping (technology → service → owner) | ITSM CMDB | — | Service and resource inventory | Often several partial copies in the fragmented state; reconciliation to inventory is the hard part |
| Services delivered to customers | Service inventory | — | CMDB, observability platform | The join from a technical signal to a customer |
| Incidents | ITSM platform | Operations and resolver teams | — | Manual creation by phone and email is the fragmented-state default |
In practice
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 same six findings recur: 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 customers; incidents created and escalated by hand; unclear ownership between the network operations centre and IT operations; and 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: an identifier that was never propagated, or a CMDB entry that never said which service a host serves.
The trade-off
What it solves
Observability lets operations answer questions nobody predicted (where this order stalled, why, and which customers it affects) across a chain of systems that each look healthy on their own.
What it does not solve
- It does not create the shared identifiers; those are interface design decisions made when integrations are built.
- It does not tell you which customer is affected unless inventory or the CMDB maps technology to service to owner.
- It does not settle ownership between the network operations centre and IT operations.
What it adds
- Log and trace volumes at telco scale are expensive to store and search.
- Every system, including vendor packages, has to propagate the same identifiers.
- A CMDB that is reconciled to inventory has to be kept current, not populated once.
Architecture decision
Keep each system’s monitoring as the operational view, or invest in end-to-end observability across the chain?
Per-system monitoring
Choose when The estate is small, largely one vendor, and failures are mostly the predictable kind a health check catches
End-to-end observability
Choose when The order chain spans several vendors and asynchronous hops, and “every system green, order still failing” has already happened
Breaks if Observability is bought as a tool without designing the shared identifiers and the service mapping: the platform holds all the data and still cannot join one order across systems or to a customer.
Takeaways
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 of many tools, siloed teams, partial CMDBs and alert noise is the normal starting point.
Check yourself
Every system dashboard is green, but orders from Friday are not activated. Which signal tells you where in the chain they stopped?Show answerHide
Traces: they follow one request across systems as spans and show which span ended in error or stalled. That only works if every system propagated the same trace id.
A new observability platform holds logs from every system, but nobody can say which customers a failing host affects. What is missing?Show answerHide
The service mapping: a CMDB or inventory record that joins the host to the service it supports and the customer who has it. That is data, not a platform feature.