Running the Collector
The radar-collector supports multiple operational modes:
First-Run Activation
When the collector starts with the default config path (radar-collector.yml) and that file does not exist, it automatically enters a browser-based activation flow (unless a stored credential already exists from a previous activation). This connects the collector to your Radar account without manual configuration.
# First run - auto-activates if default config file is missing and no stored credential
./radar-collector
# Explicit activation
./radar-collector connect
# Activation without browser (prints URL to terminal)
./radar-collector connect --no-browser
After activation, the collector stores its credential locally and begins collecting. On subsequent runs, the stored credential is reused automatically.
Continuous Mode (Production)
Standard production mode - continuously collects metrics and submits to server.
# Default configuration file (radar-collector.yml)
./radar-collector
# Custom configuration
./radar-collector --config /etc/radar/production.yml
# With debug logging
RUST_LOG=debug ./radar-collector
Behavior:
- Collects from all configured deployments at specified intervals
- Automatically submits data to Radar server via gRPC
- Runs continuously until stopped with SIGTERM/SIGINT
- Gracefully completes current collection before shutdown
- If remote config is enabled (default), deployments can be managed from the Radar server
Use when:
- Running in production environments
- Deployed as systemd service or Kubernetes pod
- Continuous monitoring is required
Offline Mode
Collect data to local files for manual inspection before submission.
Collect to File
# Auto-generated filename (includes hostname, version, timestamp)
./radar-collector --once --output-file
# Creates: radar-collection-hostname-v0.1.0-20251014-120000.json
# Custom path
./radar-collector --once --output-file /var/lib/radar/collection.json
Redaction
Redaction is controlled by collector.redact in your config file (default: true).
When enabled, the collector redacts:
- Passwords and API keys (
***REDACTED***) - Hostnames (deterministic hashing)
- IP addresses (
192.xxx.xxx.xxx) - Port numbers (masked as numeric
0)
To disable, set in your config:
collector:
redact: false
When disabled, data is written/submitted as collected.
Submit Collected Data
# Submit previously collected file
./radar-collector submit --file radar-collection-hostname-v0.1.0-20251014-120000.json
# With custom server config
./radar-collector --config production.yml submit --file collection.json
Use when:
- Air-gapped environments requiring manual file transfer
- Security reviews needed before cloud submission
- Compliance workflows require approval process
- Local debugging and analysis
Test Mode
Test single deployment without affecting production monitoring.
# Collect and submit once
./radar-collector test --deployment redis-prod
# Collect without submitting (dry run)
./radar-collector test --deployment redis-prod --dry-run
# With debug output
RUST_LOG=debug ./radar-collector test --deployment software-cluster
Behavior:
- Collects from specified deployment once
- Shows collected data (in dry-run mode)
- Exits after single collection
- Does not affect other deployments
Use when:
- Testing new deployment configuration
- Verifying connectivity before production
- Debugging collection issues
- Validating data format
Validation Mode
Validate configuration and test connectivity without collecting data.
# Validate all deployments
./radar-collector --validate
# Validate specific deployment
./radar-collector validate --deployment redis-prod
Use when:
- First-time configuration setup
- Troubleshooting connection issues
- Verifying credentials
- Pre-deployment checks
Additional Options
Logging Levels
Control log verbosity with RUST_LOG:
# Info (default) - standard operational messages
RUST_LOG=info ./radar-collector
# Debug - detailed operational information
RUST_LOG=debug ./radar-collector
# Trace - very verbose, includes all data
RUST_LOG=trace ./radar-collector
Graceful Shutdown
The radar-collector handles SIGTERM and SIGINT signals gracefully:
- Receives shutdown signal
- Stops scheduling new collections
- Completes current collection in progress
- Exits cleanly
# Send graceful shutdown signal
kill -TERM <pid>
# Or use Ctrl+C
^C
Running in Production
For production deployments, see:
- Linux Deployment - Systemd service setup
- Kubernetes Deployment - Container orchestration