►
From YouTube: Fluentd and Fluent Bit - Eduardo Silva, Calyptia
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. 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.
Fluentd and Fluent Bit - Eduardo Silva, Calyptia
Observability pipelines are a critical component on every production environment. Fluentd and Fluent Bit are well known and used for Log collection and processing. But for years our community of users have asked for a unified experience with Metrics collection. In this presentation, you will learn about our new Metrics collection and processing with Fluentd and Fluent Bit. You will learn the best practices for monitoring and how to leverage your current Prometheus services and infrastructure by using all the component together without any observability disruption.
A
Thank
you
hey
well,
my
name
is
eduardo.
Today
we
announced
this
session
called
about
fluency
and
fluent
bet
originally
description
session.
We
started
talking
about
a
our
new
journey
to
metrics
right,
but
before
to
jump
into
metric,
we're
thinking.
Okay,
maybe
we
need
to
go
to
a
deep
dive
explanation
why
this
is
a
good
deal
and
how
things
work
in
logs?
How
do
we
handle
them
before
to
jump
into
the
metric
space?
So
anybody
of
you
is
new
to
fluentdm
fluent
bed.
If
so,
please
raise
your
hand.
A
A
A
So
this
is
a
quite
interesting
challenge,
because
when
you
have
your
environment,
you
always
have
more
data,
more
data,
more
workloads,
more
workloads,
things
grows
on
that
side,
but
in
the
infrastructure.
The
way
that
you
handle
the
information
it's
hard
to
scale
right
and
that's
why
we
focus
a
lot
of
performance
performance.
A
A
I
got
this
response
and
any
kind
of
problems
or
exceptions
that
information
in
a
container
environment
usually
comes
from
a
in
a
row
and
a
wrong
text
message:
that's
a
kind
of
apache
message
quite
of
old,
and
then
this
hits
disk
as
a
file
where
you
have
multiple
records
separated
per
file.
I'm
not
saying
that
this
is
the
only
way
to
do
login
right,
some
application
chips
logs
over
tcp
or
you
have
firewalls
that
chips
lock
messages
over
udp
by
using
syslog
as
a
payload
format.
A
And
when
you
see
when
you
do
this,
and
you
store
all
this
information,
it's
not
just
about
to
have
the
information
there,
because
your
goal,
as
always
said,
is
to
perform
data
analysis
right.
It's
not
about
logging,
it's
not
about
the
tool
you
want
to
solve
data
analysis.
You
wanted
to
know
how
your
applications
are
behaving
any
kind
of
exception
that
you
have
or
anything
that
can
give
you
some
insights
right
from
what's
going
on
with
your
applications.
A
A
Now,
this
kind
of
engine
that
collects
the
data
and
send
the
data
out
has
a
couple
of
roles
and
a
couple
of
tasks
that
he
has
to
accomplish
so
collect
the
data
perform
data
transformation
because
you
want
to
parse
the
information
you
want
to
unify
in
some
format,
which
is
a
quite
a
challenge
right.
Just
if
you
have
three
developers
in
your
environment
doing
different
projects,
I'm
100
sure
that
all
of
them
will
use
a
different
structure
for
the
locks.
A
So
when
you
want
to
do
analysis
on
top
of
that
data,
you
have
to
realize
which
one
or
how
to
approach
them,
and
it's
really
hard.
Also,
there
are
many
applications
that
are
very
noisy
that
generate
messages
that
you
don't
want
and
what
is
the
problem?
The
problem
is
that,
if
you're
using
a
back-end,
for
example,
what
is
a
common
example
splunk?
A
They
are
going
to
charge
you
by
the
amount
of
data
that
you
ingest,
but
if
you're
sending
a
bunch
of
data
that
you
don't
need,
you
anyways
you're
going
to
pay
for
that
amount
of
data,
and
this
is
where
people
start
thinking
about.
Oh
cost
reduction.
We
don't
want
all
the
data,
we
need
something
that
can
filter
out
information.
That
is
not
required
right.
A
So
this
little
engine
need
to
be
smart
enough
to
provide
all
this
feature
set,
also
doing
buffering,
because
if
I'm
going
to
send
this
information
to
a
backend
database
to
the
right
side
of
this
pipeline,
things
can
go
wrong
and
I
don't
know
if
you
face
it,
but
wi-fi
just
was
we
lost
wi-fi
for
two
minutes
here
in
the
conference?
The
same
thing
happens
in
in
environments,
right
network
outage
power
outage
disk
failures.
So,
but
if
we
don't
save
the
data,
we
don't
keep
a
states
of
what
we
are
processing
and
we
will
recover.
A
A
And,
as
I
said,
the
whole
point
of
data
centralization
is
data,
analysis
right
and
you
can
choose
whatever
you
want,
and
this
is
kind
of
the
key
of
things
of
these
tools
around
the
flue
in
the
ecosystem
and
pretty
much
from
a
global
perspective.
This
is
input
and
output
right.
You
have
an
engine
that
process
all
the
input
process.
The
data
filter
do
buffering
and
send
this
data
out
to
your
preferred
destination.
A
A
Buffering
routing
scheduling,
retries
requires.
If
I'm
going
to
send
the
data
and
something
happens
and
I
could
not
send
it.
I
will
have
to
some
kind
of
logic
that
allows
me
to
send
this
data
out
and
in
the
output
side
there
are
other
kind
of
challenges:
network
setup,
some
of
the
packets
used
tls,
some
others.
Doesn't
every
pack
can
use
a
different
expect,
a
different
payload
for
the
data
right.
The
splunk
splunk
expect
an
adjacent
payload
that
is
totally
different
than
the
one
specter
by
amazon
s3.
A
So
we
have
to
take
this
binary
representation
that
we
have
and
convert
it
back
to
the
expected
payload.
It's
kind
of
we
unified
in
a
in
a
format
internally,
and
then
we
encode
the
data
for
the
right
a
backend,
and
this
is
what
fluent
does
right.
It
cares
for
you
about
all
this
complexity
of
io
network
collection,
processing,
filtering
and
making
sure
that
reliable.
You
can
get
your
data
in
your
backends.
A
So,
as
I
said,
fluent
bit
is
part
of
the
fluent
ecosystem.
It's
under
apache
license,
and
now
we
have
more
than
200
contributors
in
total,
and
the
good
thing
is
that
fluid
is
being
used
widely
nowadays,
aws
google
cloud,
microsoft,
azure
all
of
them
are
deploying
fluid
and
bit
at
a
really
heavy
scale
and
just
from
the
public
stats
from
our
docker
hub
repositories
that
are
not
related
to
how
to
deploy
fluid
in
their
own
registries.
A
We
have
around
an
average
of
two
million
polls
or
deployments
per
day
so
which
is
an
insane
amount
of
deployments
right.
It's
like
kubernetes
clusters
going
up
going
down
and
all
of
them
are
using
a
what
majority
of
them
are
using
fluid
and
we
have
a
couple
of
companies
also
using
them
for
different
purposes.
A
So
people
who
runs
in
the
cloud,
if
you
just
paint
at
a,
for
example,
a
kubernetes
cluster
in
google
right
now,
you
will
get
fluent
bet
on
it.
So
this
is
quite
a
challenge
right.
So
from
a
maintenance
perspective,
this
product
has
to
be
so
stable
that
we
cannot
mess
up
something.
If
we
wrote
something
bad,
I
will
mess
up
the
whole
infrastructure
and,
as
I
said,
fluent
was
designed
with
performance
in
mind
right.
A
We,
it
was
not
intended
to
to
think
we're
going
to
write
something
for
the
cloud
native
ecosystem
that
will
be
around
in
five
years.
It
was
not
like
that
right.
We
just
optimized
it
for
embedded
linux.
We
made
it
very
optimal
how
to
manage
everything,
and
it
was
a
good
timing
right.
The
container
space
just
came
in
and
we
just
had
all
the
pieces
in
place.
Also
buffer
management
is
really
important
right.
How
do
we
optimize
when
we
group
the
data?
How
do
we
store
this
data
between
memory
file
system?
A
A
What
is
the
difference
between
using
json
and
message
pack
from
a
payload
payload
size
perspective,
but
also,
if
I
have
an
array,
it's
easy
for
me
to
jump
between
positions
between
one
key
and
the
other
and
the
value
inside.
If
I
do
that
in
json,
I
have
to
analyze
everything
and
go
buy
it
per
byte,
yeah,
there's
quite
enough
optimizations
around,
but
we
cannot
compare
the
performance
of
playing
json
with
message
pack
now
this
is
not
like.
Json
is
bad.
A
It's
about
we're
not
going
to
do
it,
we're
not
going
to
do
json
in
internals
if
we
can
do
message
pack
and
we
use
just
json
to
communicate
with
other
backends
that
speak,
that
that
language,
that
format
right
and
when
we
get
the
records.
For
example,
if
you
think
that
we
have
a
file,
every
has
multiple
lines.
Every
line
is
considered
a
record
or
an
event,
and
this
event
get
groups
right
in
buffers
which
is
called
chunks
and
chang
can
have
multiple
events
associated
under
the
same
tag.
A
Tags
are
useful
to
say
all
this
data
is
coming
from
this
from
this
source,
because
in
the
configuration
at
some
point
you
will
say
I
want
to
send
all
the
data
that
matches
this
criteria
to
this
packet,
all
the
data
that
has
attacked
with
other
criteria
to
a
different
backend.
That's
how
people
split
data
into
elasticsearch
splunk
with
different
routing
rules.
A
Now,
when
talking
about
buffering,
it's
really
important
to
understand
that
a
we
have
limited
resources
right
and
we
have
a
bad
practice
around
in
general
in
the
industry
that
nobody
thinks
about
memory.
Nobody
thinks
about
cpu
usage
right,
but
for
a
service
that
has
to
run
24
by
seven
that
doesn't
have
a
short
period
of
time
of
light.
It's
always
running
processing
data.
We
have
to
always
be
optimizing
right,
how
much
resources
we
consume.
A
So
we
have
an
android
approach
by
default.
Is
all
the
data
goes
to
memory?
So
all
the
data
means
all
the
chunks
go
to
memory
so
every
time
that
we're
getting
records,
we
group
them
in
chunks
and
the
chunks
get
been
filled
in
memory,
but
we
always
say
that.
Okay,
we
have
this
amount
of
memory,
but
we
can
say:
let's
have
up
to
this
amount
of
a
memory
usage
by
chance.
Otherwise
your
service
can
explode
right.
The
kernel
is
going
to
kill
your
service
now
in
memory.
A
Barfini
is
fine,
it's
pretty
good,
it's
the
fastest
mechanism,
but
it's
not
persistent
if
you
reboot
the
agent
and
you
have
data
that
has
not
been
flashed
to
the
destination
yeah,
that
git
is
going
to
be
get
lost.
Also,
at
some
point,
if
you
just
rely
on
memory,
the
kernel
could
say:
oh
you're,
using
too
much
memory
we're
running
out
of
it.
It's
time
to
sacrifice
someone
so
guess
who
will
be
the
first
target
right?
A
It's
the
agent
that
is
consuming
all
this
information,
and
this
is
where
you
can
come
up
with
a
hybrid
mechanism
right.
All
these
techniques
are
not
new
they're,
quite
usually
in
database
design
right.
So
there's
no
black
magic
here
is
that
having
a
file
system
buffering
helps
a
lot
right.
So
it's
always
good
to
have
this
kind
of
iron
mechanism,
where
the
data
that
is
getting
in,
if
we
cannot
put
it
in
memory,
it
goes
to
the
file
system
right.
A
Usually
your
file
system
will
be
times
bigger
than
the
capacity
that
you
have
in
memory,
but
you
can
say:
oh,
but
also
file
system
is
slow.
It's
slower,
yeah,
it's
slower
than
memory,
but
at
some
point
you
are
not
processing
all
the
data
at
once.
Right,
you're,
always
processing
data
by
fractions,
a
couple
of
chunks
at
a
time,
not
all
of
them.
Otherwise,
you
will
get
really
in
a
really
bad
spot,
with
cpu
such
ion,
ds
and
so
on.
A
So
when
the
data
hits
also,
we
have
the
same
mechanisms
that
can
go
to
the
file
system
and
the
ideal.
The
deal
use
case
that
we
come
up
as
a
design
is
with
hybrid
mechanism,
where
you
can
have
the
data,
also
in
memory
which
is
being
processed
or
ready
to
go,
but
also
we
have
all
the
other
chunks
in
the
file
system,
and
we
have
this
concept
of
chunks
up
and
down.
A
chunk
of
breaks
down
is
just
in
the
file
system.
A
A
Now,
in,
as
the
description
said,
we
wanted
to
talk
about
matrix
today
right
the
approach
of
fluid,
but
following
different,
but
it
was
always
about
loss.
But
what's
the
story
behind
matrix
and
the
few
minutes
that
we
have
left
is
that
for
years,
even
in
cubicle
and
this
conference,
users
approached
to
us
and
said
hey
why
I
need
to
have
one
engine
for
metrics
and
one
agent
for
locks.
Why?
I
cannot
have
a
more
unified
experience
and
at
some
point
we
said
this
here
hey
and
we
had
metro
experience
just
a
little
bit.
A
A
What
has
been
quite
interesting,
so
I
found
that
doing
metrics
more
fun
than
logs,
or
maybe
we
have
been
doing
longer
for
so
much
time.
The
thing
is
that
we
are
not
new
to
metrics
right.
Fluid
has
done
metric
collection
for
a
lot
of
years
since
the
beginning,
because
it
was
for
embedded
linux.
So
we
have
a
input.
Plugins
together,
cpu
metrics,
this
io
network
thermal
temperature,
stuff
docker
metrics,
but
we
always
handle
that
as
structured
locks,
not
as
a
with
a
matrix
payload
or
a
fixed
data
model
right
in
logs.
A
A
So
and
this
is
a
kind
of
comparison
between
locks
and
metrics
logs.
You
have
instructor
messages
structure,
but
metric
has
fixed
the
data
model
and
logs
you
need
to
do
filtering
a
matrix.
Maybe
maybe
you
need
some
kind
of
do
some
kind
of
irrigation,
which
is
quite
optional
in
logs.
You
cannot
predict
the
size
of
the
data.
It's
really
hard.
A
You
it's
really
hard
to
reduce
the
data
logs
right.
You
don't
know
what's
coming
in
in
metrics,
since
you
are
in
control
of
that
you
can
kind
of
manage
or
predict
how
much
measures
you
need
to
store,
or
maybe
you
can
aggregate
them
and
reduce
the
samples
in
terms
of
types
logs.
You
know
have
map
booleans,
integral
flows,
blah
blah,
while
metrics
pretty
much
counters
gauges
histograms.
A
That
means
that
we
always
try
to
integrate
with
others
right,
not
just
go
ahead
and
replace
every
single
standard.
It's
not
the
way
to
go
so
when
we
say
we're
going
to
integrate
with
metrics.
The
first
question
is
how
right
and
okay,
let's
see
what's
the
industry
is
running
and
the
industry
today
is
prometheus,
so
the
best
way
to
approach
this
a
challenge
of
into
getting
to
the
metric
space
was
integrate
with
prometheus,
with
the
open,
metrics
spec
so
and
prometheus
quite
stable
right.
We
have
a
metric
spec.
We
have
collectors,
exporters
is
network
friendly.
A
We
can
transfer
metrics
from
one
endpoint
to
the
other
without
any
problem
and
we
decide.
Okay,
let's
get
started
with
prometheus
right
is,
will
be
our
first
journey
into
metrics
and
now
how
do
we
get
started
with
this?
Okay?
We
don't
have
any
handler
for
for
metrics
right
if
you're
coming
from
prometheus.
You
know
that
prometo
has
this
kind
of
implementation
with
sdks,
so
we
created
our
own
library
called
symmetrics
right
and
symmetrics.
Allow
us
to
do
pretty
much.
A
What
you
can
do
right
now
with
prometus
go
client
which
is
manage
all
these
kind
of
metrics
right,
create
counters,
create
guides,
create
histograms,
which
is
working
process,
but
you
can
do
all
these
kind
of
atomic
operations,
create
labels,
query
by
labels
or
change
all
of
them.
So
and
then
this
got
integrated
into
flow
and
bit
and
one
of
the
goals
of
symmetric
is
that
it's
not
just
matrix
handling.
You
can
manage
metrics,
but
then
you
have
another
problem.
How
do
you
send
these
metrics
to
prometheus?
A
How
do
you
send
this
metrics?
Maybe
oh
I'm
using
influx
d.
I
don't
care
about
promises,
but
I
want
to
solve
influx
db,
so
symmetrics
allows
to
separate
the
context
of
content
versus
transport.
Right
content
is
about
how
the
payload
looks
like
transport
is.
How
do
I
deliver
that
payload
to
a
different
place,
so
in
symmetry
we
implemented
a
way
to
transfer
all
the
content
from
a
signatures
context
to
influence
zb,
prometheus
remote
right
and
as
prometheus
exporter.
A
We
don't
do
transport
just
content,
but
also
as
a
mentor.
We
support
namespace
subsystem,
name,
descriptions
and
labels.
This
is
a
simple
example
on
how
to
create
a
metric
using
symmetrics.
It's
just.
I
think
that
if
you
compare
this
code,
what
what
you
having
as
a
goal
and
client
sdk,
it's
very
much
the
same
line
of
codes
and
no
joking,
it's
the
same
amount
of
lines.
Actually,
we
pretty
much
copy
all
the
parameters
go
client
in
c
and
we
create
a
c
metrics
right,
so
you
have
to
take
always
the
best
practices.
A
A
We
can
say:
okay,
I'm
going
to
expose
this
symmetric
context
over
http,
so
prometheus
can
scrape
this
matrix.
So
we
created
this
also,
this
extension
to
create
the
same
payload
and
also
we
support
prometheus
remote
right.
Remote
right
is
a
is
a
protocol
that
allows
you
to
ship
metrics
from
one
endpoint
to
the
other
right
by
design.
It
was
not
created
for
that
purpose,
but
the
industry
or
vendors
that
listen
for
metrics
payloads.
They
started
creating
this
kind
of
remote
right
endpoints.
A
So
if
you're
using
prometheus
yeah
get
permitted
to
scrape
all
the
data,
but
you
have
this
promised
remote
right
ability
to
send
the
data
out
and
flowing
between.
Symmetrics
has
been
quite
interesting
because
the
first
thing
that
we
did-
okay,
we
want
to
get
into
metrics
we
created
symmetrics.
Now
it's
about.
Okay,
let's
create
the
use
case
and
most
of
users
wanted
to
not
stop
using
node
export,
not
exported,
which
is
a
prometheus
one
of
the
promised
program
to
gather
metrics
from
the
linux
boxes.
A
So
they
asked
us
to
reimplement,
not
exporter
as
an
input
plugin
for
fluent
bit,
meaning
that
now
the
current
version
of
fluent
bit
can
gather
the
same
metrics
that
not
exporter
and
now
allow
the
users
to
stop
using
the
exporter
and
just
use
fluid
for
the
same
purpose.
Of
course,
we
have
not
implemented
all
the
collectors
that
not
export
it
has
that
is
based
on
demand,
but
we
support
cpu
frequency.
This
stats,
vm
stats
memory
load
average.
A
Also
in
that
is
the
collection
point
now.
If
we
think
about
the
output,
how
do
we
expose
those
metrics
right?
We
implemented
our
own
primitives
exporter
plugin.
All
of
this
is
written
in
c
it
uses
a
very
low
cpu
and
memory
usage.
So
you
allow
to
the
github
backends
to
just
come
into
fluent
bit
and
scrape
this
metrics
for
you
actually
today
you're
using
not
exporter,
and
you
have
all
your
grafana
dashboards
and
you
just
switch
to
fluent
bit,
there's
no
breaking
change.
A
You
will
get
all
the
metrics
all
the
stuff
right
away
unless
I'm
going
to
get
back
you're
using
some
linux
collecting
uk.
That
is
not
here,
cdfs
or
any
kind
of
fancy
feature
that
most
of
people
are
not
using,
but
if
there's
something
missing,
just
let
us
know,
and
we
will
implement
it
and
from
a
configuration
perspective,
it's
pretty
simple.
You
just
enable
an
input
plugin.
A
This
is
like
a
typical
config
file
of
fluent
bit,
where
you
say,
enable
the
node,
export
and
matrix
plugin
scrape
the
matrix
every
two
seconds
and
then
just
have
an
output
plug-in,
which
is
called
prometheus
exporter
that
opens
an
http
endpoint
and
expose
those
metrics
internally.
All
this
is
routed
right,
so
we
have
a
bunch
of
input
plugins
for
metrics
and
different
ways
to
expose
these
metrics
out,
expose
or
send
it
out
to
a
different
place.
A
A
What
I'm
doing
here
is
just
starting
the
service
flashing
data
every
one
second
here
so
on
this
part,
we
just
enable
the
not
exported
input
plug-in
fluentpad.
We
expose
the
information
to
two
plugins.
Two
output
plugins
one
of
them
is
primitive
exporter,
which
opens
an
http
port
and
then
to
the
standard
output.
A
So
something
like
this
is
pretty
simple
and
then
this
command
is
going
to
start
shipping,
the
metrics
to
the
standard
output,
which
is
just
useless
for
production
right,
it's
just
for
demo
purpose,
but
the
good
thing
is
that
in
the
other
side
we
can
query
those
metrics
right
using
curl
and
use
a
call.
You
will
see
that
we
get
all
the
the
prometheus
style
formats,
so
this
is
same
for
embed
shipping
out
the
metrics
in
one
format,
standard
output
and
you
are
exposing
through
prometheus.
A
Now
what
impossibility
is
this
open?
And
I
think
that
it's
really
interesting
a
lot
a
lot.
A
lot
now.
Also
I
have
here
phil
williams,
just
one
of
the
contributors
just
send
out
a
plugin
to
a
I
don't
know:
do
you
use
nginx
for
some
reason:
nginx
a
web
server?
Okay,
luckily
you're
using
it
right.
If
you
use
nginx,
what
it's
doing
is
also
might
be
exposing
metrics
from
nginx
if
you're
using
nginx.
A
Basically,
what
you
do
is
to
deploy
the
one
program
called
nginx
spotter,
which
is
a
golem
plugin
made
by
the
nginx
company
that
exposed
nginx
plugins
for
the
prometus
world
right.
So
we
did
the
same
right
now
we
implemented
the
same
functionality
as
an
input
plugin
for
fluent
bit
that
was
just
merged.
Today
we
are
pasting
here.
You
know
the
the
open
example
of
those
to
the
standard
output,
but
if
I'm
not
wrong,
this
is
the
endpoint.
A
A
A
Now
there's
a
bunch
of
things
that
we
can
continue
doing
in
the
metric
space
and
we
got
more
ambitious
about
hey,
let's
implement
more
metrics
thing,
more
collectors,
because
there's
a
huge
benefit
and
we
get
a
great
support
from
the
prometeus
community.
Now
what
is
ready
now
not
exported
for
metrics
fluid
bit
metrics,
which
are
internal
metrics?
In
the
output
side
we
can
ship
metrics
to
influx
db,
promoter,
exporter,
remote
right
and
the
ongoing
work
is
that
also
we
are
replicating
not
exporting
metrics
for
windows.
A
This
is
also
not
play
from
prometheus,
but
we're
replicating
the
same
functionality
in
fluent
bet:
nginx
metrics,
which
is
ready
we're
going
to
collect
this.d,
also
the
ability
to
convert
logs
to
metrics,
because
there
are
many
applications
that
ship
logs
as
a
json,
but
you
wanted
to
get
them
into
prometheus.
So
how
do
you
handle
that
conversion
that
this
filter
called
logs
to
matrix
will
a
be
a
good
place
for
that
as
an
output
site,
we're
going
to
implement
splunk,
metrics,
data.metrics
and
cloudwatch?
A
Also,
we
are
working
on
this
kind
of
matrix
processor
because,
as
I
said
the
beginning,
you
don't
want
always
to
ship
all
your
metrics
when
you
want
us
to
process
them,
and
maybe
process
get
the
average
of
a
value
every
minute
and
set
that
average,
but
not
send
every
sample
every
second
right
which,
at
the
end
of
the
day,
with
a
hundred
of
nodes,
your
storage
start
to
grow
right,
and
that
is
more
expensive
and
the
future
right
right.
Now
we
standardize
on
open
metrics
because
and
prometheus.
A
B
A
A
symmetry
has
a
it's
a
standalone
library.
It's
hosted
at
calyptia,
open
source
project,
celebrity
that
we
wrote
as
a
company,
but
it's
hosted
as
a
shared
library.
So
you
can.
I
can
share
the
link
with
you.
After
this
talk
is
caliptia.symmetrics.
You
can
get
it
use
it.
We
have
unit
tests,
so
you
can
see
some
examples
of
how
this
works
so
yeah,
it's
kind
of
agnostic.
We
try
to
basically
make
it
agnostic
so.
C
A
Yeah
fluently
I'm
from
bit
and
fluently
10
years
old
flowing
bit
six
years
old
fluently,
a
thousand
plugins
flowing
bet,
100
right
now
in
temperatures
of
performance
fluent
is
10x
more
performance
in
our
latest
benchmarks.
So
unless
you
have
a
good
reason
to
use
fluency,
you
use
it.
But
if
you
want
more
performance
optimize
on
your
resources,
usage
just
switch
to
fluent
bit.
We
are
the
same
project,
the
same
family,
so
it
should
be
fine
to
stick
with
one
of
two,
because
both
are
bender
neutral.
A
D
C
E
A
Yeah,
so
we
talk
about
kubernetes
is
always
have
to
consider
about
the
the
context
right
and
what
give
us?
The
context
is
api
server.
So
we
have
those
filters
to
enrich
the
records
with
that
information
and
what
you
care
about
are
labels
right,
because
you
want
to
query
by
labels
so
the
goal
this
is
not
just
fully
designed,
but
it's
detected
record,
which
is
already
enriched
with
kubernetes
metadata
and
translate
those
labels
to
symmetrics
labels.
So
you
can
get
kind
of
the
same
experience.