►
From YouTube: 2019-10-17 Go SIG
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).
C
D
D
D
D
A
B
A
E
E
E
E
D
A
A
A
Yes,
I
would
say
so
there
is
an
implementation
for
counters
engages
in
there
and
we
can
start
putting
in
a
histogram.
You
know
soon
or
now,
I
I
have
this.
It's
a
it's
got
this
lock
free
algorithm,
which
I
think
is
a
risky
move,
but
I
have
a
colleague
here
working
on
it
with
me
to
try
and
validate
that
it's
like
gonna
work.
A
E
So
as
a
part
of
name,
dresser
prototype
I'm
trying
to
remove
the
global
tracer
out
of
this
thing
and
say,
one
of
the
topic
to
discuss
is
for
that
as
well.
So
we're
gonna
have
a
global
trace
provider.
Sort
of
a
trace
factory
is
that
would
and
then
the
the
factory
is
going
to
create
the
tracer
instance,
and
so
each
plug-in
or
the
application
would
say
the
or
component
in
the
application
would
say
the
tracer
and
then
use
the
tracer
from
there.
So
we
still
need
the
global
face
or
factory
or
provider,
so
to
speak.
E
E
F
E
F
E
F
C
Do
we
also
want
to
be
more
explicit
about
marking
good
first
issues
and
not
having
like
frequent
contributors,
pick
them
up.
E
F
G
F
E
C
E
A
A
discussion
on
odep
5
about
this
as
well
yuri
just
responded
today
saying:
couldn't
we
couldn't,
we
please
eliminate
Global's
I
can
I
am
really
just
trying
to
find
the
middle
ground
here.
So
what?
If
we
all
think
we
should
have
levels
or
not?
You
can
decide
still,
but
there
are
several
open
issues
about
this.
We
should
consider
them
all
at
once.
E
D
C
C
F
D
A
A
A
A
E
A
A
E
C
E
C
F
A
E
E
E
C
C
B
E
A
B
I
got
to
pop
off
to
another
meeting
guys,
but
looking
good
I
did
have
an
item
at
the
end.
Just
FYI
there's
context
propagation
separation
coming
up
as
a
and
otep
in
this
next
version
and
I'm
concerned.
It's
one
of
those
things.
That's
complicated
enough.
We're
not
going
to
discover
all
the
edge
cases
till
we
implement
so
I've,
been
asking
various
SIG's
of
these
people
interested
in
doing
a
spike
on
separating
out
contracts
propagation
to
get
involved.
There's
some
people
in
Python
are
gonna.
B
G
E
A
Think
I
am
personally
a
little
bit
nervous,
just
merging
it,
because
it's
sort
of
an
not
quite
tested
algorithm
but
I
do
think
it's
a
good
step.
I'm
still
starting
to
understand
the
complexities
of
Prometheus
export
like
but
I
think
we
should
be
able
to
move
forward
with
prometheus
export
and
after
merging
this
and
in
in
parallel
work
on
some
validation.
A
F
A
E
E
A
A
A
C
Mean
basically
like
there,
there
are
a
lot
of
things
that
go,
doesn't
provide
well
out
of
the
box.
So,
for
example,
checking
to
see
if
check
and
confirm
that
an
array
contains
a
particular
element.
That's
something
that,
like
Cisco,
doesn't
have
a
like
sliced
continues.
Method
means
that,
every
time
that
you
want
you
test
that
you
need
to
write
all
of
like
you
need
to
check
to
do
the
loop
and
everything
and
that
just
gets
tedious
and
I
think
that
that
sort
of
like
extra-hot
leads
to
leads
to
people
testing
less.
D
C
C
D
I'm,
not
I'm,
not
saying
I'm,
not
just
to
be
clear.
I'm
not
saying
I
like
I,
do
think
everything
you're
stating
is
totally
valid.
I
just
have
a
different
experience
and
I've
had
this
conversation
with
I
can't
even
count
how
many
people
and
it
it
it's
like
a
different
set
of
priorities
and
perspectives.
E
A
D
Like
I
said,
I
do
have
a
strong
opinion.
I
always
think
it's
a
mistake.
I
have
seen
bugs
and
other
things
caused
by
that
I
always
have
to
think
extra
hard
when
I'm
using
them
I
know
generally
what
equality
means
and
go
for
everything
else.
I
either
write
a
small,
helper
or
use
contact.
If,
when
helpers
seem
to
be
repeated,
they
go
into
a
package,
that's
used
in
testing
and
then
they're
not
repeated
anymore.
Well,.
A
D
F
A
D
So
yeah,
so
my
thought
was
maybe
since
I
may
be
Isabelle
writes
them
the
way
she
wants
using
the
package.
She
she
would
prefer
and
like
I
could
like
once
those
are
written,
I
can
take
a
look
at
them
and
say
like
well.
Here
is
the
equivalent
without
that
and
then
like,
we
could
actually
just
discuss
like
actual
code.
C
A
D
C
C
D
C
E
A
And
feel
free
to
stay
I
I'd
be
happy
to
lead
with
a
little
bit
of
information.
I
learned
recently,
you
know
I'm
still,
learning
the
ins
and
outs
from
Prometheus
and
I
guess.
What's
sort
of
my
new
discovery
here
is
that
there
was
some
duze
in
my
code
where
they
were
sort
of
written
as
a
question
to
myself,
but
now
that
I
understand
a
little
bit
further
to
do
correct,
Prometheus
export
of
a
counter.
They
want
the
sum-
and
that
really
does
mean
that
you
have
to
remember
every
metric
value
you've
ever
exported.
A
A
This
is
related
to
the
open
question
in
the
spec
PR
about
deleting
handles
and
I've
agreed
with
vodka
and
then
Sergey
to
remove
the
wording
about
deleting
handles
for
now.
In
that
way,
we
can
kind
of
it
does
allow
us
to
ignore
this
problem
for
a
while,
because
the
exporter
is
gonna
be
required
to
remember
a
Prometheus
exporter
will
be
required
to
remember
things
whether
the
SDK
is
or
not
so
I
think
we
can
move
forward.
A
A
That's
because,
in
the
case
of
Prometheus,
you
can
imagine
a
configuration
or
or
sort
of
dynamically
waiting
for
your
first
request
from
Prometheus
to
decide
how
to
handle
a
measure
metric,
whether
you
want
a
histogram
or
a
summary,
for
example,
in
my
PPR
I
was
making
that
be
something
that
could
be
done
by
a
configuration
library
and
it's
essentially
you
get
a
callback
that
lets
you
decide
for
every
metric,
that's
new!
How
do
you
want
to
handle
that?
A
F
Basically,
right
now,
I'm
not
only
trying
to
export
counters,
because
this
is
the
only
thing
that
was
implemented
in
deal
decay,
so
basically,
what
I
do
right
now
is
so
this
permit.
You
do
the
thing
that
you
need
to
register
the
metric
before
you
can
actually
start
adding
if
you
are
using
a
primitive
client
library,
so
basically
need
to
create
a
registry
register.
The
the
metrics
on
done
kind
of
odd
set
whatever
so
Benna
gave
four
wonder
when
the
metric
is
collected
for
the
first
time,
and
I
just
create
the
Prometheus
metrics
out.
F
A
F
A
I
personally
had
tried
looking
at
that
myself,
a
while
back,
but
as
at
that
point,
I
was
thinking
about
just
having
an
SDK
to
directly
call
into
a
Prometheus
client
and
that
wasn't
gonna
work
very
well
because
of
this
question
that
it's
been
asked
about,
making
sure
that
there's
a
unique
reference
to
the
the
metric,
for
example,
or
whether
you
can
have
handles
that
come
and
go
so
I'm.
Putting
this
question
into
the
exporter.
It's
definitely
solvable
at
that
point.
A
A
So
I
don't
know
how
to
do
that
other
than
this
same
approach,
I
was
going
with,
which
was
like
a
yellow
file
and
a
set
config,
or
something
like
that.
That
would
let
you
dynamically
or
not
dynamically
choose
to
type
the
handler
for
each
type
of
metric
I
think
we
could
also
for
now
just
start
with
a
default
which
is
like
histogram,
with
some
default
buckets
and
ignore
the
summary
case.
I.
A
A
There's
gate
the
the
SDK
does
have
gauge
support
and
what
and
I
can
show
I
can
now
they
understand.
What's
getting
you
what's
adding
confusion,
I
can
add
a
little
bit
more
to
help
the
I'll
put
a
histogram
basically
and
then
we'll
just
use
that
for
by
default.
For
now-
and
we
won't
worry
about
this
question-
oh
I.
D
It's
mentioned
in
their
Docs
a
few
times
some
apps.
Do
it
I
would
say
that
probably
not
most
apps
most,
that's
probably
don't
do
it,
though,
or
each
tag,
because
every
metric
name,
Plus
tag,
combination
or
Prometheus
is
a
different
like
metric,
really
cardinality
purposes.
Histograms
are
also
very
like
you.
Don't
just
change
buckets
on
histograms
like
it's
a
like
it's
a
it's
a
like
it
can
mess
up
your.
A
Yeah
so
I
I
am
having
some
difficulty
is
understanding
how
to
do
the
best
thing
we
can
for
Prometheus,
but
at
least
for
now
we
could
probably
settle
on
a
default
behavior,
which
was
some
default
histograms
just
to
get
us
off
the
ground.
I
mean
we
did
make
a
decision
consciously
to
not
expose
this
information
at
the
API,
the
user
level
API
of
like
having
the
user
state,
whether
they
want
to
Instagram
or
summary
I,
think
there
will
be
some
vendors
that
can
support
multiple
representations
potentially
over
time.
I
don't
know,
but
it's.
D
A
I
mean
I
have
proposed
that
there's
this
configuration
library,
so
you
could
imagine
either
one
having
a
like
a
separate
config
step
that
the
application
main
has
to
call
saying
for
this
metric
I
want
histogram
of
these
buckets
for
that
metric
I.
Want
summary,
with
these
percentiles
or
you
could
imagine,
bowed
to
this
idea
was
to
have
a
helper
library,
that's
sort
of
like
in
the
case
where
you're
migrating
from
Prometheus.
You
want
to
declare
a
metric
instrument
and
declare
its
particular
type
of
behavior.
E
I
prefer
that
model,
because
the
exporters
doesn't
have
to
do
like,
for
example,
if
use
the
same,
histogram
is
being
shared
between
a
stack
driver
and
the
Prometheus.
Then
the
work
is
done
in
the
helper
in
both
exposures
on
how
to
do
it
same
thing,
with
the
counter
engage
as
well,
that
that
can
be
provided
in
in
between
layer
and
the
exporter
simply
gets
the
data
from
in
between
helper.
You
can
call
it
processor
or
whatever.
E
A
I
I
guess
I
just
mean
it.
It
sounds
like
you
are
thinking
that
there
should
be
a
standard
registry
for
measure
data
measure
metric
behavior,
or
do
you
think
that
it
should
be
possible
to
configure
multiple
behaviors
at
once,
like
I,
should
be
able
export
a
histogram
to
one
system
and
a
summary
to
a
different
system?.
D
A
As
a
as
a
user
I've
used
so
much
stats,
D
is
so
much
more,
then
I
don't
have
a
strong
feel
yet
for
how
the
Prometheus
user
thinks
I
will
say
that
much
I
do
think.
There's
a
problem
here
that
needs
to
be
solved.
Somehow,
like
you
know,
there's
this
in
tracing,
we
have
an
open,
telemetry
service
and
that
service
is
accepting
a
bunch
of
trace
data.
The
the
open
temperature
user
is
gonna
sort
of
expect
that
the
metrics
state
it
can
be
sent,
forwarded,
I,
think
I
I,
think
not.
A
Everybody
is
ready
to
have
Prometheus
scraping
their
server.
So
if
you
have
a
service,
why
not
forward
your
data
there
and
have
it
scraped
the
service?
So
the
problem?
That
is,
how
do
you
keep
the
state
of
these
counters
alive
so
that
Prometheus
gets
what
it
expects,
which
is
an
empty
metric,
is
exported
at
the
beginning
of
your
process
and
like
for
the
rest
of
that
process.
A
A
Because
I
I
do
have
like
as
a
statistically,
there
are
other
ways
we
can
do
this,
that
don't
necessarily
have
the
same
problems
as
as
requiring
us
to
decide
upfront
whether
there's
something
as
a
histogram
or
a
summary.
Maybe
we
can
do
a
good
job
of
approximating
both
is
what
I
would
like,
but
we
have
to
take
this
one
step
at
a
time.
A
E
Yeah
I
think
this:
let's
go
with
that
with
the
counter
engages
in
open
census.
We
used
to
have
somewhat
of
a
reader
approach
where
you
can't
really
der
so
Prometheus
exporter,
simply
hooks
up
to
this
reader
and
reads
it
whenever
the
scrape
is
called
so
everything
is
aggregated
in
encounter
I
mean
and
then,
when
the
call
comes,
it
just
reads
that
metric
and
then
provides
the
data.
So
nothing
is
kept
in
a
Prometheus
exporter.
A
A
It's
probably
a
little
bit
more
work.
I
was
planning
on
it,
though
we
should
be
able
to
to
build
a
fairly
straightforward,
Prometheus
exporter
by
copying
the
service
portion
of
that
scrape,
Handler
and
adapting
it
to
the
export
calls
from
the
SDK
with
some
sort
of
state.
That's
like
a
map,
and
it
might
be
less
confusion
overall
than
trying
to
adapt
this
model
back
into
prometheus.