Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
225 changes: 225 additions & 0 deletions src/content/docs/ebpf/best-practices.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,225 @@
---
title: eBPF best practices guide
tags:
- New Relic solutions
- Best practices guides
- eBPF
metaDescription: Best practices to help you find problems faster and deliver a better experience to your customers with New Relic's eBPF solution.
freshnessValidatedDate: never
---

eBPF-powered APM (eAPM) uses eBPF technology to provide APM functionality in a single agent with zero code instrumentation. This approach empowers platform engineering teams by eliminating the need for coordination with application teams for monitoring deployment.

## When to use eBPF-powered APM [#when-to-use-eapm]

### Ideal use cases for eAPM

**Large-scale deployments:** When you have many applications that need monitoring deployed at scale and require "good enough" metrics without the overhead of individual language agents.

**Unknown or unmodifiable workloads:** When the workload you want to monitor is written in an unknown programming language and/or cannot be modified.

**Platform engineering efficiency:** When you want to deploy monitoring at scale without coordinating with individual application teams.

**Linux-focused environments:** When you don't need to monitor Windows platforms, as eBPF works excellently on Linux in both Kubernetes and host environments.

**No distributed tracing requirement:** When your monitoring needs don't require distributed tracing capabilities.

## eBPF vs traditional APM comparison [#comparison]

Understanding the differences between eBPF-powered APM and traditional APM agents helps you choose the right approach:

<table>
<thead>
<tr>
<th>Functionality</th>
<th>eBPF agent (eAPM)</th>
<th>APM agent</th>
</tr>
</thead>
<tbody>
<tr>
<td>Summary</td>
<td>✅</td>
<td>✅</td>
</tr>
<tr>
<td>Transaction</td>
<td>✅ (segment linking for Java, Go, Node.js)</td>
<td>✅</td>
</tr>
<tr>
<td>Database operations</td>
<td>✅</td>
<td>✅</td>
</tr>
<tr>
<td>Service map</td>
<td>✅</td>
<td>✅</td>
</tr>
<tr>
<td>Distributed tracing</td>
<td>❌</td>
<td>✅</td>
</tr>
<tr>
<td>Programming language agnostic</td>
<td>✅</td>
<td>❌</td>
</tr>
<tr>
<td>Custom instrumentation</td>
<td>❌</td>
<td>✅</td>
</tr>
<tr>
<td>Auto-discover apps and services continuously</td>
<td>✅</td>
<td>❌</td>
</tr>
<tr>
<td>Deduplicate data ingestion</td>
<td>✅</td>
<td>✅</td>
</tr>
<tr>
<td>Linux support</td>
<td>✅</td>
<td>✅</td>
</tr>
<tr>
<td>Windows support</td>
<td>❌</td>
<td>✅</td>
</tr>
<tr>
<td>TCP and DNS telemetry</td>
<td>✅</td>
<td>❌</td>
</tr>
<tr>
<td>Does not require additional container</td>
<td>✅</td>
<td>❌</td>
</tr>
</tbody>
</table>

### Data source perspective

eBPF-powered APM shifts the monitoring perspective from the application layer to the kernel layer:

