Application logs are often one of the first places engineers look during an incident. But getting those logs into the same workflow as your metrics and traces can still require another collector, another configuration file, another set of plugins, and another operational surface to secure and maintain.
With New Relic's eBPF agent, teams get application monitoring and network visibility from a single deployment without the need of per-language libraries and code changes. It's the simplest path we've built to broad, consolidated visibility across your services.
That simplicity is powered by eBPF: a secure, sandboxed, and widely adopted Linux technology that lets New Relic observe what's happening on your systems safely and efficiently, without changing a line of your application code.
New Relic eBPF delivered application monitoring with automatic discovery came first, then eBPF Network Metrics and APM. But one signal was still collected outside it: your logs.
Today, we introduce the Public Preview of New Relic eBPF Logs; application logs collected automatically by the eBPF agent and correlated to your services, with no new agent to deploy.
One agent, now including logs
If you're already running the eBPF agent, you know the appeal: application monitoring with automatic service discovery and network visibility, all flowing through one lightweight agent you deploy once. eBPF Logs closes that gap by bringing log telemetry into the same unified lifecycle.
This consolidation also results in stronger security. Every additional agent is one more component to patch and secure; by collecting logs through the agent you already operate rather than a separate third-party forwarder, you reduce the number of moving parts and shrink the attack surface you have to defend.
Logs in context automatically
The point of eBPF Logs isn't just to move logs — it's to make them immediately useful. Because the agent already understands your services, your logs arrive already connected to them.
- Automatic collection: the eBPF agent picks up application logs directly from your running services; there's nothing for developers to add to the code.
- Auto-linked to your services: the same entity synthesis that powers eBPF application monitoring ties each log line to the service it came from, so Logs in Context lights up automatically.
- OpenTelemetry-first: logs are delivered to New Relic's OpenTelemetry endpoint, fitting cleanly into an open, standards-based pipeline.
- Safe by design: eBPF observes in a secure, sandboxed, read-only way. It's a proven, broadly adopted approach that adds visibility without changes to your applications or added risk.
- You stay in control of your data: New Relic's pipeline control gateway lets you filter sensitive or PII content before it arrives at NRDB.
A day in the life: an FX service under pressure
Picture a foreign exchange (FX) service that returns live currency-conversion quotes for a payments platform. During a busy trading window, a share of quote requests starts failing, and some customers see their conversions rejected.
From the FX service entity: you already watch its golden signals and network activity; you notice a spike in errors and climbing latency.
Its logs surface right there in context, correlated to the service automatically. There's no switching tools and no hunting across hosts to find them.
The logs tell the story: a burst of “stale price and rate quote expired” messages and slow responses from an upstream rate provider. The service is rejecting quotes because the provider's prices are arriving too late to safely honor.
The Result: instead of guessing whether it's the app, the network, or the provider, you have the exact log evidence in one place within one agent and one workflow. You can fail over to a backup rate feed or adjust timeouts in minutes, not hours.
Getting Started (Public Preview)
If you already run the New Relic eBPF agent, you are most of the way there. To try eBPF Logs in Public Preview:
Deploy or upgrade the eBPF agent on your Linux hosts or Kubernetes clusters — no need to swap application libraries or restart your apps. [docs link - still to come]
Turn on application log ingestion with the Public Preview opt-in.
Open your service entity and see Logs in Context automatically.
Next steps
Try eBPF Logs in Public Preview and see how application logs appear in context with the services you already monitor in New Relic.
If you are already using New Relic eBPF, start by upgrading the agent and validating application log capture in a supported environment. If you are new to New Relic eBPF, explore the broader eBPF capabilities, including eBPF Network Metrics and eBPF Logs, to see how kernel-level telemetry can simplify troubleshooting across modern cloud-native systems.
Related blog: eBPF Network Metrics for kernel-level network visibility in APM and infrastructure
Document: eBPF Docs
The views expressed on this blog are those of the author and do not necessarily reflect the views of New Relic. Any solutions offered by the author are environment-specific and not part of the commercial solutions or support offered by New Relic. Please join us exclusively at the Explorers Hub (support.newrelic.com) for questions and support related to this blog post. This blog may contain links to content on third-party sites. By providing such links, New Relic does not adopt, guarantee, approve or endorse the information, views or products available on such sites.
