Signals, SLOs and Service Assurance
Last updated 12 Oct 2026
At a glance
An observability platform is one layer in an operations architecture, not the whole of it. The estate emits telemetry, the platform raises what matters, the ITSM platform and its CMDB turn that into an incident with an owner. SLOs make it a service view, and it meets service assurance at service impact, through inventory.
The picture
How it works
Platform, then ITSM, then people
The platform can be any of several products. The system of record for operations is one: the ITSM platform and its CMDB, which map each configuration item to the business service it supports and the team that owns it.
Modern observability, term by term
| Term | Meaning | In the order chain |
|---|---|---|
| Distributed tracing | Following one request across many systems as a tree of timed spans | One order: CRM → COM → SOM → ROM, with the time spent in each |
| OpenTelemetry | The vendor-neutral CNCF standard and SDKs for producing metrics, logs and traces | What you ask every vendor to support so telemetry joins without adapters |
| APM | A product that collects and correlates the signals for an application | The tool; not a substitute for designing the identifiers |
| Event correlation | Reducing many raw events to the few that matter, by topology, time and rules | One port alarm → forty affected services → one incident, not forty |
| SLI | A measured property of the service | % of consumer broadband orders activated within 24 hours |
| SLO | The target for an SLI | ≥ 98% over 30 days |
| Error budget | How much the SLO allows you to fail | 2% of orders per month: spend it on releases, or protect it |
| Alerting | Telling a human, when it is worth a human | Alert on the SLO burning, not on a CPU |
| Root-cause analysis | Walking from symptom back to origin | From the care-queue spike back to the full disk |
Why SLOs change what you alert on
An alert on CPU wakes someone for a machine that may be fine. An alert on the order-completion SLO wakes someone because customers are being affected. SLOs turn observability from a systems view into a service view, which is the view the business already has. TM Forum describes the same idea from the standards side: TMF657 Service Quality Management defines objectives against a service, and TMF642 Alarm Management carries the alarms that correlation reduces.
Where observability meets service assurance
| Assurance function | What it does | What observability adds |
|---|---|---|
| Fault management | Collects and manages network alarms | Application and integration faults on the same timeline |
| Event correlation | Reduces alarm storms to incidents by topology | Which orders were in flight when the port failed |
| Service impact | Maps a resource fault to affected services and customers, through inventory | The service order that was activating on that port |
| Incident management | Owns the incident to closure | The trace and logs attached to the ticket, not reconstructed |
The T2R phase and its assurance module work from the network alarm up; observability works from the application symptom down. They meet at service impact, and service impact is only possible if Lead-to-Cash wrote the inventory records that make a port joinable to a customer.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Metrics, logs and traces | Observability platform | — | The emitting systems | Instrumented through OpenTelemetry where vendors support it |
| Network alarms | OSS fault management | — | ITSM event management | TMF642; raised by EMS/NMS, reduced by correlation |
| Actionable events (what crosses to ITSM) | Observability platform (alert rules) | — | ITSM event management | The platform decides what is worth a human |
| SLI and SLO definitions | Service quality management or the observability platform (varies by estate) | Service owners and the business | — | TMF657 describes the standards view; where they live is a deliberate choice |
| Configuration items and CI → service → owner mapping | ITSM CMDB | — | Service and resource inventory | Three places answer “which service is this”; they diverge unless reconciled |
| Customer-facing services and their resources | Service inventory (TMF638) and resource inventory (TMF639) | — | CMDB, fault management | Written by Lead-to-Cash; the basis of service impact |
| Incidents | ITSM platform | Resolver groups | — | One incident queue for network and application signals |
In practice
Four archetypes cover most of the market. Described the way the vendor landscape describes BSS/OSS vendors, the column that decides most selections is what the product does not solve.
| Archetype | Strengths | What it does not solve |
|---|---|---|
| Dynatrace | Applications, infrastructure and network; automatic discovery and topology; AI-assisted root cause. SaaS or self-managed, usage-based | The topology it discovers is technical; which commercial service a host serves still comes from the CMDB and inventory |
| Datadog | Broad integrations; APM, infrastructure, logs, traces and network in one product. SaaS only, usage-based | A largely on-premises network estate; cost predictability at telco log volumes |
| Splunk | Logs, events and security data; powerful search; can serve the SOC too. SaaS or self-managed, ingest-based | Tracing and topology are not its centre of gravity; cost grows with every log line |
| Grafana stack | Prometheus, Loki, Tempo and the OpenTelemetry collector; open and composable. Self-managed or Grafana Cloud | Someone has to run it; correlation across the stores and topology are yours to design |
Where vendors ship closed packages with their own consoles and cannot emit OpenTelemetry, operators correlate on the order id instead and accept that timing will not join. Five consoles and no shared identifier means every incident starts with someone exporting CSVs.
The trade-off
What it solves
A common observability platform feeding one ITSM and CMDB foundation turns telemetry into owned incidents, and SLOs make alerting reflect customer impact rather than machine health.
What it does not solve
- No platform can say which customer is affected until the CMDB or service inventory maps technology → service → owner.
- It does not reconcile the CMDB with service and resource inventory; that is a data discipline.
- Treating infrastructure availability as service health still leaves a green dashboard while customers call.
What it adds
- Usage- and ingest-based pricing has to be modelled at telco volumes before signing.
- A self-managed open stack needs a platform team to run it.
- SLO definitions need owners and agreement with the business, not only thresholds.
Architecture decision
Commercial suite, composable open source, or a log-centric platform shared with security?
Commercial suite
Choose when There is no platform team to run the tooling, the estate is hybrid and heterogeneous, and automatic discovery is worth the usage-based bill, modelled at telco volumes first
Composable open source
Choose when A platform team exists, OpenTelemetry is already the instrumentation standard, and predictable cost matters more than a turnkey product
Log-centric, shared with the SOC
Choose when Security and IT operations will genuinely share one platform and search over events is the primary workflow; add tracing deliberately
Breaks if The platform is chosen before the service model exists. Every option will raise alerts; none can say which customer is affected until the CMDB or service inventory maps technology → service → owner, and that mapping is not a product feature.
Takeaways
Key Takeaways
- SLOs make observability a service view; alert on the objective burning, not on the machine.
- Assurance works from the network up, observability from the application down; they meet at service impact, through inventory.
- Ask every vendor for OpenTelemetry. Where they cannot, correlate on the order id and know what you have given up.
- Several platform options, one ITSM and CMDB foundation. Choose the platform second; the service model it enriches from is the decision that matters.
Check yourself
A port alarm produces forty tickets, one per affected service, each marked low priority. What is wrong, and where?Show answerHide
Correlation and enrichment: the events should be reduced to one incident by topology, and enriched from the CMDB or service inventory to show customer-facing impact. Either the correlation rules or the service mapping they read is missing.
Why alert on the order-completion SLO rather than SOM CPU?Show answerHide
CPU can be high with customers unaffected, and low while orders fail. The SLO measures what customers experience, so an alert on it burning means a human is needed.