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.

Loading diagram...

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.

API Reference: REST API endpoints and authentication
Correlation Engine: Cross-system relationship discovery
Managing Collectors: Collector health and configuration

How Parascope Works