►
From YouTube: Lightning Talk: What Can eBPF Actually do for Modern-day Observability? - Ori Shussman, Groundcover
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Lightning Talk: What Can eBPF Actually do for Modern-day Observability? - Ori Shussman, Groundcover
This talk is all about exposing how the magic of eBPF can be used to achieve full observability in complex edge cases, through the lens of a real-life gRPC monitoring case study. In the era of ever-growing observability data, existing monitoring solutions are faced with new problems, often deeming them impractical. We will deep dive into the hardships of monitoring gRPC and other compressed or encrypted protocols and show how gRPC monitoring has undergone a revolution thanks to the integration of eBPF
A
Hi
very
happy
to
be
here:
I'm
Marie,
I'm
founding
engineer
at
ground
cover
I've
been
implementing
observability
solutions
for
quite
some
time
for
many
different
use.
Cases
and
I
I
fell
in
love
with
the
magic
that
is
also
known
as
ebpf
I
wish
to
share
with
you
today
the
most
important
Insight
that
I've
found
throughout
my
experiments
that
with
ebpf
we
can
reach
what
I
call
full
observability.
A
When
I
say
full
observability
I'm
talking
about
our
ability,
as
developers
and
devops,
to
see
everything
that's
going
on
in
our
cluster,
this
includes
all
the
interactions
between
our
services,
all
the
metadata
that
accompanies
them.
Various
events
such
as
program,
exceptions
and
protocol
errors
and
determining
exactly
when
all
of
this
occurred
and
which
processes
it
belongs.
A
The
best
way
to
understand
that
is
with
examples,
and
this
is
where
grpc
comes
into
the
picture.
Grpc
is
quickly
becoming
the
preferred
tool
to
connect
microservices
replacing
a
lot
of
the
modern
uses
of
http,
and
it
is
also
quite
hard
to
observe-
and
this
is
exactly
why
it
makes
the
best
example
for
our
evolution.
A
Let's
take
a
simple
example
of
a
client
and
a
server
communicating
over
grpc,
where
the
client
periodically
every
10
seconds
requests
resource
only
from
the
server.
It's
quite
a
common
use
case
where
the
client
needs
to
know
when
the
resource
is
updated,
and
in
that
simple
example,
we
need
to
see
two
two
things.
The
first
is
the
grpc
data,
which
is
the
most
basic
part
of
the
protocol.
A
A
A
A
It's
it
works
just
as
if
the
client
in
the
first
request,
says
to
the
server
fetch
resource
only
for
me
and
from
now
on,
I
will
call
resource
only
resource
7
and
from
that
moment
onwards
the
resource
name
is
not
transmitted
anymore.
Only
the
ID
that
represents
it
and
what's
the
problem
with
this
for
us.
A
Well,
grpc
connections
like
the
one
we
are
talking
about
can
live
for
a
very
long
time.
These
requests
every
10
seconds,
can
go
on
forever,
and
this
means
that
we
are
most
likely
going
to
start
observing
the
connection
when
it's
already
alive
and
in
that
point
the
resource
name
alongside
other
headers
is
not
transmitted
anymore.
A
A
Your
probes
can
be
used
to
get
data
directly
from
the
grpc
libraries
memory.
The
library
obviously
knows
that
the
resource
ID
7
represents
resource
only
otherwise
it
just
wouldn't
have
worked
the
server.
If
it
didn't
know
what
7
was,
would
not
know
what
to
respond
to
a
request
for
Resource
number,
seven.
So
using
new
probes,
we
can
get
this
data
from
the
memory
of
the
library.
A
If
there
was
a
grpc
receive
function
inside
the
library
that
receives
both
the
headers
and
the
data
as
arguments,
we
would
probe
it
and
see
all
the
incoming
information
we
would
like.
We
would
only
need
two
probes,
one
for
this
function
and
one
for
the
complementary
grpc
send
function,
and
we
would
be
done
when
you
think
about
it.
The
same
concept
works
for
all
types
of
stateful
connections,
including
encrypted
traffic.
The
encryption
Library
leave
us
a
cell,
for
instance,
obviously
knows
what
the
unencrypted
data
is.
A
A
A
In
our
case
five
view,
probes
are
what
we
needed:
one
to
see
outgoing
data
three
more
to
see
the
incoming
data
and
the
last
one
to
know
when
a
grpc
connection
has
been
closed
and
everything
works,
and
this
is
really
exciting,
seeing
all
that
work
put
to
action.
So
please
join
me
and
let's,
let's
watch
now
how
you
probes
are
used
to
fully
observe
grpc
connections.
A
In
this
demonstration
is
in
the
bottom
right,
you
can
see
the
ebpf
code
in
the
top
right
is
the
grpc
server.
Now,
starting
and
the
first
thing
that's
going
to
happen,
is
the
ebpf
code
attaches
five
probes
to
the
server
the
client
at
the
left
will
then
start
periodically
requesting
resources
from
the
server
and
printing.
All
the
information
in
the
connection,
as
you
can
see,
with
zero
code
changes
to
the
server
or
to
the
client,
the
ebpf
code
has
complete
access
and
full
observability
into
grpc
connections.