New Relic Integration

MTE Relay v5 emits structured JSON logs (see the Event Schema Reference). New Relic automatically parses each line and flattens the nested event objects into dotted attributes (performance_event.total_time_ms, security_event.severity, …) — no parsing rules are required. This guide ships logs to New Relic and imports the prebuilt dashboard and alert policy.

Artifacts

File	Purpose
mte-relay-v5-dashboard.json	Importable two-page dashboard (Traffic & MTE Performance, Security & Errors)
mte-relay-v5-alerts.json	Recommended alert policy + five NRQL conditions

1. Ship the logs

MTE Relay writes all logs to stderr as one JSON object per line. Keep USE_CONSOLE_LOGS=false (the default) wherever New Relic ingests logs.

Kubernetes / AKS (newrelic-logging Helm chart)

helm repo add newrelic https://helm-charts.newrelic.com
helm install newrelic-logging newrelic/newrelic-logging \
  --set licenseKey=<YOUR_INGEST_LICENSE_KEY>

The chart tails all container stdout/stderr; relay lines arrive pre-tagged with Kubernetes metadata and are JSON-parsed automatically.

Docker / VM (Fluent Bit with the New Relic output)

[INPUT]
    Name              tail
    Path              /var/lib/docker/containers/*/*.log
    Parser            docker

[OUTPUT]
    Name              newrelic
    Match             *
    licenseKey        <YOUR_INGEST_LICENSE_KEY>

Or run the Infrastructure agent with a logs: forwarding block pointed at the container log files.

ECS / logs already in CloudWatch

Use New Relic's AWS log forwarding — either the Kinesis Firehose destination or the newrelic-log-ingestion Lambda — subscribed to the relay's CloudWatch log group. No changes to the relay task are needed.

Timestamps

New Relic uses its own ingest timestamp unless a timestamp attribute (epoch ms) is present. The relay emits time (RFC3339); ingest-time ordering is normally indistinguishable in practice. If you require exact source timestamps, add a Fluent Bit filter that copies time to timestamp.

2. Verify attributes

In Logs → Query logs, run:

SELECT count(*) FROM Log WHERE service = 'mte-relay' FACET `performance_event.event_type` SINCE 30 minutes ago

You should see request_timing and phase_breakdown. The useful attributes:

• Identity: service, product (mrs|mar), relay_version, instance, correlation_id
• Performance: performance_event.* (total/decryption/validation/proxy/encryption ms, status_code, byte counts)
• Security: security_event.* (event_type, severity, origin, reason)
• Audit: encryption_event.* (mte_type, timing, payload hashes)
• Errors: error_event.* (event_type, stack_trace)

3. Import the dashboard

Dashboards → Import dashboard, paste mte-relay-v5-dashboard.json. The import dialog substitutes your account ID for the 0 placeholders (or replace "accountIds": [0] before pasting).

4. Create the alert policy

mte-relay-v5-alerts.json describes one policy and five NRQL conditions:

Condition	Fires when
High/critical security event	Any high/critical security_event in 5 min
Handler panic recovered	Any error_event.event_type = 'panic' in 5 min
State store persistence failures	> 5 state_save_failed/state_not_found in 10 min
Elevated request latency	Avg total_time_ms > 500 ms for 10 min (tune)
Client pair exhaustion spike	> 50 client_pairs_exhausted in 15 min (tune)

Create the policy in Alerts → Alert policies → New policy, then add each condition as an NRQL condition using the nrql and threshold values from the file (they map 1:1 onto the condition form fields). Attach your notification workflow/destination to the policy.

Cost control

Per-request performance events dominate ingest volume. On high-traffic deployments set PERF_EVENT_SAMPLE_PERCENT=10 on the relay — rates and percentiles remain statistically sound. Security, error, and encryption-audit events are never sampled.