►
From YouTube: Fluent Bit: Logs, OpenMetrics, and OpenTelemetry all-in-one - Eduardo Silva & Anurag Gupta, Calyptia
Description
Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). 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.
Fluent Bit: Logs, OpenMetrics, and OpenTelemetry all-in-one - Eduardo Silva & Anurag Gupta, Calyptia
Observability continues to be an interesting challenge, data collection for logs, metrics, and traces is an expensive operation and different approaches exist. Fluentd and Fluent Bit have been the long-term defacto standard for logging, but recently the projects expanded their scope to support and assist with Metrics and Traces. Fluent Bit now supports data collection, aggregation, and delivery for the world of OpenMetrics (Prometheus) and OpenTelemetry. In this presentation, you will learn how to collect and aggregate Logs, Metrics, and Traces all together without losing control of your data by connecting different protocols at scale. Fluentd and Fluent Bit embraces OpenMetrics and OpenTelemetry vision, come to learn how to optimize your observability pipelines, and implement the best practices for your production environments.
A
A
A
B
B
The
way
we've
begun
to
think
about
these
projects
is
really
a
swiss
army
knife
for
observability.
How
do
we
look
at
all
this
data
start
slicing
and
dicing
it,
making
it
very
accessible
as
part
of
the
ecosystem
and
how
these
projects
start
to
fit
together
kind
of
in
the
in
the
broader
set
of
the
ecosystem
right,
many
folks,
first
time
at
cubecon,
so
many
projects
going
around?
How
do
we
look
at
this
ecosystem
at
a
little
bit
of
a
broader
level?.
A
You
know
your
application,
how
this
stuff
is
working
right
at
the
end
of
the
day,
managing
infrastructure
or
managing
the
services
that
run
behind
the
scenes.
You
don't
want
to
be
worried
about
that
right.
It's
like,
if
you're
using
a
linux
system,
you
don't
want
to
know
how
glfc
is
working
right.
You
just
want
to
make
sure
that
the
application
is
running.
It's
getting
the
right
resources,
memory,
allocation,
everything
and
if
we
go
to
a
higher
level
from
observability,
your
final
goal
always
will
be.
How
do
I
analyze
my
data
right?
A
A
I
I
I
guess
that
most
of
you
already
working
in
in
some
companies
and
I'm
pretty
sure
that
99
of
you
will
say
we
don't
have
just
one
solution
for
everything
right.
You
just
don't
have
a
mysql.
Maybe
you
also
have
positive
sql,
you
have
readies
and
your
architectures
always
grows.
They
always
evolve
and
all
this
transition
there
are
always
more
components
being
added
and
at
some
point
it's
and
from
a
development
perspective.
The
same
thing
happens:
you
will
get
some
applications
written
in
java,
some
others
in
node.js
with
javascript.
A
So
you
face
this
problem
that
we
have
different
natures
or
different
origins
and,
in
our
case
observability
different
source
of
information
and
a
at
some
point
you
will.
You
will
find
that
you
are
instrumental
with
primitives,
maybe
you're
using
fluency
you're
using
fluent
bit,
but
the
goal
is
always
the
same.
How
do
I
analyze
my
data,
but
you
have
to
fix
the
first
problem,
so
we
try
to
see
that
a
and
communicate
that
the
fluent
ecosystem,
as
the
name
say,
is
fluent.
A
A
So,
no
matter
what
you're
running
your
applications,
no
matter
what
you're
using
for
instrumentation
and
the
instrumentation
at
the
end,
you
can
use
fluent
to
connect
different
ecosystems
so
and-
and
our
ecosystem
has
a
really
interesting
thing-
the
first
one.
Well,
everybody
knows
that
it's
all
fully
open
source,
but
one
of
the
things
that
you
might
not
realize-
and
you
might
are
facing
this
in
the
enterprise-
is
that
sometimes
exist
with
the
concept
of
vendor
lock-in.
A
Because
since
your
goal
is
to
do
analysis
makes
sense,
you're
going
to
say,
oh
I'm
going
to
invest
in
splunk,
elastic,
open
search,
and
then
they
will
tell
you.
These
are
the
tools
that
you
need
to
do
all
this
data
collection
right,
but
some
of
them
are
not
real,
are
open
source,
but
they
will
tell
you,
okay,
if
you
use
this,
you
get
married
to
this
technology
to
this
stack.
That
is
a
vendor
looking
because,
after
one
year
when
you
went
to
switch,
it
will
be
a
huge
pain.
What
about?
If
now,
you
think?
A
Oh
there's,
a
new
fancy
database
that
I
want
to
use
right.
What
would
be
the
solution?
Oh
you
just
no
need
to
replace
the
database.
You
also
have
to
replace
all
your
agents
and
that
becomes
a
problem.
The
fluent
ecosystem
tried
to
be
to
avoid
this
vendor.
Looking
for
you,
and,
as
I
said
a
couple
of
times,
we
are
agnostic,
no
matter
what
is
the
product?
No
matter.
What
is
the
project
or
the
ecosystem
or
the
tool
inside
the
same
cncf
stack?
We
try
to
be
compatible
with
all
the
standards
and
in
the
fluent
ecosystem.
A
Well,
if
you
are
using
it,
I
think
that
is
extra
information
who
use
fluent
bet
nowadays,
its
standards
influence
amazon,
google,
microsoft
azure.
When
cloud
providers
choose
something
is
because
it's
production,
great
and
now
a
quick
recap
of
the
past
present
and
future
of
the
fluent
deep
project
and
ecosystem
that
we
have.
You
know
everything
started
with
fluentd
almost
11
years
ago,
a
solution
to
collect
logs
for
our
x
company
to
send
all
the
data
to
the
cloud
we
made
it
open
source
and
this
break
succeeded.
A
A
It's
really
expensive
and
cpu
intensive
in
general.
At
the
same
time,
we
started
doing
some
innovation.
We
come
up
with
the
next
generation
of
tool
which
was
fluent
part
of
the
same
family,
but
reading
in
c
optimizer
for
performance
and
making
sure
that
it
was
a
really
good
solution
for
everybody,
but
our
same
philosophy,
philosophy.
We
didn't
want
to
have
a
drop-in
replacement
right.
We
said
that
fluent
bed
is
going
to
integrate
with
fluency
or
you
can
use
them
separately
or
just
independently
and
now.
A
Most
of
you
might
creating
your
own
microservices,
your
own
application,
and
you
are
just
instrumenting
by
using
or
sending
the
data
to
a
custom.
Http
endpoint,
for
example,
fluentd
supports
like
a
thousand
plugins
connecting
between
connectors
source
destinations
in
a
fluent
bed.
We
support
a
hundred,
but
as
of
now,
I
think
we
cannot
get
any
more
requirements
right.
We
support
splunk,
elastic,
open
search,
http
and
many
others,
and
the
highlights
of
production
rate
high
performance.
A
A
You
can
write
a
tool
that
can
process
millions
of
messages
per
second
right,
but
maybe
you
need
a
cluster
of
five
machines
to
process
that
right.
So
we
always
try
to
optimize
for
performance
and
see
how
much
how
far
we
can
go
with
fluent
bet,
and
we
have
demonstrated
that
in
the
last
year
we
pretty
much
started
doing
4x
or
5x
times
in
performance
improvements
by
doing
threading,
optimizing,
the
core
memory
allocations
and
so
on,
and
how
you
can
use
fluid.
There's
a
couple
of
distributions.
A
Of
course,
the
the
upstream
version
is
that
what
most
people
use
you
can
get
it
from
docker
hub.
You
can
get
your
packages
for
ubuntu
sent
to
us.
We
have
aws
that
they
have
their
own
distribution
of
fluent
bed,
which
is
similar
upstream,
but
the
difference
that
they
they
optimize
for
their
own
amazon
services
connectors.
A
A
We
have
our
own
fluent
bit
distribution
too,
but
this
is
mostly
tied
for
as
an
lts
version
right
enterprise
ready.
So
if
you're
going
to
run
a
fluent
bed-
and
you
want
to
make
sure
that
there's
no
breaking
change
for
the
next
18
months,
you
can
use
a
kalitia
for
fluent
bet
and
google
ops
agent,
google
created
this
own
agent
for
their
own
customers.
That
has
two
components
has
fluent
bet
for
all
the
lock
management
and
they
have
a
small
open,
telemetry
agent
for
metrics
and
traces,
so
they
ship
this
for
their
own
customers.
A
So
if
you're,
a
google
customer,
you
can
use
google
ops
agent,
but
at
the
end
of
the
day
you
can
do
the
same
with
the
upstream
version
right.
So
we're
not
trying
to
post
what
to
use
just
go
with
upstream
and
then,
if
you
need
something
more
specific
yeah,
it's
like
I
do
use
vanilla
kubernetes.
Do
I
use
openshift,
you
know
it's
a
matter
of
personal
decision
and
yeah.
This
is
fluent.
We
aim
to
collect
data
from
different
sources
and
send
that
data
to
multiple
destinations.
We
do
buffering
retry
logic.
A
We
back
up
in
the
file
system
in
a
very
optimized
set
a
way
now,
as
a
community
based
fluent
bit,
has
been
deployed
and
cncf,
and
all
this
like
one
more
more
than
one
billion
times
in
total
right
and
we
didn't
put
the
fraction
here,
but
this
is
about
order
of
millions
right.
So
last
year
we
pretty
much
600
millions
and
you
can
see
how
the
number
of
deployments
today
this
year
is
going.
A
So
this
is
just
insane-
and
this
is
thanks
to
the
community
and
people
who's
here
and
actually
most
of
the
features
that
you
see
in
fluent
bed
in
fluentd
is
because
of
the
feedback
that
you
provide
after
these
sessions
in
the
conference.
Everything
kubernetes,
filter,
lua,
scripting
and
I
don't
know,
elasticsearch
open
search.
All
of
that.
So
don't
think
that
you're
going
to
just
consume
information
here.
You
can
also
help
us
to
build
the
roadmap
of
what
will
be
the
future
of
the
project
and
that's
really
important
so
investments
everybody
cares
about.
A
Oh,
this
is
a
program
reading
in
c
right
memory.
Safety
is
an
issue.
What
about
languages?
It's
a
common
topic,
so
the
only
thing
that
we
can
do
is
to
making
sure
that
every
version
gets
a
most
tested,
every
time,
more
improvement
and
so
on.
So
we
invested
a
lot
on
ci
cd
regression
checks,
sanitization,
making
sure
that
it's
running
five
fine
on
all
architectures
a
we
have
a
security
team
working
with
a
google
oss
fashion
technologies.
A
We
gotta
talk
about
that
in
fluentcon,
which
was
our
conference
this
monday,
pretty
much
fluentbit
is
being
tested
with
random
input
on
different
interfaces,
different
functions
and
trying
to
make
it
crash
yeah
the
first
year
it
crashes
like
crazy
right,
but
this
has
been
running
24x7
for
more
than
one
year
and
most
of
these
corner
cases.
This
box
has
been
fixed
already
and
we
started
solving
the
logs
problem,
but
we
said
we
just
saw
blocks
right
and
I
think
that
we
think
that
matrix
is
interesting
and
there's
more
problems.
A
B
Thanks,
edward
and
yeah,
if
I,
if
I
talk
about
logs,
metrics
and
traces,
you
know
when,
when
we
talked
to
the
community,
what
we
were
finding
is
folks
had
a
bunch
of
common
use
cases.
So,
as
folks
were
gathering
logs
many
times,
there
were
metrics
in
those
logs
things
they
wanted
to
extract
and
what
we
found
was
folks
were
writing
gigantic
lua
scripts.
B
Extracting
all
these
small
decimal
points
from
logs
doing
all
sorts
of
additions
and
then
trying
to
hack
it
together
with
node
exporter
or
something
else
and
and
get
into
a
prometheus
format,
and
so
we
took
our
philosophy
of
how
do
we
integrate
with
these
ecosystems,
makes
things
easier
for
for
all
our
users,
and
that's
really
what
said
us
last
year
on:
how
do
we
integrate
much
much
deeper
into
to
a
metric
sense
and
we'll
talk
about
traces
as
well,
so,
first
logs
right?
This
is
what
we've
been
doing
for
for
11
plus
years
with
fluentd.
B
When
we
look
at
it
from
a
project
side,
you
know,
logs
are
unstructured
data.
You
can
have
some
unstructured
logs
where
someone
might
write
in
logger
hi.
My
name
is
john
or
hello.
My
name
is
jill.
We
have
structured
logs
things
well
known,
like
nginx
access,
logs
or
structured
schema
like
syslog,
you
could
have
schema
list
logs
and,
as
you
are
gathering
these
logs,
you
might
want
to
do
some
processing
right.
The
most
common
use
case
of
this
is,
if
you
are
gathering
these
logs
in
kubernetes,
you
want
to
enrich
them
with
container
pod
namespace.
B
B
One
of
the
big
use
cases
that
we
see
from
a
community
perspective
is
folks
who
are
gathering
petabytes
and
petabytes
of
data
might
not
want
to
pay
for
those
petabytes
and
petabytes
of
data
or
send
it
to
perhaps
a
less
expensive,
less
used
data
store,
so
that
things
can
be
a
little
bit
cheaper
and
that's
one
of
the
other
big
use
cases
that
we
see
with
logs
is
how
do
we
filter
those
out?
How
do
we
reduce
them
or
how
do
we
send
it
to
to
multiple
locations?
B
The
main
information
that
folks
wanted
to
capture
at
the
time
was
cpu
memory,
thermal
kernel,
all
sorts
of
metrics
from
those
and
that's
those
are
actually
the
first
plug-ins
that
flip
it
had.
It
didn't,
have
a
tail
plug-in,
it
couldn't
read
log
files,
and
so
that
was
something
we
had
way
way
back
then,
and
we
kept
on
seeing
folks
use
it.
But
when
we
saw
those
log
base
metrics
being
used
last
year,
we
realized
hey.
Those
are
not
what
folks
need
in
this
new
day
and
age.
B
What
the
kind
of
the
standard
we
see
is
is
prometheus,
being
used
almost
everywhere
and
open
metrics
being
being
that
that
compatibility
layer.
So
we
went
in
and
made
sure
that
fluentpit
can
speak
the
language
of
those
metrics
added
counters
gauges,
histogram
summaries.
We
created
libraries
of
called
c
metrics.
It's
in
the
project
you
can,
you
can
go
and
look
at
it
and
then
make
these
things
all
exportable,
so
within
all
these
metrics
that
we
go
collect
we're
able
to
export
them
into
into
various
formats.
B
B
So
the
the
first
step
we
took
there
was
with
open,
telemetry,
metrics
and
making
sure
if
you're,
using
the
open,
telemetry,
metrics,
sdk
you're,
collecting
those
things
we'll
be
able
to
collect
that
and
send
it
out,
and
we
have
a
small
demo
that
we
can
show
here
as
well.
So
what
does
this
look
like
in
actuality
when
you
look
at
the
fluent
ecosystem?
It's
really
made
of
all
these
different
plugins
inputs,
outputs
and
in
the
input
side
we've
added
a
prometheus
scraper.
B
So
you
can
scrape
your
custom
metrics
if
you're
running
as
a
side
car.
So
right
next
to
your
kubernetes
applications,
you
can
go
ahead
and
grab
those
metrics
also
mimic
node
exporter
metrics.
So
you
know
we're
not
doing
the
full
breadth
that
the
prometheus
node
exporter
team
is
doing.
That's
an
awesome
piece
of
software
does
fantastic
things,
but
there
was
a
lot
of
commonality
with
what
we
had
done
with
our
plugins,
and
we
wanted
to
make
sure
that
we
collect.
B
You
know
80
percent
of
those
give
you
a
good
dashboard
if
you're
using
things
like
grafana
or
other
things
to
visualize
on
top
and
then
from
an
output
side.
What
are
the
two
main
ways
to
to
get
these
metrics
the
prometheus
exporter?
So
if
you're
scraping
those
metrics,
how
can
I
just
plug
into
what
already
exists
and
also
prometheus
remote
right?
B
So
a
lot
of
services
these
days,
whether
they're
third-party
services
or
projects
like
m3,
thanos,
cortex,
I'm
sure
there's
some
others
having
the
ability
to
just
remote
right
into
in
directly
into
those
services
and
not
being
exclusive.
So
another
big
thing
is
like
we
didn't
want
to
say:
you
must
only
do
remote
write
with
scrape
or
only
do
node
exporter
metrics
with
exporter,
you
can
kind
of
choose,
combine,
send
it
in
three
four
different
locations
use
five
exporters.
B
What
does
this
look
like
from
a
configuration
standpoint,
so
the
metrics
also
are
our
unique
influent
bit
in
that
our
metrics
are
don't
go
through
the
same
pipelines
that
logs
go
through,
so
metrics
are
almost
treated
as
an
independent
type.
You
can,
in
this
configuration
example,
see
hey
we're
collecting
node
exporter
metrics
and
then
we're
outputting
them
to
the
port
2021..
B
So
similarly,
we
started
off
with
http,
so
input
and
output,
so
you're
able
to
ingest
with
http
and
output
with
http
we're
looking
at
additional
protocols
there
as
open
telemetry
supports
more
than
just
hdp
and
then
on,
of
course,
on
top
of
that
all
of
the
tracing
side
as
part
of
part
of
the
roadmap
which
we'll
cover
here
in
a
bit.
So
what
does
this
look
like
in
actuality
when
we
put
it
all
together?
So
we
have
a
quick
demo,
and
this
is
very,
very
simple.
B
I
have
a
javascript
application,
I'm
instrumenting
it
with
the
standard
of
the
day,
which
is
open,
telemetry,
all
the
great
work
that
that
team's
done
for
building
those
libraries
we
send
those
via
the
metric
sdk
to
flip
it,
and
then
we
have
prometheus
already
in
place,
so
it
scrapes
that
via
prometheus
scraper
and
then
we
just
visualize
it
with
with
grafana.
So
let
me
go
ahead
and
close
this
out.
B
And
let's
go
ahead
and
switch
into:
let's
do
a
couple
things
I'm
going
to
go
tab
by
tab
here.
So
first,
let's
start
with
the
application.
So
this
is
my
javascript
application.
You
can
see
I'm
using.
Let
me
go
ahead
and
increase
the
size
here,
I'm
using
the
otlp,
open,
telemetry
protocol
metric
exporter
and
I'm
sending
it
to
fluid
bit
on
its
8080
port.
B
So
within
fluid
bit
I
have
a
read
from
the
http
open
telemetry
and
then
I
have
an
exporter
which
is
that
prometheus
exporter
that
I
mentioned
earlier
and
if
I
go
to
the
2021
port,
what
does
it
look
like
if
we
just
viewed
it
raw?
This
is
really
all.
It
is
just
a
simple
counter
from
open,
telemetry
test
up
down
then
prometheus.
We
look
at
prometheus
and
it's
scrape
config
it's
grabbing
from
fluent
bit
on
the
2021
port
that
we
were
exposing
and
finally
come
back
to
grafana,
and
how
do
we
visualize
all
that?
B
B
And
let's
talk
a
little
bit
about
roadmap
and
the
first
first
big
one
is
traces
right.
So
when
we
look
at
logs
and
traces
and
metrics
because
we
treat
them
as
independent
data
sources,
one
of
the
the
ideals
is:
how
can
we
start
to
make
some
really
meaningful
correlations
or
interactions
between
those
pieces
of
data,
and
especially
when
we
look
at
fluent
bit
and
what
we've
done
with
logs
we've
had
some
of
these
notions
of
stream
processing.
B
So
you
can
write
sql
today,
on
top
of
your
logs
common
use,
cases
might
be
I'm
using
nginx
access
logs.
I
want
to
group
by
error
codes
with
the
sql
query,
select
star
from
group
by
error
code
or
response
code
and
then
pump
out
a
smaller
amount
of
logs,
similarly
trying
to
bring
some
of
that
logic
over
to
traces,
bringing
some
of
that
logic
over
to
metrics,
and
in
order
to
do
that,
we
need
to
introduce
the
the
same
style
of
hey:
here's,
a
brand
new
format
of
traces.
B
So
our
idea
is
to
bring
that
into
q4
of
this
year
and
also
extend
the
the
current
open,
telemetry
input
output.
So,
instead
of
you
having
to
say
open,
telemetry,
metrics
or
open
telemetry
traces
have
it
all
live
within
kind
of
that
same
configuration
set
that
you
saw
before
then
the
other
biggest
one,
something
that
is
always
continuous
is
performance
improvements.
B
B
You
know
the
k3s
super
small
micro
kubernetes
clusters
so
want
to
make
sure
that
that
performance
maintains
and
to
do
that,
we
want
to
have
a
better
handling
of
how
we
treat
all
these
events,
because
we're
not
just
going
to
be
collecting
logs
anymore,
we'll
collect
metrics,
we'll
collect
traces
and
make
sure
that
all
of
that
is
async
has
a
good
good
higher
performance.
We're
also
going
to
be
introducing
threading
support.
So
we
added
that
on
the
output
side
with
fluent
bit,
so
you
can
add
more
threads.
B
So
if
you're,
for
example,
sending
terabytes
of
data,
you
can
add
this
worker
setting,
which
is
now
the
default
in
1.9
and
and
really
pump
that
data
through
and
now
we're
finding
the
bottleneck
coming
on
the
tail
side.
When
I'm
reading
that
data,
if
I'm
reading
a
petabyte
per
day,
how
do
I
make
sure
that
I'm
reading,
maybe
from
10
000
files
or
as
container
density
increases,
I
increase
the
amount
of
files
that
I
have
on
that
node,
so
we're
going
to
be
introducing
input
plugins
in
a
separate
thread
and,
of
course,
optimized
core
operations.
B
So,
if
you're
really
interested
in
some
of
these
performance
improvements,
we
had
a
couple
talks
from
flumecon
which
are
recorded
and
already
on
youtube
things
from
aws
about
improving
the
event
loop.
Also
things
from
again
the
folks
in
the
security
side
who
are
doing
some
of
the
fuzzing
and
ensuring
things
are,
are
compatible
and
well
a
developer
experience.
B
Bring
that
data
in
do
some
correlations
generate
some
prometheus
metrics
generate
some
some
hotel,
metrics
or
whatnot
from
so
yeah.
That
experience
is
coming
in
q3
would
love
to
talk
to
folks
who
are
interested
in
writing
more
of
those
plugins
always
interested
in
getting
the
the
community
feedback
there.
So
yeah!
You
know
in
this
last
one.
You
know
when
we
think
of
our
our
ideals
and
how
we
keep
building
the
project
and
alongside
the
community
you
know
with
with
bruce
lee.
We
think
of
you
know
be
like
water
be
be
fluent.
B
B
D
D
F
So,
thank
you.
First,
you
mentioned
about
traces,
which
sounds
great.
I
guess
my
question
is:
have
you
thought
about
doing
it?
The
other
way
around,
which
is
having
fluent
bits,
emits,
is
or
its
own
traces,
so
that
we
can
follow
the
path
of
our
logs
and
kind
of
like
know
that
when
a
log
is
emitted,
it
is
sent
somewhere
and
then
we
would
be
with
these
two
traces
be
able
to
know
the
full
path
until
when
the
log
is
sent
to
the
database
and
how
long
that
takes
basically.
F
A
A
B
Receiving
the
internal
information,
so
this
I'm
smiling
because
you
know
a
few
weeks
ago
in
one
of
our
community
meetings,
we
talked
about
this
idea
of
being
able
to
peer
into
what
is
a
plug
and
doing
what
what
information
is
flowing
through.
So
we
started
a
discussion
on
it
in
in
github,
so
love
participation
in
there
try
to
spec
out
like
what
those
requirements
look
like.
We
have
some
ideas,
but
of
course,
there's
there's
a
lot
to
to
go
back
and
forth
with
security.
C
Hi,
first
of
all,
thank
you.
You
said
in
q4
you
flap,
it
will
get
racist
support,
but
I
think
we
can
right
now
we
can
use
forwarder
plug-in
forward
output
for
sounding
traces
from
the
kubernetes
to
maybe
open,
telemetry
or
other
places.
Will
you
suggest
that
yeah
we
will,
it
will
be
okay
or
you
will
suggest
that
we
should
wait
for
q4
or
legit
trace
support.
B
There's
there's
some
good
sessions
on
that
or
or
recorded
content
on
that
there's
a
guide
on
the
hotel
documentation
on
how
to
do
it,
but
this
is
actually
different,
so
this
would
be
receiving
the
traces
to
fluid
bit.
So
so
this
so
in
q4,
you'll
be
able
to
receive
those
traces.
If
you're
using
the
fluent
forward
protocol
via
app
or
via
fluenty
or
flintbed,
you
can
already
integrate
with
hotel
collector.
D
G
A
A
Now
those
beatback
files
from
yokto
are
there
for
historical
reasons,
and
we
aim
to
support
them,
but
we
as
maintainers
a
actually.
We
are
so
busy
with
so
many
requirements
that
we
can
no
longer
maintain
that
recipe.
It
might
be
broken.
We
just
try
to
update
the
version,
but
if
you're
using
jokto,
you
know
beatback
files
and
you
can
fix
it
at
least
on
meta
pr
and
happy
to
get
that
you
know
process
through
there's.
A
So
otlp
for
us
is
more
another
protocol
that
we
integrate
with
we
integrate
with
c
slope
forward
and
well
I
don't
know
we
have
nqtt.
We
have
a
bunch
of
protocols
that
we
support
so
for
us
all.
Otlp
is
another
protocol
that
we're
going
to.
We
started
supporting
right
now,
initially
with
matrix,
because
we
were
experimenting
with
metrics
now.
The
default
case
is
traces,
but
we're
going
to
do
just
route,
traces
and
yeah.
A
So
we
support
that
already
in
the
input
and
in
the
output
side
yeah,
we
did
all
the
protocol
buff
conversion
to
ceiling
layer,
and
that
is
functional
already.
What
about
otp
otlp
logging
yeah?
We
just
heard
that
otlp,
the
log
spec
was
just
released,
but
there's
not
much
content
that
we
can
add
at
the
moment
because
of
the
following.
A
So
we
start
to
support
them
prometheus
then
ot,
for
example.
If
I
say
what
is
the
standard
for
traces
open
telemetry
right
now,
if
I
ask
today
what
is
the
standard,
for
example,
for
what
was
metrics
for
logging,
I
think
that
is
not
standard.
Right.
Oclp
is
heading
into
into
that
direction.
So
as
soon
as
this
get
more
traction
in
the
community,
we
get
more
use
cases
right.
We're
going
to
start
supporting
all
these
layers.