<table>
<thead>
<tr>
<th>Feature</th>
<th>APM language agent</th>
<th>eBPF-powered APM</th>
</tr>
</thead>
<tbody>
<tr>
<td>Data source</td>
<td>Application's memory / runtime hooks</td>
<td>Linux kernel (via eBPF)</td>
</tr>
<tr>
<td>Language dependency</td>
<td>High (requires specific agent for each language)</td>
<td>None (operates on kernel's view of process)</td>
</tr>
<tr>
<td>Code modification</td>
<td>Required</td>
<td>Not required (observes process from outside)</td>
</tr>
<tr>
<td>Outcome</td>
<td>Deep insight for known languages</td>
<td>Great insight for any workload on Linux (C++, Rust, etc.)</td>
</tr>
</tbody>
</table>

## Best practices for deployment [#deployment-best-practices]

### 1. Unified monitoring approach

**Single agent for infrastructure and application monitoring:** Plan to use one agent to handle both infrastructure and application monitoring needs.

**Benefits:**
* APM insights that populate New Relic APM UI automatically
* Network insights from the same agent (available November 2025)
* Future capabilities: log collection and database insights

**Result:** Unified APM insight where the agent automatically gathers critical application performance data (eAPM) and network metrics to populate existing APM dashboards, providing deep context without code changes or restarts.

### 2. Supplementing traditional APM

**Coexistence strategy:** Use eBPF agent to supplement APM language agents for comprehensive coverage.

**Recommended approach:**
* **APM language agents:** Handle custom instrumentation needs
* **eBPF-powered APM:** Cover everything else for continuous monitoring and discovering/reporting new services

This gives you full APM coverage with coexistence between eAPM and APM agents, without double data ingestion.

### 3. Network metrics integration

Combine eBPF-powered APM with eBPF Network Metrics for both application and network insights:

**Deployment options:**

<table>
<thead>
<tr>
<th>Application metric source</th>
<th>Network metric source</th>
<th>Configuration</th>
</tr>
</thead>
<tbody>
<tr>
<td>APM language agent</td>
<td>eBPF agent (Network Metrics only mode)</td>
<td>Two agents</td>
</tr>
<tr>
<td>eBPF agent (eAPM)</td>
<td>eBPF agent (same agent)</td>
<td>Single agent</td>
</tr>
</tbody>
</table>

**Advantages:** Provides visibility into network insights outside your application boundary, totally augmenting APM capabilities.

<Callout variant="tip">
**Release status (November 2025):** eBPF-powered APM is generally available, while eBPF Network Metrics is in public preview.
</Callout>

## Implementation recommendations [#implementation-recommendations]

### Choose eBPF over Pixie

We recommend installing eBPF-powered APM in your environment rather than Pixie for better performance and feature set.

### Start with eAPM for scale

If you need to deploy monitoring at scale across many applications and want "good enough" metrics without complex coordination, start with eBPF-powered APM.

### Add Network Metrics for complete visibility

Once eAPM is deployed, consider adding eBPF Network Metrics to gain visibility beyond application boundaries for comprehensive troubleshooting capabilities.

### Plan for future capabilities

The eBPF agent roadmap includes log collection and database insights, making it an increasingly powerful unified monitoring solution.

## Related resources [#related-resources]

* [eBPF overview](/docs/ebpf/overview/) - Understanding eBPF capabilities
* [Linux installation guide](/docs/ebpf/linux-installation/) - Installing on Linux hosts
* [Kubernetes installation guide](/docs/ebpf/k8s-installation/) - Installing on Kubernetes clusters
* [Full-stack observability best practices](/docs/new-relic-solutions/best-practices-guides/full-stack-observability/) - Additional monitoring guidance

35 changes: 35 additions & 0 deletions src/content/docs/ebpf/dashboard.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,35 @@
---
title: "New Relic eBPF Dashboard"
metaDescription: "Learn how to configure New Relic eBPF network monitoring dashboard."
tags:
- Integrations
- eBPF integration
- eAPM
- eBPF Network monitoring
- extended Berkeley Packet Filter (eBPF)
- Linux host
- Kubernetes cluster
freshnessValidatedDate: never
---

The eBPF Network dashboard provides deep visibility into your system's network health by tracking critical DNS and TCP metrics directly from the kernel. You can diagnose connectivity issues by analyzing success and failure rates for DNS resolutions and TCP connections. Pinpoint performance bottlenecks by monitoring key latencies like TCP handshakes, packet delivery, and the duration of short-lived connections. The dashboard also helps you track data throughput by visualizing bytes sent, received, and any packets dropped.

To configure the eBPF network dashboard:

1. Go to **[one.newrelic.com](https://one.newrelic.com) > Dashboards**.
2. In the **Dashboards**, click **+ Create a dashboard**.
3. In the **Create a dashboard** window, click **Browse pre-built dashboards**.
4. In the search bar, type **eBPF** and select the **eBPF**.
5. *(Optional)* In the displayed window, click **Edit** to change the account.
6. Click **Setup eBPF Agent** to setup the data source or click **Skip this step** if the eBPF agent is already setup.
7. Click **View dashboard** to view the data collected by the eBPF agent.

<Callout variant="tip">

The eBPF agent automatically generates entity names differently depending on the environment:

* In hosts or Docker, these names are a combination of the process name, its directory or container ID, and the listening port. For example, `ruby:/home/ubuntu/app:[5678]` or `java:f4aead533895:[8080]`.

* In Kubernetes, these names are derived from the service name for example, `mysql-database-service`.

</Callout>
67 changes: 60 additions & 7 deletions src/content/docs/ebpf/k8s-installation.mdx
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
title: "Install and configure New Relic eBPF integration"
metaDescription: "Learn how to install and configure the New Relic eBPF agent for your Linux host and Kubernetes cluster."
title: "Install and configure New Relic eBPF integration for Kubernetes"
metaDescription: "Learn how to install and configure the New Relic eBPF agent for your Kubernetes cluster using Helm charts."
tags:
- New Relic integrations with eBPF
- New Relic eBPF agent
Expand All @@ -11,18 +11,31 @@ tags:
freshnessValidatedDate: never
---

<Callout title="Preview">
We're still working on this feature, but we'd love for you to try it out!

This feature is currently provided as part of a preview pursuant to our [pre-release policies](/docs/licenses/license-information/referenced-policies/new-relic-pre-release-policy/). It is not available to customers subject to HIPAA or FedRAMP regulations.
</Callout>

You can install the New Relic eBPF agent on your Kubernetes cluster to monitor your entire system health. The eBPF agent provides deep visibility into application performance without requiring code changes or deploying language-specific agents.

## Compatibility and requirements [#requirements]

* Ensure that all [Kubernetes integration compatibility and requirements](/docs/kubernetes-pixie/kubernetes-integration/get-started/kubernetes-integration-compatibility-requirements/) are met.

### Network requirements

To ensure the eBPF agent functions correctly, configure the following network access:

**URL allowlist:**
* `otlp.nr-data.net:4317`
* `otlp.eu01.nr-data.net:4317` (Required only for EU region accounts)
* `https://downloads.newrelic.com`
* `https://nr-downloads-ohai-staging.s3.amazonaws.com`

**Port allowlist:**
* Port 12345
* Port 4317

**Mount path requirements:**
* `/` (root filesystem)
* `/sys` (system filesystem)


## Install the eBPF agent [#install]

Expand Down Expand Up @@ -523,3 +536,43 @@ This section configures secure communication between the eBPF agent and client c
</Collapser>

</CollapserGroup>

## Upgrade the eBPF agent [#upgrade]

To upgrade the eBPF agent in a Kubernetes cluster:

### Standard upgrade
Use the following Helm command to upgrade to the latest version:

```bash
KSM_IMAGE_VERSION="v2.13.0" && helm repo add newrelic https://helm-charts.newrelic.com && helm repo update && kubectl create namespace "newrelic" ; helm upgrade --install nr-ebpf-agent newrelic/nr-ebpf-agent --set licenseKey=<key> --set cluster="<cluster-name>" --namespace=newrelic
```

### Upgrade to a specific version

To upgrade to a specific version, use the `--version` flag:

```bash
KSM_IMAGE_VERSION="v2.13.0" && helm repo add newrelic https://helm-charts.newrelic.com && helm repo update && kubectl create namespace "newrelic" ; helm upgrade --install nr-ebpf-agent newrelic/nr-ebpf-agent --set licenseKey=<key> --set cluster="<cluster-name>" --namespace=newrelic --version=0.2.5
```

Replace `<key>` with your New Relic license key and `<cluster-name>` with your cluster name.

## Uninstall the eBPF agent [#uninstall]

To uninstall the eBPF agent from your Kubernetes cluster:

```bash
helm uninstall nr-ebpf-agent -n newrelic
```

<Callout variant="tip">
This command will remove all eBPF agent components from your cluster. The namespace will remain unless you explicitly delete it.
</Callout>


<DocTiles>
<DocTile title="eBPF Linux installation" path="/docs/ebpf/linux-installation/">Learn how to set up the New Relic eBPF agent for your Linux host.</DocTile>
<DocTile title="Troubleshooting eBPF" path="/docs/ebpf/troubleshooting/">Learn how to troubleshoot issues with the New Relic eBPF agent.</DocTile>
<DocTile title="eBPF best practices" path="/docs/ebpf/best-practices/">Learn about best practices for using the New Relic eBPF agent.</DocTile>
</DocTiles>
Loading
Loading