►
From YouTube: Fluent Community Meeting
Description
Fluent Community Meeting
A
B
A
On
stage,
so,
if
you
have
questions
talk
about
the
roadmap
fluently
fluent
bet,
android
myself
will
be.
You
know
pretty
happy
to
talk
about
that,
so
to
get
a
more
casual
conversation,
if
you
want
so
we
will
have
this
session
for
about
20
minutes,
30
minutes
before
the
coffee
break.
So
maybe
a
good
time
for
feedback,
and
you
know
talk
more
about
the
things.
C
C
A
A
Okay,
for
example,
if
you
have
a
cluster
with
a
hundred
of
nodes
and
these
nodes
are
talking
to
a
cloud
service
most
of
the
big
companies
don't
want
to
share
secrets
with
each
node
because
of
security
reasons
right
yeah.
There
might
be
solutions
like
bolt
or
something
that
you
can
use
to
distribute
the
the
secrets,
but
some
security
policies
and
security
things
might
say
you
should
not
expose
secrets
to
the
nodes
right,
so
you
have
to
go
through
an
intermediate
layer
and
that's
why
sometimes
a
narrator
or
intermediate
layer
is
required
for
that
case.
A
The
other
case
is
like
my
cluster,
or
my
distributed
system
is
growing
so
much
now
I
have
a
thousand
tomorrow
might
have
ten
thousand
notes,
no
matter
if
there's
bare
metal
machines,
kubernetes
or
not,
if
all
of
these
agents,
for
example,
are
talking
to
my
local
deployment
of
storage
database
right.
Sometimes
this
database
cannot
handle
the
load
right
and
don't
have
all
the
tools
in
place
for
that,
because
it's
decided
that
I
will
need
to
manage
this
like
a
cluster
scale.
A
It
up
scale
it
down
and
it's
really
complex,
because
sometimes
you
don't
know
when
your
load
is
going
to
increase
it's
hard
to
predict
and
so
what
they
do.
They
put
the
regulator
because
they
said
in
the
irrigator.
I
will
have
a
huge
buffer
in
disk
and
I
will
make
sure
that
the
traffic
goes
kind
of
linear
linear
in
always
sending
the
same
amount
of
traffic
over
the
network.
A
Like
I
don't
know,
100
megabytes
per
second
always
the
same,
and
if
the
data
gets
delayed,
that's
fine,
so
it
depends
on
case
by
case
in
most,
for
example.
That's
why
the
influence
in
the
fluent
bed
side-
I
would
say
we
are
seeing
the
same
users
of
fluent
bait-
are
always
looking
for
more
performance.
A
D
D
Efficiency,
so
we
are
in
the
health,
health
industry
and
in
our
business
it
sometimes
is
more
important
that
the
things
are
logged.
So
logging
is
more
important
than
business
logic,
so,
for
instance,
prescriptions
we
have
to
log
every
percent
prescription
to
go
back
and
verify
it,
and
my
question
is
now
we
are
doing.
A
D
A
I
would
suggest
that,
if
your
worries
about
that
data
must
be
safe
pretty
quickly
and
in
an
efficient
way,
I
would
suggest
maybe
use
fluent
bed
instead
of
fluency
right.
Fluency
is
efficient,
but
when
you
hit
certain
load,
it
might
struggle
a
little
bit
and
fluency
is
also
a
single
thread
process
right.
A
But
you
can
enable
the
file
system
a
like
a
secondary
system
where
you're
going
to
get
a
resilient
copy
of
this
data
and
now
why
the
mechanism
flowing
bit
is
more
optimal
than
fluency,
because
we
use
a
similar
approach
than
databases.
We
use
memory,
mapped
files,
so
we
reduce
the
number
of
system,
calls
that
are
required
to
sync
and
write
the
data
to
disk.
A
We
found
that
there's
been
a
times
faster
and
less
cpu
intensive
when
it's
about
to
write
data
to
disk
second,
and
that
happens
in
one
thread
in
flow
embed.
Second,
in
the
output
side,
the
output
plugin
is
planned
or
elastic,
or
most
of
them
runs
in
a
separate
thread,
so
this
blocking
step
will
not
exist
in
there
right.
So,
if
you
are
writing
a
platform,
I
will
that
you
rely
on
data
safety
and
io.
A
Now,
once
you
get
the
data
using
that
first
safety
step
like
getting
the
data
in
a
safety
on
this
and
then
re
be
prepared
to
ship
the
data
out.
I
think
that
then
doesn't
matter
if
you
choose
splunk
s3,
because
you
will
have
a
backup
of
the
data
right.
One
of
the
problems
a
is
synchronization.
Sometimes
data
is
generated
so
fast
and
rotated
so
fast
that
the
agent
sometimes
could
not
be
able
to
pick
up
that
data
right.
It
depends
of
how
noisy
your
application
is,
but
yeah.
A
I
will
base
my
my
suggestion
on
that.
I
don't
know
if
that
answer
correctly,
but
if
I'm
going
to
think
about
a
platform
and
think
about
io
data
safety,
I
will
implement
fluent
bit
with
these
features,
enabled
file
system
threading,
the
output
and
yeah,
so
if
fluentd
will
use,
I
don't
know
for
that.
A
minimum
use
case
spend
like
a
hundred
megabytes
of
memory
flowing
between
my
use,
10.
D
Okay,
great
answer-
and
I
have
another
one
around
the
operator:
how
is
you
have
the
metric
collection?
Are
you
planning
to
add,
like
custom
resources
to
to
make
the
developers
able
to
create
collections
like
in
the
primitives
operator?
You
can
create
a
special
service,
monitor
that
automatically
apply
updates
the
the
scraping
of
parameters.
D
A
C
Yeah,
I
think,
with
with
the
fluent
operators
roadmap
on
metric
collection,
most
of
it's
geared
towards
it's
a
queue.
I
think
they
said
q3
q4
and
that's
the
cubesphere
team.
My
guess
is
when
you,
when
you
look
at
the
metric
collection
features
that
exist
today,
they're
really
geared
towards
having
very
firm
knowledge
about
what
you
want
to
collect
right,
whether
that's
node
exporter
or
the
prometheus
endpoint
with
the
operator.
C
C
Yeah,
and
actually
I
wanted
to
one
of
the
other
pieces
from
the
the
previous
question
too
about
like
whether
you
should
stream
the
data
or
buffer
to
disk
either
way
works
really.
Well,
if
you
think
about
kubernetes,
all
of
that
is
being
written
to
disk
anyways
right,
it's
all
a
container
log
and
we
continually
update
the
offset
so
in
the
chance
that
something
is
to
happen
in
the
daemon
set
or
the
process
dies
when
it
restarts.
C
It
knows
exactly
where
to
resume
from,
and
I
I
think
maybe
it's
it's
my
own
bias,
but
sometimes
when
you
know
exactly
where
you
left
off
there's
a
file
there,
you
feel
a
little
safer
right.
That
being
said,
the
chunks
are
just
the
same
exact
for
the
same
exact
data,
but
just
formatted
a
bit
different,
so
either
way
works.
Yeah.
E
B
C
E
E
C
Yeah,
it's
a
good
question.
You
know
I
and
I
don't
want
to
speak
on
behalf
of
the
cube
sphere
team,
but
one
of
the
thoughts
at
least
that
I
would
have
around
it
is
that
you
might,
you
essentially
are
constructing
a
single
pipeline
and
the
the
fluent
operator
is
taking
the
distinct
pieces
of
those
those
sources,
filters
and
outputs
and
then
just
bridging
them
them
all
together
and
while,
yes,
that
could
be
done
with
a
config
map,
you
might
want
to
update
the
sources
independently
and
not
affect
kind
of
the
remainder
of
the
the
pipeline.
C
So
I
think
that
was
one
of
the
the
intentions,
of
course,
not
not
trying
to
put
words
in
the
the
cubes,
your
folks
mouth,
but
yeah.
One
of
the.
I
think
that
was
one
of
the
big
things
and
also,
if
you
look
at
how
some
of
the
services
interact
with
those
crds,
they
are
very
much
like
drop
downs
of
hey
click,
your
source,
click,
your
filter,
click,
your
output,
and
I
think
that
works
well.
When
each
of
those
is
a
is
a
separate
custom
resource.
E
So
do
you
combine
all
these
crds
to
form
one
config
and
then
so?
But
if
you
want
to
change
like,
let's
say
one
of
the
sources
you
like,
let's
say
in
fluency,
you
don't
have
the
option
to
dynamically
reload
your
config
anyway,
you
will
have
to
restart
right.
So
how
does
that
affect
your
crd
like?
If
you
have
only
one
that
will
know
like
you
will
have
to
construct
the
config
again?
E
C
Fluid
is
one
fluenty
does
support
dynamic
reload,
but
I
get
what
you're
saying
like.
Even
if
you
change
four
or
five
sources,
you're
still
gonna
the
process
still
needs
to
be
updated.
Yeah.
I
think
that's,
that's
absolutely
true.
I
think
again
it
was
probably
more
for
the
convenience
of
just
having
each
of
those
objects
independently.
E
C
C
Those
sounds
pretty
good.
We
have
community
meetings
by
the
way
every
thursday
every
two
weeks,
thursdays.
We
do
a
rotation
two
in
north
america,
late
european
time
and
then
one
european
and
asia
pacific
time
so
actually
mickey's
led
on
one
of
those
meetings.
Before
I
lead
some,
we
have
pat,
who
leads
some
others,
so
it's
would
love
to
have
more
folks
join
us.
We
talk
about
road
map.