►
From YouTube: 2020-08-27 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
All
right,
let's
start,
please
add
your
name
to
the
list
of
attendees
in
the
meeting
notes
and
let's
see
what
do
we
have
in
the
list
of
topics
observed
right
to
receive
your
pr
from
them.
B
Sorry
about
that
yeah,
so
I
just
wanted
to
touch
base
on
this.
I
presented
this
receiver
or
two
weeks
ago.
The
group
wanted
to
see
where
it
would
go.
So
I
opened
a
pr.
Yesterday
I
opened
this
on
the
core
repo.
I
realized
that
might
be
a
bold
move,
but
I
just
wanted
to
start
from
there
and
see
what
you
guys
thought
about.
B
What
that
might
look
like
you
know,
given
that
it's
go
native
and
potentially
potentially
not
have
a
lot
of
overhead
to
ship
it
in
in
the
build.
I
wanted
to
start
with
that
and
get
your
guys
thoughts.
A
Yeah,
that's
great
I'll,
have
a
look
at
it
and
we'll
see
if
anybody
else
any
other
maintainer
or
is
interested
to
have
a
look
at
that.
Definitely
very
interesting
to
me
and
we
actually
just
concluded
the
the
proof
of
concept
with
human
being
and
the
results
are
published
in
the
relevant
github
issue.
Let
me
actually
post
the
link
here
for
anybody
who
is
interested
to
know
where
that.
C
A
So
there
is
a
document
linked
from
the
from
the
threat
of
that
issue,
with
the
details
of
the
performance
measurement.
Very
briefly,
the
conclusion
is
that
it's
it's
usable.
A
But
anyway,
I
think
it's
it's
a
successful
proof
of
concept.
We
can.
We
can
recommend
fluency
as
a
companion
to
collector
as
we
thought,
but
in
as
a
short-term
solution
right
but
longer
term.
I
think
it's
very
useful
to
have
the
the
alternate
solution
that
you
propose
and
see
if
we
want
to
have
certain
capabilities,
if
not
everything
that
will
be
passed,
natively
supported
by
the
collector.
So
this
is
a
very
welcome
pr.
I'll
definitely
have
a
look
one
concern
we
had.
We
discussed.
A
That
was
how
much
the
executable
size
will
increase
as
a
result
of
this,
but
anyway
I'll
take
a
look
and
we'll
come
into
that.
B
A
Okay,
so
we're
good
with
that
next
topic:
young
punitious,
remote
pride
exporter,
is
young
in
nicole.
D
Yeah
so
that
pr
spoken
and
said
that
he'd
like
to
review
that
before
after
the
collector
has
switched
to
like
a
newer
hotel,
p
metric,
proto
and
and
like
I'm,
I'm
right
now
converting
from
otlp
directly
in
that
exporter.
And
then
I'm
just
wondering
what
a
timeline
looks
like
for
this
switch
to
happen
in
the
collector.
Because
I
I
think
there
are
still
changes
happening
in
the
proto
repository
and
like
I'm,
not
sure
how
soon
like
it
will
translate
to
a
change
in
the
collector.
E
Yeah
sure
I'm
not
as
unsure
as
you
are
young
most
likely
most
likely.
I
know
there
is
a
deadline,
so
if,
by
next
week
this
is
not
happening,
we
should
start
reviewing
the
pr
as
it
is
and
we
will
do
the
conversion
while
we
transfer
all
the
other
code.
So
I
I
cannot
give
you
a
better
or
more.
D
Okay,
okay,
that
that's
fine;
and
but
it's
just
that
you'll
probably
be
working
with
someone
else
by
the
time
because,
like
I'll
be
gone
next
after
next
week,
yeah,
but
next
week,.
A
G
I
was
just
noticing,
there's
like
26
pr's
open
right
now.
Some
of
them
are
pretty
stale
and
looks
like
you
know.
A
A
Any
other
ideas
on
how
we
can
make
better
progress
on
the
pr's
and
everything
quickly.
I
agree
that
it's
less
than
ideal,
especially
not
not
just
the
sheer
number
of
the
open
pr's,
but
how
long
they
stay
open
and
then.
H
A
G
I
would
I
would
be
happy
to
jump
in
there
and
look
at
some
of
them
or
do
what
it
takes
to
get
them,
so
they
pass
the
bill
that
would
help.
A
Yes,
that
would
be
great
if
you
feel
any
of
those.
They
are
interesting
to
you.
If
you
feel
that
you
would
like
to
take
the
responsibility
for
any
particular
one.
Please
do
so.
G
Array
span
types:
let's
see
where
did
that
go
to?
Where
is
that
still
or
did
that
get
married.
A
One
that
I
proposed
that
I
measured
today.
G
Okay,
great
all
right
I'll
go
something
through
some
of
these
others
like
I
could,
I
could
take
care
of
these
ones
were
about
pump
the
versions
up.
I
guess.
E
E
If,
if
you
try
to
help
that
one
happy
to
accept
okay,
all
right
general
in
general,
my
point
is
indeed
there
are
some
stale
prs
and
probably
we
are
not
moving
very
fast,
but
one
thing
that
people
can
also
help
is
reviewing
other
pr's.
I
mean
I
really
appreciate
when
you
kevin
or
anyone
else,
pre-review
things.
So
then
it
makes
my
life
easier.
You
can
feel
if
you
feel
you
want
to
help
with
this.
I
I
think,
having
a
good
review
before
me
or
tigran
will
also
review.
It
helps
a
lot
us.
A
E
Converted
in
contribute
as
well-
okay,
yes
everywhere,
because
otherwise
I
would
have
not
done
this
so
everywhere
they
are
converted.
There
are
a
bunch
of
components
that
are,
I
was
lazy,
converted
them,
which
means
they
still
convert
from
otlp
to
open
sensors
and
then
apply
their
logic.
So
some
of
these
components
may
require
people
to
help
us
moving
like
there
are
some
vendors
specific
things
like
neurally
honeycomb
lifestyle
just
remove
their
thing
because
they
accept
otlp
directly
right
now,
but
some
of
these
things
may
need
to
to
change
as
well.
A
G
A
E
B
Sure
I'm
happy
to
do
that.
This
is
my
pr
so
nice
to
meet
you
bargain.
Yes,
stanza
is
a
open
source
log
tailing
processing
agent.
It's
designed
to
run
standalone
if,
if
desired,
but
it
is
written
in
go
so
it
can
be
imported
directly
into
the
receiver
as
I've
done
and
configured
inline
just
as
a
single
receiver.
B
So
it
supports
a
wide
variety
of
of
we
call
them
operators
but
there's
sort
of
a
similar
concept
to
open
telemetry's
pipeline.
We
have
input
operators,
you
can
tailor
file,
you
can
receive
logs
over
tcp
or
udp
windows
event.
Log
journal
d
et
cetera
a
variety
of
different
types
of
processors,
so
you
can
parse
json
regex
basically
manipulate
the
log
record
into
something
you
know
useful
and
then
pass
it
along
to
the
pipeline.
B
E
Okay,
I
will
look
into
this.
I
I
have
zero
expertise
in
logs,
so
if
anyone
agrees
that
this
is
a
very
important
software
that
we
need
to
support
in
core
just
help
me
understand
this,
because
I'm
I'm
clueless
on
this-
I'm
just
trying
to
to
to
help
everyone,
but
I
don't
know
if
this
should
be
in
core
or
country.
It's.
B
Happy
to
work
with
anyone
who
wants
to
to
drill
into
it
further
with
me.
A
Then
did
the
demo
of
this
solution
two
weeks
ago.
I
believe,
then,
if
you
have
any,
the
recordings
are
probably
there,
but
if
you
have
any
summarizing
documents
which
show
the
I
think
you
did,
you
also
did
the
performance,
measurements
and
stuff
like
that
right.
It
may
be
useful
for
you
to
send
them
to
both
them
to
have.
A
And
both
of
them,
we
can
also
discuss
this
internally.
If
you
want,
I
can
give
you
more
details.
You
know
that
we
are
adding
log
the
support
for
logs
to
the
collector
some
level
of
support.
Is
there
minimal
support,
particularly
with
outsourcing
most
of
the
reading
receiving
functionality
to
through
and
bit
as
an
external
process?
What
this
one
does
is
is
more
open.
Telemetry
collector,
collector
centric
approach,
where
everything
is
just
a
go
code,
and
so
it
adds
support
for
reading
files,
for
example,
but
which
the
collector
does
not
do.
E
You
don't
need
to
convince
me
if,
if
you,
if
everyone
agrees
with
pink,
I'm
fine,
it's
just
a
matter
of
not
having
experience
and
I
saw
new
dependencies
and
I'm
trying
to
keep
our
make
our
life
easier
by
not
having
to
deal
with
with
the
dependencies
that
we
cannot
control
that
stuff.
An
alternative
question
I
would
have,
should
we
support
both
men
and
these
stanza
in
the
core
or
just
one
of
them,
and
go
with
one
version
in
core
again.
E
We
have
to
support
both
in
the
whole
ecosystem,
but
it's
a
question
of
what
is
the
default
that
we
want
to
support.
A
Yeah
those
are
good
questions.
I
think
we
don't
really
have
the
answers
yet
I
would,
I
will
aim
to
first
add
the
support
to
the
country.
Probably
since
you
already
created
the
pr,
let's
have
a
look
at
that
and
then
we
can
take
it
from
there.
I
believe
something
like
this
is
necessary
in
terms
of
functionality
in
the
collector
sooner
or
later,
but
how
exactly
we
get?
There
is
probably
an
open
question,
actually
a
posted
sort
of
a
roadmap
for
the
lock
supported
up
in
telemetry.
A
It's
not
merged
yet,
but
already,
I
think
it's
approved
by
the
required
number
of
approvers,
so
it's
probably
going
to
be
merged
soon,
and
it
includes,
and
also
the
overview
of
logs
in
north
inflammatory,
there's
another
document
which
which
which
describes
what
is
the
minimal
functionality
that
we
need
to
have
in
open
climate
collector
with
regards
to
logs.
So
this
probably
exceeds
somewhat
that
meaning,
which
means
that
there
is
no
rush
to
have
this
functionality
right
now.
But
if
we're
getting
this
functionality
earlier
than
we
wanted
to,
then
it's
probably
even
better
right.
A
I
E
E
E
Like
a
tech,
lead-ish
person,
I
mean
I'm
I'm
happy
to
review
and
help
with
a
lot
of
things,
but
we
need
somebody
to
to
overseeing
the
entire
picture
as
this
pr,
for
example,
personally,
I
have
zero
experience
into
how
this
works
and
stuff.
I
I
can
review
and
see.
Yeah
go.
Quality
is
good,
makes
things,
but
I
don't
know
how
how
the
logging
world
works.
A
E
Yeah,
are
you
confident
that,
okay,
there
is
a
roadmap?
There
is
a
goal
where
to
want
where
we
want
to
go,
go
who
who,
who
is
in
charge
of
making?
The
call
of
this
is
the
right
way
to
achieve
that
goal.
That's
where
I
feel
I'm
lacking
and
I
feel
like
I'm
not
gonna,
be
able
to
help
I'm
I'm
able
to
trust
others
who
have
experience.
E
J
J
Come
on,
I
think,
to
some
degree
we
should
probably
also
hash
this
out
in
the
log
stick
right,
but
I
think
the
question
is
reasonable,
like
the
way
that
I
interpret
this-
and
you
know
I
have
unfortunately,
you
know
missed
that
demo
because
of
you
know
the
other
things
that
I
had
to
do,
but
I'm
actually
quite
excited
about
this
and
I'm
gonna.
Second,
you
know
mark's
comment
that
you
know
the
faster.
We
can,
you
know,
didn't
push.
You
know
support
for
logs
through
this
thing.
J
I
think
it's
going
to
be
good
for
everybody,
and
you
know
you
know
dan
and
his
folks
almost
feel
like
you
know
they
are
volunteering
to
be
additional
headcounts
to
some
degree
here
which,
which
is
which
is
pretty
excellent,
so
I
haven't
had
a
chance
to
look
at
it
myself.
You
know
I'm
going
to
try
to
line
up
some
folks
on
my
end.
Also
to
sort
of
you
know
give
this
a
fair
shake
in
the
same
photo
fluid
bit
thing.
J
You
know,
we've
been
doing
focusing
on
some
other
things
in
the
last
couple
weeks,
but
so
certainly
like
I
would.
I
would
be
in
support
of
you
know
getting
something
there
there's
a
code
base.
You
know
yeah
we'll
bat
it
around
a
bit,
but
I
don't
know
dan.
You
know
how.
How
are
you
guys
looking
at
this,
you
would
you
like
how
active
for
role
do
you
want
to
play
here.
B
I
you
know,
I
think
that
if
we
get,
if
we
can
get
this
into
it,
we
want
to
you
know
to
be
very
involved.
I
you
know,
I
guess
I
can't
comment
on
what
the
company
is
willing
to
commit
resources-wise,
but
we
certainly
are
committed
to
making
sure
this
is
an
excellent
logging
library
and
that
you
know
if
there
are
use
cases
coming
out
of
open,
telemetry
they're,
going
to
be
use
cases
that
we
want
to
solve
anyways.
B
B
The
larger
context
of
what
we
could
do
for
for
the
collector,
it's
probably
probably
a
better
question
for
mike
and
and
unfortunately,
he
couldn't
make
it
today.
A
B
Yeah,
I
definitely
could
I
can
you
know.
Maybe
we
plan
on
doing
that
in
the
log
sig
at
six
I
can.
I
should
be
able
to
do
that.
G
Another
thing
you
might
think
about
is
you
know
the
the
stuff
that's
in
core
for
tracing
and
metrics,
for
the
most
part
is
cncf
other
cncf
projects,
so
you
know
is,
would
you
guys
be
thinking
about?
Maybe
you
know
putting
the
open
source
part
up
into
the
cncf
foundation,
or
does
it
make
sense
to
do
something
like
that.
E
E
When
it
comes
to
tracing
and
metrics,
I
can
make
all
the
decisions,
because
I
know
very
well
the
area
I
still
feel
like.
We
lack
someone
or
maybe,
if
you
want
to
be
that
person
and
be
more
involved
into
reviewing
all
these
design
things,
but
we
need
somebody
who
is
who
is
the
leader
on
blogs
and
I
can
go
and
just
say,
hey
person
who
just
please
tell
me
if
this
is
the
right
thing
to
do
or
not.
E
Could
could
be,
I
would
prefer
to
be
one
or
two
people
that
we
even
start
make
an
extension.
Add
them
as
approvers
to
the
to
the
collector
and
and
yes
initially,
we
oversee
their
reviews
and
stuff,
but
then
later
they
become
authority
in
that
area
because,
as
I
said,
we
lack
on
this.
That's
that's
my
my
my
personal
understanding
of
the
moment
that
when
prs
like
this
come,
I
have
zero
clue
of
how
to
to
understand
them
more
than
just
okay.
There
is
an
http
server.
I
know
how
to
create
that.
E
Having
some
experience
like
you
or
someone
with
experience
and
and
yeah,
and
just
starting
to
review
code
and
be
active
in
the
collector
pr's
and
issues
more,
that's
that's
the
only
thing
that
we
want.
Sorry.
J
I
E
A
L
L
M
I
E
J
Makes
makes
perfect
sense,
there's
somebody
on
my
end
that
I
that
could
potentially
you
know
that
like,
but
I
have
to
sort
of
have
some
conversations
internally
there's
one
of
our
guys
who's
been
contributing
gemma
on
on
the
tracing
side.
Already,
let
me
see
if
you
know
if,
if
we
can
line
that
up
potentially
as
an
option,
we
can
hash
it
out.
J
You
know
funny
yeah
I've
been
getting
these
offers
for
yachts
for
a
long
time,
but
like
today,.
J
Obr's
yeah,
I
I'm
little
leads
like
I
don't.
Even
I
can't
even
right
like
today
I
got
an
inbound
from
one
of
the
one
of
the
warriors
basketball
team
right
obr's,
like
specifically
came
at
me
with
oh
yeah,
apparently
you're
going
ipo.
We
have
some
floor
tickets
available.
That's.
A
J
L
I
B
Just
one
quick
one,
more
quick
note
on
this:
if
you
don't
mind
sorry,
I
just
looked
at
your
looked
at
the
testing
that
was
done.
The
benchmarking
on
the
flipbit
integration
and
I'd
be
happy
to
try
and
reproduce
this
with
with
the
observer
iq
agent
as
well
and
see
if
we
can
yeah.
K
I
A
quick
question
I
was
talking
to
alolita
today.
Two
of
our
interns
wrote
like
one
of
the
problems
that
we
had
is
that
the
collector
had
a
prometheus
exporter
that
exposes
from
slash
metrics,
but
it
didn't
have
a
push
for
me
to
use
exporter,
meaning
it
couldn't
do
remote
right.
I
H
E
Young
was
chatting
with
me,
and
I
promised
to
him
that
next
early
next
week,
I'm
I'm
doing
something
of
that
pr,
it's
already
in
core.
It's
just
a
matter
of.
We
are
a
bit
behind
with
our
own
proto
definition,
our
internal
model,
and
I
was
asking
him
to
wait
a
bit.
But
if
that's
not
possible
yeah,
we
have
a
story
for
that.
I
E
A
M
J
E
E
E
A
A
K
A
A
K
A
A
What
do
we
do
with
this
dependencies
kevin?
You
wanted
to
have
a
look
at
this.
G
E
H
G
E
G
A
This
one,
I
think
this
should
go
to
j.
What
do
you.
N
A
A
N
I
think
I
think
this
is
this
is
the
this
is
already
approved.
You
can
just
anurag
is
doing
all
the
engines
for.
N
A
A
E
N
L
L
G
C
I
J
I
know
it's
a
tricky
tricky
times.
Man.
I
A
Okay,
I
think
we
can
start
so.
The
logs
world
map
open
telemetry
roadmap
for
logs
it
just
got
merged.
A
I
think
it
would
be
very
useful
to
maybe
very
quickly
go
over
the
items
in
the
roadmap.
It's
this
is
just
an
initial
understanding
of
what
it
means
to
have
logs.
You
know,
inflammatory
would
be
probably
useful
for
everybody
to
have
a
look
at
what
the
list
contains,
and
some
things
are
actually
already
implemented,
which
is
good.
Let's,
let's
have
a
look
at
the
list.
So
what
do
we
want
to?
Do?
It's
two
to
two
major
parts.
A
One
is
in
the
specification
and
as
the
case,
the
other
is
in
the
collector
for
the
specification.
What
do
we
want
to
do?
We
want
to
have
the
guidelines
about
what
do
the
logging
libraries
need
to
do
to
support
mods
in
an
open,
telemetry
compliant
manner,
write
all
those
things.
A
You
said
that
the
library
needs
to
output,
the
trace
context
in
what
form,
format,
etc,
etc,
and
with
the
the
recommendations
about
how
to
do
how
to
implement
those
things
in
the
libraries
then,
according
to
those
recommendations,
we
want
to
implement
a
so
not
according
to
that.
We
want
to
implement
an
sdk
for
java
language,
which
makes
it
easy
for
logging
libraries
to
add
that
support.
A
Then
then,
using
the
sdk
that
would
create
for
java
show
how
exactly
those
recommendations
can
be
followed,
and
then
we
create
a
open,
telemetry
logging
solution
for
java
logging,
libraries
for
one
of
them,
the
most
popular
ones
or
maybe
for
a
couple,
even
vlog
4g,
maybe
logger
whatever
we
think
at
the
moment
is
the
most
important
to
show
how
it
works.
Obviously,
it
should
be
compliant
with
that.
The
concepts
that
we
only
have
in
specification
for
the
load
context
should
be
added
to
the
to
the
logs.
A
It
should
support
sending
through
otlp
protocol
yeah
things
like
that
and
then
to
show
how
that
can
be
used.
We
also
create
an
example:
application
which
uses
that
library
and
its
logs
and
traces
and
shows
that
that
how
the
correlation,
how
the
logs
and
traces
are
emitted
in
in
the
correct
way,
so
the
correlation
is
there.
A
I
think
it's
important
example
like
that,
a
simple
example
which
basically
shows
the
right
way
to
use
the
development,
planetary
loads
and
traces
together
and
further
advance,
whatever
we
have
to
have
in
the
specification
for
the
logs,
we
already
have
a
few
documents
things
like
the
overall
overview.
A
The
protocol
obviously
already
has
the
logs
definition
the
how
the
trace
contract
should
be
specified
in
the
last
one.
That
david
has
a
knockout
for
stuff
like
that,
so
this
is
basically
all
that
goes
to
the
specifications
or
either
a
document
of
some
sort
or
to
the
sdk,
so
that
it's
it's
a
library
of
some
sort
and
then
the
second
big
portion
is
what
do
we
have
in
the
collector
right?
A
We
want
to
have
the
support
for
the
for
the
logs
in
the
ltlp
protocol
to
receive
and
send
that
this
is
actually
already
implemented
to
have
the
data
type
for
the
array.
Values
again
already
implemented
this
at
the
time
of
writing.
This
was
not
yet,
but
it's
already,
and
then
we
want
to
have
a
bunch
of
exporters
in
the
collector
that
are
able
to
send
the
logs
to
different
vendor
back-ends.
A
We
don't
have,
I
think
we
don't
have
any.
Today.
We
only
have
our
tlp
sending
we
have
ability
to
write
to
two
files
for
diagnostic
purposes,
but
not
not
vendor-specific
network
transports,
and
we
will
need
to
have
those
and
encourage
vendors
to
load
implementations
for
that
implement
the
fluence
for
protocol
receiver.
This
is
also
already
done.
It
was
part
of
the
proof
of
concept
that
we
wanted
to
do.
The
plc
is
completed.
This
receiver
is
implemented
there.
A
Results
are
published
there
as
well
at
support
for
for
the
these
common
processors
to
support
logs
as
data
types
right,
basic
things
like
modifying
the
attributes
in
the
logs
modifying
resources
that
are
coming
in
the
logs
and
stuff
like
that,
the
pure
energy
is
targeted
to
support
it.
It
supports
traces
and
metrics
today,
but
not
logs.
So
we
want
all
these
common
generic
processors
to
support
logs.
Just
like
many
support
choices
and
metrics,
then
we
want
to
have
some
performance
tests
like
we
have
for
traces
and
metrics.
A
We
want
to
have
the
same
thing
for
the
logs.
We
have
some
rudimentary
sleeps.
I
think
single
test
at
the
moment,
which
does
some
benchmarking
for
the
for
the
logs.
A
A
J
The
performance
test,
the
purpose
for
those
is-
is
mostly
to
prevent
requestions
because
we're
going
to
run
them
in
in
the
in
ci
somehow
or.
A
Yes
correct:
we
have
that
we
have
that
for
traces
and
metrics
and
the
purpose
is
you're
quite
twofold.
Right
one
is
to
prevent
regressions
and
the
other
is
to
have
published
results
they
every
time
we
run
a
master
branch
build
all
the
performance
tests
are
executed.
They
are
available
for
everybody
to
have
a
look
at
to
see
the
project.
A
If
there
is
regression,
if
it
test,
exceeds
the
defined
limits
for
the
cpu
and
memory
usage,
we
have
the
tester
for
that
it
works.
We
have,
we
even
have
a
single
one
test
for
the
for
the
logs.
At
the
moment
again,
it
was
managed
just
today,
so
this
one
says
to
test
the
operation.
Basically,
it's
about
what
things
we
wanted
to
do
for
the
proof
of
concept.
Again,
this
is
done
virtually
everything
we
wanted
to
do
for
the
poc.
It's
done.
We
have
the
results
published
links
from
the
from
the
github
issue.
A
There's
a
google
document
which
describes
the
results,
so
this
is
done,
and
the
last
one
which
I
would
want
to
have
is
a
kind
of
more
comprehensive
example,
which
shows
how
you
use
the
collector
on
a
on
a
kubernetes
native
application
right
with
with
different
services
running
under
kubernetes
and
with
the
collector
collecting
the
logs
traces
and
metrics
from
from
all
those
services
and
demonstrating
how
the
correlation
works,
how
how
everything
is
supposed
to
work?
A
Basically,
right
when
you
have
all
three
signals
produced
by
the
applications
and
the
the
collector
getting
all
the
telemetry
and
sending
to
the
back
ends
this
one,
not
not
not
probably
a
simple
example
should
be
kind
of
more
complicated
than
the
simple
one
that
we
would
want
to
do
with
java,
for
example,
this
one
could
be
preferable.
Q
also
should
not
be
different
languages.
If,
by
then
we
have
support
for
different
languages,
so
something
that
demonstrates
really
clearly
shows
how
you
use.
That
demonstrates
the
value
of
the
entire
solution.
A
A
Do
you
have
a
timeline
for
others?
No
timeline.
The
open,
telemetry's
current
goals
is
to
have
a
ga
release
for
the
traces
and
metrics.
First
right.
I
don't
think
we
have
an
exact
date
for
that,
organizing
the
call-
maybe
you
can
help
me,
but
I
believe
it
has
to
happen
this
year
for
the
logs.
It's
very
unlikely
that
yeah
this
year.
L
Yeah
so
works
we're.
The
tracing
spec
is
going
to
be
locked
down.
What
is
it
next
week?
Metrics
will
be
shortly
after
that
the
first
batch
of
rc's
are
going
to
take
place
in
the
following
weeks.
We
want
the
open,
telemetry
at
least
tracing
and
metrics,
to
go
ga
this
year.
Pretty
desperately
logs
will
be
some
point
next
year
really
depends
on
the
throughput
that
we
do
in
this
group
and
and
in
the
collector
group.
P
A
We're
actually
keeping
the
scope
relatively
small
compared
to
the
traces
and
metrics,
so
this
is
significantly
smaller
effort
than
what
we
do
for
for
the
traces
or
for
the
metrics,
so
hopefully,
even
with
smaller
number
of
people,
we
should
be
able
to
have
something
useful
within
the
scope
that
is
in
this
document.
Hopefully
yeah.
I
think
we
should
aim
to
have
something
next
year,
not
not
later
than
maybe
meet
next
year.
Maybe
earlier.
A
I
think
it's
definitely
a
useful
thing
to
have.
I
wouldn't
say
it's
probably
the
bare
minimum
of
functional
issues.
It's
part
of
the
bare
minimum
functionality,
definitely
one
of
the
probably
important
things
that
you
would
want
to
have
after
you
do
the
the
minimum
things.
Yes,
I
I
do.
We
do
have
that
today
for
traces
only
by
the
way,
not
even
for
metrics,
so
probably
that
first
needs
to
be
added
for
the
metrics
and
then
for
the
long
spot.
A
A
Then
I
agree
just
to
make
it
three
this
this
world
map
is
not
something
that
is
set
in
stone
right.
We
should
be
free
to
up
things,
removing
them
things
right,
modify
things.
This
is
just
for.
This
is
not
any
sort
of
commitment.
It's
just
for
us
to
be
aligned
to
understand
what
is
it
that
we're
working
on?
What's
the
current
goal
for
us,
so
we
see
things
missing
here.
We
are
free
to
add
stuff.
A
A
O
Sorry,
one
belated
question:
it's
ron
from
walmart
what
about
javascript
in
addition
to
java,
because
that
would
capture
a
lot
of
client
and
server
side
functionality
today,
especially
at
walmart.
A
Yeah,
I
I
think
eventually,
we
most
likely
will
want
to
have
support
for
multiple
languages.
Not
just
java
java
is
just
one
of
the
maybe
languages
where
we
have
right
now,
the
best
understanding
of
how
we
would
do
that,
and
also
we
previously
did
a
proof
of
concept
of
how
that
would
work,
and
that
was
the
reason
why
it
was
chosen
as
the
chosen
as
the
first
language.
We
would
want
to
support,
but
definitely
it's
completely
open
to
our
support,
and
I
think
we
should
eventually
at
least
we
should
add,
support
for
other
languages.
A
P
A
P
Looking
to
drive
that
you
use
the
java
implementation
to
experiment
and
figure
out,
what's
right
for
the
specification
and
then
after
the
specification,
it
should
should
go
to
the
rest
of
the
sdks.
I
A
Right
so
we
actually
have
the
issue
recorded
in
the
specification
repo.
I
was
looking
for
volunteers
to
help
with
that.
I
don't
think
we
have
anybody
who
wanted
to
do
that.
Yet
I
agree
it's
important.
A
We
did
some
some
work
on
the
open,
telemetry's
semantic
conventions
recently,
which
generally
right
not
just
walks
but
generally
for
traces
and
metrics
as
well.
A
So
we
we
have
a
bit
more
clarity
on
what
the
semantic
conventions
look
like
at
open
telemetry,
but
I
think
there
is
still
a
lot
of
room
for
improvement
and
ecs
again,
I
think
it's
yes,
that's
very
important
to
do
is
just
we
don't
have
necessarily
the
right
person
who
can
drive
this
if
anybody
wants
to
do
that,
I
think
it's
very
valuable
to
do,
and
could
you
be
open
to
that.
I
So
what
what
would
you
imagine
the
scope
of
works
that
is
needed
here
be
cause
like?
I
think
the
suggestion
from
elastic
was
that
we
will.
They
will
designate
a
subset
final
stops.
It
doesn't
make
sense
because
it's
elastic
specific
and
then
they
can
put
it
as
a
full
request,
and
we
will
accept
that.
So
I
think
there's
the
we
need
to
go
to
elastic.
I
don't
know
if
they're
on
the
caller
and
ask
if
they're
still
on
board
with
that.
But
what
would
you
want?
Somebody's
at
least
driving
that
to
do.
A
C
A
A
A
Okay,
I
guess
one
other
thing
that
I
wanted
to
discuss
and
that
would
be
will
be
last
for
me
is
how
do
we
proceed
with
the
java
implementation
david?
I
think
we
have.
A
We
wanted
to
initially
place
this
in
the
java's
open,
telemetry
sdk,
but
there
were
some
concerns
about
how
this
will
affect
the
velocity
of
the
traces
and
metrics,
because
because
the
there
is
not
much
throughput
from
the
reviewers
currency
that
they
can
allocate
to
reviewing
their
logs
related
prs.
A
Interestingly,
there
was
a
new
repo
created
inflammatory
for
java
country
things,
so
I
think
this
could
be
an
interesting
place
where
we
could
put
that
at
least
initial
implementation
of
the
of
the
log
support
blocks
sdk
for
java
and
then
maybe
over
time.
We
move
it
to
the
to
the
primary
repository
make
it
part
of
the
core
open,
telemetry
sdk.
A
P
So
I
actually
joined
with
the
last
one
I
joined
the
meeting
and-
and
we
had
a
discussion
about
it-
you
know
their
concern
is
almost
entirely
that
they
don't
have
the
resources
to
do
code
reviews
and
such
during
that
meeting
bogdan
stepped
forward
and
said
that
he
would
kind
of
lead
up
code
reviews
on
that.
So
at
the
moment,
there's
kind
of
a
general
approval
that
we
can
work
in
the
sdk
extensions
directory
in
the
java
repo,
so
that
pull
request
that
I've
got.
P
There
is
moving
forward
and
you
know
bugged
and
gave
me
some
comments
today,
I'll
I'll
fix
those
up
tomorrow
and
maybe
we
can
get
that
merged.
Okay,
great,
that's
great.
A
Nice,
very
good,
okay,
that's
that's
even
better
than
I
thought
okay,
so
we
can
make
progress
on
that
front
as
well.
Okay.
So
what
I'm
gonna
do
is
go
over
the
roadmap
list
and
create
corresponding
issues
for
each
of
the
items
that
is
not
yet
done
and
then
we'll
see
who
is
going
to
take
this
items
and
and
actually
execute
on
that.
A
Yes,
they
are.
We
have
log
logs
logs
or
log
tag
label
in
the
in
the
specification,
repo
and
in
the
collector
repo
both
have
the
yeah
that
logs
label
so
I'll
definitely
label
them.
As
a
mobs
related
thing.
A
I
I
A
To
clarify
this
is
this
is
not
only
about
logs
right.
We
want
to
the
semantic
conventions,
should
work
across
all
the
signals
right
when
you're
saying
a
log
or
a
trace
or
a
metric
is
coming
from
a
host,
then
you
need
a
way
to
describe
that
host
right
and
you
want
that
way
that
you
describe
it
to
be
uniform
across
all
signals,
so
the
semantic
conventions
that
we
have
at
all
inflammatory
they
they
are
not
just
for
logs.
A
A
And
and
stackdriver
has
those
right
has
the
traces
related
conventions
it.
L
O
A
I
did
not
have
an
intent.
Sorry,
I
did
not
have
an
intent
to
say
that
ecs
is
not
good
enough.
We
need
to
have
something
else,
but
the
intent
was
that
whoever
is
doing
this
work
better
to
have
a
look
at
what
else
exists
right
in
the
industry.
I
I
It's
still
evolving,
but
I
think
it's
good
and
has
a
good
foundation,
and
I
can
point-
maybe
it's
my
ignorance
to
others
in
the
industries
that
we
should
be
looking
to
other
than
obviously
open
metrics
in
the
metric
space,
and
I
think
open
telemetry
with
you
know,
bringing
in
open
sensors
and
open
tracing
has
brought
in
the
best
of
tracing.
So
I
don't
know
that
there's
work
to
be
done
on
the
semantic
definition
for
trace
and
metrics
to
pull
from
the
outside,
not
that
we
can
develop
ours
now
logs.
I
I
feel
that
is
like
a
much
more
complex
problem
domain
than
trace
and
metrics,
simply
because
logs
are
not
well
structured.
There's
infinite
number
of
you
know
log
possible
log
values,
but
there
are
common
ones
that
everybody
want
to
refer
to
and
that's
why
I
feel
that
the
issue
of
surrounding
convention
for
logs
is
more
complicated
and
actually
bigger
than
metrics
and
traces,
and
therefore,
like
my
intent
in
saying
you
know,
let's
bring
in
cmo
ecs
and
I
think
the
response
from
splunk
was.
I
You
know
we
would
rather
go
with
this
yes
than
pro
and
sim
was
that
you
know
we
don't
have
anything
for
logs,
so
I'm
not
suggesting
changing
the
metrics
and
trade
semantics
and
open
telemetry,
I'm
suggesting
bringing
in
acs
to
augment
what
we
have
and
expand
it
into
logs.
Because,
honestly,
like
in
my
experience,
I
have
to
hear
other
vendors
here.
There
is
nothing
that
is
more
comprehensive
than
ecs
in
the
industry.
Now
resolving
the
dot
notation
versus
you
know
hierarchical
notation,
that's
a
good
exercise
to
do.
I
A
Maybe
the
answer
is
nothing.
I
don't
know
right.
That's
for
the
person
who
is
going
to
to
look
into
that,
and
I
I
don't
disagree
with
you,
I'm
just
I
I
don't
know
if
I
knew
the
answer,
I
would
just
maybe
do
it
myself
right
now
right,
in
my
opinion,
this
this
requires
somebody
to
thoughtfully
go
over
the
issue.
A
L
Yeah,
the
elastic
folks
usually
join.
We
have
the
the
morning
sessions,
it's
usually
surreal,
le
clerk
from
elastic
it's
pretty
late
for
over
in
where
he
is
in
paris
right
now,
so
we
can
bring
it
up
with
him
next
week,
assuming
he
joins.
I
had
I
had
talked
to
elastic
about
two
months
or
three
months
ago
about
this.
They
were
very
keen
for
us
to
use
either
all
of
ecs
or
any
subset
of
ecs.
I
L
So
I
don't
think
we're
gonna
get
any
pushback
from
them
like
it's
literally
what
tigran
mentioned
just
we
have
to
line
up
either
which
subset
of
it
we
want
to
take
or
when
we're
setting
the
semantic
convention
to
the
other
data
types
just
make
sure
it
either
meshes
make
sure
it
meshes
with
the
elastic
once
again.
A
Mark
imagine
simple
situation
if
elastic
has
a
definition
for
some
concept,
which
has
a
different
name
compared
to
the
same
concept
that
already
exists
at
open
telemetry,
then
what
do
we
do?
In
that
case
right?
We
need
to
decide
whether
we
do
we
rename
what
we
have
enough
inflammatory
already
do.
We
allow
two
different
names
for
the
same.
A
M
A
L
Is
there
a
is
there
like
an
otep
or
a
pr
on
specs
repo
or
something
where
people
are
proposing?
The
the
actual
semantic
names
that
we
use.
M
A
Add
a
new
concept:
they
propose
an
apr
which
has
maybe
a
few
more
conventions
around
that.
L
Okay,
I'll
bring
this
up
with
the
specs
meeting
next
week.
I
think
see
when
you're
usually
a
good
place
to
discuss
this.
I
I
J
Of
the
protocol
and-
and
that
needs
to
be
hashed
out
right-
that's
that's
the
real,
that's
the
real
problem
right
and
there's
the
force
of
open
telemetry
already
having
made
up
their
mind.
You
know
various
other
vendors
and
people.
I've
been,
you
know
sweating
over
that
and
it's
basically
about
to
go
ga
at
this
point.
G
B
J
Yeah
I
like
ecs,
I
you
know
I
was
I
was
I
I
liked
the
presentation
they
did
it.
It
seemed.
I
think
it's
the
best
thing
out
there
that
I've
seen
so
I
have
nothing
against
it
from
that
perspective,
but
I
don't
really
have
a
good
idea
of
how
to
resolve
these
issues
with
the
sort
of
names
like
sort
of
this
just
sits
on
top
of
each
other
in
a
weird
way.
L
Well,
just
don't
expect
a
whole
lot
this
week,
because
it's
a
perf
review
time
at.
I
L
Yeah,
I
imagine
but
yeah
I'll
see
if
philip
can
spare
some
time
it
might
end
up
being
after
next
year.
I
Nothing
urgent,
thank
you,
yeah
and
then
think
on
the
other
questions
that
I
had
in
the
list
that
you
mentioned.
I
think
there's
a
use
case
in
almost
every
vendor,
where
you
would
want
a
a
pass
logs
and
generate
metrics
seems
to
be
an
interesting
thing
to
do
in
the
collector.
I
was
wondering
your
thoughts
on
that.
A
Yeah,
that's
that's
an
interesting
feature.
We
we
contemplated
about
having
something
like
that
where
the
input
data
type
is
basically
different
from
the
output
data
type.
It's
currently
not
possible
in
the
collector.
The
way
that
the
pipelines
work
is
it's
a
single
data
type.
What
comes
in
the
same
data
comes
out,
but
it's
a
possibility
and
I
completely
agree
with
it:
it's
a
definitely
an
interesting
capability
to
have
to
have
sort
of
a
processor
which
yes
can
receive
logs
or
traces
and
metricize
them
right,
output.
Metrics.
A
A
A
I
I
I
think
we
discussed
it
somewhere
that
the
idea
of
creating
a
log
or
an
event
based
on
the
metric,
like
the
scenario,
is
that
you
want
to
do
client-side,
collective
side
alerts
on
metric
behavior
and
if
they
meet
a
certain
condition,
you
generate
an
event
right,
yes,
and
I
kind
of
thinks
of
an
event
as
a
log.
But
I
don't
know
if
we
decided
or
not
decided
whether
events
are
the
special
signal
or
are
there
a
subset
of
logs.
I
So
yeah,
okay,
I
open
issues
for
that,
but
think
about
whether
those
should
be
in
your
world-
and
I
I
also
kind
of.
A
Definitely
yes,
long-term,
definitely
mark
it's
just
that
we're
trying
to
keep
the
roadmap
to
a
bare
minimum
to
make
sure
we're
actually
delivering
something
that
is
complete
in
a
sense
right,
complete
for
at
least
some
use
cases
with
with
the
number
of
people
that
we
have
who
work
on
loads
right
now,
which
is
much
much
smaller
than
traces
and
metrics.
A
A
Against
having
a
bigger
roadmap,
that's
that's
fine!
I
I'm
okay
with
increasing
the
the
scope
of
the
project,
especially
if,
as
you
said,
if
you
can
manage
to
bring
some
more
help
from
aws,
we
can
do
even
more.
I
A
A
A
Hopefully
if,
if
there
are
no
significant
negative
implications,
like
significant
increase
in
the
size
of
the
executable
and
stuff
like
that,
then
I
think
it's
yes
definitely
useful
to
aim
to
actually
have
that
in
the
collector.
Instead
of
relying
completely
on
the
fluent
beats
ability
to
read
the
logs,
at
least
for
significant
frequent
cases,
we
could
do
that
natively
in
the
collector
and
not
require
that
we
think
at
all
right.
So
to
me.
Yes,
that's
that's
an
interesting
direction
and
possible
line
item
in
our
in
our
roadmap
as
well.
A
I
Okay,
again
I'll
go,
get
try
to
get
some
resources
on
that.
How
do
you
did
we
set
on
the
question
of
how
do
we
handle
different
maturity
levels
in
the
collector
so
like
if
the
yeah
understood
yeah,
it's
yeah.
A
Yeah
very
good
question
with
a
change
this
big,
especially
right
because
it
brings
a
whole
another
agent
into
the
collector
with
a
lot
of
dependencies.
I
would
definitely
initially
aimed
to
introduce
a
concept
of
an
experimental
build
and
only
there
enable
this
capabilities
initially
exist
right,
so
that
it
does
not
affect
our
ability
to
release
the
collector
in
a
stable
form
for
traces
and
metrics,
because
this
this
brings
lots
of
code
base
and
lots
of
dependencies.
A
Yeah
yeah
a
build
time
right,
a
build
time
to
traditional
builds
with
with
certain
capabilities
only
available
in
the
experimental
version.
Today
you
can
all
obviously
enable
or
disable
all
those
components
at
one
time
by
just
using
the
the
right
configuration,
but
to
be
more
confident.
I
would
want
to
completely
separate
those
at
the
bit
time
so
that,
and
also
because
it
may
be
a
very
significant
increase
in
the
executable
size.
A
We
wouldn't
want
the
other
users
to
pay
the
cost
of
having
all
the
functionality
in
the
in
the
collector,
which
is
not
used
useful
to
them,
or
maybe
it's
useful,
but
not
stable
enough
to
be
used.
So
they
don't
need
to
pay
that
cost
right.
So
we
will
only
include
what
we
believe
is
ready
to
be
g8
in
the
collector
in
the
industry.
A
A
I
A
There
is
the
there
is
a
special
interest
group,
a
temporary,
seek
formed
around
that
it's
called
errors.
Sync,
I
think
they
meet
weekly.
They
made
proposals
around
that.
I
am
not
part
of
the
sikh
I'm
not
fully
aware
of
what
is
happening
there,
but
they
made
some
proposals
around
how
the
errors
should
be
represented
in
the
in
inflammatory
exceptions
and
errors.
Very
some
of
it
is
already
part
of
the
specification.
A
It's
at
this
stage
it's
about
errors
that
are
recorded
inside
spans
in
the
spans.
We
have
what
is
called
events
right,
which
is
according
to
our
vision.
It's
another
way
of
recording
logs
that
are
associated
with
spams
for
now,.
A
A
For
now,
all
the
work
that
is
done
is
in
that
particular
context
in
the
trace
context,
right
for
the
errors
that
are
part
of
the
spans,
but
I
think
what
what
they
are
doing
is
also
applicable
to
the
logs
as
well
right,
if
you're
recording
an
exception,
it
doesn't
really
matter
whether
it's
that
legal
exception
happened
as
part
of
the
spam
execution
or
it's
a
it's
a
standalone
thing
that
you
would
want
to
record
there.
So
what
the
work
that
they
are
they
are
doing
is
applicable
to
also
to
the
logs.
A
Yeah
we
we
don't
have
that
in
the
in
the
standalone
logs
at
all
specified
in
any
way,
but
I
fully
expect
that
they
the
work
that
they
do,
it's
not
complete,
yet
once
they
complete
it,
we
likely
should
be
able
to
adopt
it
either
as
is
or
it
should
be,
something
very
close
to
what
they
are
doing
for
the
stanza
landlords
as
well.
J
Thank
you,
okay,
thank
you,
so
so
on
that
one
then
like,
if
I'm
using
lock
for
chair
and
I'm
logging
an
exception,
you
know
maybe
a
question
for
david-
that
work
that
you're
doing
right
now
would
basically
just
turn
that
into
a
bunch
of
locks
right.
P
Well,
I
mean
so
well,
we've
got
different
paths,
but
the
the
path
that
I
think
we
care
about
is
you
know
basically
log
for
j
to
otlp
to
the
collector
and
so
kind
of
the
way
that
I
would
see.
That
is
that
you
know
when
you
get
the
the
log
call
from
log4j.
P
We've
got
just
the
exception
and
then
we've
got
whatever
log
message
you
have
with
that.
So
we
would
do
whatever
formatting,
to
that
exception,
that
we
would
do
for
a
for
adding
it
to
a
trace,
and
then
it
would
go
through
the
log
path.
Okay,
you
know,
because
it's
not
just
developers
that
are
doing
this.
Obviously
we
you
know
you
may
want
to
have
springs
logs
and
and
they're
just
going
to
use
a
lot
for
j.
So
we
want
to
be
able
to
have
that
path
as
well.
J
Yeah,
it
seems
pretty
reasonable,
hey
mark.
How
far
is
your?
How
far
is
your
interest
going
there
you
know
is
it?
Is
it
stack
traces
and
you
know
the
sort
of
classic
error
logging?
Or
are
you
thinking
you
know
even
further,
like
you
know,
including
you
know,
crash
dumps
and
you
know
quadrums
and
this
type
of
stuff,
but
that's
something
that
I've
seen
get
a
lot
more
popular
recently.
J
I
P
I
think
it's
definitely
part
of
the
same
problem
domain,
but
it's
also
you
know.
We've
got
a
lot
of
historical
precedent
on
logging
exceptions,
but
then,
like
you,
know,
going
further
and
logging
the
core
dome.
You
know
that
usually
is
a
different
path.
I
think
so
you
know
at
some
point.
It
would
make
sense
to
include
it,
but
I
think
you
know,
starting
with
common
practice
now
and
then
extending
out
after
that
would
make
more
sense.
I
L
No,
it's
it's
its
own
data
type.
I
mean
underneath
its
stack
traces
with
some
additional
information
on
them,
but
it
has
its
own
data
type
internally.