Signals, SLOs and Service Assurance
Distributed tracing, OpenTelemetry, SLIs and SLOs, event correlation, and where observability meets fault management and service impact.
An observability platform is one layer in an operations architecture, not the whole of it. The estate emits telemetry; the platform collects it and raises what matters; the ITSM platform and its CMDB turn that into an incident with an owner; people act. The platform can be any of four. The system of record for operations is one.
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 standard (CNCF) for producing metrics, logs and traces, and the SDKs that emit them | What you ask every vendor to support so telemetry joins without adapters |
| APM | Application performance monitoring: 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 | Service level indicator: a measured property of the service | % of consumer broadband orders activated within 24 hours |
| SLO | Service level objective: 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 |
Choosing the platform
Four archetypes cover most of the market. They are described here the way the vendor landscape describes BSS/OSS vendors: coverage, hosting, commercial model and — the column that decides most selections — what the product does not solve.
| Archetype | Strengths | Hosting | Commercial model | What it does not solve |
|---|---|---|---|---|
| Dynatrace | End-to-end coverage of applications, infrastructure and network; automatic discovery and topology; AI-assisted root-cause analysis; strong database, cloud and network support | SaaS or self-managed | Commercial subscription, usage-based | The topology it discovers is technical. Which commercial service a host serves, and who owns it, still comes from the CMDB and inventory |
| Datadog | Broad integration coverage; APM, infrastructure, logs, traces and network in one product; strong cloud and SaaS support; large integration marketplace | SaaS only | Commercial subscription, usage-based | A largely on-premises network estate; cost predictability at telco log volumes |
| Splunk | Logs, events and security data; powerful search and analytics; wide range of data sources; the same platform can serve the SOC | SaaS or self-managed | Commercial subscription, ingest- or usage-based | Tracing and topology are not its centre of gravity; ingest cost grows with every log line the estate emits |
| Grafana stack | Open and composable — Prometheus (metrics), Loki (logs), Tempo (traces), Alloy or the OpenTelemetry collector; highly customisable; OpenTelemetry-native; strong community | Self-managed (open source) or Grafana Cloud | No licence when self-hosted, or a managed subscription | Someone has to run it — a platform team is the licence. Correlation across the three stores, and topology, are yours to design |
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 — which must be modelled at telco volumes before signing.
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 operations 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 one of the four will raise alerts. None of them can say which customer is affected until the CMDB or the service inventory maps technology → service → owner — and that mapping is not a product feature.
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 as network ones |
| Event correlation | Reduces alarm storms to incidents by topology | Trace and order context: which orders were in flight when the port failed |
| Service impact | Maps a resource fault to the services and customers it affects — through inventory | The application-layer link: the service order that was activating on that port |
| Incident management | Owns the incident to closure | Evidence: the trace and logs attached to the ticket, not reconstructed |
The T2R phase and its assurance module cover fault management from the network up. Observability comes at the same incident from the application down. Where they meet is service impact — and service impact is only possible if Lead-to-Cash wrote the inventory records that make a port joinable to a customer.
Decisions
Architecture decision
Should monitoring focus on infrastructure availability or on end-to-end service health?
Infrastructure availability
Choose when you are starting from nothing — a green/red view of each system is the first thing operations needs and the cheapest to build.
End-to-end service health
Choose when the estate is distributed and vendors are mixed, and “every system green, orders still failing” has already happened.
Both, with SLOs on top
Choose when infrastructure signals feed the platform team; service SLOs feed the business and decide what pages a human. The mature answer.
Breaks if infrastructure availability is treated as service health: the dashboard is green, the customer is on the phone, and the operator learns about its own outage from social media.
Architecture decision
One observability platform for the whole estate, or each vendor’s own tooling?
One platform, OpenTelemetry in
Choose when the estate is yours to instrument and the platform team can run it; traces then join across vendors.
Per-vendor tooling, correlated by order id
Choose when vendors ship closed packages with their own consoles and cannot emit OpenTelemetry — correlate on the order id and accept that timing will not join.
Breaks if five consoles and no shared identifier: every incident starts with someone exporting CSVs.
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.
- Four platform archetypes, one ITSM and CMDB foundation. Choose the platform second; the service model it enriches from is the decision that matters.