Architecture Overview

This article is intended to assist Customer Experience Engineers, Network Engineers, Field Engineers, with a comprehensive understanding of the Crosswork Assurance platform architecture, data flows, and component relationships for effective troubleshooting and support.

Executive Summary

Crosswok Assurance (formerly Cisco Crosswork Assurance) is a cloud-native network monitoring and analytics platform built on Kubernetes. The platform processes telemetry data from network sensors, performs real-time analytics, and provides actionable insights through a modern web interface.

Key characteristics:

• 60+ microservices deployed as Kubernetes workloads

• Event-driven architecture using Apache Kafka

• Multi-tenant with complete data isolation

• Horizontally scalable for enterprise deployments

System Context

This diagram shows how the solution fits into your environment. External systems (sensors, users, integrations) connect to Crosswork Assurance, which processes and stores telemetry data:

Three-Plane Architecture

We organize the 60+ services into three logical planes. This grouping helps you quickly narrow down where to look when troubleshooting:

Control Plane

These services manage how the platform is configured and how sensors are orchestrated. Issues here are often subtle—sensors failing to register, configuration changes not taking effect, or tenant-specific problems. Check this plane when the system is "running" but not behaving as expected.

Data Plane

This is where the real work happens. Sensor data flows through these services to be ingested, processed, and stored. When users report "missing data," "stale metrics," or "dashboards not updating," you'll be investigating this plane.

Presentation Plane

This is what you and your users interact with directly. When someone reports they "can't access the system" or "the UI is broken," start here. These services handle authentication, serve the web interface, and expose APIs.

Data Flow Pipeline

Understanding how data moves through Crosswork Assurance is critical for troubleshooting. When data is missing, you can trace backwards through this pipeline to find where the flow is broken.

Pipeline Stages

The following table shows each stage of the data pipeline. Data flows from left to right—if you're missing data, start checking from the right (closest to the UI) and work backwards:

Kafka Topics

Kafka organizes data into topics. Knowing which topics exist helps you verify data is flowing correctly:

Data Stores

Crosswork Assurance uses specialized databases for different types of data. Understanding which database stores what helps you know where to look when troubleshooting:

Deployment Modes

Crosswork Assurance supports different deployment configurations depending on your requirements:

Service Quick Reference

Use this table when you need to quickly check a specific service's health or find its logs:

Common Questions

Q: Why is data not appearing in the UI?

Check the data pipeline in order:

1. Sensor connectivity (RoadRunner logs)

2. Kafka consumer lag

3. Ignite processing errors

4. Druid ingestion status

Q: Why are queries slow?

Druid historical cache may not be warmed. After restart, allow 10-15 minutes for cache population. Check druid_historical_cache_hit_rate metric.

Q: Why are sensors not connecting?

Verify:

1. Certificate validity (mTLS)

2. Network connectivity to RoadRunner port

3. Sensor-Orchestrator configuration

4. Firewall rules for sensor traffic

Next Steps

Now that you understand the architecture, use these guides for specific tasks:

• Post-Installation Health Verification Guide to verify platform health after deployment

• CLI Reference Guide access command-line tools for administration

• Complete Port Matrix and Firewall Rules Network configuration details

• On-Prem Troubleshooting Diagnose and resolve common issues

This article walks through the mental model we've built into the troubleshooting documentation. The goal is to give you a consistent framework for understanding the solution—not just a list of commands, but a way of thinking about the system.