►
From YouTube: 2020-07-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).
A
B
I
did
put
a
PR
up
last
night
if
anybody
who
else
wants
to
look
at
it
because
I
don't
know
if
he
will
have
time
today,
but
they
changed
the
photos
like
just
straight
changed
them
for
attributes,
and
so
it
basically
I
guess,
like
everybody's,
been
using
like
direct
exporters
like
when
I
see
people
like
successful
using
the
library,
so
we
were
starting
to
plug
it
in
and
like
I
was
using
the
regular
exporter
to
to
the
go
collector
and
it
was
just
like
movie
bombing.
So
like
two
days
work
we've
figured
out.
B
B
B
A
B
B
They
just
flat-out
like
changed
the
whole
thing
like
most
everything
else
stayed
about
the
same
like
that
child
span.
Count
thing
was
deleted
out,
but
they
are
certainly
not.
It
seems
like
ascribing
to
any
kind
of
like
actually
using
the
proto,
like
you,
gotta,
increment
things
right
now,
so
I'm
hoping
they
did
add
in
the
proto
library
they
added
a
maturity,
level
breakdown
matrix
so
common,
which
is
where
attributes
were
I,
guess
and
now
it's
changed
over
is
at
data
now,
but
the
trace
proto.
B
C
B
B
B
I
think
that
that
they're
doing
that
the
people
that
have
been
doing
it
in
the
in
the
early
channels
that
I've
seen
that
have
been
adopting
I
think
they're,
using
like
the
Zipkin
exporter
directly.
Rather
than
like
going
to
the
go
collector
I
do
know.
I
did
read
that
some
of
the
other
language
SIG's
are
going
to
be
deleting
their
direct
exporters
out
and
saying
only
used
to
go
collector,
which
that.
B
I
I
had
a
conversation
with
New
Relic
about
a
month
and
a
half
ago
before
switch
jobs
and
the
they
were
like
we
want
to
get
out
of
the
agents
business
like
we
don't
want
to
be
supporting
like
a
look
like
language-specific
libraries
or
anything
any
longer.
So
they're
gonna,
like
tell
like
I,
think
that
their
strategy
is
like
we're
gonna
for
everybody
to
use
hotel
and
then
we're
just.
B
C
C
B
Because
I
think
the
smart
vendors
are
doing
that
right,
but
but
yeah
it's
a
yeah.
It
should
be
good,
though
I,
don't
I
think
this
is
something
people
I
haven't
heard.
Anybody
complain
about
using
this
exporter
clear.
Really
it's
been
broken
for
a
while,
so
I,
don't
I
think
that
people
just
hadn't
tried
II,
really
I
did
didn't.
C
B
B
B
Other
than
that
I
did
see,
there
is
a
convenience
handler.
I
haven't
seen
that
we've
implemented
it
so
at
some
point
probably
will.
But
there
is
now
a
recommendation
to
offer
a
record
exception
and
if
it's
the
exact
same
pattern
that
we
do
with
the
telemetry
exception
device
of
like
kind
air
stacktrace.
B
B
A
Two
unrelated
things,
so
one
is
I
started
looking
as
my
entry
into
the
open,
telemetry
API
and
projects
started
looking
into
integrating
those
with
XO
meter
because,
as
I
mentioned
before,
XO
meter
had
this
problem,
where
all
the
various
integrations
with
providers
are
in
different
states.
It's
horrible
to
maintain,
so
it
would
be
really
neat
to
instead
also
go
through.
A
B
A
I'm
trying
to
map
the
XO
meter
until
data
structures
and
API
is
on
to
open
telemetry,
so,
basically,
XO
media
would
be
using
open
telemetry
and
the
people
who
are
the
users
of
XO
meter
wouldn't
have
to
worry
about
that
api
because
they
are
already
implementing
XO
meter.
But
in
the
end
it
would
go
another
route
instead
of
using
the
diuretic
so
meter,
reporters
which
are
right
now
specific
for
the
various
providers
they
be
going
through
telemetry
and
then
whatever
you
configure
in
there.
That
would
be
nice.
C
Yeah
that'd
be
a
nice
bridge
for
people,
I
mean
I
I'm,
not
sure
whether
it's
worth
your
effort,
but
that's
really
kind
of
that's.
The
only
decision
point
is
whether
you
want
to
spend
the
time
cuz
like
it's.
It
gets
people
to
where
they
could
be
exporting
things
into
whatever
the
vendor.
The
thing
is,
and
then
they
could
switch
potentially
to
open
telemetry
later
yeah.
Well,.
A
C
A
C
We've
been
talking
about
whether
it's
more
useful
to
just
give
people
migration
Doc's
over
Dovan
telemetry
versus
like
having
an
actual
bridge
that
just
transparently
works,
because
the
data
models
are
gonna,
be
different
in
subtle
ways
and
stuff,
and
it
might
be
really
hard
to
make
it
just
work.
Yeah.
A
B
Yeah,
the
telemetry
bridge
wasn't
difficult
to
get
started.
The
challenge
is
really
gonna,
be
adding
like
you,
can
just
drop
it
in
and
it'll
start
working,
but
it
won't
give
you
like
any
it'll
just
give
you
like
base
spans,
like
it
won't
add
any
attributes
or
anything
because
it
doesn't
know
like
what
to
grab
so
like
the
next.
So
once
we
open
it
to
the
public
and
put
the
first
release
out
like
just
having
it
worth
being,
is
step
one
and
then
step
two
will
be
the
ability
to.
B
So
I
think
that
we're
gonna
end
up
honestly
with
something
that
heavily
resembles
the
telemetry
metrics
library
for
defining
telemetry
trace
spans,
because
there
has
to
be
a
way
or
I'm,
not
saying
it's
gonna
be
an
entire
new
library,
but
there
is
gonna
have
to
be
a
mechanism
of
like
a
definition
of
where
you're
saying.
Essentially,
this
is
the
metadata
that
I
want
picked
off.
B
There
might
be
a
transform
on
it
to
add
to
the
attributes
whatever,
and
then
you
might
want
to
get
something
off
of
the
measurements
and
label
that
in
particular
way
as
well.
So
if
you
looked
at
it
like
I'm,
just
you
know,
if
you,
if
you
just
added
like
this,
essentially
comes
out
to
you,
there
has
to
be
a
declarative
way
to
say
like
from
a
telemetry
event.
What
are
the
things
that
I
actually
want
off
of
it
right.
B
B
B
B
A
I
think
here
about
basically
just
a
definition
of
configuration.
B
B
You
can
then
provide
a
definition
at
start
time
ahead
of
time,
because
the
way
it
works
is
is
when
telemetry,
so
the
bridge
library
is,
is
going
to
be
leveraging
the
the
registry
library
to
introspect
like
the
entire
application
and
every
child
application
for
any
telemetry
events
that
exists
and
then
the.
If
you
also
add
that
initializations
that
provided
the
same
way
that
we
do
with
telemetry
metrics
reporters
of
like
here's
a
list
of
metrics.
We
could
then
go
through
that
list
and
be
like
oh
user,
provided
an
additional
things.
B
So,
when
I'm
wiring
up
the
function,
the
the
telemetry
handler
that's
going
to
do
the
reporting
here
for
this
particular
handler
I'm,
going
to
also
like
add
these
extra
steps
of
like
pick
these
attributes
off
and
and
whatever
else.
So
it's
essentially
just
like
weaving
everything
together
at
the
start
to
define
the
handlers
to
do
that.
I.
B
B
C
B
C
C
B
B
Tags
or
your
tags
me
be
different.
The
most
common
one
for
me
is
that
your
your
naming
convention,
it's
gonna,
be
different,
like
if
you're,
using
like
with
the
Prometheus
reporter
or
like
I,
encourage
people
like
don't
just
use
the
default
like
declare
the
event
name
explicitly
like
use
the
Prometheus
conventions
for
naming
your
your
events,
and
that
does
does
not
fly
at
all
with,
like,
especially
like
the
shortcut.
C
I
think
I,
like
I,
like
the
idea
of
like
leaving
all
that
stuff
up
to
the
end-user
I
just
feel
like
there's,
probably
a
lot
of
cases
and
I
guess
it
could
be
up
to
each
individual
library
to
provide
it
or
not,
but
like
like
having
an
integration
library
between
ecto
and
open
telemetry,
for
example.
That
just
like
does
the
same
thing.
Everybody's
gonna
want
to
do
versus
like
trying
to
declare
it
in
a
in
a
generic
enough
way
that
you
could
use
it
with
open,
telemetry
or
with
something
else
like
like.
C
Maybe
somebody
wants
to
have
a
histogram,
and
somebody
just
wants.
The
average
grater
for,
like
Layton,
sees
on
nectar,
queries
or
something
like
that,
but,
like
I,
think
for
the
most
part,
people
are
gonna
want
histogram
so
like,
if
there's
just
a
library
that
sets
that
up
for
you,
you
don't
have
to
use
it,
but
you
can
and
then
you
don't
have
to
figure
it
all
out
yourself.
C
C
B
B
The
and
I
think
that's
gonna
be
even
more
feasible
now
with
the
registry
library,
so
as
part
of
it
I
added
a
lecture
support
which
includes
like
a
bunch
of
like
little
macros.
One
is
for
like
just
being
able
to
declare
the
events,
because
elixir
has
certain
peculiarities
that,
like
a
module
attributes
and
then
the
second
thing,
though,
is
like
the
the
methods
that
are
available
to
generate
documentation
are
just
part
of
the
module
itself.
So
you
can
just
there's
a
helper,
a
crow
that
you
can
put
into
that.
B
You
can
use
in
your
in
your
documentation
in
the
module
to
say,
like
hey,
spit
out
all
the
telemetry
event
definitions
here,
and
it
will
just
like
shoot
out
a
bunch
of
markdown
that,
like
formats
it
in
a
standard
way,
but
because
you
can
just
because
that
function
is
just
available
on
the
registry,
you
can
just
pass
in
any
module.
So
if
like
for
Phoenix
or
something,
if
you
have
a
library
where
you
want
to
have
like
a
different
doctor,
8
that
has
like
I,
like
all
of
your
telemetry
information
in
one
spot
as
well.
B
So,
like
I
want
to
list
like
every
last
thing
and
have
like
a
whole
telemetry
guide
for
my
giant
library
right
so
like
that
might
be
the
case
for
like
Phoenix
right,
because
Phoenix
has
like
a
separate
like
telemetry
guide
page
now.
So
with
that
you
can
like
in
the
documentation
like
you,
can
just
template
in
and
say
like,
like:
hey
generate
the
coma
treatment
documentation
for
this
particular
module.
C
Yeah
I
think
I'm
wondering
like
what
would
it
look
like
if,
if
what
we
both
built
internally
was
just
a
like
default
that
people
could
choose
if
they
don't
care
right,
like
I,
think
most
people
don't
know
enough
to
make
that
module
themselves
and
if
there
just
was
wanted
like
if
they
could
just
use
the
one
we
have
internally,
there's
nothing
proprietary
about
it,
except
that
we've
made
some
choices
that
aren't
configurable
right
like
what.
If
there
was
just
the
same
thing,
only
public
and
everybody
could
just
use
it
if
they
don't.
A
C
And
I
think
a
lot
of
the
value
of
this
thing
that
we've
built
is
that
it's
not
configurable
like
we
don't
want
it
to
be
configurable.
We
want
to
just
always
work
the
same
for
all
of
our
things,
so
the
problem
with
making
it
open
source
is
that
somebody
else
might
have
different
choices,
not
like
the
underlying
layer
is
configurable.
So
if
you
want
to
expose
all
those
knobs,
then
basically
you
don't
have
any
value
anymore.
C
B
Don't
know
if
I'm
going
to
include
that
in
my
talk
in
September
or
not,
but
I
have
thought
about
like
to
your
point.
Cuz,
like
I,
think
we
all
have
the
same.
Those
of
us
have
built.
It
know
that,
like
it's
not
like
in
itself,
particularly
useful
to
anybody
like
I
was
like.
Oh,
this
is
a
library
and
I'm
going
to
import
it
and
use
it,
but
as
an
example
of
how
to
do
it,
I.
C
C
Why
should
they
need
to
copy
it?
I
guess
is
my
bigger
question
like
why
don't
they
just
use
it?
You
know
if
we
just
open
source
it
or
something
but
I,
think
yeah
I,
don't
know
like
like
I,
don't
know
if
I
like
the
idea
of
copy
and
paste
this
entire
library
into
your
company,
but
then
tweak
it
to
match
your
needs
right
versus
having
something
that
has
and
it's
configurable
without
actually
changing
the
code.
I
think.
B
It's
possible
because
I
mean
like
the
very
base
framework
of
it
like
at
least
the
way
that
I
constructed
it
is
that,
like
you,
have
like
a
drop
in
that
gives
you
like
immediately
like
lemon
tree
DM
like
via
metrics,
and
things
like
that,
like,
if
you
just
drop
it
in
and
don't
configure
anything
that's
available
to
you
and
then
the
rest
of
it
is
like
there's
just
a
list
of
available
modules
for
things
that
you
might
be
using
in
this
application.
So
like
there
is
a
standard
ecto-1,
there
is
a
standard
phoenix
one.
B
There
might
be
one
for
fetch
or
like
whatever.
Whatever
those
things
are,
that
those
tools
are
it's
just
a
list
of
available
modules
and
then,
like
you,
just
add
it
in
your
configuration,
and
there
are
things
that
are
configurable
along
those
individually,
but
they
essentially
are
just
like
a
behavior
with
like
an
initialization
and
a
definitions
function
and
like
so
you
can
initialize
certain
things
and
you
can
get
a
list
of
the
definitions,
but
all
those
definitions
are
like
wired
up
automatically.
So
I
think
that
there
is
potential
there
like
that.
C
B
C
We've
been
talking
internally
about
like
how
or
could
we
open
source
what
we
have
right,
because
I
think
the
thing
about
ours
is
that
it
makes
a
lot
of
choices
that
wouldn't
necessarily
met
match.
Everybody
else
like
our
sets
of
spandex
and
stuff.
Just
because
that's
what
we
use,
but
then,
if
you're
not
using
data
dog,
then
that's
useless
to
you
and
you
don't.
C
We
don't
have
another
option
for
tracing
currently
so
I
think
if
it
was
open
on
the
tree
than
it
be
more
generically
usable,
because
that's
just
like
gonna
become
the
default
thing
that
everyone's
using
at
some
point
at
least
that's
the
hope,
so
that
would
make
it
more
generically
usable
but
I.
Guess
with
the
plug-in
architecture.
You
could
say,
like
you
know,
use
up
until
I'm
a
tree
for
tracing
use
up
until
I'm
tree
for
metrics
and
then
use
somethin
else
for
logs,
potentially.