Log in
Forgot password ?
Become a member for free
Sign up
Sign up
New member
Sign up for FREE
New customer
Discover our services
Dynamic quotes 


SummaryMost relevantAll NewsAnalyst Reco.Other languagesPress ReleasesOfficial PublicationsSector news

New Relic : What Is eBPF and Why Does It Matter for Observability?

04/23/2021 | 02:10pm EDT

Working within the Linux kernel is ideal when implementing security, networking, and observability features. However, it's not without its challenges. Whether modifying kernel source code or adding modules, developers have traditionally found themselves contending with complicated infrastructure and abstracted layers that are difficult to debug. Extended BPF (eBPF) solves both of these problems.

Extended Berkeley Packet Filter (eBPF) is a kernel technology (starting in Linux 4.x) that allows programs to run without having to change the kernel source code or adding additional modules. You can think of it as a lightweight, sandbox virtual machine (VM) inside the Linux kernel, where programmers can run BPF bytecode that takes advantage of specific kernel resources.

Using eBPF eliminates the need to change kernel source code and streamlines the ability of software to leverage existing layers. As a result, it's a powerful technology with the potential to fundamentally alter how services like networking, observability, and security are delivered.

Here's a closer look at what it is, how it works, and when to consider implementing it.

How eBPF works

eBPF programs are event-driven and attached to a code path. The code path contains specific triggers-called hooks-which execute any attached eBPF programs when they're passed. Some examples of hooks include network events, system calls, function entries, and kernel tracepoints.

When triggered, the code is compiled first to the BPF bytecode. In turn, the bytecode is verified before it runs, to ensure it doesn't create a loop. This step prevents the program from compromising the Linux kernel either accidentally or on purpose.

After a program is triggered at a hook, it then makes helper calls. These helper calls are functions that equip eBPF with many features for accessing memory. Helper calls need to be pre-defined by the kernel, but the list of what functions exist continues to grow.

eBPF was initially used as a way to increase observability and security when filtering network packets. However, over time, it became a way to make the implementation of user-supplied code safer, more convenient, and better-performing.

The advantages of eBPF

eBPF is typically used to trace user-space processes, and its advantages shine here. It's a safe and useful method to ensure:

  • Speed and performance. eBPF can move packet processing from the kernel-space and into the user-space. Likewise, eBPF is a just-in-time (JIT) compiler. After the bytecode is compiled, eBPF is invoked rather than a new interpretation of the bytecode for every method.
  • Low intrusiveness. When leveraged as a debugger, eBPF doesn't need to stop a program to observe its state.
  • Security. Programs are effectively sandboxed, meaning kernel source code remains protected and unchanged. The verification step ensures that resources don't get choked up with programs that run infinite loops.
  • Convenience. It's less work to create code that hooks kernel functions than it is to build and maintain kernel modules.
  • Unified tracing. eBPF gives you a single, powerful, and accessible framework for tracing processes. This increases visibility and security.
  • Programmability. Using eBPF helps increase the feature-richness of an environment without adding additional layers. Likewise, since code is run directly in the kernel, it's possible to store data between eBPF events instead of dumping it like other tracers do.
  • Expressiveness. eBPF is expressive, capable of performing functions usually only found in high-level languages.
eBPF best practices

Since eBPF is such a new technology, many things remain unexplored. Best practices around eBPF are still evolving as the technology gains prominence. While no defined set of best practices exist, there are a few things that you can do to ensure effective, efficient programs.

If you're using eBPF for your ecosystem, we recommend that you:

  • Use LLVM Clang to compile C into bytecode. When eBPF first hit the scene, it was necessary to code and assemble the program by hand. Then, developers used the kernel's assembler to generate bytecode. Fortunately, it's no longer necessary to do this. Clang provides infrastructure for frontend and tooling in C languages.
  • Use the BCC toolkit when writing BPF programs. The BPF Compiler Collection (BCC) is a toolkit that can help you create efficient kernel tracing and manipulation programs. It's especially suited for tasks related to performance analysis and controlling network traffic.
The pitfalls of eBPF

Although it's powerful, eBPF is not a silver bullet that suits every project or ecosystem. eBPF does have some notable disadvantages, which can make it frustrating to work within certain instances. Some developers might find eBPF inadequate to use because:

  • It's restricted to Linux and a recent kernel. eBPF was developed in the Linux kernel and is completely oriented around it. That makes it less portable than other tracers. Additionally, you need a fairly recent kernel. If you're running anything older than v 4.13, you won't be able to use it.
  • Sandboxed programs are limited. eBPF derives increased security by limiting what resources programs can access. However, by limiting what parts of the OS a program can access, functionality is also potentially limited.
