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.
다음 단계
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
이 블로그에 표현된 견해는 저자의 견해이며 반드시 New Relic의 견해를 반영하는 것은 아닙니다. 저자가 제공하는 모든 솔루션은 환경에 따라 다르며 New Relic에서 제공하는 상용 솔루션이나 지원의 일부가 아닙니다. 이 블로그 게시물과 관련된 질문 및 지원이 필요한 경우 Explorers Hub(support.newrelic.com)에서만 참여하십시오. 이 블로그에는 타사 사이트의 콘텐츠에 대한 링크가 포함될 수 있습니다. 이러한 링크를 제공함으로써 New Relic은 해당 사이트에서 사용할 수 있는 정보, 보기 또는 제품을 채택, 보증, 승인 또는 보증하지 않습니다.