►
From YouTube: 2020-11-11 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
Okay,
cool.
Do
we
have
topics.
C
D
Yeah,
so
just
briefly,
it's
been
a
while,
since
we've
provided
an
update
on
how
our
stanza
is
going
so
we've,
you
know
we
applied
to
the
cncf
to
become
a
sandbox
project
and
unfortunately,
yesterday
our
application
was
reviewed
and
and
denied.
D
So
I've
reached
out
to
stephen
get
some
more
details
on
this.
I
know
that
in
the
past
some
sandbox
projects
have
been
able
to
sort
of
reapply.
You
know
and
get
a
follow-up
review
in
two
weeks
or
so
there's
a
possibility
of
that,
but
they
did
suggest
that
we
reapply
in
the
spring.
So
I'm
not
going
to
count
on
that.
D
So
yeah
a
little
bit
disappointing,
but
you
know
another
option
that
we
had
discussed
a
while
back
was
potentially
moving
stanza
under
the
open
telemetry
organization
as
a
sub
project.
D
I
think
that's
still
very
much
on
the
table
for
us,
and
you
know,
assuming
that
the
technical
committee
is
not
not
really
interested
in
accepting
stanza
in
the
very
near
term.
I
think
that
probably
still
makes
the
most
sense
then
as
the
path
forward.
So
I
probably
would
like
to
make
have
some
discussions
with
some
folks
in
the
near
term
about
what
that
could
look
like
at
a
technical
level
yeah.
So
that's
where
about
where
we're
at
with
that.
A
Okay,
yeah,
so
frankly
that
was
actually
the
thing
that
I
was
also
going
to
bring
up.
I
think,
but
like
you,
you
got
it
then
I
think
it
would
be
good
to
sort
of
see
whether
you
can,
whether
there's
you
know
whether
there's
some
debug
info
good
to
come
along
with
the
you
know,
with
the
rejection.
Was
it
so
that
we
kind
of
have
an
idea,
and
then
I
think,
oh
probably,
you
know
been
poking
morgan
in
the
background,
at
least
that's
the
one
person
that
I
know.
A
A
So
some
poking
him
a
little
bit
in
the
background
as
well,
and
if
I-
and
if
any
of
you
here
you
know,
know
any
of
the
toc
folks,
I
I
personally
don't
I
haven't
been
around
long
enough
and
I
didn't
have
any
you
know
photos
for
that.
E
Yes,
I
showed
up
a
little
late,
so
I
missed
the
beginning.
But
are
you
all
talking
about
api
level
stuff,
but.
A
No
quickly
quickly
to
catch
you
up,
the
the
topic
is
stanza
and
stanza
getting
into
the
sandbox
that
you
know.
The
idea
was
that,
with
all
the
effort
that
guys
you
know
behind
stanza
have
put
in
it
would
be
really
a
good
like
starting.
You
know
they
would
be
good
to
just
adopt
that
as
the
kind
of
code
base.
You
know.
A
The
initial
code
base
for
ford
for
for
logging,
in
open,
telemetry,
right
and
stanza
is
an
open
source
project,
but
it
is
you
know
it's
under
it
like
observer
iq,
which
is
you
know,
the
guy's
company
governance
right,
and
so
you
know,
we've
talked
with
them
and
you
know
they
they
are
willing.
You
know
to
get
this
under
cncf
governance
as
a
first
step.
I
think
otherwise,
you
know
in
previous
lock-screen
meetings
we
had
discussed.
A
That
would
otherwise
be
a
little
bit
tricky
to
kind
of
you
know,
get
it
as
the
sort
of
you
know
core
code
base,
but
you
know
you
know,
you
know
dan
and
his
folks
are
very
open.
You
know
to
get
this
into
cncf,
so
we
had.
We
talked
to
a
bunch
of
you
know.
Folks
on
the
cncf,
specifically
of
saranavarni.
A
Of
to
get
some
input
and
he
suggested
that
we
go
to
sandbox
route
and
then
you
know
you
know
dan
and
his
folks,
you
know,
did
the
sandbox
app
and
it
was
rejected
yesterday
and
so
we're
trying
to
figure
out
what
that
means,
and
I
think
what
I
was
calling
for
was.
If
anybody
here
knows
any
of
the
doc
members,
then
if
we
could
get
some,
I
don't
even
want
to
say
back
channel
really
just
shoot
them
an
email
and
or
something
you
know
see.
E
And
just
for
clarity,
real
quick
is
stanza.
Is
this
something
that
would
be
like
a
collector
component?
Is
this
data
processing,
or
is
this
something
that's
like
more
like
an
api
like
in
in
memory
thing
that
we're
doing.
D
Yeah,
so
it's
an
embeddable,
blog
processing,
library
or
you
can
run
as
a
standalone
agent,
but
I
think
in
the
context
of
open
telemetry,
what
we've
got
right
now
at
least
is
a
concept
is
that
it
is
a
receiver,
and
so
I
I
think
that
probably
makes
the
most
sense
to
keep
it
that
way,
but
there
might
be
some
alternate
options
that
could
be
explored.
E
Yeah,
nice,
okay,
that
that's
helpful
I'll
see
if
I
can
poke
around
as
well.
On
that
front.
Awesome
thanks.
A
Put
the
link
in
the
chat
in
case
somebody
wants
to
look
at
it
hasn't
seen
it
before.
So
I
think
what
we
heard
was
that
you
know
reapply
in
in
spring,
but
I
think
that's
not
optimal,
because
I
think
you
know
to
really
double
down
on
using
this
code
base
to
get.
You
know
log
collection
going
in
open
telemetry
in
like
I.
I
don't
think
anybody
wants
to
wait
three
months
so.
E
You
know
they're
just
slammed
like
we're,
trying
to
get
open
telemetry
to
graduate
from
sandbox
and
that's
taking
forever
just
because
they're
booked
out
it's
like
the
second
largest
project
in
the
cncf
and
it's
like
in
production
everywhere
and
we're
still
a
sandbox
project.
So
it's
like
so
like
there's
just,
I
think,
a
general
backlog
of
stuff
on
their
agenda.
So
I
suspect,
that's
probably
what's
at
the
heart
of
it,
or
at
least
that's
been
my
experience
with
them
so
far,.
F
A
A
One
more
time
right
so
and
that's
why
you
know
getting
getting
get
to
get
installed
for
three
months
seems
just
that
I
right
now,
I'm
not
not
we'll
have
to
see
what
we
can
do
and
maybe-
and
you
know,
as
dan
said,
you
know,
the
other
thing
that
was
floated
was
that
you
know
it
could
also
become.
I
think,
a
open,
telemetry
sandbox
thing
for
which
I
think
open
telemetry
then
governs
that
and
then
that
open
telemetry,
I'm
sure,
has
a
talk
of
some
sort
as
well.
Again.
A
Sorry
I'm
a
bit
of
a
noob
here,
but
we
might
be
able
to
run
it
up
that
way.
E
Yeah,
if
it's
gonna
be
like,
if
we're
looking
at,
I
think
there's
like
two
ways
to
look
at
it.
If
this
is
something
that
we're
hoping
to
be
like
a
core
component
that
just
like
comes
with
the
collector-
and
this
is
like,
like
the
basis
for
how
we
want
to
do
long,
processing
going
forwards.
If
that's
something,
you
know
that
the
technical
committee's
interested
in
or
if
that's
the
way
this
group
is
looking,
then
bringing
it
in
to
open
telemetry
would
probably
be
the
the
best
way
to
do
that.
I
I
don't.
E
I
don't
want
to
speak
for,
for
you
know
the
the
project.
I
don't
know
anything
about
stanza
but
versus
if
it's
like,
just
like
a
plug-in
that
you
can
install
like
any
other,
you
know
plug-in,
then
that
wouldn't
be
a
requirement,
but
so
I
think
it
depends
on
on
how
much
people
are
seeing
it
as
like
a
central
part
of
vlog
processing
so
but
yeah.
That
would
probably
be
the
quickest
way
as
far
as
the
the
red
tape
is
concerned,
and
probably
for
the
open
telemetry
project.
E
If
we're
going
to
really
if
it's
going
to
become
like
a
dependency
for
the
project,
I
think
people
would
probably
prefer
it
to
get
merged
in.
But
again
you
know,
I
don't
want
to
don't
speak
for
the
project
maintainers.
I
know
there's
often
a
lot
of
other
things
going
on
when
you
make
those
kinds
of
decisions.
G
So
there's
a
plan
for
open
telemetry
to
have
options,
use
or
useful
a
bit.
The
collector.
A
Well,
so
so
personally,
that's
just
one
one
guy
speaking
right,
but
I
do
think
there
needs
to
be.
Batteries
include
a
default
thing
right.
I
think
that's
the
same
on
metrics
and
tracing
as
well,
and
I
think
there's
got
to
be
a
code
base
that
does
that
right
and
I
think
I
think
this
is
the
one
that
like
super
promising.
A
You
know
dan
and
his
folks
have
been
demoing
it
multiple
times
over
the
last
couple
of
weeks
and
months.
So
this
has
been
cooking
for
a
while.
I
think
the
lockstick
previously
has
been
quite
excited.
You
know
at
the
idea
of
sort
of
really
kind
of
like
basically
like
you
know,
first
empty
repo
versus
something
that
actually
works
right.
You
know,
I
think
it
was
it's
written
in,
go
it's
compatible.
I
think
mindset
compatible.
You
know
some
of
us,
you
know
know
these
guys
from
you
know
their
background.
A
You
know,
they've
been
doing
this
type
of
stuff
for
a
long
time,
so
they're
believable
all
of
that
stuff
right,
it's
just
it's!
It's
it's
very
cool.
Actually,
so
I
think
we
just
so.
The
idea
would
be
that
that
becomes
the
open,
telemetry
logging
code
base.
You
know
that
that
was
we
were
trying
to
push
through
that
yeah
and
you
know.
A
Obviously
you
know
the
sort
of
receiving
thing
is:
is
pluggable
in
open,
telemetry
right
and
there's
a
there's,
a
there's,
a
plc
that
like
pulls
influent
bit
and
etc,
etc,
but
I
think
the
idea
would
be
that,
like
we
get
to
a
single
executable,
I
think
that
just
form
factor-wise
would
be
awesome
and
if
folks
want
to
do,
you
know
sort
of
as
the
default
batteries
included
option.
If
folks
want
to
build
distros,
you
know
pulling
in
different
things.
They
should
feel
open
too
architecture.
Is
there.
F
Do
we
have
a
performance
information
published
yet,
or
you
know
like
throughput,
that
would
compare
stanza
within
open
telemetry
with
fluent
bit,
because
that
would
help
make
the
case
if
the
performance
is
better,
for
example,
which
I
would
think
it
would
be.
D
Yeah,
so
we
have,
we
have
benchmarks
with
stanza
as
a
standalone
agent
running
against.
You
know
similar
scenarios
with
flintbed
and
fluentd
and
in
those
scenarios
we've
you
know,
we've
been
able
to
demonstrate,
I
think,
quite
an
impressive
improvement
of
the
performance,
the
receiver,
the
proof
concept,
receiver
right
now,
I
would
say,
is
not
not
has
not
yet
been
highly
optimized,
so
there
certainly
could
be
more
gains,
but
I
think
we're
pretty
close
to
on
par
right
now.
D
The
the
main
bulk
of
it,
I
think,
is
in
like
converting
to
the
like
the
protobuf
format
that
open
telemetry
uses
and
we're
kind
of
doing
that,
like
one
log
entry
at
a
time.
So
if
we
batch
that-
and
you
know
hyper
optimize
that
we're
gonna
see,
I
think
better-
a
lot
better
performance
than
we
have
now.
We
just
haven't
done
that
yet
is
it
already
up
as
a
receiver?
D
Yeah,
it's
in
the
control
repo
in
the
unstable,
build
right
now
and
there
are.
There
are
some
benchmarks,
some
benchmark
tests
in
the
receiver
and
those
were
posted
on
one
of
the
pr's.
So
we
could
probably
get
you
links
to
those.
If
we
yeah,
I
could
dig
those
up.
D
Yeah,
I
said
so
I
I
do
want
to
say
what,
like
I
think,
christian
spoke
really
well
to
you
know
also
what
I
think
observed
iq
hopes
for
out
of
this
integration,
but
just
to
advocate
a
little
bit
for
observe
iq
here.
If
I,
if
I
can
do
that,
you
know
it
was
kind
of
discussed
internally
and
and
the
ideal
solution
for
us
would
be,
at
least
in
the
short
term,
to
be
a
a
separate
sandbox
project.
D
This
would
just
give
us
a
little
bit
more
of
a
runway
for
building
the
software
that
we're
building
around
stanza.
Well,
we
believe
we
can
accomplish
everything
that
open
telemetry
wants
at
the
same
time,
so
that
would
be
the
idea.
That
is
why
we
went
that
route
in
the
first
place,
but
we're
not
going
to
drag
our
feet.
If
that
doesn't
work
out,
you
know
we
want
to
be
part
of
open
telemetry,
either
way
so
awesome.
E
Cool
well
I'll,
see
I'll
see
what
I
can
do
to
help.
I'm
actually
just
just
kind
of
reorienting
here
with
tracing
finally
kind
of
getting
in
the
bag
from
a
spec
perspective
and
the
metrics
group
of
being
in
a
really
healthy
place
was
thinking.
It
would
be
a
good
time
to
kind
of
hop
back
into
this
logging
group
and
see
where
you
all
were
at
and
see
if
I
could
help
shepherd
this
project
into
its
next
phase.
A
So
I
think
that
that's
it
as
far
as
I
know,
there's
a
whole
bunch
of
folks
on
the
call
y'all
speak
up
if
there's
anything
else
that
we
can
discuss.
A
H
My
name
is
max:
I'm
part
of
microsoft.
I
instrument
mostly
client
telemetry,
is
nervous,
so
everything
that
is
running
across
platform
like
office,
onedrive
hololens.
H
H
I
have
a
question
so
for
the
most
prominent
logging
frameworks,
pretty
much
anything
that
starts
with
log
four
like
log4
log4cxx
log
for
j
analog
log4net,
there's
a
concept
of
so
called
named
loggers.
So
you
can
interpret
that
differently.
H
You
can
either
interpret
it
as
named
logger
or
a
named
log,
so
which
conceptually
transpires
into
passing
over
the
knowledge
of
what
is
the
originating
logger
name,
possibly
on
each
individual
event
and
made
it
through
that
logger.
H
That
way,
you
can
actually
build
cool
stuff
like
three
structures
which
visualize
the
hierarchy
of
loggers
and
how
events
flow
and
filter
based
on
what
is
the
originating
logger
name
now,
in
order
to
build
that
structure,
you
actually
have
to
have
some
way
of
either
standing
the
original
name
or
the
logger
id,
which
is
a
hash
of
that
name
or
somehow
like
pass
that
knowledge
down
to
the
exporter.
Well,
right
now
we're
missing
this
inspect
and
as
we
work
on
open,
telemetry,
c,
plus
plus
sdk,
I
had
the
question
to
karen
mark.
H
Both
guys
are
here
on
this
call
right
now
that
we
are
obviously
a
way
to
preserve
that
knowledge
right
now.
So
what
I'm
asking
for
is
kind
of
green
light
from
the
spec
committee
on
that,
so
that
we
can
actually
prototype
having
it,
because
it's
not
spec
yet,
but
then
we
can
discuss
if
it's
not
getting
spec
cool,
but
then
we
are
missing
like
fundamental
mapping
from
the
higher
level
logging
facilities
to
open
telemetry,
you
can
see
what
I'm
saying
I've.
I
mentioned
the
issue
in
the
chat
window.
H
E
C
So
this
is
actually
something
I've
talked
with
tigran
about
a
little
bit
in
the
past,
I'm
trying
to
find
where
it
was
at,
but
I
believe
his
he
was
envisioning
actually
putting
this
somewhere
in
the
attributes.
Okay,
so
that's
actually,
where
I'm
I'm
looking
to
see.
If
we
had
that
defined.
H
As
long
as
we
have
some
place
for
it,
that
means
that
at
the
higher
level
in
api
and
sdk,
we
can
actually
preserve
that
knowledge.
Then
we
go
to
lp
exporter,
for
example,
and
we
already
have
a
place
for
that
then
and
other
flows,
for
example,
for
azure.
If
I
invoke
etw
exporter
with
the
etw
agent,
I
still
can
preserve
that
knowledge.
H
So
my
point
is
seems
like,
while
designing
the
sdk,
we
should
already
have
this
kinda
in
mind
and
design
it
future
proofed
enough,
as
if
there's
gonna
be
the
rightful
place
for
that.
So
do
you
guys
kinda
agree
with
this
thing.
C
I
think
there's
definitely
some
this
set
of
fields
isn't
concrete,
yet
I
guess
is
kind
of
my
understanding,
and
so
I
think
tigran's
vision
for
that
was
that
a
lot
of
these
fields
would
start
as
attributes,
and
if
we
found
over
time
that
we're
using
them
a
lot,
then
they
would
be
promoted
to
top-level
fields.
Okay,
if
I'm
understanding,
where
you're
coming
from.
H
But
that
shouldn't
prevent
us
from
kind
of
designing
this
at
the
higher
level
to
preserve
that
knowledge.
So
if
exporter
is
aware
of
that
explicitly
we
can
set
if
exporter
is
unaware
of
that
cool,
so
if
exporter
doesn't
want
to
preserve
the
logger
name
or
the
log
name,
fine,
we
are
not
can
missing
anything
and
in
environments
where
customers
run
with
that
fool.
H
I
think
it's.
We
still
have
that
api
level
get
logger.
It's
just
we
say.
Oh,
we
need
to
forget
about
it.
It's
just
a
pretty
much
useful,
useless
parameter,
just
the
key
in
the
map.
We
don't
store
it
anywhere,
so
my
thinking
is
well
how
about
we
actually
keep
that
in
mind
and
stay
aware
of
this,
because
at
some
point
it
could
be
becoming
an
attribute
on
the
protocol
right.
C
Personally,
I
I
very
much
agree
with
you
that,
like
I
think
we
should
be
very
careful
about
throwing
away
information.
We
don't
think
is
important
if
we
have
have
information
in.
C
H
Sounds
good
karen
mark,
so
you
guys
can
capturing
this
right.
E
Yep
yeah
one
suggestion,
so
we
we
already
have
a
concept
of
name
tracers,
which
is
the
same
basic
concept
as
a
named
logger
and
those
are
already
in
in
otlp.
So
I
just
posted
a
link
to
those
constructs,
so
it's
called
like
instrumentation
library
is
what
the
the
object
is
called.
E
So
you
might
want
to
look
at
that
pattern,
that's
already
in
there,
because
I
think
it
would
be
basically
the
same
pattern.
I'm
not
sure
what
the
I
think.
C
This
is
a
a
little
bit
different
in
that
it's
usually
an
so
the
same
instrumentation
is
going
to
have
multiple
loggers,
so
you
know.
Basically,
if
you
have
a
web
server,
you
might
have
a
net
a
nested
set
of
things
that
roll
up
into
that
web
server.
C
So
your
instrumentation
is
going
to
be
level
on
top
of
that,
but
the
logger
might
have
a
receiver
as
part
of
that
web
server
and
that
that
kind
of
groups
all
of
those
log
entries
into
that
little
bit
and
then
that's
kind
of
you
know
what
max
was
talking
about
with
it,
that
being
nested.
You
can
group.
I
H
It's
not
necessarily
nested
it's
nice
to
have
it
nested,
because
if
you
have
it
nested
you
and
for
your
exporter
and
for
your
flow,
you
can
build
a
tree,
but
another
case
like
a
client-side
application
can
have
things
like
storage
or
data,
uploader
or
other
component
and
then,
as
long
as
you
kind
of
carry
that
information
around,
you
can
then
again.
Filter
the
closest
in
android,
for
example,
is
log
tag.
H
Ironically,
it's
not
a
logger
name,
but
you
can
still
have
that
like
get
logger
where
a
name
would
become
a
log
tag
and
then
you
can
grab
by
that.
So
those
are
scenarios
that
I
have
in
mind
where
we
can
use
it
internally
and
not
having
it
may
prevent
us
from
onboarding
to
open
telemetry.
If
we
don't
have
one-to-one
map,
you
see
guys
what
I'm
saying.
That's
why
I'm
worried
about
it.
H
And
it's
like
it's
much
easier
to
shrimp
something
on
top
of
open
telemetry.
When
I
have
my
easy
kind
of
one-to-one
mapping
right.
H
As
an
example,
I'm
bringing
other
libraries
as
well
like
anything
that
starts
with
workforce,
and
that
be
the
case
for
some
of
our
internal
libraries
we're
actually
going
to
open
source
this,
but
with
the
goal
in
mind,
to
also
have
this
route
that
eventually
want
to
pull
open
challenges.
A
So
I
guess
the
question
is
then,
if
I
understand
this
correctly
and
please
correct
me
if
I'm
wrong,
but
this
concept
of
a
logger,
the
named
logger
is
something
that
that
we
feel
is
is
common
to
a
degree
that
specifications
should
have
an
opinion
on
it,
and
ideally
we
would
make
it
either
a
top
level
field
like.
If
you
look
at
the
spec,
it
would
be.
You
know,
top
level
field
would
be
something
like
tray
city
span,
id
severity
text,
etc.
A
You
know,
or
if
not,
and
maybe
at
least
define
a
key
under
attributes,
which
is
also
supposed
to
sort
of
follow
some
sort
of
loose
conventional
schema,
such
as
http.status
code,
which
is
I've
just
pulled
up
a
bunch
of
the
you
know,
spec
examples
to
sort
of
visualize
that
so
you
you
know
you
would.
You
would
like
to
have
a
commitment
on
there
being
a.
A
Yeah,
like
it
sounds
like
you
would,
you
would
probably
be
okay
max
to
put
it
as
a
top
level,
but
maybe
maybe
if
that
you
know
like
at
least
the
attribute
like
defined
attribute
thing
so
that
you
can
kind
of
you
know
slide
it
in
and
like
the
other
side
can
can
reliably.
You
know
detect
whether
it's
there
and
then
use
it.
H
It's
not
even
blocking
us
where
exactly
this
field
is
located,
for
example,
mark
and
karen
they
are
working
on
like
log
stash
export,
no,
no,
no
tlp
export,
so
it
won't
matter.
They
can
still
preserve
that
knowledge.
They
can
still
implement
the
sdk
and
api
and
log
slash
exporter
and
the
other
student.
I
work
with
he's
working
on
htw
exporter,
where
we
pack
everything
in
etw
event,
so
not
having
it
in
no
tlsp
spec.
It's
not
blocking
us.
A
You
know
also,
you
know,
I
would
you
know
tikrun,
ultimately,
you
know
is
the
guy.
You
know
the
real,
the
real
brain
behind
the
specs,
so
not
having
him
here.
I
I
think
I
think
bobby
crowd
here
understands
to
ask.
It
seems
like
a
reason
blast
to
me.
I
I
recognize
the
concept
that
ask
is
to
have
the
concept
represented.
A
I
think
it's
very
fair
personally,
you
know
so
avenues
here
is
you
know,
wait
two
weeks
and
you
know
I
have
to
run
back
on
the
call,
but,
like
you
probably
don't
want
to
wait
that
long,
but
maybe
we
can
make
you
know
maybe
I'll
pop
in
take
around
and
you
know
maybe
david
can
do
the
same
thing
and
then
maybe
do
it
like
quicker
turn
around
and
get
it
or
something
or
in
the
github
issue.
Sure
yes,.
E
E
So
if,
if
there
aren't
any
other
items
on
the
agenda,
would
it
be
cool
to
get
just
like
a
quick
status
update
about
where
things
are
at?
On
the
the
logic
logging
project?
I
see
you
know,
google
at
least
I
saw
produce
like
a
a
collector.
That
was,
I
think,
designed
to
replace
maybe
some
of
their
existing
logging
infrastructure.
So
that's
like
a
good
step
forward.
E
I
thought
I
saw
someone
one
from
gcp
as
well.
Maybe
it's
just
a
prototype
that
I
was
looking
at,
but
aws
also
aws
has
a
collector
distro
out
there.
I
don't
know
if
that's
the
same
thing
as
as
the
agents
that
they
were
previously
running
on
on
their
vms
right,
like
there's
a
logging
agent
that
that
both
aws
and
gcp
were
hoping
to
replace
with
the
collector.
A
E
Well,
in
terms
of
like
where
this
working
group
has
been
like,
what's
what's
been,
the
the
focus
lately.
A
And
you
know
there
was
a.
As
I
said
earlier,
there
was
a
prototype
to
sort
of
demonstrate
how
we
could,
like
you
know,
have
data
coming
through
fluent
bit
but
to
the
rest
of
the
pipeline,
and
you
know,
and
then
you
know
dan
and
his
folks
showed
up,
and
you
know
we
were
basically
saying
hey.
A
You
know
this
is
it's
just
a
great
candida
code
base
and
since
then
I
think
it
was
mostly
working
in
the
background
to
see
what
we
can
do
in
order
to
get
this
under
the
right
governance
so
that
people
can
really
like
you
know,
pile
up
behind
it
and
in
the
meantime
you
know
dynamics
folks
have
have.
You
know
done
the
contrib
thing
and
you
know
try
to
sort
of
weave
things
through
pr's,
but
I
think
again.
A
Therefore,
the
full
commitment
on
both
sides
is,
I
mean
you
know,
engagement,
but
no
marriage
yet
so
I
probably
I
don't
know
if
that's
the
right
terms,
but
we
would
all
like
to
see.
We
would
like
to
see
this
married,
so
yeah
and
then,
at
least
from
my
perspective
I
mean
I
can't
wait
to
have
like
support
of
logging
in
there.
I
know
a
lot
of
folks.
A
Are
you
know
working
super
hard
on
getting
you
know,
as
you
said,
they're
getting
you
know
the
tracing
out,
and
you
know
that
matters
to
us
commercially
metrics
also-
and
you
know,
at
least
from
the
sumo
logic
perspective
in
more
than
I
mean
can't
wait
to
sort
of
you
know,
get
going
on
the
implementation
of
the
logging
stuff
as
well.
It's
strategic
for
us
which
goes
back
to
the
topic
at
the
beginning.
I
just
see
how
we
can
kind
of
find
a
way
to
make
progress.
E
So
if
I
wanted
to
play
play
with
things
today,
what's
what's
available
like
I
see,
there's
receivers
and
collector
contrib
and
there's
a
certain
amount
of
of
logging
added
as
data
structure
to
otlp
like
if
I
wanted
to
to
play
with
stuff
like
what
what
are
the
use
cases
that
that
have
already
been
implemented,
I
could
go.
Try.
A
E
A
Maybe
david
and
dan
can
like
represent
the
fluent
bit
and
and
this
dancer
and
give
pointers.
D
Sure
so
what
stanza
I
mean,
the
probably
the
by
far
the
most
common
use
case,
would
be
just
file
tailing
parsing.
Turning
it
into
you
know
a
well
well
interpreted
log
line,
I
would
say,
and
then
that
can
be
passed
down
the
pipeline
and
I'm
happy
to
help
out
with
that.
D
If
you
want
to
tinker
a
bit
yeah
so
at
least
on
the
receiver
and
there's
that
stanza
can
also
do
some
other
things
capturing
like
windows,
event,
logs
journal
d,
you
can
receive
logs
over
udp
or
tcp
a
couple
other
input
mechanisms
that
you'd
find
in
our
documentation
and
then
a
whole
host
of
different
parsers,
and
things
like
that
as
well.
E
D
Yeah
pretty
much
yeah,
and
I
I
should
it
should
be
clear
here.
Actually
so
stanza
has
operators,
which
are,
I
think,
very
much
a
novice
to
the
components
of
open,
telemetry's
collector
and
in
this
in
the
the
build
that
is
out
there
right
now,
only
file
input
and
json
and
regex
parsing
are
enabled.
We
have
several
other,
like
probably
two
dozen
other
operators,
which
can
be
enabled
with
essentially
a
single
import
statement.
D
So
if
you
go
beyond
those
may
require
recompilation.
But
again,
if
you
want,
if.
C
So
I
know
there's
been
otlp
logging
added
to
the
collector.
I
also
was
adding
logging
support
to
the
java
sdk
to
be
able
to
go
from
log4j
to
that
otlp
support.
We've
got
the
central
piece,
but
not
the
tlp,
exporter
or
well.
I've
actually
got
a
log4j
plugin,
but
it
doesn't
go
into
that
support.
Yet
I
think
max
is
also
working
on
the
same
sort
of
thing
for
the
c
plus
sdk.
E
C
So
right
now
the
log4j
plugin
we've
got
all
it
does,
is
takes
it
and
adds
the
trace
id
and
the
span
id.
C
Adds
it
right
now
into
just
a
json
format
and
then
the
idea
is
that
that
then
goes
into
the
new
new
logging
support,
which
then
is
presented
to
an
exporter.
There's
a
otlp
exporter
so
going
through
that
same
process
as
that
the
metrics
does
make.
E
Sense,
okay
makes
sense,
so
this
is
just
a
pipeline
of
you've
already
got
your
existing
logs.
If
we
have
trace
and
span
ids
we're
going
to
staple
them
on
there,
and
then
we've
got
building
out
a
facility
to
pump
that
as
a
separate
stream
and
then
maybe
being
able
to
start
wrapping
that
into
like,
at
the
exporter
later,
to
be
able
to
pump
out
like
a
combined
stream
of
these
different
networks.
But
we
don't
have
it
in
open,
telemetry
brand
logging
api
or
anything
like
that.
At
this
point,.
A
And
so
that
was
on
purpose
right
I
mean
the
early
discussions
were
around.
You
know,
trying
to
first
integrate
with
existing
frameworks.
E
So
yeah
yeah
no
make
sense
yeah.
I
would
love
to
see
that
stuff,
but
it'd
be
great
to
figure
out
some
of
the
other
use
cases,
but
I
definitely
agree
that,
like
the
primary
use
case
is
interface,
integrating
with
existing
logging
frameworks
right,
like
I'm
sure
the
world
wouldn't
mind,
another
logging
interface,
but
it's
probably
not
the
top
of
everyone's.
B
B
So
I
was
playing
a
couple
weeks
ago
with
the
idea
of
using
fluent,
beat
and
and
using
fluent
beat
receiver
to
pass
the
logs
through
open
telemetry
collector,
together
with
metadata
tagging
and
then
sending
them
to
let's
say
otl
exporter
or
whatever
is
available,
and
I'm
currently
working
on
the
few
gaps
that
we
have
identified
and,
namely
being
able,
because
for
for
the
data
format,
we
have
the
resource
which
includes
information
about
well
the
resource
like
pod
id
or
source
ip
things
like
that,
and
then
the
actual
records
and
this
model
doesn't
work
very
well
with
land
build
receiver,
because
everything
is
flat.
B
We
don't
have
anything
in
resource.
We
have
just
the
log
records
that
include
them.
The
information-
and
this
doesn't
play
work
well
with
kubernetes
metadata
attacker,
because
it
expects
that
same
information
that
is
able
to
identify
the
the
source
spot
is
in
the
resource.
So
I'm
working
on
a
grouping
processor.
B
That
is
that,
where
you
can
identify
define
several
fields
that
can
go
to
from
the
log
record
or
any
sort
of
record
to
the
resource
level,
and
then
the
kubernetes
metadata
tagging
can
pull
it
up
and
and
add
the
information
for
for
what?
What
kind
of
pot
is
that
deployment
things
like
that?
So
we
would
have
the
the
use
case
for
kubernetes
locks
handled
and
after
this
will
be
made
working.
We
can
include
this
into
an
open,
telemetric,
collector
or
open
telemetric
hand.
B
Chart
so
we'll
be
able
to
support
that
use
case
for
kubernetes,
which
I
think
is
quite
important
step.
E
G
I
have
a
question
for
dan
yeah
jeff
from
walmart.
Looking
at
your
results,
you
you
ran
those
tests
and
then
any
testing
in
like
kubernetes
pods
with
the
stanza.
D
Yeah,
I
don't
know
that
we've
done
benchmarking
specifically,
but
we've
put
a
whole
lot
of
work
into
supporting
those
use
cases.
We
we,
we
actually
have
like
a
plug-in
framework
for
stanza,
where
these
are
just
sort
of
templatized,
yaml
files
and
we've
done
a
lot
to
sort
of
organize
it
so
that
you
know
if
you've
got
a
use
case
like
say
running
nginx
on
kubernetes.
D
You
know
you
might
be
running
nginx,
not
on
kubernetes,
and
so
we've
got
a
plug-in
for
that.
And
then
we've
got
a
plug-in
for
kubernetes.
That
can
you
know
tail
the
relevant
log
files
and
route,
the
nginx
ones,
to
an
nginx
parser,
and
then
you
know
continue
on
so
yeah.
D
A
lot
of
a
lot
of
work
done
has
gone
into
those
just
solving
the
kubernetes
use
cases
in
general
I
mean,
there's
I'm
sure,
a
multitude
of
them,
but
as
many
as
we've
identified,
I
think
we've
been
able
to
solve
them
all
now
and
actually
taking
inspiration
from
the
use
case.
That
shermak
was
just
talking
about.
We
actually
implemented
an
otlp
exporter,
essentially
an
out.
D
E
D
Yeah
yep,
it's
yeah,
it's
just
called
otlp
output.
F
F
A
Alrighty,
I
guess
that's
a
wrap
sounding
like.
A
Cool
try
to
take
some
notes.
I
missed
that
last
part,
you
know
answering
all
the
ted's
questions
which
which
were
all
our
questions
to
ask,
so
I
didn't
put
that
in
there.
You
know
max
in
particular
make
sure
that
I
don't
miss
that
I
didn't
misrepresent.
You
know
your
concern.
If
you
want
to
take
a
look
feel
free
to
edit.
It.
H
It
looks
perfect.
I
checked
that.
A
Cool
and
you
know
I'll
see
you
guys.