When eBPF typically works well

eBPF is rapidly gaining traction in cloud native applications. As a result, eBPF is used most commonly in two situations:

  • There's a need for observability using kernel tracing. In this situation, eBPF is faster and more accurate. There are no context switches involved, and eBPF programs are event-based so nothing runs without a specific trigger-and you won't miss any occurrences.
  • Traditional security monitoring doesn't work. eBPF is finding lots of uses in distributed and container-based environments, including Kubernetes. In these environments, eBPF can close the visibility gap because it can provide visibility into HTTP traffic.

You might also find eBPF deployed for other security measures, including:

  • Firewalls
  • Device drivers
  • Network performance monitoring
New Relic and eBPF

Pixie (acquired by New Relic), is an open source, kubernetes-native-in-cluster observability platform that provides instant visibility into Kubernetes workloads with no manual instrumentation. eBPF provides most of the magic behind the Pixie platform. As described earlier, eBPF allows you to run restricted code when an event is triggered. This event could be a function call either in kernel space(kprobes) or userspace(uprobes). Pixie uses both uprobes and kprobes to enable observability across services and applications.

Pixie automatically harvests telemetry data by leveraging eBPF, and its edge-machine intelligence connects this data with Kubernetes metadata to provide visibility while maintaining data locality. This visibility complements New Relic's powerful Kubernetes observability solution. And starting in late May, you'll be able to send Pixie-generated telemetry data to New Relic One, gaining scalable retention, powerful visualizations, advanced correlation, and intelligent alerting capabilities.

eBPF is observability made efficient

eBPF is a new technology that improves observability, networking, and security in the Linux kernel. It eliminates the need to change kernel source code or add modules, so you can create a richer infrastructure to support your system without overcomplicating it.

We took a look at what eBPF is, how it works, and why it's so useful in distributed environments. By monitoring from the kernel layer, many of the challenges associated with observability in the cloud are solved. You can enjoy deeper visibility, more context, and more accuracy in your data.

Next Steps

Install Pixie and experience the magic of eBPF for observability.


New Relic Inc. published this content on 23 April 2021 and is solely responsible for the information contained therein. Distributed by Public, unedited and unaltered, on 23 April 2021 18:09:04 UTC.

© Publicnow 2021
All news about NEW RELIC, INC.
06/24NEW RELIC  : Extract URL Values Using Regex Capture to Improve Your NRQL Results
06/23NEW RELIC  : Error Tracking Across Your Entire Stack with New Relic Errors Inbox
06/21NEW RELIC  : Under the Hood of New Relic's Lambda Extension
06/17NEW RELIC  : 10 Things You Should Know About Juneteenth
06/17NERDLOG ROUNDUP : Detect, Diagnose, and Mitigate Issues Faster with Next-Gen AIO..
06/15NEW RELIC  : AWS Quick Start for Amazon EC2 Makes Observability Simple
06/14SHOWING UP TO WORK AS ME : Being an LGBTQI+ Executive
06/14NEW RELIC  : How Workiva takes observability to a new level with custom apps on ..
06/10NERDLOG ROUNDUP : New Relic Errors Inbox and Student Edition
06/09FROM PANDEMIC TO COMMUNITY POWER : Mutual Aid Network Wins FutureHack for Good
More news
Financials (USD)
Sales 2022 711 M - -
Net income 2022 -205 M - -
Net cash 2022 397 M - -
P/E ratio 2022 -27,1x
Yield 2022 -
Capitalization 4 462 M 4 462 M -
EV / Sales 2022 5,72x
EV / Sales 2023 5,00x
Nbr of Employees 2 168
Free-Float 78,7%
Duration : Period :
New Relic, Inc. Technical Analysis Chart | MarketScreener
Full-screen chart
Technical analysis trends NEW RELIC, INC.
Short TermMid-TermLong Term
Income Statement Evolution
Mean consensus HOLD
Number of Analysts 14
Last Close Price 69,94 $
Average target price 69,44 $
Spread / Average Target -0,71%
EPS Revisions
Managers and Directors
William Staples Chief Executive Officer
Mark Sachleben Chief Financial Officer & Secretary
Hope F. Cochran Chairman
Bonney Pelley Senior Vice President-Strategy & Operations
Dan Scholnick Independent Director
Sector and Competitors
1st jan.Capitalization (M$)
NEW RELIC, INC.6.94%4 549
ADOBE INC.14.82%275 243
TWILIO INC.13.86%66 002
AUTODESK, INC.-6.31%62 411
WORKDAY INC.-0.38%58 985