Ozone Data Collector
The Ozone Data Collector is a single-tenant virtual appliance that runs inside the customer network, collects telemetry from local devices, and forwards a curated subset to the Ozone Orchestrator (ozone.techforcz.com) over one outbound HTTPS connection. This section takes the appliance from a downloaded OVA to a registered, polling collector: sizing, install, firewall, proxy, and enrolment, each as its own guide. The full catalog of what it can talk to lives in Collection Methods & Protocols.
The collector in one paragraph
It dials out only, so no inbound port is ever opened for the Orchestrator. It bundles its own datastores (SQLite for state, VictoriaMetrics for metrics, Redis for cache) and message bus (NATS JetStream), so it keeps polling, correlating, and alerting locally even when the WAN link is down, and buffered telemetry replays on reconnect. It speaks 63 onboarding methods across 10 device categories through a single plugin-based universal collector, not a fleet of per-protocol containers. The full two-tier model is in Platform Architecture, and the security of the outbound channel is in Security & Compliance.
Everything the appliance receives normalizes to one telemetry envelope, then flows through a fixed local pipeline before anything is forwarded. The stages below all run on-prem, so the appliance keeps working when the WAN is down.
The appliance bundles its own stores (SQLite for state, VictoriaMetrics for metrics, Redis for cache) over a NATS JetStream bus, so nothing here depends on the cloud. Notifications and tickets are delivered locally by the collector's Integrations, and only aggregated counts and enriched problems ever leave the network through saas-sync.
What is new on the edge
Recent releases add operator-facing controls that used to live only in the SaaS:
- Config backup and compliance. A
netshot-syncservice bridges to Netshot for network config backup and drift compliance, and mirrors config-change events onto NATS so the correlation engine can fold "config changed 12 minutes before the alert storm" into a problem statement. - Audit trail and RBAC. Every WebUI action is written to an append-only SQLite audit log (
GET /api/v1/audit, with CSV and PDF export), and the frontend derives the operator role from the JWT to gate actions. - Break-glass login. A locally signed admin token (
POST /api/v1/saas/breakglass-login) lets an operator into the WebUI during a full SaaS outage, so the appliance stays usable when the WAN is down. - Advisory auto-remediation. The problem engine can dispatch remediation suggestions (escalate, bounce a flapping port after approval, and so on). It ships advisory only: active execution stays off until an operator opts in.
- Web hardening. The WebUI nginx sets HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and Permissions-Policy, and is the same-origin reverse proxy for every
/api/v1/*service.
Host footprint at a glance
| Resource | Baseline | Driven by |
|---|---|---|
| vCPU | 4 | device count + collection cadence |
| RAM | 8 GB | VictoriaMetrics + NATS + Redis |
| Disk | 100 GB+ SSD | local retention (metrics 30d, logs/flows) |
| OS | Ubuntu 22.04 LTS (inside OVA) | shipped image, not host-managed |
| Egress | 443/TCP to ozone.techforcz.com | registration, heartbeat, ingest |
State lives in SQLite (roughly 15 databases, one per subsystem) on a host bind mount at AIOPS_DATA_DIR (default /opt/aiops/data), not a Docker named volume, so it survives rebuilds, volume prune, and system prune. Detailed sizing and growth math are in Installation, sizing.
The design thesis is "0 Postgres/Keycloak dependencies, 1 outbound egress path." The collector uses SQLite only, has no PostgreSQL and no Keycloak, and reaches the Orchestrator through exactly one HTTPS path. That is what makes the appliance easy to run in a locked-down customer environment.
Deployment journey
Follow these in order. Each is a standalone guide.
| Step | Guide | What you do |
|---|---|---|
| 1 | Installation | Size the host, import the OVA, cold-boot, confirm the single-stack rule |
| 2 | Firewall & Network | Open outbound 443 to the Orchestrator, allow DNS/NTP, expose device-facing LAN ports |
| 3 | Outbound Proxy | Route egress through a forward proxy, handle TLS interception and authentication |
| 4 | Enrolment & Verification | Register with a one-time token, run the 16-check diagnostics, confirm fleet visibility |
Once the appliance is enrolled, onboard devices from the Collection Methods & Protocols catalog: it covers the 63 methods, the receiver ports, the SNMPv3 matrix, and the 4-step onboarding wizard.
When something is wrong
Edge faults (network drops, buffer growth, TLS handshake failures, services down) are triaged in Collector Troubleshooting, which also carries the step-by-step operator runbook.