Infrastructure Monitoring
Infrastructure Monitoring
Questions here test how host, cloud, and Kubernetes telemetry reaches New Relic and how to query and control it.
Core rules
- The infrastructure agent is a single binary installed on a host. It reads newrelic-infra.yml (license key, proxy, log forwarding, custom attributes) and writes samples such as SystemSample, ProcessSample, StorageSample, and NetworkSample.
- On-host integrations (nginx, MySQL, Apache, Redis, Kafka, and others) live in the integrations.d directory and add their own event types and metrics.
- Cloud integrations collect AWS, Azure, and GCP metrics either by polling APIs or, preferred for AWS, CloudWatch Metric Streams, which push with lower latency; running both duplicates ingest and cost.
- Kubernetes monitoring uses the nri-kubernetes integration and the cluster explorer; Pixie adds eBPF-based in-cluster depth without code changes.
- Prometheus and OpenTelemetry sources are ingested through the Prometheus integration or an OTel collector, arriving as dimensional Metric data whose attributes drive FACET and filtering.
- Custom attributes become queryable tags; include/exclude filters and drop rules control ingest volume.
Worked example
Hosts show no CPU data for one node. Running NRQL FROM SystemSample SELECT average(cpuPercent) FACET hostname returns nothing for that host, so the problem is collection, not the query: verify the agent service is running, the license key and region are correct, the host can reach the collector endpoint, and any proxy setting in the agent config is valid. If other hosts appear, the integration itself is fine.
Traps
- Assuming the infrastructure agent ships logs by default; log forwarding needs explicit configuration.
- Faceting on the wrong attribute, or using a legacy event type when cloud integrations produce dimensional Metric data.
- Double-ingesting the same cloud metrics via both API polling and metric streams.
- Treating Kubernetes pod metrics as host metrics; they come from different event types.