►
From YouTube: 2022-04-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
B
B
B
I
posted
the
link
to
the
otep
if
you're
interested.
Please
have
a
look
at
it
all
that
number
two
zero
one.
B
I
don't
see
anything
else,
but
I
see
santosh
is
here
which
is
good
and
I
think
we
want
to
talk
about
the
logs,
slash
events,
api
right.
We
didn't
finish
the
discussion
last
time.
You
added
the
open
questions.
I
see
in
the
document.
B
C
Yeah,
I
I
haven't
had
a
chance
to
look
at
your
comments
that
you
added
this
morning,
so
I
in
general.
I
do
also
think
that
instead
of
open,
telemetry
apis
people,
instead
of
using
open,
telemetry
apis
for
logs
for
those
additional
functionality
that
the
other
apis
don't
provide.
Instead
of
that,
maybe
we
should
encourage
the
existing
apis
to
enhance
their
interfaces
to
support
traditional
functionality
which
existing
apis.
Do
you
mean
the
lot4j
and
all
the
existing
apis?
C
B
C
Yeah,
I
mean
basically
I'm
not
a
party
to
any
of
the
log
aspects.
I
I
have
no
interest
as
such
I'm
working
on
different
things
right
now,
but
in
general
it
feels
like
you
know.
Those
are
the
guys
that,
should
you
know,
enhance
their
current
interfaces
to
to
support.
B
B
I
would
still
try
to
solve
whatever
problems
we
have
ourselves,
assuming
that
the
external
dependencies
stay
as
they
are,
it
may
be
just
just
quicker
and
easier
to
achieve
right
and
the
particular
problems
that
I
guess
we
have
right
now
is
that
I
think
the
the
most
important
one
is
that
the
one
that
jack
was
describing
it's
about.
B
It
seems
like
it's
kind
of
pointless
right.
You
you,
you
are
offering
an
api
to
people
which
is
which
is
which
doesn't
have
the
the
configurability,
the
the
the
richness
of
the
configurability,
that
they
are
used
to
in
their
ecosystem,
and
so
why?
What's
the
point
like
who
is
going
to
you
to
be
using
that,
I
think
one
possible
answer
to
that?
Is
that
maybe
no
for
java?
Maybe
it's
pointless
you're
right,
but
not
all
languages
are
like
that
right.
B
So
we
there
are
languages
where
there
is
no
such
established
ecosystem
of
logging
solutions,
take
c,
plus,
plus
or
even
go.
There
is
a
number
of
logging
libraries,
but
there
is
no
established
way
of
doing
logging
and
it's
not
so
rich
in
the
possible
in
the
configurability
and
the
possibilities
there.
B
So
there
is
value
and
it's
in
some
of
these
languages.
It
may
be
actually
something
that
we
would
want
to
do.
I
don't.
B
Be
maybe
that
that
even
means
in
java,
what
you
do
is
only
used
for
the
events.
In
that
case,
I
think
it's
a
fine
outcome.
I
don't
see
that
as
a
big
deal.
If
java
has
a
strong
logging
solutions,
already,
it's
okay,
we're
not
trying
to
out-compete
it
in
any
way
we're
offering
an
alternate
for
maybe
a
small
subset
of
cases
for
java
world.
D
Yeah,
I
think
that's
a
good
point.
You
know
you
know.
Just
because
java
has
a
rich
ecosystem
doesn't
mean
we
need
to
limit
other
languages
from
having
a
log
api
and
open
telemetry.
D
D
They
didn't
have
to
build
the
api
for
the
open,
telemetry
api
from
scratch,
because
a
lot
of
the
same
concepts
already
existed,
and
so
they
just
took
advantage
of
those
where
they
already
existed
with.
I
think
they
have
this.
What
activities
instead
of
spans
and
so
in
a
similar
way
java
could
add
an
event
api,
but
because
we
already
have
a
reach
ecosystem
for
for
logging
apis,
we
could.
We
could
omit
the
traditional
application
log
api.
B
D
That's
true,
that
would
be
like
a
discussion
we
would
have
to
hash
out
and
in
the
java
group
on
whether
you
know
if
who
who
would
be
the
intended
users,
you
know,
and
is
it
worth
building
if
we
don't
have,
you
know
enough
people
that
we
are
enough
kind
of
groups
that
we
think
would
be
interested.
B
C
Yeah,
I
think
it
will
be
javascript
java
javascript
for
the
web
java
for
android
and
I
think
swift
for
ios,
okay,
but
potentially
dotnet
as
well,
on.net
and
c
as
well.
If
the
desktop
apps,
you
know.
B
Also,
you
know
wants
to
use
this
and
all
of
these
languages
you're.
Looking
for
you
want
to
emit
client-side
events
right.
That's
that's
the
goal,
yeah!
Okay.
B
D
Yeah,
you
know,
I
I
think
we
could
talk
about
it.
You
know
if,
if,
if
java
were
to
go
forward
with,
if
this
were
to
go
forward
and
java
were
to
implement
it,
would
java
be
required
to
have
all
aspects
of
this
api
or
could
we
or
could
we
limit
our
surface
area
just
to
the
event
piece
and
still
be,
I
guess
compliant.
B
B
D
Yeah
I
mean
I'll
bring
this
up
with
the
javasig,
but
there's
there's
already
been
multiple
conversations
where
folks,
like
john
watson,
have
expressed
interest
in
an
event
api
in
general
and
so
yeah.
I
I
think
that
that's
a
reasonable
approach.
C
So
it's
so
with
respect
to
events.
It's
always
from
the
beginning.
I
see
in
the
documentation
that
logs
and
events
you
know
we
have
considered
them
the
same,
but
there
hasn't
been
much
activity
from
the
event
side
until
the
decline
side.
You
know
we
came
in
right.
C
What
is
the
reason
for
that
like,
for
example,
in
the
back
end,
there
are
kubernetes
events.
You
know
that
need
to
be
captured.
So
has
there
been
any
effort
in
representing
any
of
the
backend
events?
Has
there
been
any
implementation
of
those
backend
events
using
the
log
record
so
far,.
D
Yes,
there's
a
a
kubernetes,
I
forget,
I
forget
what
it's
called.
The
collector
has
a
kubernetes
events
receiver.
I
think.
C
B
The
collector
in
the
collector,
we
exposed
the
otlp's
data
model
directly.
It's
it's
wrapped,
but
essentially
it's
it's
a
one-to-one
representation
of
what
what
open
telemetry
protocol
defines
as
being
a
log
record
and
inside
the
collector.
You
can
generate
those
events
directly.
I
mean
you
create
log
records,
you
create
them
within
a
scope
within
a
touch
of
attach
it
to
a
resource.
B
B
C
The
implication
of
not
having
an
api
so
far
is
that
the
different
teams
you
know
they
have
used,
they
have
put
things
in
different
places.
For
example,
I
was
looking
at
the
ebpf
events
they
have,
instead
of
using
the
attributes
the
same
key
value
pairs
they
have
put
in
the
body.
C
B
Yeah,
I
think,
that's
fair,
that's
a
fair
observation
when
you,
when
you
in
a
way
the
the
api
that
you
will
offer,
will
help
to
shape
the
event
in
the
form
you
your
funnel.
I
guess
the
the
thinking
into
into
a
specific
direction,
even
though
maybe
you
will
not
restrict
it
prevent
a
particular
shape.
You
may
give
a
preference
to
to
expressing
things
in
in
a
way
right.
So
that's
that's
fair.
I
think
that's
a
that's
a
good
observation,
so
I
think
I
think
we're
good
with
moving
forward
with
this.
B
I
don't
see
a
blocker
here,
it's
more
like
about
okay,
so
let's
see
the
specific
api
and
maybe
the
the
way
to
convince
that
this
is
the
right
approach
would
be
to
do
some
very
quick
prototyping
in
a
couple
languages
like
like
java
plus
javascript.
I
guess
those
are
the
interesting
ones
right.
The
java,
because
it's
it
has
this
complication
about
logs
existing
logging,
libraries
and
javascript
is
because
it's
kind
of
quite
different
from
from
java.
Within
that
regard,
I
think
it's
very
poor
from
the
perspective
of
what
logging
libraries
exist
today
there.
B
C
And
on
the
previous
discussion
about.
C
Basically,
this
will
still
be
called
as
a
as
a
logs
api,
but
will
be
used
more
for
events
than
for
logs
right.
B
The
reason
I'm
I
I
keep
insisting
on
calling
the
login
name
is
also
because
everywhere
else
in
the
protocol,
for
example,
right
inside
the
collector
code
base
everywhere
else,
where
we
already
have
anything
related
to
logging
or
event
functionality,
they
are
called
logs.
That's
the
thing
right.
If
we
now
call
this
thing,
an
advanced
api,
we're
creating
a
mismatch
in
the
naming
which
I'm
not
sure
it
it
is,
it
is
a
good
idea
right.
B
So
I
mean
it's:
it's
fine
in
the
specification
says
log
that
events
are
the
same
thing
right.
It's
fine
to
use
both
terms
when,
when
you're
talking
about
things
but
in
the
the
apis,
I
would
prefer
that
the
foundational
aspects
of
what
what
what
identifiers
you
use
there
for
the
function
names
for
for
data
types
to
still
try
to
stick
to
to
the
name
log,
because
that's
what
we're
doing
essentially
in
the
protobufs
and
it's
it's
it's
over
all
of
the
code
based
right
now
in
the
collector.
C
Okay,
so
in
terms
of
prototyping,
what
would
be
the
sequence
of
things
would
do
we
need
to
first
raise
a
pair
on
this
spec
so
that
we
agree
on
the
clarity
of
the
I
mean
this
specificity
of
specificity,
of
the
interface.
B
Yeah,
so
what
what?
What
I
think
would
would
be
great
to
do
this.
This
needs
to
become
an
authentic
right
in
the
otp.
It
would
be
great
if
you
could
show
let's
say
what
the
exact
apis
would
look
like
in
java
and
in
javascript
right
show
the
exact
the
one
that
you
have
in
your
document
right
now.
It
looks
more
like
more
like
a
pseudocode
to
me.
I
don't
know,
maybe
it's
java,
I'm
not
sure,
but
be
more
specific.
Obviously
you
don't
need
to
implement
it
at
all.
B
B
I
think
that
would
be
a
very
strong
starting
point
right,
along
with
I
guess,
once
you
have
those
specific
apis
describing
java
and
javascript,
you
can
have
the
the
I
guess,
the
pros,
the
the
english
version
of
it.
That
goes
into
the
specification.
Maybe
it's
it's!
It
will
be
even
easier
to
understand.
Okay,
how
do
you
generalize
this
to
become
the
specification.
C
B
C
Okay,
I
I
do
want
to
talk
about
the
instrumentation
scope
too,
for
a
few
minutes.
If
there
are
no
other.
B
Sure
are
we
good
with
this
one,
this
topic?
Anyone
else
has
any
comments:
we're
good,
okay,
cool.
Let's
talk
about
scope,
yeah.
C
So
I
am
relatively
new
to
open
telemetry
compared
to
you
all,
so
I
haven't
used
the
api
so
much
so
the
instrumentation
a
scope
on
it.
The
previously
instrumentation
library,
is
something
that
a
library
author
would,
you
know,
create
right
and
probably
they
would
get
a
handle
of
the
open
telecom.
C
B
Yeah
you
you
you're
right.
The
most
common
use
case
is
you're
a
library
author.
You
obtain
a
a
tracer
to
obtain
a
tracer.
You
essentially
describe
the
scope
like
the
name,
the
version,
possibly
the
attributes
if
it
gets
added
and
then
you
you
everywhere
else
in
your
library,
you
use
this
particular
tracer
to
emit
the
stats
or
maybe
you're,
not
writing
a
library
or
you're.
Actually
writing
an
application
for
your
application.
You
may
obtain
a
tracer
or
maybe
more
than
one,
maybe
it's
not
prohibited,
and
then
you
you,
you
do
the
same
right.
B
You
admit
spans
the
the
way
that
it
changed
recently
it
was
called
an
instrumentation
library.
We
renamed
it
to
scope
to
allow
more
flexibility
in
terms
of
allowing
decisions
about
what
is
a
scope,
a
scope,
maybe
a
library,
but
maybe
something
else
as
well-
maybe
a
class,
a
module,
a
package
or
whatever
you
want
to
call
whatever.
You
is
reasonable
to
be
a
piece
of
logical
unit
for
which
you
meet.
You
meet
the
lender.
C
B
C
Okay,
so
the
let's
look
at,
let's
say
a
library
that
was
used
in
multiple
different
places
right
it
could
be
used
both
in
the
back
end
in
the
client
side.
I
I
don't
know
if
in
a
practical
scenario
example,
but
let's
hypothetically
assume
that
a
library
author
builds
a
library
that
is
used
at
multiple
places.
C
Now
they
don't
know
what
attributes
should
be
passed
to
the
instrumentation
scope
when
they
build
it.
So
are
they
supposed
to
pick
them
up
from
the
environment
through
environment.
B
Variables
not
really
they
are
supposed
to
know
for
the
use
cases
that
I
posted
in
the
author.
So
the
use
case
was
the
following.
I
am
writing
an
instrumentation
to
emit
profiling
events.
I
know
that
I'm
writing
an
instrumentation
for
profiling
event.
As
an
author,
I'm
not
doing
something
else.
This
is
about
profiling,
I'm
adding
profiling
support.
To
my
let's
say
I
I
have
a.
There
is
an
http
client
library
right
that
can
make
http
requests,
and
now
I
want
to
enrich
it
so
that
it
starts
emitting
profiling
events.
B
B
I
obtain
a
scope
and
I
say
that
these
are
client
events
and
then
everything
when
when
there
is
an
event
under
there's
a
click
event
on
an
element
right,
I
emit
the
event
through
that
particular
scoped
log
emitter
right-
and
this
is
about
the
use
cases
when
you
know
you're
right,
but
in
some
cases
maybe
you
don't
so
that's,
maybe
a
poor
feat.
B
C
So,
as
a
end
user,
let's
say
I
enable
profiling
right
on
my
application,
which
could
be
using
20
libraries.
C
C
Yeah,
so
so
my
I,
I
have
a
feeling
that
this
is
these
attributes.
They're
they're
needed
at
a
much
higher
level
than
the
instrumentation
scope.
They're
they're
needed
even
they're,
basically
going
to
be
common
across
all
instrumentation
scopes
can.
B
C
C
Because
I
know
that
my
application
is
going
to
emit
profiling
events
across
all
libraries.
D
B
From
all
the
libraries
you,
you
can't
just
say
that
every
every
place
in
the
in
in
every
library
which
obtains
a
log
emitter
should
include
the
profiling
attribute,
because
you
don't
know
that
those
are
all
about
profiling.
They
may
be
about
other
things
as
well
right,
correct.
So
the
person
who
writes
this
instrumentation
knows
what
they
are
actually
doing.
Are
they
emitting
profiles,
or
they
are
doing
something
completely
different?.
D
C
Does
make
sense,
but
we're
still
repeating
you
know
this
attribute
across
those
four
libraries
correct,
and
why
do
you
see
that
as
a
problem
and
it's
not
a
problem
as
such?
You
know
when
we
are
trying
to
you
know,
remove
duplication
of
the
attributes
at
the
signal
level,
or
you
know
it
could
it
could
be
even
taken
up
even
higher?
You
know
where,
when
when
I'm
sending
my
payload,
you
know
you
attach
all
the
instrumentation
scopes
against
one
resource
and
then
send
out.
C
So
maybe
you
know
it
would
be
good
to
have
something
not
in
the
resource
but
at
the
resource
level
about
the
instrumentation
scopes,
a
set
of
attributes
which
might
be
common
to
you
know
everything
underneath.
B
And
I
think
you're
suggesting
another
level
between
the
scope
and
the
resource,
okay,
so
that
that
is
going
to
be
nearly
impossible
to
do,
because
in
open
telemetry
protocol
we
do
have
these
three
levels.
We
have
the
the
resource
logs.
We
have
the
scope
logs
and
the
log
record.
These
these
levels
exist
if
and
the
same
for
for
the
traces
and
metrics-
and
this
this
is
a
stable
part
of
the
protocol.
Introducing
anything
in
between
is
going
to
be
a
breaking
change.
C
So,
let's
look
at
that
right.
I
think
you,
you
can
always
add
it's
not
a
layer,
but
let's
say
you
can
always
add
additional
fields
in
the
in
the
trace
data
right
in
the
trace
data
object,
you
have
resource
and
then
another
repeat,
an
array
of
instrumentation
scopes.
So
you
can
always
add
a
third
field.
There.
C
Yeah,
so
I
have
another
use
case
where
you
know
so
this
morning
we
we
had
a
detailed
discussion
with
broke
down
on
the
sessions
and
apart
from
sessions,
there
is
another
scenario
where
we
it's
on
a
on
a
so
so,
basically,
a
session
is,
is
a
timeline
of
user
activity
right.
So
you
want
to
be
able
to
say
that
hey,
you
know,
while
this
user
is
logged
in.
C
These
are
the
different
events
they
performed
and
in
every
event
there
is
going
to
be
some
common
context
like
which
page
the
user
is
on
the
page
url
right.
So
that's
going
to
be
repeated
in
every
span,
every
log
every
metric.
Now
you
know
you
could
say
that
you
know
reputation
is
fine.
You
know,
what's
the
big
deal,
but
you
know
we
are
talking
about
mobile
apps,
the
browser
apps.
You
know
running
on
the
mobile.
B
I'm
going
to
argue
for
that.
To
be
honest,
I
I
don't
see
how
this
is
significant,
because
when
it's
it's
about
user
interactions
right,
the
user
clicks
something
and
the
view
changes.
There
are
probably
a
few
events
generated.
It's
not
going
to
be
thousands
and
thousands
of
spams.
I
can't
believe
that,
to
be
honest,
maybe
I'm
wrong,
but
my
understanding.
It's
going
to
be
a
handful
of
events,
maybe
and
spans
log
records
that
are
generated
for
every
user's
interaction
and
the
users.
B
It's
a
it's
a
human
right.
They
don't
interact
with
the
application
at
the
rate
of
a
thousand
clicks
per.
Second,
it's
going
to
be
so,
while
the
way
I'm
seeing
is
every
particular
batch
of
data
that
you're
emitting
in
your
telemetry
is
going
to
contain
5
10
20
log
records.
How
many
can
there
be
not
20
000
for
sure
if
you're
going
to
repeat
like
a
session
id
or
a
url
there
in
all
of
those
stock
records?
C
No
compression
is
is,
is
not
a
positive,
is
not
visible
because
there
are
yeah
yeah.
I
think
it.
The
http
protocol
itself
doesn't
support
compression
for
uploads.
You
know
it's
only
for
the
download
so.
B
C
C
A
Yeah,
but
even
then
like,
I
think
that
what
we
are
discussing
is
actually
covered
by
this
change.
That
tigran
has
mentioned
in
the
in
in
the
agenda
like
that:
the
oteps
one,
because
my
understanding
is
that
this
is
adding
attributes
at
the
scope
level,
both
for
all
all
three
signals
right.
B
It's
complicated
tremec.
The
problem
is
that
for
session
ids,
they
they
may
change
over
time.
B
A
B
B
That's
the
problem
right,
the
api
as
it
is
described
now.
It
is
consistent
with
the
with
the
with
the
with
other
ways
that
open
telemetry
works.
You
obtain
stuff
at
the
startup
and
you
you
use
it
and
they
are
immutable,
but
your
pain
is
immutable
typically,
but
the
session
id
kind
of
violates
this
assumption
session
id
can
change
at
any
moment.
You
don't
know
when
it
changes.
I
think
this
this.
B
C
Yeah
yeah,
no,
in
fact,
we
started
with
that
and
then
folks
from
microsoft.
I
think
they
raised
a
concern
that
the
already
the
attribute
names
have
a
lot
of
repetition:
there's
a
common
prefix
to
all
the
attributes,
the
key
value
pairs
so.
D
C
D
So
so
can't
you
can't
you
do
kind
of
somewhere
in
between
so
this
otap
suggests
adding
scope
attributes,
and
could
you
have
a
processor
that
appends
session
id
as
a
scope
attribute.
C
C
I'm
I'm,
it
is
fine,
it's
just
that
a
couple
things
right.
You
know
those
have
to
be
mutable
and
I
also
feel
you
know
we
could
take
it.
One.
C
You
know
why
not
you
know
why
repeat
the
session
id
in
each
scope,
because
that
puts
a
requirement
on
the
instrumentation,
the
library
authors
to
to
to
make
sure
they
insert
those
attributes.
Now.
B
B
D
And
so
like
another,
another
part
of
the
compression
in
the
in
the
you
know.
Payload
size
thing
is
that
the
browser
applications
seem
really
motivated
to
use
http
json
instead
of
http
protobuf
for
encoding
those
payloads.
If
you
want
to
trim
down
the
size
of
the
payloads,
then
the
first
like
the
low-hanging
fruit
is
to
stop
encoding
it
as
json
to
start
encoding
it
as
protobuf.
C
I
think
I'll
follow
you
an
article.
There
was
an
exercise
somebody
did
from.
I
don't
know
some
company
where
they
said
that
the
json,
the
browsers
json
serialization
is
is,
is
more
efficient
because
it's
done
by
the
browser.
C
Yeah,
no,
I
think
we're
not.
I
don't
know
if
it
is
decided
that
the
browsers
will
send
json,
so
even
with
protobuf.
B
I
think
that's
what
daniel
was
saying
they
they
said
they
are
not.
I
don't
think
they
have
implemented
the
otlp
protobuf
binary.
They
were
waiting
for
a
tlp
json
to
be
stabilized
to
implement
it.
That's
the
last
thing.
I
remember
him
saying
about
otlp
in
javascript.
I
may
be
wrong,
but
that's
what
I
remember.
A
D
So
in
java
we
we
rewrote
the
serialization
to
encode
information
in
protobufs,
and
so
we
don't
have
to
bring
in
any
heavyweight
external
libraries
to
do
that.
We
have
similar
kind
of
size
requirements
for
the
java
agent.
Folks
want
that
to
be
small,
and
so,
rather
than
bringing
in
a
one
and
a
half
megabyte
dependency,
we
just
rewrote
it.
B
C
Yeah,
I
I
I
will
go
back.
I
think
I
get
what
you're
saying.
I
think
I
am
expecting
some
pushback
from
you
know
having
to
support.
You
know
third
world
mobile
application,
mobile
phones,
which
are
very
slow
in
the
third
world.
D
Okay,
another
another
thought
is
so
you
know
right
now.
We
only
support
gzip
compression.
That's
the
only
required
compression
algorithm,
that's
pretty
computationally
expensive,
there's,
there's
alternative
compression
algorithms
that
you
know
can
can
process
bytes
much
faster
and
still
yield
pretty
reasonable
compression
ratios
yeah.
B
Jack,
how
much,
how
much
payload
do
you
really
expect
from
from
from
a
browser
application
like?
How
much
can
you
actually
produce
there.
D
B
Yeah,
okay,
anyway,
if
you
can
show
in
numbers
that
this
is
actually
the
the
size
of
the
payload
is
bloated
by
whatever
percentage
or
the
number
of
bytes
and-
and
this
is
happening
at
that
particular
rate-
and
we
could
save
this
many-
I
don't
know
computations
or
whatever.
If
we
didn't
do
that,
then
okay,
I
can
be
convinced,
but
so
far
I
don't
see
those
numbers.
B
D
It
was
a
good
discussion.
Thank
you
guys
so,
really
quickly.
I'm
just
going
to
include
a
link
in
the
doc.
To
this.
I
did
some
analysis
of
different
compression
algorithms
for
the
collector
a
couple
months
back
and
you
know,
compares
and
contrasts
the
different
compression
algorithms
and
you
know
what
kind
of
compression
ratios
they
get
and
how
fast
they
do
compression
it.
It
might
be
useful
to
take
a
look
at
that,
and
you
know
what
what's
noticeable
is
that
gzip
is
reasonably
performant,
but
snappy
is
about
30
times
as
fast.
D
So
you
know
that
that's
food
for
thought
that
you
know
if
you're
worried
about
the
performance
of
smartphones
and
third-world
countries.
Maybe
we
can,
you
know
push
for
supporting
other
compression
algorithms.