Infrastructure Observability
Hosts and process groups
Full-stack OneAgent monitors the OS (CPU, memory, disk, network) and deep-monitors processes; infrastructure-only monitoring covers the OS without deep code monitoring; discovery mode only inventories. Host groups apply consistent settings and tagging across a fleet, and network zones control which ActiveGate an agent talks to - the usual answer for firewall-constrained topologies. OS service monitoring watches systemd/Windows services.
Kubernetes
Three deployment shapes appear in questions. Application-only (operator, OneAgent pods injected per workload namespace) is the default and cheapest. Full-stack grants the operator privileged node access for node and OS-level visibility. Cloud-native full-stack injects code modules without privileged nodes - the right answer for managed clusters where node access is unavailable. The Kubernetes app surfaces workload, node, and cluster health and events.
Clouds, devices, and custom metrics
Cloud integrations pull AWS/Azure/GCP service metrics and tags; Extensions 2.0 (EF2) run on ActiveGate to poll SNMP, JMX, databases, and other endpoints. Custom metrics arrive via the metrics ingest API (StatsD, Telegraf, Prometheus scrape). Anomaly detectors and alerting profiles turn these into problems.
Worked rule of thumb
Ask where does the collector run? If the answer requires reaching into a private network - SNMP device, database, JMX - the extension belongs on an ActiveGate in that network, not on every OneAgent. If the question says "we cannot SSH into the nodes," choose cloud-native full-stack.
Trap: ActiveGate is not a metric source for host CPU; only OneAgent (or an integration/extension) produces that.