Collector Reference: Discovery
OS and SNMP collectors that reach directly into infrastructure targets to discover what's actually running
Discovery collectors differ from platform collectors in a fundamental way. While platform collectors talk to a specific system's API (Kubernetes, Proxmox, Ceph), discovery collectors reach out directly to infrastructure targets to discover what's running inside them. They operate as a cross-cutting concern — enriching and extending the data gathered by platform collectors.
OS Collector
The OS collector connects to Linux hosts via SSH to discover operating system configuration, software inventory, security posture, and container runtime state — all without installing agents on targets.
CI Types Discovered (4)
| CI Type | Description |
|---|---|
os.linux | Operating system instance — distribution, kernel, packages, services, security config |
os.software | Promoted software — operationally significant packages with behavioral signals |
os.certificate | X.509 TLS certificates found on disk, deduplicated by fingerprint |
os.container | Docker/Podman containers discovered on hosts |
How It Works
- Rulesets define which CIs to target (e.g., all running Proxmox VMs)
- Target discovery queries the Parascope API for matching CIs and extracts IP addresses
- SSH connection is established using credentials from Parascope's secure credential store
- A self-contained bash script is streamed to the target and executed in memory — nothing is installed
- Results are parsed, promoted (software selection), and published for processing
Collection Sections
The script collects 12 independent sections, each individually toggleable per ruleset:
| Section | What It Collects |
|---|---|
| os_identity | Distribution, version, kernel, hostname, architecture, timezone |
| packages | Full package inventory (dpkg or rpm) |
| services | Systemd unit states |
| network | Interfaces, IPs, routes, DNS resolvers |
| filesystems | Mount points with capacity and usage |
| resource_usage | CPU model/count, memory, swap, uptime, load |
| listeners | Listening TCP/UDP ports with process names |
| certificates | X.509 certificates in standard paths |
| patch_status | Pending security and regular updates |
| security_baseline | SSH config, user accounts, sudo access, SELinux/AppArmor |
| hardware | Virtualization type, block/network devices |
| containers | Docker/Podman containers with config and state |
Software Promotion
Not every installed package becomes a CI. The promotion engine identifies operationally significant software based on:
| Signal | Example |
|---|---|
| Listening port | nginx listening on port 80 |
| Active daemon | postgresql running as systemd service |
| Known pattern | redis-server matches infrastructure pattern |
| Force promote | Custom packages configured in ruleset |
| Unpackaged listener | Unknown process with a network socket |
Software CIs are deduplicated across the fleet — one CI per unique (name, version, package type) combination.
Authentication
- SSH Private Key — recommended, stored securely in Parascope
- SSH Password — for legacy systems, stored securely in Parascope
- Jump host — for targets in isolated networks behind a bastion
OS Enrichment
The OS collector also enriches parent infrastructure CIs (VMs, nodes) with OS-level summary data: distribution, kernel version, CPU/memory utilization, and IP mismatch detection.
Configuration
Managed via Settings → OS Collection using collection rulesets. See the full OS Collection documentation for detailed configuration.
SNMP Collector
The SNMP collector discovers network devices using the Simple Network Management Protocol, collecting device identity, interface inventory, and physical connectivity (LLDP topology).
CI Types Discovered (1)
| CI Type | Description |
|---|---|
network.device | Network device — switches, routers, access points, firewalls |
What Gets Collected
| Category | Data |
|---|---|
| Device Identity | System name, description, location, contact, uptime, object ID |
| Interfaces | Interface table with names, types, speeds, MAC addresses, admin/oper status |
| IP Addresses | IP addresses assigned to interfaces |
| LLDP Neighbors | Link Layer Discovery Protocol neighbor information for physical topology |
SNMP Versions
| Version | Authentication | Use Case |
|---|---|---|
| SNMPv2c | Community string | Simple environments with trusted networks |
| SNMPv3 | Username + auth/priv protocols | Production environments requiring encryption |
SNMPv3 supports:
- Auth protocols: MD5, SHA, SHA-224, SHA-256, SHA-384, SHA-512
- Privacy protocols: DES, AES, AES-192, AES-256
Target Discovery Modes
| Mode | Description |
|---|---|
| Static | Targets defined directly in configuration (comma-separated IPs/hostnames) |
| Netbox Query | Targets discovered dynamically by querying Parascope API for Netbox devices |
| CIDR | Subnet ranges scanned for SNMP-responsive devices with confidence-based auto-promotion |
Netbox query mode enables automatic target discovery — as new devices appear in Netbox, the SNMP collector automatically starts monitoring them without configuration changes.
LLDP Topology
The SNMP collector creates physical_connection relationships between network devices based on LLDP neighbor data, building a map of your physical network topology.
Enrichment
When a network device already exists as a CI from another source (e.g., Netbox), the SNMP collector enriches it with operational data (SNMP-discovered interfaces, IP addresses, LLDP neighbors) rather than creating a duplicate.
Configuration
Configured via Settings → Collectors when adding an SNMP source. See the SNMP Collection guide for detailed configuration.
| Setting | Description |
|---|---|
| Targets | Static target list (comma-separated IPs/hostnames) |
| SNMP Version | Protocol version: v2c or v3 |
| Community String | Community string for v2c authentication |
| Discovery Mode | How targets are found: static, Netbox query, or CIDR scan |
| Collection Interval | How often to collect data (default: 5 minutes) |
See the full SNMP Collection documentation for detailed configuration, device classification, and LLDP topology discovery.
Platform vs Discovery Collectors
| Aspect | Platform Collectors | Discovery Collectors |
|---|---|---|
| Data source | Platform API (K8s, Proxmox, etc.) | Direct target access (SSH, SNMP) |
| Perspective | Outside-in (what the platform knows) | Inside-out (what's actually running) |
| Dependency | Needs platform API access | Needs direct network access to targets |
| Scope | Everything the platform manages | Cross-cutting — enriches any CI with host-level data |
| Examples | Container orchestration, storage pools, VM config | OS packages, certificates, network topology |
The most complete infrastructure picture comes from combining both — platform collectors provide the structural view, while discovery collectors fill in the operational details that platforms can't see.
Related Documentation
- OS Collection — Full OS collection documentation with configuration details
- SNMP Collection — Full SNMP collection documentation with device classification and topology
- Managing Collectors — Collector health and configuration
- Managing Credentials — SSH credential management for OS collection
- Collector Reference: Infrastructure — Kubernetes, Proxmox, OpenStack, Netbox
- Collector Reference: Platform Services — Ceph, PostgreSQL, Prometheus, Grafana, Vault, DNS