Health Monitoring
The tunnel hosts report to New Relic through the New Relic Infrastructure agent installed on the AMI, and they keep the CloudWatch surface that every AWS resource has by default. This is a deliberate, ADR-backed choice: the platform convention (adventive-platform-infra CLAUDE.md §5) is that AWS resources use CloudWatch and New Relic arrives through the account-level AWS integration, with no per-host wiring. For the tunnel, the backbone between the Cloudflare edge and the private AWS network, the signal that matters most is fast detection of the cloudflared process dying, so the agent is added on the hosts. The decision and the deviation are recorded in the ADR and the repo OVERRIDES.md.
What runs on the host
Section titled “What runs on the host”The New Relic Infrastructure agent (newrelic-infra) is installed by the adv-cflared-newrelic Image Builder component and started at boot. It does not carry a baked-in key: cflared-bootstrap.service reads the license key from Secrets Manager (/adventive/newrelic/license-key) and writes /etc/newrelic-infra.yml with the key, enable_process_metrics: true, and adv_env / adv_role custom attributes. That gives host metrics (CPU, memory, disk, network) and process samples, so a crashed cloudflared is visible as its process disappearing from the host. The CloudWatch agent is already on the AMI from the AWS-managed component and is retained unchanged.
The agent runs as its own newrelic-infra.service, independent of cloudflared.service. It does not touch the cloudflared unit, its Restart=on-failure policy, the bootstrap, or the ASG health check, so it has no effect on self-heal (see Architecture).
Metrics available today
Section titled “Metrics available today”| Source | Metric | Purpose |
|---|---|---|
| New Relic SystemSample | CPU, memory, disk, network | Host health and capacity |
| New Relic ProcessSample | cloudflared process presence | Daemon crashed (process disappears) |
| CloudWatch | EC2 status checks, host metrics | AWS-native surface, ASG health |
cloudflared exposes a Prometheus endpoint at 127.0.0.1:2000/metrics (enabled in the rendered config.yml), including cloudflared_tunnel_ha_connections. Scraping that into New Relic is a tracked follow-up: nri-prometheus is Docker and Kubernetes only, so the scrape will be added with nri-flex or the New Relic Prometheus agent, verified against the live endpoint, in a later component revision.
Alerting
Section titled “Alerting”New Relic alerting on the host and process signals (a NRQL condition on the cloudflared process sample dropping to zero, and host CPU/memory) is provisioned in New Relic once the tunnel-connection metric lands, so a single policy covers process presence and connection count together. Until then, the Cloudflare Zero Trust dashboard is the authoritative view of tunnel-connector health at the edge, and the ASG plus systemd self-heal (see Architecture) act without depending on any alert.
Current state
Section titled “Current state”| Layer | Development | Staging / Production |
|---|---|---|
| CloudWatch agent (AWS-managed component) | On the AMI | On the AMI |
| New Relic Infra agent (host + process) | Deployed on the dev host | Ships in the same AMI |
| New Relic host reporting | Verify appears under Infrastructure | Same |
| cloudflared Prometheus scrape into New Relic | Follow-up | Follow-up |
| New Relic alert policy | Follow-up (with the scrape) | Follow-up |