---
title: New Relic
slug: telemetry-pipeline/new-relic
docTags: 
createdAt: 2025-04-21T01:01:52.321Z
---

# New Relic Sink 

The **New Relic** sink delivers **logs and metrics** from worker into New Relic using New Relic’s ingest APIs. This guide explains **what each parameter does** and how it affects reliability, performance, and operations.

## Core Identification and Routing

### account\_id (required)

The New Relic account identifier that receives the data.

Operational impact:

- Wrong account ID routes data to the wrong tenant or causes ingest rejection. 
- Treat as a controlled value and ensure it aligns with the target environment (dev vs prod). 

### region (optional)

Selects the New Relic region for ingestion.

Options typically include:

- **us:** US region 
- **eu:** EU region 

Operational impact:

- Region controls which ingest endpoint is used. 
- Wrong region commonly results in authentication failures or data not appearing where expected. 

## API Selection

### api (required)

Chooses which New Relic API is used for ingestion.

Options:

- **events:** Events API (general event ingestion) 
- **logs:** Logs API (log-specific ingestion pipeline) 
- **metrics:** Metrics API (metric ingestion pipeline) 

Operational impact:

- This setting determines: 
  - Which data model New Relic expects 
  - How events are interpreted and indexed 
  - Which features are available downstream (log search vs metric charts vs event queries) 

Important note:

- Sending logs to a metrics API (or vice versa) will typically result in partial loss, rejection, or incorrect representation. 

## Authentication

### license\_key (required)

New Relic license key used to authenticate ingestion requests.

Operational impact:

- Invalid/revoked keys lead to sustained ingestion failures and buffer growth. 
- Keys are sensitive secrets: ensure they are protected and rotated according to policy. 

##

## Batching

### batch (optional)

Controls how events are grouped into outgoing requests.

Why it matters:

- Batch settings directly trade off throughput, latency, memory usage, and “blast radius” of retries. 

batch.max\_bytes (optional, default: 1,000,000 bytes)

Maximum uncompressed payload size before a batch is flushed.

Operational impact:

- Larger values reduce HTTP overhead but can increase failure impact and retry payload size. 
- Very large payloads may hit gateway limits and get rejected. 

batch.max\_events (optional, default: 100)

Maximum number of events per batch.

Operational impact:

- Higher values improve throughput efficiency. 
- Lower values reduce latency and reduce the amount of data retried if a request fails. 

batch.timeout\_secs (optional, default: 1 second)

Maximum batch age before flushing.

Operational impact:

- Lower values reduce latency (faster visibility in New Relic). 
- Higher values increase batching efficiency at low event rates. 

## Buffering and Backpressure

### buffer (optional)

Controls how worker queues events while New Relic is slow/unreachable.

buffer.type (optional, default: memory)

- **memory:** faster, but data is lost on crash/restart 
- **disk:** more durable across restarts, but slower and requires disk sizing 

buffer.max\_size (required)

Hard cap on buffer usage.

Operational impact:

- Too small → frequent backpressure/drops during outages 
- Too large → long recovery bursts and higher resource usage 

buffer.max\_events (optional; memory only, default: 500)

Limits buffered event count (memory mode).

Operational impact:

- Protects against unbounded event accumulation when event sizes vary. 

buffer.when\_full (optional, default: block)

Behavior when the buffer is full:

- **block:** backpressure upstream (best for lossless pipelines) 
- **drop\_newest:** drop incoming events (best when continuity > completeness) 

## Compression

### compression (optional, default: gzip)

Controls request payload compression.

Supported values include:

- gzip, snappy, zlib, zstd, or none 

Operational impact:

- Compression reduces bandwidth and can improve ingestion reliability over constrained links. 
- Compression increases CPU usage; the trade-off becomes visible at very high throughput. 

## Event Preparation Controls (Field Inclusion/Exclusion)

### encoding (optional)

Controls which fields are included in outbound payloads and how timestamps are formatted.

encoding.only\_fields (optional)

- Sends only the specified fields. 
- Useful to reduce payload size, limit sensitive data, and enforce a stable schema. 

encoding.except\_fields (optional)

- Excludes specified fields. 
- Useful for redacting secrets, PII, or noisy fields. 

encoding.timestamp\_format (optional)

Controls how timestamp fields are rendered:

- RFC3339 or various Unix timestamp precisions (seconds, ms, us, ns) 

Operational impact:

- Incorrect timestamp formatting can cause: 
  - ingestion rejection 
  - incorrect event ordering 
  - misleading dashboards (events appear “in the future” or far in the past) 

## Proxy

### proxy (optional)

Routes outbound HTTP requests through HTTP(S) proxies.

proxy.enabled (optional, default: true)

Enables proxy support.

proxy.http / proxy.https (optional)

Proxy endpoints for HTTP and HTTPS traffic.

Operational impact:

- Required in restricted egress environments. 
- Proxy misconfiguration often looks like timeouts and persistent retries. 

proxy.no\_proxy (optional)

List of hosts that should bypass the proxy.

Operational impact:

- Useful when New Relic endpoints should be direct while other traffic is proxied, or vice versa. 
- Misconfigured no\_proxy can cause inconsistent behavior across environments. 

## Request Behavior (Concurrency, Rate Limits, Retries, Timeouts)

### request (optional)

Controls reliability and performance of outbound HTTP calls. Backoff follows a Fibonacci pattern.

request.concurrency (optional, default: adaptive)

- **none:** concurrency fixed at 1 (predictable, lower throughput) 
- **adaptive:** automatically adjusts concurrency based on observed latency 

Operational impact:

- Adaptive increases throughput and can recover faster, but may oscillate if the endpoint is unstable. 

request.rate\_limit\_num / request.rate\_limit\_duration\_secs

Rate limiting for outbound requests.

Operational impact:

- Protects the upstream ingest endpoint and your own egress bandwidth. 
- If too restrictive, backlog increases and end-to-end latency grows. 

request.retry\_attempts (optional)

Maximum retries for failed requests.

Operational impact:

- High values improve survivability during outages but increase duplicate risk (at-least-once). 
- Very high values can create long retry tails and sustained backlog. 

request.retry\_initial\_backoff\_secs (default: 1)request.retry\_max\_duration\_secs (default: 30)request.retry\_jitter\_mode (default: Full)

Controls retry backoff timing and randomization.

Operational impact:

- Jitter reduces synchronized retry bursts across many agents. 

request.timeout\_secs (default: 60)

Maximum time an HTTP request can run.

Operational impact:

- Too low can create “orphaned requests” and increase duplicates due to retries. 
- Too high can tie up concurrency slots and slow recovery. 

### Adaptive Concurrency Fine Tuning (Advanced)

Parameters under request.adaptive\_concurrency (decrease\_ratio, ewma\_alpha, initial\_concurrency, max\_concurrency\_limit, rtt\_deviation\_scale) rarely need changes.

Operational warning:

- Incorrect tuning can cause unstable throughput and meta-stable behavior.