How Parascope Works
How Parascope discovers, processes, and presents your infrastructure data
Design Principles
Parascope is built on these foundational principles:
-
Source-Aligned Data Model: Parascope preserves the original data models from each source system. A Kubernetes pod looks like a Kubernetes pod, not a generic "compute instance." This means you always see data in the context you expect.
-
Observer Pattern: Parascope observes and reports what exists, not what should exist. It's descriptive, not prescriptive — giving you a truthful view of your actual infrastructure state.
-
Convention Over Configuration: New sources and CI types work automatically without manual configuration. When a new collector is added, its data flows through the system and appears in the UI immediately.
-
Extensible by Design: Parascope supports a growing catalog of infrastructure sources. New collectors integrate without platform downtime or changes to your existing setup.
-
Multi-Tenant SaaS: Each tenant's data is fully isolated. Your infrastructure data is never visible to other tenants.
How Data Flows
Parascope follows a three-stage pipeline: Collect → Process → Present.
1. Collection
Collectors query your infrastructure systems on a regular schedule and gather configuration data and metrics. Each collector is purpose-built for its source type, speaking the native API or protocol of the target system.
A single collector can manage multiple instances of the same source type — for example, one Kubernetes collector monitoring several clusters simultaneously, with independent health tracking for each.
2. Processing
Collected data is processed automatically to:
- Detect changes — incoming data is compared against stored state to identify what has been created, updated, or deleted. Only configuration changes are tracked in change history; runtime metrics are stored but not audited
- Extract relationships — references between CIs are identified automatically from the collected data (e.g., a pod running on a node, a VM connected to a network)
- Enrich data — cross-source enrichment adds context from other sources (e.g., DNS records matched to IPs discovered on infrastructure CIs)
3. Presentation
Processed data is available through:
- Web application — dashboard, search, detail views, relationship graph, change history
- REST API — programmatic access for automation and integration
- Query Console — ParaQL query language for ad-hoc analysis and reporting
Collector Deployment
Collectors can be deployed in two modes depending on where your target systems are located:
| Mode | Use Case | How It Works |
|---|---|---|
| Central | Cloud-accessible APIs (e.g., AWS, GCP, Azure, SaaS platforms) | Collectors run within the Parascope platform and connect directly to your systems' APIs |
| Remote (Appliance) | On-premises systems behind firewalls | A pre-built virtual machine runs collectors locally and securely transmits data back to the Parascope platform over an encrypted connection |
The remote appliance allows discovery of infrastructure that is not reachable from the cloud — data centers, private networks, and air-gapped environments.
What Gets Tracked
Parascope separates collected data into two categories:
| Category | Tracked in Change History | Examples |
|---|---|---|
| Configuration | Yes | VM name, CPU count, network interfaces, software versions, security group rules |
| Metrics | No (stored, not audited) | CPU utilization, memory usage, uptime counters, request rates |
This separation ensures your change history is meaningful — showing intentional configuration changes rather than runtime fluctuations.
Related Documentation
- API Reference — REST API endpoints and authentication
- Correlation Engine — Cross-system relationship discovery
- Managing Collectors — Collector health and configuration