How QUARK works

QUARK sits on top of your existing NetOPS deployment. It requires no additional agents: everything QUARK knows comes from telemetry NetOPS is already collecting.

Architecture

NetOPS ──▶ Ingestion ──▶ Correlation engine ──▶ Findings & recommendations
 (metrics, events,        (topology, baselines,
  alerts, inventory)       dependency graph)

1. Ingestion

QUARK connects to the Netwatch server through its API and continuously streams:

• Metrics — every item history NetOPS collects (CPU, memory, disk, interfaces, application checks).
• Events and alerts — trigger state changes, with severity and acknowledgment status.
• Inventory and topology — hosts, host groups, and discovered relationships between devices.

Ingestion is read-only. QUARK never modifies your monitoring configuration.

2. Baselines

For every metric, QUARK learns what "normal" looks like — per host, per time of day, per day of week. Baselines are seasonal, so Monday-morning login storms and nightly backup windows don't produce false anomalies.

3. The correlation engine

When something deviates, QUARK doesn't evaluate it in isolation. The correlation engine asks:

• What else changed in the same time window?
• Are the affected hosts related — same host group, same network segment, same upstream dependency?
• Has this pattern occurred before, and what was the cause then?

The output is a finding: one coherent story ("Storage latency on the SAN is degrading disk wait times on 14 VMs in cluster A") instead of 14 separate alerts.

4. Recommendations

Each finding is matched against QUARK's remediation knowledge and your environment's context to produce recommended actions. Recommendations are suggestions — QUARK does not change your systems.

Deployment

QUARK runs as a managed service connected to your NetOPS deployment, or on-premises alongside the Netwatch server for air-gapped environments. Ask your Netwatch contact which model fits your deployment.

Data handling

• Telemetry is processed for your tenant only and is never used to train shared models.
• On-premises deployments keep all data inside your network.
• All NetOPS API access is scoped to a dedicated read-only service account you control.