Rule-Driven SLA Compliance Reporting
Noisy Atom is helping Cisco produce, design, and build an SLA Reporting Engine. Over a chosen reporting period it pulls performance metrics and inventory directly from the Provider Connectivity Assurance (PCA) platform, and alarms and incidents from Crosswork Workflow Manager (CWM). It then applies rules that a user has written to describe an SLA, each made up of one or more Service Level Objectives (SLOs), computes where the service met or violated those objectives, and publishes the result as a downloadable report and as JSON that a web interface renders for navigation.
Project Metrics
Under the Hood: Services, Workers, and Storage
Technical Deep Dive
Ingestion Over a Reporting Period
Provider Connectivity Assurance keeps its performance metrics in Apache Druid, a store built for time-series queries over large volumes. The engine queries Druid for exactly the reporting window it needs and joins the result to the PCA inventory so that every measurement is tied to a known service, site, or circuit. Alarms and incidents are pulled from Crosswork Workflow Manager for the same window and attached to the same inventory objects.
Distributed Computation
Report generation is compute-heavy and bursty: a month-end run may touch thousands of objects across many SLAs at once. The work is broken into Celery tasks, queued through Redis, and spread across a pool of Python workers. FastAPI services front the system: one holds the SLA and SLO rules, another accepts and validates the trigger payloads that start a run. State that must survive a restart lives in CouchDB as JSON documents.
Built and Run as Microservices
Every component ships as a Docker container and is deployed with Docker Swarm. The services follow a common set of microservice standards for configuration, health, logging, and metrics, and report into the shared Prometheus stack. The engine is developed with the BMad Method, an agile, AI-driven development process in which planning artefacts stay explicit and agentic coding tools implement the stories against them.
From Platform Data to Compliance Report
A trigger names a reporting period and a set of SLAs. Metrics and inventory are read from Provider Connectivity Assurance through its Druid store, alarms and incidents come from Crosswork Workflow Manager, and a pool of Celery workers does the computation. The finished report and its JSON summary are stored and served to the customer through a web interface.
How an SLA Becomes Something You Can Measure
A Service Level Agreement is a contract between a provider and a customer. Inside it are Service Level Objectives: individual, measurable promises such as monthly availability above a threshold, one-way delay below a limit, or a maximum time to restore service after a fault.
The engine stores each SLA as a set of rules held by a FastAPI service and persisted in CouchDB. A rule says which metric to read, which objects in the inventory it applies to, how to aggregate over the reporting period, and what counts as a violation. Alarms and incidents from Crosswork Workflow Manager are matched to the same objects so that planned maintenance and known faults are handled the way the contract says they should be.
One Report Run, Step by Step
- A trigger payload arrives naming the customer, the SLAs, and the reporting period.
- The rules service returns every SLO rule that belongs to those SLAs.
- Workers read metrics and inventory for that period from Druid, and alarms and incidents from CWM.
- Each rule is evaluated per object; violations, exclusions, and compliance percentages are computed.
- Results are written as a JSON document and rendered into a downloadable report.
Reports People Can Download, Screens People Can Navigate
The same computed result is published two ways. A downloadable report gives the customer a fixed record for the reporting period. A JSON document feeds a Node.js web interface where a user can move from the SLA, to the objectives inside it, to the individual objects and time ranges where a violation occurred. Every service emits logs and metrics to a shared Prometheus stack, so a report that takes too long or fails is visible to the operations team, not just to the customer waiting for it.
Why It Matters
Service providers sell connectivity against written promises, and their customers increasingly want proof rather than assurance. The SLA Report Engine gives both sides one computed, repeatable answer to the question "did the service meet the agreement this period", built directly from the platform that measured the service.