►
From YouTube: 2022-05-19 meeting
Description
Open Telemetry Meeting 1's Personal Meeting Room
A
A
A
All
right
cool,
I
guess
we
can
get
started
all
right
as
usual.
Guys,
please
add
your
names
to
the
attendees
list.
If
you
could
nice
well.
Looking
at
the
agenda
topics
today
looks
like
matrix.
Sdk
rc1
was
released,
I
believe
two
days
ago,
so
awesome
job
everyone
thanks
for
all
the
reviews
and
patience,
especially
diego
for
leading
this.
A
I
think
diego's
joining
today
too.
It's
just
a
bit
late,
but
yeah.
It's
pretty
awesome,
aaron
thanks
for
linking
the
blog
blog
post
yesterday,
so
yeah
we're
all
pretty
excited
for
this.
Next
steps
try
to
get
as
many
people
to
use
this
as
possible.
You
know
so
our
rc
can
be
verified
and
we
can
make
an
actual,
stable
release
so
great
job.
Everyone,
all
right,
cool,
doesn't
look
like
there's
any
other
topics
right
now,
so
I
can
go
right
ahead
into
the
issues.
E
E
You
know
when
let's
say
so,
this
this
issue
specifically,
is
about
the
the
prometheus
exporter
you
know
has
like
stores.
All
of
that
in
in
a
double
ended
queue.
So
what
if
the
the
scrape
is
not
happening
for
some
reason,
you
know
it
remains
in
memory.
So
the
author's
question
is
that
so,
like
that's
not
going
to
be
ideal,
you
know,
that's
not
desirable.
What
do
we
do
about?
You
know
such
cases.
I
also
created
another
issue
to
you
know
bring
up
this
discussion.
E
Let's
say
somebody
does
some
some
some.
You
know
unintended
mistake
in
their
sdk
like
something
when
adding
the
metrics.
So
how
do
we?
What
do
we
do
at
least
to
have
some
sort
of
checks
in
our
sdk
and
then
an
exporter
pipeline
to
prevent
it
from
blowing
up
the
whole
application.
Just
wanted
to.
You
know
start
some
discussion
so
that
we
can
start
working
towards
doing
something
about
it.
B
Yeah
yeah,
this
is
definitely
a
good
thing
to
start
yeah.
I
agree
it
could
be
pretty
bad.
I
think,
with
regards
to
prometheus,
though,
like
the
exporter
specifically
doesn't
have
this
problem
anymore,
because
I
think
this
issue
is
based
on
the
previous,
like
pull-based
implementation,
where
it
basically
buffered
the
metrics
that
get
pushed
into
it
until
it
gets
scraped,
whereas
now
the
prometheus,
sorry,
the
prometheus
exporter,
will
only
read
the
metrics
while,
while
it's
being
scraped
right,
so
it
will
do
it
dynamically
and
won't
buffer
those
metrics.
B
E
B
B
I
know
that's
kind
of
orthogonal
to
the
to
the
main
issue,
but
it
would
be
good
if
you
know,
for
instance,
it's
like
a
http
duration
in
there
and
the
instrumentation
doesn't
support
the
http.path
attribute.
So
instead,
it's
like
you
know,
making
a
new
metric
for
every
single
request
with
a
unique
id
or
something
like
that.
We
should
recommend
deleting
that
label
or
something
like
that.
If
possible,.
B
E
B
I
think
like
there
is
the
force
flush
method
on
the
exporters,
so
they
are
allowed
to
buffer
if
if
they
want
or
do
retries,
so
I
don't-
I
don't
think
it's
an
exporter
issue
necessarily
like
that.
There's
no
way
we
can.
We
can
protect
against
that
for
all
all
export
implementations,
but
so
were
you
going
to
say
something
shikhan.
E
B
E
Yeah
that
that
would
be
great
can
also
take
a
look
at
what
dot
net
on
other
sdk
is
doing,
and
then
we
can
try
to
come
up
with
some
solution.
I
I
looked
at
the
matrix
recommendation
guidelines.
There
wasn't
any
specific,
you
know
guideline
because
they
wanted
the
sdk
authors
to
decide
what's
best
for
their
implementation
and
look
at
other
sdks
and
do
something.
A
B
So
the
problem
is,
we
have
to
keep
like
the
aggregations
around
in
like
a
addressable
fashion,
so
that
they're
they're
basically
stored
in
dictionaries
by
the
attribute
keys
right
now
yeah.
So
it's
like
it's
more
of
an
issue
of
like
which
ones
do
you
drop,
you
need
to
know
which
ones
are
the
oldest
and
and
yeah
and
handle
it
in.
Like
a
you
know,
graceful
fashion.
A
A
I
see
so
we
have
some
sort
of
limit
and
but
what
what's?
What's
the
I
guess
we
could
talk
about
design
after
all,
but
yeah?
Okay,
I
understand
the.
I
understand
the
premise
for
this
cool
so
as
for
this,
do
one
of
you
want
to
comment
on
this
just
explaining
our
current
implementation
of
the
prometheus
exporter
yeah?
How.
E
Yeah,
I
added
this
again.
I
don't
add
a
comment
that
you
and
alex
was
alex.
Had
some
thoughts
about
this
just
want
to
bring
it
up.
This
is
like.
There
was
also
some
mention
about
this
in
the
community
that,
as
you
know,
other
linked,
I
think,
in
in
coming
months.
More
people
will
be
interested
in
knowing
about
this.
B
F
B
B
Yeah
I
played
around
with
that.
It
was
mostly
like
for
for
collector
exported,
so
you
could,
you
could
basically
call
you
could
convert
like
stuff
from
python
into
otlp
and
then
in
the
same
process,
send
it
out
through
a
collector
exporter,
but
it
was
not
anything
to
do
with
the
instrumentation
right.
B
B
I
think
the
only
thing
to
call
call
out
my
comment
was,
I
said,
like
I
think,
if
people
are
asking
for
this
for
python,
they'll
probably
ask
for
it
for
like
ruby
and
node
as
well.
So
I
think
like
it
might
be
reasonable
to
let
the
c
plus
plus
sig.
You
know,
figure
out
a
way
forward
since
since
they're
sort
of
like
the
lowest
common
denominator
for
a
lot
of
interpretive
languages,
if
they
want
to
have
like
foreign
function,
calls
to
to
like
the
underlying
c
plus
sdk.
B
A
It
looks
like
I
haven't
read
the
latest
comment
yet,
but
it
looks
like
they're
from
the
c
plus
plus
community,
just
judging
by
their
answer.
I
think
they
might
be
waiting
on
our
response
so
alex.
Do
you
mind
just
kind
of
like
writing
that,
like
we
haven't
really
taken
any
steps
towards
this?
Yet
it
would
probably
in
like
an
onus
on
their
their
side
right
to
if
they
want
to
move
this
forward.
E
B
A
A
A
A
Okay,
oh
yeah.
I
remember
this
yeah
yeah
yeah,
so
for
windows
like
it
doesn't
really
affect
things
but
like
like.
I
think
it
complains
whenever
there's
like
an
r
proceeding
like
the
file
path,
but
this
has
never
like
affected
any
performance
issues.
It
just
throws
a
warning,
but
yeah
we
don't
see
anything
printed
to
the
console
for
flask,
but
it's
good
that
you
you're
able
to
actually
get
it
working.
The
the
weird
thing
is
it:
it
works
prior
to
this
pr
change.
A
A
A
E
A
B
A
Right,
I
guess
like
like
this
might
be
a
long
shot,
but
has
has
auto
inspiration
always
worked
for
windows.
Yes
know
like
I'm.
I
don't
know
if,
like
it
just
so
happens,
we've
always
been
testing
on
linux.
You
know,
I
don't
know,
but
I
think
I've
done
this
before
and
it
did
work
so
like.
I
have
fairly
confident
confident
that,
like
it's
just
something
stupid,
so
yeah
yeah.
F
E
E
F
B
B
B
A
B
A
A
E
There
is
nothing
that's
happening
on
the
sdk
front,
nothing.
You
know
change
on
the
sdk
specification.
I
mean
there
was
mostly
discussion
about
whether
or
not
to
introduce
the.
Like
I
mean
we
have
the
ap
for
the
tracing
and
matrix,
but
the
sdk
is
basically
the
language
independent.
We
are
hooking
the
you
know,
handlers
into
the
libraries
and
then
exporting
them.
So
the
discussion
there
was
there
were
a
couple
of
discussions
around
introducing
api.
E
A
A
A
B
B
I
was
wondering
what
kind
of
like
outreach
we
can
do
to
sort
of
get
people
to
try
this
rc
before
we
mark
the
thing
as
stable,
like
I
think,
for
for
a
minimum
we
could
put
stuff
in
our
readme
and
stuff
like
that.
Asking
people
to
try
it
out,
but
it
would
probably
be
good
to
you
know,
do
something
more
than
that.
E
B
B
A
C
E
A
E
A
A
A
B
A
B
A
A
E
A
C
B
E
E
B
A
B
B
B
D
D
A
B
Yeah,
that's
that's
awesome.
I
think
the
server
ones.
I
don't
think
we
had
any
server
ones
previously
and
those
ones
like
they're
different
than
the
like
requests,
one
so
yeah
we
should.
We
should
work
on
that.
I
wonder
one
like
potential
thing:
I'm
guessing
is
gonna
happen.
Is
I
remember
for
tracing.
We
had
this
issue
with
you
get
like
parent
and
child
trait
spans
for
like,
for
instance,
http
libraries
that
were
composed.
B
So
this
would
be
like
pretty
bad
for
metrics
since
they're
on
by
default
all
the
metrics.
So
I
wonder
if
it
makes
sense
to
just
do
metric
instrumentation
once
at
the
lowest
level
for
these
or
if
we
want
to
have
like
the
same
mechanism
to
you,
know
like
check
if,
if
some
something's
already
recording
a
specific
semantic
invention.
A
B
B
I
guess
the
point
I
was
getting
at
is:
maybe
we
should
open
some
issues
for
instrumenting,
maybe
like
ascii
and
whiskey
with
metrics
for
for
server
side,
metrics
right
just
to
start
at
least
I
feel
like
for
for
our
stable
release,
we're
going
to
have
to
have
some
sort
of
instrumentation
story,
so
got
it
all
right.
I
I
guess
I'll
just
be
making
a
lot
of
issues
for
everybody,
then
yeah
and
then
I'll
follow
up
on
slack.
A
B
A
That's
what
you
meant,
okay
got
it
cool
sounds
good,
yeah,
all
right,
nice,
it's
a
good
effort.
This
will
be
a
good
effort,
cool
anybody
else.
Have
any
other
topics
talk
about?
We
don't
have
anything
else
in
the
agenda.
So
up
jokes,
oh,
never,
mind!
Yeah!
That's
just
you
trust.
Were
you
here
to
talk.
A
G
A
E
G
So
yeah,
so
I
have.
I
had
spent
a
couple
of
months
working
through
improving
our
release,
workflows
in
the
in
the
java
repos
and
was
hoping
that
I
could
that
it
could
be
useful
for
other
cigs,
and
so
I
put
together
a
kind
of
a
repository
template
that
has
a
automat,
automated
workflow
release
workflow
as
well
as
some
other
github
common
github
workflows
that
we've
found
useful
and
so
in
this
pr
here.
G
What
I'm
only
proposing
the
the
release,
automation,
workflows
and
if
you,
if
you
go
back
leighton
and
go
over
to
the
repository
template
on
the
top
link,
yeah
so
yeah.
So
this
here
describes
the
release,
automation
and
kind
of
why,
if
you
stay
at
the
top,
the
kind
of
the
important
thing,
I
think
is
why
this
release
automation,
workflow
or
what
right
like,
there's
infinity
different
ways.
G
So
I
would
say:
that's
one
of
the
primary
drivers
of
this
particular
release.
Automation
process.
The
other
is
releasing
from
release
branches
which
not
everyone
is
doing.
We
worked.
We
were
doing
from
one
of
the
open
limit,
the
java
repos,
but
not
the
other
two
previously,
but
it
looked
like
you
all
were
already
releasing
from
release
branches.
So
I
don't
think
that
is
really
a
change
for
you.
G
A
G
G
Main
branch
and
creates
a
new
creates
the
release
branch
based
on
that
name
and
then
so
that
release
branch
is
created.
Just
exactly
as
what
you
know.
You
have
in
maine,
currently
no
changes
and
then
it
creates
two
pull
requests,
one
which
bumps
the
version
in
the
release,
branch
and
one
which
bumps
the
version
in
the
main
branch,
and
so
this
is
under
the
assumption
that
you're,
using
like
a
dash
dev
or
we
in
java
use
dash
snapshot
on
our
main
always
and
then
in
the
release
branch.
G
So
and
one
nice
thing
with
the
since
the
prs
are
submitted
by
the
bot
account
and
you
can
have
make
you
can
use
the
bot
account.
So
we
have
a
open,
telemetry,
javabot,
github
user,
and
so
I
logged
into
that
user
and
signed
the
ezcla
with
that
user
as
myself
and
then,
since
the
pr
has
come
from
that
bot,
the
person
who
triggered
this
release
workflow
can
approve
it
and
merge
it
because
it's
a
different
user.
G
Now
I
understand
from
leighton
that
in
your
repo
you
require
two
approvers,
so
that's
not
quite
as
convenient
in
the
java
repos.
We
only
require
one
approver,
so
it's
it.
It
does
make
it
nice
for
triggering
the
triggering
the
release,
automation
yourself
and
reviewing
it
and
merging
it,
makes
that
process
go
quickly.
A
G
G
G
Yeah
will
actually
perform
your
release
and
it
it
will
generate
the
github
release
and
it
will
copy
over
the
section
of
the
changelog.
So
you
know
it
detects
the
version
you're
releasing
and
it
strips
out
that
part
of
the
change
log
between
the
that
version
and
the
previous
version
and
automatically
includes
that
in
the
release,
notes
and
publishes
the
github
release.