• /
  • EnglishEspañolFrançais日本語한국어Português
  • Log inStart now

eBPF AI monitoring

New Relic's eBPF agent extends the same zero-code, language-agnostic approach it uses for eBPF APM to the AI layer of your stack. Once the agent is installed, it automatically detects outbound calls your services make to LLM providers directly from the Linux kernel, and reports GenAI performance, cost, and reliability telemetry without any SDK, code change, or dedicated AI monitoring agent.

This telemetry appears on the same auto-discovered eBPF entity that already reports your APM, network, and log data, giving you a single, unified view of a service's health alongside its AI usage. This is especially useful for spotting GenAI workloads you didn't know existed: third-party services, legacy applications, or code you don't own that are quietly calling out to an LLM vendor.

Key features

  • Zero-code GenAI detection: Automatically discovers outbound calls to LLM providers (such as OpenAI, Azure OpenAI, and Amazon Bedrock) at the kernel level, with no SDKs, wrapper libraries, or code changes required.

  • Works seamlessly alongside eBPF APM: Comes with the eBPF agent, so you don't need to deploy or manage a separate agent to start collecting GenAI telemetry. You have the option to enable/disable eBPF AI workload monitoring (off by default).

  • Automatic detection and backoff: Suppresses its own AI telemetry when a language APM agent is already instrumented and reporting AI monitoring data for the same service, avoiding duplicate data. This is the same pattern the eBPF agent already uses for APM, network, and log data.

  • Optional prompt and response capture: When enabled, the agent captures GenAI metadata only, such as model, vendor, token usage, latency, and errors. A separate setting lets you additionally capture the full prompt and completion content when you need it for debugging or quality review.

  • Unified entity view: GenAI telemetry appears on the same entity as your eBPF APM, network metrics, and logs data, so you don't need to correlate across multiple entities to understand a service's behavior.

Supported LLM providers

eBPF AI monitoring currently detects and reports on outbound calls to these LLM providers:

  • Google Gemini
  • OpenAI
  • Anthropic Claude
  • Amazon Bedrock

Detection happens at the kernel level, based on the HTTP calls your services make to these providers' APIs, so no vendor SDK or client library is required. Calls to other providers aren't reported as GenAI telemetry.

Use cases

  • For platform engineers: Get an inventory of every service in your environment that's calling an LLM provider, including ones you don't own or didn't know were AI-enabled.

  • For teams with opaque or third-party workloads: Monitor GenAI usage, cost, and latency for legacy applications or vendor binaries that you can't instrument directly.

  • For AI cost and performance oversight: Identify token-heavy or slow-responding GenAI calls across your estate before deciding where to invest in deeper, code-level AI monitoring instrumentation.

  • For security and compliance visibility: Understand which of your services send data to external AI providers, so you can decide where to apply obfuscation or drop rules. Refer to Sensitive data and eBPF AI monitoring below.

Enable eBPF AI monitoring

While the capability is off be default, you can enable it easily - with a separate control to capture full prompt and response content, from the guided install flow or by editing your agent configuration directly.

Guided install

Both the Linux host and Kubernetes guided install flows include two switches for AI monitoring:

  • Enable eBPF AI Monitoring: Turns on GenAI workload monitoring. Disabled by default.
  • Enable recording model inputs and outputs: Captures full message content (prompts and completions) for GenAI interactions. Disabled by default, and only available once Enable eBPF AI Monitoring is turned on. Use with caution, as this sends the actual prompt and response text to New Relic.

Important

New Relic automatically disables eBPF AI monitoring if it detects a language APM agent, to avoid duplicating telemetry that the APM agent's own AI monitoring instrumentation already reports.

Configure it manually

If you're not using the guided install, set these parameters in your agent configuration:

  • ai_monitoring.enabled: Controls GenAI telemetry reporting. Accepted values: "true" (always send), "false" (never send), "auto" (send only when no language APM or OTel agent is already reporting AI monitoring data for the entity).
  • ai_monitoring.genAICaptureMessageContent: When true, captures full prompt and completion content for GenAI interactions. Only takes effect when ai_monitoring.enabled is true or auto. Use with caution.

On Linux hosts using the install script, set the equivalent ai_monitoring.enabled and ai_monitoring.genAICaptureMessageContent environment variables instead. This mirrors the pattern already used by reportApmData, reportNetworkMetrics, and reportLogs. For the full list of parameters, refer to the Configuration parameters section of the Linux installation or Kubernetes installation guide.

View your eBPF AI monitoring data

You can view eBPF AI monitoring data in the New Relic APM UI:

  1. Go to one.newrelic.com > APM & Services.
  2. Select the eBPF entity for the service that's calling an LLM provider.
  3. Click AI monitoring in the left navigation, then select AI traces.

Tip

The eBPF agent automatically generates entity names based on your environment:

  • In hosts or Docker: Names combine process name, directory path or container ID, and listening port. Examples: ruby:/home/ubuntu/app:[5678] or java:f4aead533895:[8080]
  • In Kubernetes: Names are derived from service names, like mysql-database-service

To view the list of attributes collected by the eBPF agent, refer to the eBPF agent attributes reference.

Sensitive data and eBPF AI monitoring

Important

eBPF AI monitoring doesn't obfuscate, mask, or drop sensitive data on its own. By design, it reports exactly what it observes on the wire.

If you leave Enable recording model inputs and outputs off (the default), the agent never captures prompt or completion content, only metadata like model, vendor, token counts, and latency. This avoids sending sensitive prompt or response text to New Relic in the first place.

If you turn recording on because you need that content for debugging or quality review, data obfuscation and dropping for sensitive information is only available through the Pipeline Control Gateway (PCG) using OpenTelemetry Transformation Language (OTTL). The direct eBPF-to-New Relic data flow doesn't include built-in obfuscation for AI monitoring data. Contact your account representative to add PCG to your order.

For example, this configuration redacts the completion content captured from a GenAI interaction (adjust the attribute name to match what your eBPF agent reports. Refer to the eBPF agent attributes reference for the exact attribute names):

transform/Traces:
trace_statements:
- statements:
- replace_pattern(attributes["gen_ai.completion"], ".+", "***REDACTED***")
conditions:
- attributes["gen_ai.completion"] != nil

This example redacts only the completion attribute shown. For additional or customizable obfuscation and drop rules, including rules for the prompt content, specific model vendors, or other attributes, configure the OTTL Transform processor supported by PCG directly. Refer to Redact PII for more examples.

eBPF APM

Learn how to use New Relic's eBPF APM for zero-code, language-agnostic application monitoring.

Introduction to AI monitoring

Learn how AI monitoring gives you visibility into the performance, cost, and quality of your AI-powered app.

Pipeline Control Gateway transform processor

Learn how to obfuscate, redact, or drop sensitive data using OTTL before it reaches New Relic.

eBPF agent attributes reference

See the full list of attributes the eBPF agent adds to your data.

Copyright © 2026 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.