►
From YouTube: Advanced Logging with Fluent Bit - Eduardo Silva, Arm Treasure Data & Wesley Pettit, Amazon
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Advanced Logging with Fluent Bit - Eduardo Silva, Arm Treasure Data & Wesley Pettit, Amazon
Fluent Bit is a Fluentd sub-project that aims to solve the newest challenges in the cloud-native space. In this deep dive session, we will talk about its architecture, how data workflows operate and the ability to perform advanced stream processing on the edge. You will learn how to gather data value using the new SQL engine, data snapshots, aggregation windows, and basic machine learning.
https://sched.co/Zexe
A
Hello:
everyone
welcome
to
the
advanced
vlogging
with
fluence
session
at
qcon
2020
europe.
My
name
is
eduardo
silva
and,
together
with
a
wesley
pettit
from
amazon,
we're
fluent
maintainers
we're
going
to
deep
dive
into
fluid-based
internals
how
to
solve
the
vlogging
problems
and
everything
that
you
was
waiting.
A
A
Is
have
the
capability
to
perform
data
analysis,
but
to
perform
their
analysis,
you
need
to
collect
the
data
and
maybe
centralize
them
in
one
place.
A
common
use
case
is
to
have
a
hardware
or
a
piece
of
software
that
delivers
some
messages
on
break
or
some
blog
and
then
centralize.
This
information
like
in
a
database
or
a
cloud
service.
So
then
you
can
perform
your
own
data
analysis,
but
when
the
data
starts
scaling
up
also,
we
need
to
scale
up
our
logging
pipeline.
A
We
need
to
scale
up
our
aggregation
layer
and
also
the
analysis
get
affected
by
this,
because
now
you
have
more
data
to
process
and
sometimes
a
timing
performance
is
really
important
for
any
business
and
also
there
are
many
challenges
with
this,
because
data
comes
from
different
places.
Sometimes
we
can
collect
login
information
or
metrics
from
network
endpoints
from
tcp
udp
from
the
file
system,
from
the
local
machine,
or
also
through
services
like
systemd
or
others,
and
before
we
can
do
data
analysis.
A
We
need
to,
of
course,
convert
take
this
data
out
from
the
source
right
convert
this
data
from
maybe
instructor
format
to
a
structure.
Format
perform
data
enrichment,
because
sometimes
we
need
to
add
some
context
to
this
data
to
finally
be
able
to
deliver
this
data
to
a
destination
like
a
cloud
service
or
your
fancy
database,
and
if
we
think
about
kubernetes,
I
think
the
scenario
is
more
complex.
A
Kubernetes
is
a
distributed
environment,
your
application
lives
in
a
pot,
and
that
part
is
not
alone
in
a
node
can
have
many
pots
together
and
a
cluster
can
have
many
nodes.
So
if
your
application
is
just
in
one
pot
and
may
or
may
n
different
replicas,
how
do
you
correlate
all
this
information
back
together
in
a
database?
So
you
can
do
data
analysis,
and
that
is
one
of
the
complexities
of
this.
A
A
common
workflow
for
login.
Imagine
that
you
have
like
a
a
gmail
file,
which
you
have
just
one
container.
This
contains
reading
data
to
the
standard
output
or
standard
error
interface.
Okay.
So
as
an
example,
I
have
a
jbl
file
on
the
left,
which
is
called
apache
logs,
that
just
generate
random
apache
logs
messages
and
at
the
end
you
get
to
some
raw
messages
like
the
one
that
you
have
the
right
with
an
ip
address
and
time
sum
and
the
whole
message
from
there
from
the
http
protocol,
but
in
kubernetes
or
any
containerized
environment.
A
That
message
that
was
generated
by
the
container
is
redirected
most
of
the
time
to
the
file
system.
Sometimes
it's
handled
by
journal
d
in
a
different
way,
but
by
default
it
goes
to
a
file
system
to
a
container
identification
that
has
the
port
name,
the
namespace
in
a
normal
log
file
that
also
not
do
not
only
contain.
B
A
Was
generated
from
which
node,
which
host
and
do
we
have
any
labels?
Do
we
have
any
annotations
that
comes
from
any
specific
context,
so
this
information
alone
is
not
useful
enough.
We
need
to
correlate
all
this
information
together
and
because,
at
the
end
with
this
information,
and
then
we
want
to
have
something
more
complete
like
this,
where
we
have
all
the
kubernetes
context.
We
have
the
message.
A
For
example,
we
have
the
host
where
this
data
was
generated
from
the
container
name,
the
docker
id,
because
all
this
information
is
relevant
to
for
us
to
be
able
to
perform
data
analysis
once
we
centralize
the
data
in
our
database,
and
that
is
one
a
one
of
the
solutions
fluent
fluently
is
a
log
processor
that
is
part
of
the
fluency
family.
We
are
proud
to
say
that
fluent
bait
is
a
cncf
supply
under
the
umbrella
of
fluency
and,
of
course,
a
fully
apache
license.
A
It
was
created
in
2015
originally
for
embedded
linux,
but
then
it
quickly
evolved
for
the
cloud
space
and
nowadays
it's
almost
everywhere
it's
written
in
c
language,
and
that's
one
of
the
main
reasons,
because
it
has
a
very
low
memory
and
cpu
footprint.
It
has
a
plugable
architecture.
We
have
more
than
60
plugins
available
made
by
the
community,
and
these
plugins
allows
us
to
collect
data
from
different
source
from
the
to
filter
data
or
send
data
out
to
different
destinations.
A
A
Do
the
data
transformation
and
apply
all
your
logic
that
is
necessary
in
kubernetes,
likely
you
deploy
fluent
as
a
demo
set,
but
also
you
can
deploy
it
as
a
sidecar.
But
here
in
the
example,
we
deployed
f1b
as
a
demonstration
running
the
node,
where
it's
able
to
collect
all
the
logs
from
the
node
to
finally
correlate
all
this
information
back
with
the
api
server,
where
the
you
can
get
information
like
a
labels
annotations.
A
So
your
final
record
can
have
all
the
information
that
is
necessary
for
the
data
analysis,
we're
going
to
run
a
pretty
quickly
demo
to
see
how
this
works.
I'm
going
to
share
my
screen,
I
started
the
recording
I'm
going
to
start
the
demo
in
three
two
one
here
in
the
terminal,
the
demo
that
we're
going
to
do
it's
a
pretty
basic
demo.
A
Basically,
on
my
left
hand,
I'm
running
mini
cube,
mini
cube
and
on
the
right
one,
I'm
going
to
run
in
my
local
machine
fluent
bed,
but
this
time
flowing
bit,
which
is
running
the
right
paint,
is
basically
will
work
as
an
aggregator
collect
any
message
that
comes
from
any
cluster
right
process.
It
reform
it
to
json
and
bring
it
out
to
the
standard
output.
A
A
A
Okay,
this
is
just
running
locally
because
we
are
not
shipping
out
the
messages
we're
just
querying
the
local
intents
of
mini
cube.
So
what
we're
going
to
do
now
is
to
deploy
fluid.
I
just
prepare
and
skip
to
make
it
shorter.
When
we
ingest
the
config
map
we
deploy
the
demon
set
for
mini
cube
and
we
just
query
the
status
of
it
after
this
deployment.
After
a
few
seconds,
we
will
see
that
in
our
right
pane
the
data
will
start
flowing
and
being
formatted
in
json.
A
I'm
going
to
stop
right
now,
I'm
going
to
delete
that
pot,
so
we
can
do
a
clear
analysis
on
the
right
side,
as
you
can
see,
for
example,
on
this
record,
we
have
the
date.
We
have
the
original
log,
the
stream
and
the
time
stamp
from
that
original
record,
and
also
we
have
the
whole
kubernetes
metadata,
which
is
quite
important
because
we
get
the
pot
name,
the
name,
space
name
for
id
labels,
host
container
name
and
so
on
and
well.
The
original
messages
is
here
in
the
second
key,
which
is
called
log.
A
Now,
I'm
going
to
show
another
feature
of
fluid
which
support
a
custom
parsing
based
on
live
and
annotations.
So
I
have
here
the
same
apache
log
container
definition,
but
I'm
adding
a
parser
in
an
annotation.
Basically,
I'm
saying
please
parse
this.
All
these
records
from
this
container
using
the
apache,
parses
and
apache
parasite
is
predefined
in
the
fluid
bed
configuration
so
as
soon
as
I
deploy.
This
fluid
will
get
aware
of
all
these,
our
apache
dot
messages.
It
will
structure
them
and
send
it
out
to
my
aggregator,
which
is
running
on
the
right
side.
A
For
example,
if
we
can
take
a
look
at
this
log,
it's
pretty
much
the
same.
We
have
the
date,
the
log,
the
stream
the
time,
but
also
now
we
have
assisted
flowing
a
new,
a
new
map
which
contains
the
data
processor
coming
from
the
original
log
message.
So
if
you
go
up,
you
will
see
that
we
have
the
ip
address
or
the
host.
We
have
the
user,
the
method,
the
path
that
was
accessed,
the
return
status
cost
and
the
size.
This
is
a
unique
feature
that
is
provided
in
fluent
bit.
A
A
B
A
One
of
the
major
changes,
also
in
the
core,
is
ability
to
have
a
more
configurable
and
reliable
networking
functions
and
before
this
fluid
bit
was
didn't,
have
the
option
to
send
data
through
keep
alive
connections
right
now,
but
right
now
you
can
reuse,
keep
alive
connections.
You
can
reuse
all
your
tls
hand
checks.
So,
of
course
you
can
send
data
fastest.
This
was
not
a
need
years
ago,
but
nowadays
it
is,
since
people
is
mostly
streaming
data.
Every
second.
A
Also,
we
have
a
full
windows
support
version
and
on
this
version
we
we
have
implemented
the
whole
windows
service,
so
you
can
run
fluid
and
windows
like
a
service,
also
the
plugin
to
collect
data
from
the
windows
event.
Log
has
been
highly
improved.
In
addition,
now
you
can
run
fluid
for
windows
on
kubernetes
without
any
problem.
We
did
a
couple
of
improvements.
A
Also,
our
community
has
contributed
a
lot
of
ways
to
monitor
a
fluent
bed.
So
right
now
we
have
in
our
documentation
a
couple
of
examples
on
how
to
run
your
own
grafana
dashboards,
so
you
can
take
advantage
of
the
whole
monitoring,
also
from
the
same
pipeline
that
you
are
working
with
in
the
part
of
the
storage.
A
Also,
how
much
this
space
are
you
using
and
how
much
memory
up
in
memory
are
you
consuming
for
all
your
data
ingestion
and
delivery
as
part
of
the
enterprise
and
partnerships
with
it,
we're
happy
to
say
that
we
have
a
new
new
connector
so
improve
connector,
for
example,
for
the
amazon
elasticsearch
service,
we
have
a
new
plugin
for
the
amazon
cloud
watch.
Wes
is
going
to
talk
more
about
it
and
also
new
enterprise,
connector
for
locked
dna
and
new
relic
services.
A
As
an
overall
status
of
the
project,
and
just
in
2020
or
half
of
this
year,
right
now
we're
hitting
more
than
100
million
deployments,
and
this
is
just
an
insane
growth
of
the
project.
So
every
day
we
have
more
than
500
000
deployments
from
different
clusters
and
everywhere
in
the
world.
We
don't
have
visibility,
who
or
from
where
we
just
have.
We
know
that
we
are
getting
all
these
dollars
every
day
and,
of
course,
this
is
thanks
to
the
community
and
the
traction
that
we
are
getting
and
in
the
enterprise.
B
B
B
So,
as
I
mentioned,
aws
has
its
own
like
custom,
unique
signing
mechanism
that
we
came
up
with
to
fit
the
scale
of
aws,
and
there
are
many
many
sources
that
you
can
have
for
credentials
depending
on
where
in
aws
you're
running,
and
so
this
was
a
blocker
for
me
to
contribute
plugins
to
the
core
fluid
bit
but
new
in
flintbit
1.5.
There
is
a
core
library
for
aws
authentication,
signing
and
credentials.
B
So,
basically,
last
year
eduardo
and
I
met
at
kubecon
and
then
aws
re
invent.
We
talked,
and
then
I
took
a
long
vacation
in
december
and
during
that
time
I
day
and
night
worked
writing
code
to
create
this
library,
a
custom
library
influent
bit
to
do
authentication
and
signing,
as
you
saw
in
the
previous
slide,
it
ended
up
being
almost
7
000
lines
of
code.
It
was,
it
was
pretty
huge,
but
it's
finally
now
released
and
it
works,
and
so
I'm
going
to
talk
about
what
you
can
do
with
it.
B
B
So
amazon
electric
search
service
is,
you
know
it's
just
a
a
hosted
version
of
elasticsearch,
but
it
has
authentication
in
front
of
it.
So
we
needed
this
library.
So,
as
you
can
see
here,
there
are
new
fields,
it
was
off
aws
region.
You
also
turn
tls
on,
and
one
thing
I
want
to
note
is
the
port
is
usually
443
if
you're,
using
amazon
elasticsearch
and
for
the
host
you
do
not
put
the
protocol,
you
don't
put
the
http
https
in
there.
B
B
I
am
role
that
it
will
make
an
sts
assume
roll
call
on
and
so
that
you
can
use
an
alternate
role
to
put
to
elasticsearch
check
out
the
documentation.
If
you
want
to
learn
more
about
that,
then
so
you
know.
As
I
said
last
year,
I
created
a
external
plugin
in
go
for
cloudwatch.
I
rewrote
that
plugin
and
contributed
to
the
core
fluid
bit
in
c,
which
you
can
see
here.
This
is
a
configuration
for
it.
It
supports
all
the
same
options.
B
B
B
We
also
have
seen
evidence
that
the
the
max
throughput
achievable
with
this
new
plug-in
is
significantly
higher
than
the
golang
plug-in.
I
had
said
that
I
was
going
to
try
to
quantify
that
for
this
talk.
Unfortunately,
things
I
got
busy
and
I
was
not
able
to
get
hard
numbers,
but
maybe
maybe
next
year
the
future
talk
we'll
have
we'll
have
more
on
that
anyway,
so
long-term
things
that
I'm
thinking
of
working
on
so
I'm
I
want
to
rewrite
all
of
the
go
plug-ins
in
in
c
and
contribute
them
to
the
core
fluid
bits.
B
We
have
everything
high
performance
and
centralized
in
the
philippine
code
base.
Then
we
can
deprecate
the
go
plug-ins,
alias
the
names
of
the
old
plug-ins
into
the
c
plug-in,
so
that
you
can
have
a
clean
migration
for
all
users
from
the
go
plugins
to
see
plug-ins
that
can
be
entirely
transparent
because
they
support
the
exact
same
features.
B
The
timeline
for
all
this
is
uncertain,
though,
and
as
I
say
here,
don't
quote
me
on
it
like
there's
no
guarantee,
but
this
is
what
I'm
thinking
so
also
in
fluid
bit
1.4,
I
built
an
ec2
instance
metadata
filter
that
adds
a
your
instance
id
and
availability
zone
to
your
logs.
If
you
want
it,
I
think
in
the
future,
maybe
we'll
expand
that
I
might
also
work
on
an
ecs
task:
slash
service,
cluster
metadata
filter
as
well,
we'll
see
and
then
in
terms
of
outputs.
B
I'm
thinking
eventually
could
maybe
get
all
six
of
those
things
that
you
see
there
in
the
core
fluent
bit.
So
all
of
the
existing
ones
also
elasticsearch,
which
we
already
launched,
I'm
now
working
on
s3,
I'm
thinking,
maybe
amazon
eventbridge,
might
be
useful
too.
I'm
not
sure
interested
in
feedback
on
that.
However,
you
want
to
send
feedback
to
me
issues
or
twitter
or
whatever,
or
this
or
the
fluent
slack,
but
interested
in
seeing
if
people
would
be
find
that
useful.
B
What
am
I
working
on
right
now
so
right
now,
I'm
working
on
amazon,
s3
output,
output,
support,
there's
an
issue
for
it
on
the
fluent
bit.
Github
check
that
out.
If
you
have
suggestions
that,
let's
see
since
it
is
in
august
that
this
talk
is
being
streamed,
hopefully
that
will
actually
be
nearly
done
by
then
and
will
be
releasing
fairly
soon.
We'll
see
our
plan
is
sometime
in
september.
B
Hopefully,
so
I
put
a
lot
of
thought
into
the
s3
output
so
the
way
that
the
the
fluency
fluentd
s3
output
works.
Is
it
buffers
files
locally
and
then
it
uploads
them
all
in
one
go
to
s3,
and
then
that's
okay,
but
it's
not
perfect
because
you
know,
while
you're
buffering
on
disk
there
is
this
risk
of
data
loss
right.
B
If
fluent
bit
goes
down
or
fluent
d
goes
down
and
you
lose
those
files,
if
you
don't
have
a
reliable
disk,
like
you,
maybe
you're
running
in
a
more
ephemeral
via
environment
like
a
serverless
environment,
you
can't
really
trust
the
disk.
It
doesn't
really
work.
So
my
goal
is
to
make
this
s3
plug-in
be
more
sort
of
like
a
streaming
model.
B
So
it's
going
to
use
multi-part
uploads,
so
the
multi-part
upload
api
basically
lets
you
send
data
in
very
small
chunks
to
s3,
so
you
can
break
up
a
file
into
pieces
and
send
it
in
chunks.
But
the
thing
is,
it
doesn't
require
that
you
actually
have
all
of
the
file
ready.
When
you
want
to
send
it,
you
can,
as
you
get
data
stream
up
stream
chunks
to
s3,
and
that's
what
your
my
bad
diagram
is
trying
to
show
with
the
puzzle
pieces
going
into
the
bucket.
B
Is
that
as
fluid
bit
is
getting
data,
it's
adding
a
new
piece
to
the
bucket
and
then
once
it
reaches
the
file
size
that
you
want.
It
will
tell
s3
to
concatenate
those
together
and
create
a
final
file.
So
basically,
the
long
and
short
of
it
is
that
you're
streaming
to
s3
you're,
not
buffering
more
than
a
few
megabytes
of
data
locally.
B
B
You
have
to
restart
it,
so
here
is
an
output
definition
that
I'm
thinking
of,
as
you
can
see
here,
you
can
set
the
file
size
that
you
want
in
s3
and
remember
note
that,
like,
as
I
said,
it
will
be
streaming
and
uploading
in
little
chunks,
but
the
final
file
that
you
see
will
be
whatever
size
you
pick.
You
can
also
specify
a
timeout,
so
you
can
say,
like
every
60
minutes,
create
a
new
file
on
s3.
I
can
do
that
as
well.
B
So,
okay,
if
you
are
an
awc
user
and
you
want
to
get
help
with
fluent
bit
how
how?
How
should?
How
do
you
go
about
it?
We
have
really
really
high
adoption
of
fluent
bit,
so
we
get
a
lot
of
questions
and
issues.
The
preferred
mode
is
to
open
an
issue
on
the
aws
aws
for
fluid
bit
repo,
because
I
have
a
bunch
of
folks
at
aws
who
I
have
trained
to
understand
fluid
bit,
and
we
can
all
work
on
answering
your
questions.
B
B
So
another
interesting
thing
that
I
want
to
talk
about.
This
is
kind
of
switching
gears.
This
is
moving
away
from
aws.
This
is
taking
off
my
enterprise
hat
and
putting
on
my
just
pure
open
source
hat
recently
I
have
been
working
with
the
folks
at
the
open
telemetry
project,
so
open
telemetry
is
a
new
cncf
project.
It's
an
incubating
project
and
its
goal
is
to
create
a
standard
set
of
sdks
and
specifications
for
metrics
and
traces,
and
maybe
eventually
logs
too,
that
basically
all
of
the
vendors
will
support.
B
So
it's
it's
very
exciting
project,
I'm
very
glad
that
exists
and
very
happy
to
work
with
them.
The
little
bit
that
I
have
so
they
have
recently
started
working
on
defining
a
log
data
model
which
might
become
maybe
a
standard
schema
for
log
data,
a
standard
kind
of
structured
model
for
logs
that's
its
goal.
B
But
I
want
to
talk
about
what
it
might,
how
this
model
works
and
what
it
might
look
like
if
we
supported
it
in
fluid
bit.
So
I
always
say
I
I
talked
to
the
folks
who
worked
on
this
model,
but
I
can't
take
any
credit
for
it.
It
was
primarily
created
by
an
open,
telemetry
maintainer
named
tigran
nigerian.
B
I
think
I
got
his
name
correct.
I
apologize
if
he's
watching
and
I
did
not
get
it.
I
don't
know
if
he
is
actually
if
he
will
be
watching
this
talk.
Who
knows
I'll,
try
to
tell
him
to
watch
it
anyway?
Okay,
so
he
the
log
data
model
they
came
up
with.
It
has
a
couple
different
fields,
structured
fields.
The
goal
is
to
standardize.
B
Structured
logging,
basically
so
structure
logging
is
great
because
it
makes
it
easier
to
process
and
analyze
your
logs,
because
the
data
is
an
instruction
format,
but
the
ideal
case
would
be
that
there's
like
a
standard
way
to
structure
them,
because
if
all,
if
you
structure
your
logs
in
different
ways
with
different
field,
names,
you're
still
kind
of
in
a
bit
of
a
miss
mess,
and
so
that's
the
goal.
So
you
have
a
time
stamp.
Unix
nanoseconds!
B
You
have
fields
for
correlation
with
traces
and
spans.
You
have
a
standard
way
to
represent
severity,
a
name
for
the
log
like
an
event
name,
you
have
a
body
which
is
for
unstructured,
not
machine,
readable,
but
human
readable
data.
You
have
attributes
which
are
for
structured,
like
key
value
pairs
that
might
be
machine,
readable
and
part
of
the
goal
of
this
schema
is
to
eventually
create
a
standard
key
names
for
basically
any
type
of
data
that
you
want
might
want
to
put
in
there.
B
So
I
don't
know
like
kubernetes
metadata
ip
address
like
there
will
be
a
standard
field,
name
that
you
always
use
for
the
whatever
metadata
that
you're
adding
to
your
logs
and
then
the
resource,
that's
actually
where
the
kubernetes
metadata
would
go.
It
would
be
a
standard
way
to
with
key
value
pairs
represent
where
a
log
came
from.
B
So
here's
an
example
log.
So,
as
you
can
see
here,
there's
the
timestamp,
then
there's
a
set
of
attributes
like
I
said
these
are
key
value
pairs.
The
ideas
eventually
have
very
clearly
defined
semantic
conventions
for
how
you
name
those
key
pairs
so
that
they
are
are
really
uniform
across.
You
know
all
of
your
applications,
then
you
have
the
resource,
which
is
where
the
log
came
from
again
same
thing.
B
Eventually,
we
want
to
create
a
very
standard
way
of
naming
that
naming
all
of
those
things,
and
then
we
have
a
couple
more
fields,
so
we
have
a
severity
which
has
both
a
text,
description
and
a
numerical
description,
and
then
that's
about
it.
So
what
would
it
look
like
to
support
this
in
fluid
bits?
So
this
is
something
that
we're
thinking
about.
B
We
probably
won't
do
it
until
later
this
year,
or
maybe
the
beginning
of
next
year,
because
open
telemetry,
like
I
said
it's
incubating
it's
extremely
new,
this
log
data
model
was
just
created.
I
don't
think
it's
really
been
adopted
or
used
by
anybody.
Yet
so,
basically,
the
kubernetes
filter
or
the
ecs
met
ec2
metadata
filter.
Anything
that
adds
metadata
for
where
a
log
came
from
you'd
want
to
add
that
to
the
resource
in
our
tail
plug-in
in
fluid
bit.
B
B
B
A
A
B
B
A
B
I
see
okay,
so
she's,
not
she's,
not
here
on
audio.
I
do
know,
I'm
not
sure
if
this
was
related
or
helped,
but
I
knew
that
know
that
afterwards,
for
a
few
minutes
at
least,
we
will
be
available
in
the
two
dash
kubecon
maintainer
channel
in
the
cncf
slack,
and
you
can
ask
us
questions
there.
Maybe
we
can
maybe
we'll
have
an
answer
there
for
that.
Okay,
so
next
time
can
it
be
used
as
an
exporter
for
prometheus.
B
A
Before
we
forget
the
wesley,
we
have
a
hundred
people,
and
so
basically
we
have
a
demo
on
this
presentation
that
for
some
we
got
a
technical
issue.
So
the
if
you
watch
not
again,
but
if
you
watch
the
presentation
again
around
minute
five,
you
will
get
the
demo
update
so
watch
on
demand
in
a
couple
of
hours
and
that
will
be
available.
A
B
A
B
Yeah,
it
depends
upon
your
exact
level
of
usage
and
the
plugin
you're,
using
like
I
mentioned
with
the
plugins
that
I
built
if
you're
using
the
older
golang
versions,
something
maybe
more
like
100.
Megabytes
of
memories
is
probably
a
good
safe.
Number
I'd,
probably
still
actually
stick
with
something
in
a
range
of
150,
but
with
the
most
of
the
plugins,
the
ones
that
are
in
the
core
that
are
in
c.
You
really
should,
realistically,
they
shouldn't
be
using
more
than
50
unless
you're
just
getting
extremely
high
high
load.
B
Okay,
so
we're
being
told
this
is
on
the
question
of
where
are
the
slides?
The
slides
can
be
found
in
sketch,
like
like
the
word
schedule,
but
so
I
actually
don't
know
what
that
means.
I've
done
a
bad
job
of
paying
attention
to
how
the
kubecon
virtual
works,
but
hopefully
you
guys
will
all
in
the
audience.
Well
now.
A
B
I'm
seeing
can
fluent
bit
buffer
logs
if
the
target
host,
for
example,
elasticsearch,
is
unreachable
for
a
while.
Yes,
that
is
true,
it
has
buffering
capabilities
same
as
fluenty.
It
works
a
little
bit
differently
if
you,
google,
for
fluent
bit
buffering,
there's
a
whole
section
in
the
documentation
that
goes
over
it.
B
B
Yes,
okay,
so
this
is
not
really
honestly
a
fluent
big
question,
but
I'll
still
answer
it
anyway.
I
am
also
the
creator
of
fire
lens.
In
addition
to
being
the
aws
flint
bit
maintainer,
I
basically
do
container
logging
at
aws.
That's
my
specialty.
We
are
working
on
that.
We
want
to
build
some
sort
of
better
config
mechanism
in
aws
fargate
for
fluent
bit.