►
From YouTube: 2022-02-23 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).
B
C
D
A
A
A
The
second
is
an
otep
which
we
we
discussed
a
while
back
about.
How
do
we
map
data
received
externally
to
to
open
telemetry
that
otep
tries
to
answer
that
question?
I
think
it
I
opened
it
a
few
months
ago.
It
got
lost
somewhere,
so
I
revived
it
fixed
some
stuff
there.
So
if
you
have
any
thoughts
and
ideas
about
this
topic,
please
also
review
that
it
has
already
enough
approvals,
but
I
will
keep
it
open
for
a
while,
so
that
people
have
a
chance
to
see
and
comment.
A
F
Okay,
hi
hi.
How
are
you
again?
Thank
you
for
doing
an
introduction.
That's
awesome!
I
think
we,
sir
again,
thanks
to
you
know
this
has
been
a
great
team
effort
in
terms
of
everybody,
working
together
and
kind
of
brainstorming
and
working
with
cyril,
with
daniel,
with
christian,
with
jonah,
most
folks
providing
feedback
on
this
proposal,
and
let
me
just
share
the
issue.
F
So
we
we
finally
kind
of
decided
that
you
know
what
we
had
so
far
was
good
enough
and
the
idea
is
really
to
start
from
there.
There
is
a
google
doc
that
is
associated
with
the
otep
issue
that
I
think
people
have
already
started.
Then
I
saw
some
comments
from
dan
and
folks
who
you
know
again
would
like
to
get
some
feedback
from
others.
Also
cyril.
Do
you
want
to
walk
through
this,
or
do
you
want
me
to
again?
We
can
do
it
together
if
that's
yeah,.
F
I'm
sure,
but
again
this
is
the
dock.
I
just
shared
it
and
the
idea
was
again
I
can.
I
can
go
and
briefly
kind
of
do
an
overall
introduction,
but
we're
very
excited
to
kind
of
have
this
discussion
where,
as
most
of
you.
F
Sure
sure
is
that,
can
you
hear
me
okay,
because.
F
Okay
is
that
you
know
for
all
of
us
who
are
working
on
the
logging
specification,
as
well
as
defining
full
support
for
logs
in
the
otlp
protocol.
F
The
idea
was
to
put
together
otep
to
submit
to
the
logsig
for
incorporating
support
for
the
elastic
common
schema
in
the
in
hotel
and
to
provide
full
interoperability
for
ecs,
which
is
the
elastic
common
schema
for
common
implementations.
Right
and-
and
this
specifically
also
came
from
some
significant
use
cases
that
are
outlined
in
the
motivation
section.
I
can
share
the
doc
if
that's
useful.
F
So,
specifically
in
the
motivation
section
again,
we
tried
to
outline
some
of
the
key
use
cases
for
specifically
advanced
use
cases
for
handling
security
use
cases
as
well
as
event
management,
which
are,
you
know,
used
in
the
industry,
a
fair
bit
beyond
unstructured
log
such
as
you
know,
network
logs
or
vendor
http
logs.
So
really
looking
at
you
know
the
overall,
unstructured
and
structured
logging
formats
and
and
being
able
to
handle
different
use
cases.
F
The
other
significant
use
case
that
we
thought
would
be
good
to
highlight
is
adding
first
class
support
for
kubernetes
logs,
especially
application
logs
in
and
application
events
system,
logs,
etc.
Right
and
and
also
the
possibility
of
you
adding
some
definition
of
a
content
type
for
event
support.
F
So
these
were
some
of
the
you
know.
Key
use
cases
that
we
we
kind
of,
wanted
to
outline
and
call
out
and,
of
course,
have
you
know
a
larger
community
discussion
to
be
able
to
leverage
some
of
the
semantic
conventions
that
have
already
been
defined
in
ecs
and
that
could
be
used
as
part
of
the
extended
definition
in
in
hotel
for
logs
as
well.
F
As
you
know,
incorporating
some
of
the
specific
types
of
events
that
can
be
supported
also
by
the
ecs
so
cyril,
with
that
background,
I
think
I'll
hand
it
over
to
you
for
kind
of
stepping
through
some
of
these
areas
and
again
you
know,
would
love
to
have
a
larger
community
discussion
around
this.
C
Alolita,
so
we
have
worked
so
we
worked
with
lolita
to
capture
well,
the
benefits
we
identified
on
she
said
one
is
related
to
the
all
the
security
use
cases
and
today,
a
lot
of
the
contributions
to
the
elastic
command
schema
are
done
by
our
security.
Colleagues,
on
the
other
family
of
motivation
of
benefits.
Is
the
capability
to
structure
the
logs
of
vendor
products
or
open
source
products.
We
can
imagine
nginx
apache
httpd
so
after
we
have
highlighted
this.
C
So
it's
a
great
excitement
that
elastic
to
to
have
this
opportunity
to
contribute
to
collaborate
and
contribute
to
the
open,
dymetry
project,
with
a
clear
understanding
that
we
don't
want
this
to
be
to
ending
and
being
a
fork,
so
that
because
we
we
acknowledge
that
there
will
be
some
migration
on
efforts
to
merge,
because
some
concepts
are
already
existing
in
hotel
semantic
conventions,
so
it
will
have
to
to
align
together
on.
C
We
acknowledge,
I
think,
elastic
that
it
will
mean
that
if
the
donation
is
successful,
then
we
will
have
to
add
adapt
on
elastic
command.
Schema
will
become
our
new
language
until
we
want
this
to
be
very
clear
with
the
open
telemetry
community,
if
we
donate
ecs,
then
our
next
command
schema
at
elastic
will
be
the
open,
telemetry
semantic
conventions,
augmented
by
what
we
have
donated.
C
On
with
the
alignment
that
will
be
needed,
then
we
we
describe
some
guiding
principle
to
explain
to
the
audience.
What
were
the,
why
elastic
common
schemas
has
been
built
like
this
so
concept
like
human
readability,
reuse
of
namespaces.
C
Some
things
are
similar.
Something
are
different
between
hotel
semantic
conventions.
On
elastic
common
schema.
I
have
provided
an
example
of
an
nginx
access
logs
parsed
by
ecs.
I
could
also
have
put
an
apache
http
access
log
file,
one
next
to
the
other,
to
highlight
the
benefits
of
having
some
shared
commands
semantic
conventions,
so
that
people
can
collect
a
lot
from
any
http
server,
whatever
it
is,
and
they
will
get
a
unification
on
this
and
then
we
have.
We
have
worked
on
comparison
so
comparison
comparing
some
principle.
C
We
have
highlighted
the
nuance
between
resource
attributes,
the
span
on
log
attributes
on
how
it
compares
to
the
ecs
world.
We
have
looked
at
the
naming,
the
naming
mechanism
like
dotted
names,
namespaces
the
extensibility
mechanism.
We
wanted
to
verify
because
hotels
are
there.
Is
this
grpc
based
data
schema,
but
then
there
is
the
flexible
attributes.
C
I
also
did
an
exercise
to
compare
the
data
types
to
understand
how
these
things
will
merge
together.
So
we
found
some
differences
here.
One
is
that
elastic
common
schema
data
types
are
also
related
to
the
way
it
is
stored
on
to
optimize
retrieval
of
data
search
on
data
that
are
stored.
So
it's
a
bit
different
on
it.
It
will,
it
would
have
to
be
aligned,
and
then
we
have
highlighted
some
differences,
because
we
acknowledge
that
there
are
some
differences,
often
small,
sometimes
a
bit
bigger
on.
C
We
acknowledge
that
if
open
temperature
adopts
merge
elastic
common
schema,
we
will
have
to
do
some
homework
to
evolve
some
of
our
namings
internally,
and
then
we
have
done
some
work
also
to
look
at
an
an
alternative
for
a
hotel
which
is
to
look
at
the
promise
naming
conventions,
but
where
we
have
identified
some
limitations
on
primarily
the
fact
that
promised
naming
conventions
in
fact,
are
not
standardized.
F
Yeah
and
cyril,
to
that
point
again,
I
see
a
great
opportunity
for
being
a
hotel
being
able
to
propose
you
know
a
more
standardized
way
of
interoperating
with
standard
naming
conventions
there
so
again
just
to
call
out
you
know
in
terms
of
what
exists
today
and
what
we
could
actually
leverage
and
as
an
opportunity
to
you
know
again
have
a
fully
interoperable
solution.
C
We
have
done
some
work
also
when
I
said
there
are
limitations
in
the
promising
conventions.
We
don't
mean
that
the
way
elastic
has
solved
it
is
superior
and
we
we
have
identified
that
some
metrics
already
are
defined
in
hotel,
songs
to
the
hotel,
collector,
osmetrix,
receiver
and
so
on,
and
then
it's
sometimes
different,
often
different
from
what
elastic
has
chosen,
and
it
would
totally
make
sense
that
the
way
to
merge
this
is
that
elastic
choices
would
be
shadowed
and
ignored
in
favor
of
what
already
exists.
A
So
I
think
this
is
great.
I
think
this
is
very
useful
to
list
the
actual
differences
side
by
side
and
to
make
it
clear
what
they
are.
I
haven't
had
the
chance
to
look
at
the
document
in
details.
I
will-
and
I
will
comment
there,
but
I
think
having
done
this
work
is
very
useful
for
everybody
who
has
an
opinion
to
not
not
to
be
forced
to
read
two
large
specifications
and
then
do
the
diff
delta.
A
So
this
is
yeah
yeah.
You
did
lots
of
important
work
for
for
others
to
to
to
understand
what
what
are
the
differences.
I
think
the
idea
of
merging
well
borrowing-
I
guess
semantic
conventions
from
from
two
different
places
and
merging
them
into
one-
to
to
have
a
richer
set
of
conventions
that
everybody
can
use
is,
is
very
good
right.
It's
sound!
A
This
definitely
needs
to
be
brought
up
for
to
to
all
of
open
telemetry
because
it
affects
it's
going
to
affect
not
just
logs
but
the
rest
of
the
open,
telemetry
as
well
other
signals,
because
many
of
the
credentials
are
applicable
to
not
just
loads
but
to
traces
as
well
like
things
like
hostname
right,
obviously
applicable
to
all
of
the
signals.
A
So
it
definitely
needs
to
be
discussed
at
the
minimum
in
the
specification
see
as
well,
but
and
and
the
way
that
you
were
describing
that
the
merging
needs
to
happen
in
a
way
that
I
guess
open,
telemetry's
existing
convention
overrides
the
convention
existing
at
ecs.
If
they
they
are
conflicting,
they
both
exist,
but
they
are
conflict
with
each
other.
If,
if
that
is
the
approach,
then
that
that
makes
things
easier
from
open,
telemetry's
perspective
right,
we're
not
then
proposing
anything
to
be
to
any
breaking
changes
to
existing
conventions
at
all
inflammatory.
A
Right
right,
yeah
I
mean
yeah.
I
I
again
I
didn't
have
a
chance
to
look
at
the
details,
but
from
the
I
guess
at
the
cursory
glance
this.
This
looks
quite
interesting
to
me
and
I
don't
see
at
the
moment
any
blockers.
F
Yeah
we'd
love
to
get
again
first
first
comments
and,
of
course
you
know,
this
is
going
to
be
a
multi-month
project,
so
things
will
evolve
and
things
will
get
get
tangible.
You
know
in
the
areas,
especially
from
a
project
point
of
view,
as
cyril
was
saying,
you
know
once
ecs
is
and
can
be
adopted
into
hotel.
F
The
question
is,
you
know,
how
does
elastic
consume
that
in
the
long
run
and
also
is
fully
maintainable
so
that
elastic
the
elastic
team,
as
well
as
other
engineers,
can
participate
fully
in
the
maintenance
of
of
the
and
the
evolution
of
the
schema
going
forward
in
hotel.
B
Yeah
I
I'd
love
to
just
chime
in
and
say
I'm
I'm
really
happy
to
hear
that
elastic
leadership
in
elastic
communities
interested
in
like
doing
the
work
to
make
this
happen.
I
think
that's
that's
awesome,
and
I
would
second
on
the
the
metrics
front
if
we
could
broke
the
prometheus
community
in
as
well
to
to
trying
to
standardize
some
of
some
of
that
stuff,
that
would
that
would
go
a
long
way
to
creating
something
that
that
truly
feels
like
like
an
actual
standard,
which
would
be
amazing.
B
I
I
do
have
one
question,
though,
like
the
I
think,
the
part
where
there's
probably
the
most
work
has
to
be
done
would
be
on
the
tracing
front,
because
that's
the
area
where
open
telemetry
has
has
gone
ahead
and
defined
the
the
most
quantity
of
semantic
conventions
we
already
have
and
we're
actively
in
the
process.
There's
an
instrumentation
group,
that's
like
actively
in
the
process
of
trying
to
to
finalize
and
standardize
or
standard
stabilize
those
conventions
on
the
open,
telemetry
side.
B
C
So
first
we
had
this
mindset
in
rome
you
do
as
romance
on.
Second,
I
have
a
kind
of
good
news.
Is
that
elastic
is
at
the
moment
involving
its
epm
agents
to
embrace
the
to
embrace
the
open,
telemetry
apis?
So.
D
C
B
Well,
I
would
love
if,
if
you
all
have
the
the
cycles
available,
if
people
from
the
elastic
community
are
interested
in
joining
the
the
instrumentation
working
groups,
that
we
have
like
we're
really
looking
for
feedback
and
subject
matter,
experts
to
kind
of
go
through
all
of
these
tracing
conventions,
not
not
just
the
not
just
the
superficial,
or,
I
should
say
superficial,
not
just
the
names
of
the
attributes,
but
also
things
like
span
structure
and
actually
digging
into
some
of
the
details.
B
Like
we've
just
done
a
fine
tooth
comb
pass
through
http
and
messaging
semantics,
but
there's
things
like
database
semantics,
sql
semantics
things
like
that,
and
we
would
love
love
to
have
more
eyes
on
that.
So,
if
that's
something
you're
interested
in,
if
there's
people
available
on
the
elastic
side
to
help
with
that,
that
would
be
awesome.
We'd
love
to
work
with
you.
C
Okay,
yeah,
I
will
see
with
with
the
apm
people,
but
I
guess
so
yeah
okay,
so
it's
called
the
instrumentation
sig.
F
B
There's
a
tuesday
apac
meeting
and
a
thursday
eu
friendly
meeting
yeah.
B
Meeting
currently
is
focused
on
messaging
and
the
tuesday's
meetings
currently
focused
on
http
but
yeah,
but
reach
if
you're
on
the
cncf
slack.
Please
please
reach
out
to
me
there
and
I'm
happy
to
plug
you
in.
F
So
I
I
think
again
going
back
to
next
steps
on
this
proposal.
I
would
like
to
kind
of
figure
out
what
are
the
next
steps?
Clearly,
so
that
again,
you
know
we
kind
of
target
evaluating.
You
know
this,
the
what
changes
need
to
be
made
on
the
spec
side
and
again
tigran.
Look
at
look
forward
to
your
guidance
here.
Next.
D
A
F
A
Definitely
bring
it
to
the
next
spec
sig
meeting
on
tuesday
next
week
to
make
sure
that
there
is
a
visibility
outside
the
logging
seat
as
well
yeah-
and
I
guess
the
next
steps
after
that.
If
there
is
a
broad
agreement
that
this
is
the
direction
that
we
want
to
move
on,
is
then,
then
it
would
be
about
submitting
actual
ortep.
A
But
then
I
guess
that
that's
the
third
step,
so
I
would
start
with
actually
encouraging
everybody
to
have
a
look
at
the
the
proposal
tell
what
they
think
about
it
and
make
sure
it
is
widely
circulated
in
the
spec
seek
and
elsewhere,
not
just
not
just
maybe
spec
right
yeah.
This
is,
this
is
a
broad
topic
that
I
would
like
a
lot
of
people
to
actually
have
a
look
at
that
open,
telemetry
or
just
spec
approvers.
F
Yeah,
that's
a
good
good
suggestion,
tigran
and
I
think
that
asl
said
he's
on
pto
next
week.
But
what
I
can
do
is
I
can
actually
present
to
the
spec
sig
on
tuesday,
just
to
make
sure
that
there
is
visibility
as
well
as
to
the
maintainer
sig.
And
then
you
know
again
make
sure
that
the
review
period
and
comments
are
ongoing
on
the
on
the
proposal
and
the
doc.
F
A
C
C
G
I
have
one
note:
I
I'm
not
sure
if
this
was
maybe
brought
before,
but-
and
I
missed
that.
But
we
have
this
nice
capability
with
telemetry
schemas
described,
and
I
guess
that
we
might
consider
in
the
intermediate
period
to
have
let's
say
two
flavors
of
the
schema
so
ot
base
one
and
the
ecs
base
one
and
then
use
telemetry
schemas
to
transform
between
the
toes
between
the
two.
If
someone
wants
to
stick
to
one
for
whatever
reasons
so.
A
That
was
one
of
the
possibilities
of
the
of
the
schemas
that
that
I
had
in
my
mind,
early
on
but
never
explored
further.
Maybe
I
don't
know
if
you
want
to
do
that.
It's
a
possibility
like
if,
if
you
actually
build
the
translation
that
is
necessary
for
supporting
one
schema,
you
can
use
that
those
same
building
blocks
to
map
between
two
different
schemas
actually
so
code
wise.
It
may
not
be
a
stretch
to
actually
do
what
what
you're,
suggesting
and.
F
And
I
think
germac
that
you
would
do
that
anyway,
in
order
to
you
know,
support
the
transformations.
As
steven
said,
the
other
part
that
could
be
considered
is
you
know,
having
a
phase
one
as
what
we
have
today
with
these.
You
know
with
the
current
definition
on
the
data
model
and
then
an
advanced
definition
that
incorporates
the
acs
updates
again
just
thinking
thinking
out
loud
right
now,
but
definitely
that
transformation
would
be
inevitable.
I
think,
no
matter
what
you
know
how
that
was
implemented.
A
So
when
you're
a
vendor-
and
you
support
more
than
one
schema-
that's
inevitable
right.
As
I
said,
we
do
that
in
as
a
vendor,
we
historically
had
signalfx
schema
and
there
is
no
open
telemetry
schema.
So
we
had
to
support
this
translation
internally,
although
it's
not
powered
by
the
same
schemas
concept,
we
have
a
top
inflammatory
it
predated
the
concept
of
schemas,
but
as
a
vendor
like
like
elastic,
for
example,
what
serial
was
saying
if
they
need
to
support
the
second
version
of
the
schema?
A
Probably
they
they
will
need
to
continue
supporting
the
old
one
as
well
right.
So
that's
something
that
they
need
to
deal
with
on
their
back
end.
Somehow,
and
often
one
of
the
approaches
is
to
do
this
translation
somewhere
right
yeah,
I
I'm
not
totally
sure
we
need
it
to
be
part
of
open
telemetry
like
the
ability
to
do
this
translation.
A
A
So
in
the
collector
we
were
planning
to
have
a
processor
which,
which
would
allow
translating,
between
versions
of
open
telemetry
schema
not
between
different
schemas,
but
between
versions.
Now,
technically,
that
same
thing
can
be
extended
in
a
way
that
allows
translating
between
two
different
schemas.
As
soon
as
there
is
some
sort
of
compatibility
between
the
two.
A
C
Isn't
it
something
that
splunk
you
have
already
done
with
your
splunk
htc
receiver,
on
the
hotel
collector
and
then
you
also
have
an
exporter.
I
think
for
atc.
F
Okay,
I
mean,
and
is
that
again
tigran-
is
that
something
that
is
has
a
time
period
for
support.
That
is
from
an
transformation
point
of
view
that
is
do
over
time.
Do
you
see
the
migration
fully
towards
the
hotel?
A
A
Yeah,
so
we
we
will
continue
supporting
both
for
now,
but
there
is
no
specific
plans
to
retire
any
of
those
schemas.
Our
backend
supports
receiving
both
okay,
okay.
F
H
I'll
just
jump
in
and
say
you
know
largely
echo
what
everyone
else
has
said.
This
is
very
exciting
and
I
think
a
huge
step
forward
for
us
once
we
can
get
this
done.
I
also
wanted
to
call
out
and
validate
something
else.
I
saw
in
the
proposal,
which
I
think
is
very
exciting.
Basically,
the
the
notion
of
turnkey
logs
integrations.
I
think,
if
I
understood
correctly,
that
would
be
delivered
in
the
collector
yeah.
H
So
you
know
like
a
my
sequel,
logs
receiver
or,
and
things
like
this
and
and
I
think,
we're
in
a
very
good
position
to
do
that.
H
Once
we
have
a
clear
schema,
you
know
going
all
the
way
back
to
the
stanza
contribution
it
has
this
notion
of
plugins
and
the
the
idea
there
was
that
users
can,
through
configuration,
essentially
deliver
that-
and
I
like
I'm
just
thinking
ahead
here,
but
I
like
this
idea
that
perhaps
we
have
the
ability
with
configuration
to
specify
all
the
necessary
parsing
for
a
particular
technology,
but
then
we
can
also
then
just
like
easily
package
that
up
or
convert
that
into
a
sort
of
a
hard
coded
integration.
H
I
And
remote
configuration
on
top
of
it
that
will
be
very
sweet,
yeah
yeah.
So
from
my
side
you
guys
know
I'm
a
fan
of
this
of
this
of
this
of
this
of
this
idea,
and
you
know
getting
this
done,
I
very
happy
to
see
the
proposal
here
being
discussed
and
I
just
wanted
to
you
know
actually
also
echo
what
ted
said,
which
is.
You
know
I
heard
that
that
we
have
elastic
leadership
all
the
way
lined
up,
and
that's
that's
huge.
I
It's
it's
obvious
that
there's
a
lot
of
ap
involved
here.
These
things
are
never
easy.
So
it's
a
it's
a
good
day.
C
To
record
on
the
vendor
integration,
when
I
prepared,
I
had
the
feeling
that
when
we
have
this
nginx
receiver
today
in
the
collector
nginx
receiver
is
just
about
matrix,
but
I
think
it
would
make
sense
to
to
say
it's
both
metrics
on
logs
or
whatever
on
that
it
just
it's
a
turnkey
integration.
You
you
just
specify:
where
is
your
nginx?
Maybe
a
http
port
for
to
get
the
metrics?
Maybe
a
file
pass
for
logs
undone.
C
F
All
right
cool,
so
I
guess
we
expect
review
comments,
lots
of
comments
from
the
on
the
dock
and
and
again
ted.
I
will
also
definitely
circulate
this
on
all
the
sigs
that
I
can
join
into
and
would
love
to
have
your
your
magic
power
here
also
to
go
and
spread
the
word
on
the
on
the
other
sides,
and
again
all
of
us
should
do
the
same.
F
And
I
think
we
have
morgan
also
here.
If
not,
we
should
definitely
rope
him
in
also.
B
Cyril,
should
I
j
just
direct
people
with
questions
to
to
reach
out
to
you
at
slack?
Is
that
that
sound
good,
oh
you're,
muted,.
F
Cyril,
maybe
you
can
redirect
folks
to
the
dock,
because
I
think
it's
good
to
capture.
F
On
the
issue
and
the
docs,
you
know
so
that
again
everybody
is
on
the
same
page.
It's
such
a
you
know
significant
proposal
that
I
think
that
it
would
be
nice
to
have
everything
you
know
commonly
shared
and
transparent
for
everyone.
A
B
Yeah
I
just
wanted
to
to
check
in
with
this
group,
coming
from
the
client-side
instrumentation
sig
around
logging
apis
and
a
potential
event
api.
B
I
know
that
there's
there's
general
interest
in
not
developing
a
logging
api
and
instead
using
connecting
up
with
existing
logging
apis-
and
I
was
just
looking
for
some
background
that
I
could
could
bring
to
other
people
about
where,
where
that
this
group
currently
sits
with
all
of
that,
so
I
think
my
first
question
would
be,
if
there's
no
api
at
all,
how
do
we
connect
existing
logging
apis
to
to
the
sdk
it
just?
Would
you
know
if
you
just
point
me
in
the
direction
of
of
where
that's
written
down?
B
That
would
be
great,
and
then
I
guess
my
next
question
would
be.
Has
there
been
any
work
to
we'll
be
logging
from
instrumentation
that
we
provide
in
various
languages?
B
Does
it
make
sense
if
we
don't
have
a
logging
api
to
at
least
ask
the
sigs
to
kind
of
like
in
some
way
write
down
or
pick
what
logging
api
we
we
would
be
using
in
those
languages
so
that
end
users
have
some
expectation
of
of
what
would
be
hooked
hooked
up
there.
A
Yeah,
the
thinking
of
this
was
that
logging
has
so
much
legacy.
There
are
so
many
logging
libraries
in
many
languages
that
we
don't
want
to
introduce
yet
another
one.
We
want
to
actually
support
the
existing
logic.
Libraries,
the
the
way
that
it
is
possible
to
do
already
today,
using
the
two
prototypes
in
java
and
in
python.
Is
you
just
pick
the
the
logging
library
which
was
implemented
in
that
prototype?
I
think
for
python,
it's
the
built-in.
A
I
don't
know
if
it's
called
logging,
the
name
of
the
library
I
don't
remember,
and
then
you
configure
in
python.
It's
called.
I
think
log
was
the
name
of
the
thing.
It's
thing
like
like,
like
the
appender
in
java,
you
configure
that
and
then,
after
that,
you
use
the
regular
logic,
log
log
statements
flat,
login
library,
you
you
need
warnings,
errors
and
all
that
stuff
that
you
usually
do.
I
A
D
A
Java,
I
think
it
supports
log4j,
and
I
don't
know
if
there
is
any
other
libraries.
A
Yeah,
so
I
only
tried
the
python
version.
I
didn't
try
the
java
version,
but
I
think
it
should
work
supposedly
right.
It's
been
implemented,
so
that's
the
way
that
it's
supposed
to
be
done.
I
don't
know
if.
D
A
B
I
think
it
makes
sense.
I
think
some
feedback
I
would
want
to
see
is
just
so
there
in
some
languages,
there's
like
an
obvious,
easy
choice
that
that
wouldn't
create
issues
for
for
end
users.
B
One
group
of
people,
I'm
thinking
about-
are
open
source
libraries,
where
we're
gonna,
say
natively,
embed,
open
telemetry
for
those
libraries.
If
they
want
to
then
log
you
know,
is
there
a
logging
api?
They
can
choose
that
that
wouldn't
create
dependency,
conflicts
or
potential
trouble.
I
know
that's
true
in
some
languages,
but
I
think
I
want
to
check
in
whether
that's
true
in
all
the
languages
we
support,
like,
I
know
like
go
for
example
there.
I
don't
think
there
is
like
an
obvious
a
winner
or
standard.
B
So
I
think
that's
one
thing
I
would
want
to
just
just
double
check
that
that
we
can
actually
pick
pick
a
library
that
we
recommended
every
language,
but
I
I
would
agree
that
if
that
is
possible,
like
there's,
there's
not
necessarily
a
need
to
develop
a
logging
api,
but
somewhat
similarly
on
the
client,
instrumentation
sig.
B
We
are
interested
in
an
event
api,
there's,
a
desire
to
have
a
more
clear-cut
event,
api
that
group
plans
on
recording,
ui
events
and
stuff
as
logs
currently,
rather
than
developing
a
whole
new
signal
to
do
it
and
there's
a
feeling
there
that
that,
having
an
event
api
would
be
helpful
basically
similar
to
the
current
span
event
api,
but
just
decoupling
it
from
from
tracing
and
making
it
part
of
a
standalone
thing.
B
And
I
was
curious
whether
how
this
group
feels
about
that
kind
of
work
if
we
were
to
come
with
a
proposal
for
an
event
api.
How?
How
would
that
be
received
by
this
group?
So.
F
So
I
want
to
add
to
that
said,
because
you
know
again,
I
had
made
the
initial
proposal,
for
you
know,
supporting
real
user
monitoring
events
and-
and
you
know,
had
actually
proposed
that
an
event
type
be
considered
because
they
are
significant
differences
for
handling
events
and
again
would
love
to
see,
even
though
you
know
right
now,
we
are
saying
that
we
could
handle
all
types
of
events
through
logs.
F
You
know,
as
in
foundation,
I'd
love
to
see
a
bit
more
deeper
analysis
there,
because
I
don't
think
that's
what
you
know
can
be
done
for
all
use
cases,
but
then,
on
the
other
hand,
we
don't
have
to
build
for
all.
We
could
possibly
scope
for
you
know
specific
use
cases
and
support
them
with
logs,
but
I
just
want
to
call
out
that.
I
think
that
there
is
a
need
to
evaluate
deeply
or
in
in
a
deeper
way.
F
You
know
whether
that
events
api
would
be
the
best
way
to
you
know,
support
events
rather
rather
than
actually
having
an
actual
data
type
on
the
protocol.
A
I
guess
a
great
justification
of
existence
of
such
an
indent
api
would
be
a
demonstration
that,
using
the
logging
api,
like
like
an
existing
logging
library,
mapped
to
the
logging
sdk.
The
approach
that
we
were
describing
is
not
working
right,
you're
not
able
to
emit
the
event
in
a
way
that
you
want
to
emit
like
you,
can't
actually
make
it
the
shape
that
you
want
it
to
be
right.
F
Exactly
I
mean
and
I'd
like
to
see
that
analysis,
because
I
do
think
that
you
know
there
are
two
camps
and
both
of
them
have.
You
know
absolutely
valid
points
in
terms
of
implementation.
You
can
either
push
the
complexity
to
an
api,
or
you
can
actually
extend
the
protocol
to
be
able
to
handle
events
right.
So
again,
it's
a
question
of
where,
where
do
we
want
to
as
a
project
have
the
complexity
and
at
which
layer.
B
Yeah
yeah,
so
that's
that's
that's
great,
and
that
is
something
we're
working
on.
Martin
kuba
who's
on
the
call
as
well
is
currently
leading
development
of
a
javascript
prototype
for
for
browser,
browser-based
rum
and
the
the
main
thing
we're
trying
to
do.
B
But
the
approach
we're
trying
to
take
in
open
telemetry
is
is
more
of
a
merged
approach,
so
you
know
using
tracing
to
to
measure
latency
of
like
event,
handlers
and
things
like
that
and
getting
all
of
that
integrated
and
we're
having
a
lot
of
success
with
that
approach,
but
yeah
the
big.
I
think
final
remaining
question
will
probably
be
around
for
things
that
are
truly
like
ui
events.
B
Can
we
model
them
just
as
logs
with
you
know
a
dedicated
you
know,
name
parameter,
probably
as
an
attribute
based
on
prior
discussions
and
is
having
all
of
that
coming
out.
The
same
pipe,
you
know
an
efficient
and
reasonable
way
to
to
deal
with
things.
Yeah.
F
Yeah,
exactly
and
and
then
again
I
think
that
if
we
were
to
take
specific
use
cases
and
and
martin-
and
I
have
worked-
you
know
chatted
about
this
earlier-
is
that
again
it's
one
thing
to
handle.
You
know
what
I
call
traditional.
You
know
events,
but
then
there
is
ui,
you
know
based
events
or
browser
or
mobile.
F
You
know
devices
which
are
also
emitting
events
and
then
there's
also
something
such
as
ebpf
events,
which
are
also
another
use
case,
but
you
know
deep
down
in
the
stack,
so
the
question
is,
you
know:
can
we
actually
propose
a
model
where
you
are
proposing
an
api
that
can
handle
that,
and
you
know
we
incur
the
transformation
costs
at
the
api
level,
or
do
we
actually
have
that
built
in
into
the
protocol?
Right
and
again,
that's
something
we
absolutely
need
to
evaluate
as
a
project
as
this
will
become
very
complex,
very
quickly.
B
I
B
Yeah
yeah,
I
think
I
mean
I
think
so
it's
just
you
know
the
only
to
me
the
I
will
say
the
the
part
of
why
I'm
in
favor
of
of
having
all
of
this
as
part
of
the
same
data
stream
is
the
the
logging
data
model
looks
totally
sufficient
to
to
handle
events.
So
it
just
seems
like
a
little
odd
to
to
introduce
like
a
totally
new
channel
in
our
protocol.
B
B
The
same
way.
We
have
a
span
name
in
the
sense
that
you're
trying
to
compare
you're
trying
to
do
aggregate
analysis
across
like
a
particular
class
of
events,
whereas
with
log
messages
you
you
you
might
do
that,
but
that's
not
like
the
primary
purpose
of
a
log
right
like
logs,
tend
to
have
a
unique
message
and
you're
you're
more
interested
in
in
looking
at
them
as
like,
like
a
stack
trace,
but
there's
a
lot
of
overlap.
Right,
like
I
think
it's
it's
like
very
blurry.
B
B
B
You
know
tigrad
you've
done
a
lot
of
work
on
the
efficiency
of
like
parsing
all
this
stuff
and
if
you're
kind
of
in
favor
of
it
it
not
not
being
a
practical
necessity
to
have
name
be
a
top
level
field,
then
then
I
really
don't
see
a
limitation
with
our
current
current
logging
model.
It's
just
more,
almost
like
a
convenience
of
having
an
api
that
is
just
structured
in
such
a
way
that
you
can't
screw
up
picking
an
event.
A
You're
saying
the
name
would
be
an
actual
function
argument
that
you
would
pass
rather
than
one
of
the
attributes,
which
is
fine.
I
think
that's
yeah,
that's
the
way
that
you
want
to
structure
the
api.
That's
that's
fine
yeah,
but
otherwise
yeah.
I
agree
with
it
and
actually
I
I
would
be
very
reluctant
in
I
guess,
seeing
a
proposal
with
two
different
apis
one
for
logging,
another
for
events,
api.
A
B
Things
right:
it's
yeah,
it's
really
just
convenience
like
the
the
api.
We're
currently
looking
at
just
looks
like
the
current
span
event
api,
because
we
haven't
seen
a
need
yet
for
anything
more
complex
which
is,
you
know.
You
have
two
functions
event
which
takes
in
a
name
and
a
set
of
attributes
and
another
function,
you
know
exception,
like
record
event,
record
exception,
yeah
yeah
with
and
the
record
exception
takes
in,
you
know,
exception
and
whatnot,
and
then
you
can
see
it'd
be
very
easy
to
add
a
record
log
function.
A
A
A
B
Into
the
the
exact
same
lower
level,
api
or
the
the
basically,
what
you
currently
have
is
like
an
sdk
interface.
So
yes,
okay!
Well,
if,
if
y'all
are
down
with
that,
I
know
martin,
I
don't
know
if
you
want
to
say
say
anything
in
addition,
but
but
we're
working
on
a
on
a
proposal
with
prototypes
we'll
be
happy
to
present
it
when
it's
ready.
E
Yeah,
I
think
I
think
pretty
much
you
covered.
Everything
like,
I
would
say,
like
this
discussion
has
been
going
on
for
a
while.
You
know
from
our
perspective,
the
login
login
data
model
is
so
flexible
and
the
direction
we
received
was
we
could
represent
events
just
by
semantic
conventions
just
by
introducing
attributes.
So
you
can,
you
can
represent
pretty
much.
You
know
any
type
of
event
I
think
in
vlogging.
E
So
I
think
that
the
right
now,
our
like
immediate
need,
is
it's
like
we're
working
on
a
prototype
for
client-side
data
from
from
browser,
as
had
mentioned,
and
just
we're
just
trying
to
figure
out
how
to
actually
what
to
actually
call
to
generate
those
events.
F
E
F
A
A
A
D
A
D
I'm
thinking
from
the
perspective
of
like
what
you
want
to
do
for
events
specifically,
which
have
a
a
type
and
some
sort
of
classification
I
think,
and
to
we're
talking
about
including
those
as
as
attributes
and
so
to
include
those
kind
of
two
fields
in
every
single
event
that
you
want
to
emit,
might
feel
a
bit
awkward
and
or
those
kind
of
feel,
like
more
top-level
things
in
the.
In
the
event,
space.
B
Yeah
yep,
like
it
does
seem
inevitable
that
we
would
end
up
adding
like
we
would
call
them.
If
it
wasn't
official,
we
would
call
them
helper
functions
and
be
including
them
as
like,
open
telemetry
packages,
just
so
that
the
ergonomics
felt
better
and
then,
if,
at
that
point
it's
it's
like
a
layer
then
going
out
into
like
a
logging
api
and
then
back
like
a
third-party
api
and
then
back
it
might.
It
might
seem
a
little
weird.
B
The
only
other
concern
I
have
with
the
saying
we're
not
going
to
have
a
logging
api
or
it's
saying,
you're
an
event
api
and
you
should
go
somewhere
else
is
just
and
again
we
just
have
to
see
how
it
plays
out,
but
there's
just
a
resonance
from
the
open
tracing
days
where
we
had
this
separation
of
saying
like
well,
there's
one
piece
that
you
get
here
but
to
complete
the
puzzle,
you
you
have
to
like
trot
off
like
somewhere
else
and
that
created
just
like
a
really
surprising
amount
of
confusion
among
users,
and
you
know
the
separation.
B
There
was
in
a
different
place
than
what
we're
talking
about
here
a
little
bit,
but
I
have
gotten
feedback
when
I've
talked
to
people
and
they
said
where's
the
logging
api
and
they
say
well
we're
not
going
to
build
one
you
just
use
use
whatever
I
get.
I
get
weird
looks
essentially
from
from
end
users
they're
like
what
do
you
mean
I
want
to?
I
want
to
use
open
telemetry.
So
what
do
you
mean?
B
C
I
would
like
to
ask
the
question
the
other
way
around,
because
I've
worked
on
at
the
moment.
I
am
capturing
jenkins
logs
with
hotel
on
them.
If
you
are
implementing
a
library,
let's
say
the
ibernate
mapping
framework
in
java,
you
have
to
produce
logs
to
help
people
debug
and
understand
these
startup
messages.
B
So
the
way
open
telemetry
is
designed
with
the
other
signals.
Is
we
have
this
separation
between
api
and
sdk?
For
this,
this
is
like
one
of
the
primary
reasons.
The
api
package
you're
bringing
in
doesn't
have
an
implementation,
and
if
you
don't
install
an
implementation
like
the
sdk,
then
there's
a
no
op
implementation
by
default
and
on
logs
you
will
want
maybe.
C
File
on
you,
I
guess
you
will
have
to
convince
all
these
framework
authors
on
all
this
application,
also
that
they
will
replace
all
their
single
message
that
they
meet
with
their
preferred
login
framework
to
adopt
your
framework,
and
then
they
will.
You
are
likely
to
see
them
asking
for
all
the
crazy
appenders
that
they
have
been
used
to
like
file
rotation,
and
so
I
would
be
even
if
it's
appealing
to
say
I
want
one
unified
solution.
I
Going
back
to
like
this
discussion,
we
had
about
this
topic
early
on
in
the
log
sick
days
right.
I
I
continue
to
believe
that
this
is
not
really
an
either
or
in
reality
right.
I
think
the
logic
decided,
and
I
think
that
was
the
right
decision.
I
continue
to
believe
that
that
it
was
going
to
be
more
successful
to
get
it.
You
know
off
to
the
races
by
not
trying
to
come
up
with
yet
another
api,
but
but
I
also
do
believe
that
there's
got
to
be
a
batteries
included
option
here.
Yeah.
I
You
know,
I
think
it's
inevitable,
and
maybe
this
is
the
time.
This
is
why
I
was
saying
you
know.
Maybe
maybe
this
is
basically
you
know.
Just
just
you
know,
that's
the
starting
shot.
You
know
to
figuring
out
what
that
would
look
like.
I.
I
really
think
that,
like
we,
it's
gonna
just
have
to
be
both
right.
D
I
Then,
like
tigran,
had
like
very,
very,
very,
very
strong,
convincing
arguments
for
why
that
might
not
be
the
best
idea,
which
was
which
was
which
was
quite
insightful,
was
I
was
looking
at
the
you
know
the
next
100
million
developers
right
that
are
going
and
they
are
going
to
write
the
next
hundred
million
apps
and
like
they
don't
really
care.
You
know
about
log4j
anymore
at
some
point
right,
but
the
reality
is
that
there's
also
100
million
apps
already
out
there.
I
B
Right,
but
don't
don't
that
we
already
have
that
at
the
sdk
level
right
like
that,
would
all
be
what
we
consider
sdk
like
exporter
plugins,
it's
just
a
question
of
like
the
api
people
use,
and
I
do
think
this
group
100
made
the
correct
decision
of
ensuring
that
we
can
capture
existing
logs
first
and
shouldn't
we'll
never
go
the
direction
of
saying
you
have
to
use
our
api
or
in
order
to
use
open
telemetry.
B
F
So
ted
you're,
going
to
make
a
proposal
for
potential
events
api.
Is
that
what
okay.
B
Yeah,
I
think
that
we're
starting
with
martin's
making
a
a
a
prototype
currently
using
what's
available
in
open
telemetry
today
and
we'll
be
able
to
look
at
that
and
then
yeah
as
part
of
that,
also
make
an
events.
Api
like
make
an
api
proposal
based
on
what
we,
how
this
implementation
feels.