Every monitoring setup starts with a fundamental choice: install software on the thing you’re watching (agent-based), or query it from outside (agentless). The answer is almost always “both, for different things” — but understanding the trade-offs prevents architecture mistakes that are painful to unwind later.
How each approach works
Agent-based monitoring
A small daemon (the “agent”) runs on each monitored host — server, VM, container, Kubernetes node. It collects metrics locally (CPU, memory, disk, network, processes, containers, application-specific data) and sends them to a central backend over an outbound connection.
Examples: Datadog Agent, Prometheus node_exporter, Zabbix agent, Netdata agent, Elastic Metricbeat, New Relic infrastructure agent.
The data pipeline: Host → Agent collects metrics locally → Agent pushes (or backend scrapes) → Central storage → Dashboards + alerts.
Agentless monitoring
The monitoring system queries targets remotely — via SNMP (network devices), WMI (Windows), SSH (Linux), cloud provider APIs (CloudWatch, Azure Monitor), or HTTP (status endpoints, synthetic checks). Nothing is installed on the target.
Examples: SNMP polling in PRTG or Zabbix, AWS CloudWatch metrics, external uptime checks, Checkmk’s agentless discovery mode.
The data pipeline: Central monitor → Polls/queries target remotely → Central storage → Dashboards + alerts.
The trade-offs
| Factor | Agent-based | Agentless |
|---|---|---|
| Data depth | Deep — per-process, per-container, per-core, custom app metrics | Shallow — service-level, interface-level, what the protocol exposes |
| Data frequency | High — per-second possible (Netdata), 10–60s typical | Lower — typically 60–300s (SNMP polling, API polling) |
| Deployment effort | Moderate — install and maintain agent on every host | Low — configure from the central monitor |
| Maintenance | Agent upgrades, compatibility across OS versions | Credential management, network access rules |
| Network dependency | Agent works through firewalls (outbound push) | Requires inbound access or API connectivity |
| Resource overhead | 1–2% CPU, 50–150 MB RAM (typical modern agent) | Zero on the target; polling load on the monitor |
| Works on managed services | No — you can’t install agents on RDS, Lambda, S3 | Yes — via cloud provider APIs |
| Works on network devices | Rarely — switches/routers don’t run custom software | Yes — SNMP is the standard |
When to use each
Use agent-based when:
- You control the host (your servers, VMs, containers, Kubernetes nodes).
- You need deep visibility — per-process CPU, container-level metrics, application traces, custom metrics.
- Hosts are behind firewalls that block inbound connections — agents push outbound.
- You want high-frequency collection (sub-minute) for real-time dashboards.
Use agentless when:
- You’re monitoring cloud-managed services (RDS, Lambda, S3, Azure SQL, GKE) — no host to install on.
- You’re monitoring network devices (switches, routers, firewalls) — SNMP is the only option.
- You’re monitoring targets where you can’t install software (customer environments, third-party services, legacy appliances).
- You want external validation that services are reachable — uptime monitoring and synthetic checks are inherently agentless.
The common hybrid pattern
Most production environments use both:
| Target | Approach | Tool example |
|---|---|---|
| Application servers (Linux/Windows) | Agent-based | Datadog Agent, node_exporter, Zabbix agent |
| Kubernetes clusters | Agent-based (DaemonSet) | Prometheus + kube-state-metrics |
| AWS managed services (RDS, Lambda) | Agentless (CloudWatch API) | CloudWatch → Grafana, Datadog AWS integration |
| Network switches/routers | Agentless (SNMP) | Zabbix, PRTG |
| External availability | Agentless (HTTP checks) | Pingdom, Checkly |
| Third-party APIs | Agentless (API checks) | Synthetic monitors, custom scripts |
The OpenTelemetry factor
OpenTelemetry (OTel) is the CNCF-standard, vendor-neutral instrumentation framework — and the biggest shift in agent-based monitoring in years. Instead of installing a Datadog agent, a New Relic agent and a Prometheus exporter, you install the OTel Collector once and route telemetry (metrics, logs, traces) to any compatible backend.
Why this matters:
- Reduced lock-in — switch monitoring vendors without re-instrumenting your applications.
- Single agent — one collector replaces multiple vendor-specific agents.
- Industry direction — Datadog, New Relic, Dynatrace, Grafana, Elastic and Splunk all accept OTel data. Building on OTel today is a safe long-term bet.
The trade-off: OTel is still maturing (logs support reached stable in 2024, but vendor-specific features like Datadog’s eBPF process visibility aren’t available through OTel). For new projects, start with OTel. For existing estates with vendor agents already deployed, migration is a gradual process, not a weekend project.
How to decide for your environment
- Inventory your targets. Hosts you own → agent-based. Managed services and network devices → agentless. This usually gives you the split.
- Pick a primary agent. Datadog Agent (managed), Prometheus node_exporter (open-source), Zabbix agent (traditional) — or the OTel Collector for vendor neutrality. See our tool comparison.
- Don’t run multiple agents for the same data. A Datadog Agent and a node_exporter both collecting CPU metrics is wasted overhead. One agent, one source of truth per metric type.
- Plan for maintenance. Agent upgrades, OS compatibility, container image rebuilds — factor this into your operational model. Agentless reduces this burden but at the cost of data depth.
Bottom line
Agent-based monitoring gives you the deepest visibility on hosts you control. Agentless monitoring is essential for cloud services, network devices and external validation. The question isn’t which approach to choose — it’s which targets get which approach. In 2026, OpenTelemetry is narrowing the gap by offering a single, vendor-neutral agent that feeds any backend, making the agent choice less permanent than it used to be.