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 — with 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)

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

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