Collector Reference: Platform and Services

These collectors monitor the services and platforms that support your infrastructure: storage clusters, databases, monitoring systems, secret management, and DNS. Each collector connects to a platform's API, discovers its components, and publishes configuration items into Parascope for tracking and correlation.

Ceph Collector

The Ceph collector discovers storage infrastructure from Ceph clusters via the Ceph Dashboard/Manager REST API.

CI Types Discovered (11)

Authentication

• Ceph Dashboard API: username/password for the Ceph Manager Dashboard REST API
• Connects via the Ceph Dashboard URL (typically port 8443)

What Gets Collected

• Config (tracked): Cluster health status, CRUSH map, pool configuration, OSD class and weight, daemon versions
• Metrics (not tracked): Capacity usage, IOPS, throughput, OSD utilization percentages

Health Dashboard Integration

The Ceph collector feeds the Ceph Health Widget on the Parascope dashboard, showing cluster health status and capacity at a glance.

Key Relationships

• OSDs member_of Cluster
• Monitors member_of Cluster
• Hosts member_of Cluster
• Pools member_of Cluster

PostgreSQL Collector

The PostgreSQL collector discovers database infrastructure, schemas, and configuration across one or more PostgreSQL servers.

CI Types Discovered

Authentication

• Connection string: standard PostgreSQL connection parameters (host, port, database, user, password)
• Read-only access is sufficient for collection

Monitoring role and privileges

The collector only ever reads, but a few resource types need privileges a plain application user usually lacks:

• Replication slots (postgresql.replication_slot) require pg_monitor (or the REPLICATION attribute) to read pg_replication_slots.
• Cross-database introspection (schemas, tables, indexes, extensions in every database) requires CONNECT on each target database.
• Full role detail benefits from pg_monitor, which exposes restricted system views without granting write access.

If those privileges are missing, the affected query is rejected as an insufficient-privilege error and that resource type is simply skipped on each cycle. Collection keeps running, but it quietly undercollects with no obvious signal. To get full coverage, provision a dedicated least-privilege monitoring role rather than connecting as a superuser or the application user:

-- Create a dedicated, login-capable monitoring role.
CREATE ROLE parascope_monitor WITH LOGIN PASSWORD 'change-me';

-- pg_monitor is a built-in role that grants read access to restricted
-- statistics/config views (incl. replication slots) WITHOUT any write access.
GRANT pg_monitor TO parascope_monitor;

-- Allow connecting to each database you want introspected (repeat per database).
GRANT CONNECT ON DATABASE app_db TO parascope_monitor;

pg_monitor is preferred over a superuser because it is read-only by construction: the collector can never modify data or configuration. Point the collector's credentials at this role.

What Gets Collected

• Config (tracked): Server version, configuration parameters, database sizes, table structures, installed extensions, replication config
• Metrics (not tracked): Connection count, transaction rates, cache hit ratios

Multi-Server Support

Configure multiple PostgreSQL servers as separate sources, each with independent credentials and health tracking.

Key Relationships

• Databases is_contained_by Servers
• Schemas is_contained_by Databases
• Tables is_contained_by Schemas

Prometheus Collector

The Prometheus collector discovers monitoring infrastructure from Prometheus servers: what targets are being monitored and what alerting rules are configured.

CI Types Discovered (4)

Authentication

• HTTP: Prometheus API (typically unauthenticated or via reverse proxy)

What Gets Collected

• Config (tracked): Server configuration, target endpoints and labels, rule definitions and expressions
• Metrics (not tracked): Target scrape duration, sample counts

Key Relationships

• Targets member_of Instance
• Rules member_of Instance
• Instance sends_alerts_to Alertmanager

Grafana Collector

The Grafana collector discovers dashboards and data sources from Grafana instances.

CI Types Discovered (3)

Authentication

• API Key: Grafana API key or service account token with viewer permissions

What Gets Collected

• Config (tracked): Dashboard titles, folder organization, panel configurations, data source types and connection details
• Metrics (not tracked): Dashboard view counts

Key Relationships

• Dashboards member_of Instance
• Datasources member_of Instance

OpenBao Collector

The OpenBao collector discovers secret management infrastructure from OpenBao instances, with a focus on PKI certificate tracking.

CI Types Discovered (5)

Authentication

• OpenBao Token: read-only access to sys/mounts, sys/auth, and PKI engine paths

Key Features

• PKI Certificate Tracking: Monitors issued certificates and their expiration dates
• Secret Engine Inventory: What secret engines are enabled and how they are configured
• Auth Method Discovery: What authentication methods are available

Key Relationships

• Secret Engines member_of Server
• Auth Methods member_of Server
• PKI Roles is_contained_by Secret Engines
• PKI Certificates issued_by PKI Roles

Backstage Collector

The Backstage collector discovers service catalog entities from Backstage instances, providing visibility into your software catalog alongside your infrastructure.

CI Types Discovered (4)

Authentication

• Backstage API: Bearer token or unauthenticated access depending on your Backstage configuration

What Gets Collected

• Config (tracked): Component metadata, ownership, lifecycle stage, system membership, API specifications
• Relationships: Components member_of Systems, Systems member_of Domains, Components provides APIs

Keycloak Collector

The Keycloak collector discovers identity and access management configuration from Keycloak instances.

CI Types Discovered (5)

Both realm roles and client roles are collected. A client role is named {clientId}/{role}, for example my-app/admin, so a client's admin never collides with the realm's own admin. Realm roles keep their bare name.

Authentication

• Keycloak Admin API: Admin credentials or service account token

What Gets Collected

• Config (tracked): Realm settings, client configurations, group hierarchy, role assignments, user attributes
• Relationships: Clients member_of Realms, Roles member_of Realms, Groups member_of Realms, Users member_of Groups, Groups has_role Roles

DNS Collector

The DNS collector discovers DNS zones and records from a range of DNS sources. The source type is configured per source; supported sources are:

• CoreDNS: via zone transfer (AXFR); requires an explicit list of zones
• BIND: via zone transfer (AXFR); requires an explicit list of zones
• AWS Route53: via the AWS SDK; auto-discovers all hosted zones
• Infoblox: via the WAPI REST API; auto-discovers all authoritative zones
• Active Directory DNS: via LDAP; auto-discovers AD-integrated zones from the directory's DNS partition

CI Types Discovered

Authentication

Authentication depends on the configured source type:

• CoreDNS / BIND: zone transfer (AXFR) from the authoritative server; access is controlled by the server's allow-transfer ACL
• Route53: AWS credentials (access key/secret or an assumed role)
• Infoblox: WAPI username and password
• Active Directory DNS: domain controller credentials for an LDAP bind (NTLM or simple, over LDAPS)

What Gets Collected

• Config (tracked): Zone names, SOA records, record types and counts, DNSSEC configuration
• Zone records (A, AAAA, CNAME, MX, TXT, SRV, etc.) are tracked within the zone CI

Key Features

• FQDN Enrichment: DNS data enriches other CIs with hostname/FQDN information, enabling lookup of infrastructure by DNS name
• Zone Change Tracking: Detect when DNS records are added, modified, or removed

Related Documentation

• Managing Collectors: Collector health and configuration
• OS Collection: Agentless operating system discovery
• CI Types: Complete CI type reference