►
From YouTube: 2023-01-05 meeting
Description
Instrumentation: Messaging
A
B
B
Did
you
have
a
a
good
holiday
break?
Did
you
have
a
holiday
break.
B
It
was
good,
it
was
a
little
exhausting.
We
drove
for
a
bit
to
go,
see
my
my
folks
but
a
lot
of
time
on
the
road,
but
it
was
so
fun
got
to
see
that.
D
A
A
C
Yeah
I,
don't
know
what
sort
of
Zoom
but
I
was
really
worried.
I
had
this
like
same
bug
that
I
got
for
like
a
configuration
working
group
where
it's
like
the
Zoom
host,
won't,
let
you
unmute
and
I
was
like
what,
because
everyone
else
on
the
meeting
was
unmuted
and
I
was
like
okay,
I'll
just
assume
the
host
and
I
assume
the
host,
and
it's
like
the
Zoom
host.
Won't.
B
C
B
C
Yeah
we
had
some
ice
storms
here
in
the
Pacific
Northwest
and
so
I
I
would
have
liked
to
have
missed
him.
C
A
C
Yeah
yeah,
it's
the
same
here,
although
we
can't
plow
snow
here
because
we're
not
used
to
that
either.
So
it's
just
really
not
a
good
situation
when
any
sort
of
winter
weather
happens
here.
C
B
C
C
C
Yeah,
okay,
cool
well
welcome
everyone
back
from
the
New
Year's
as
we
jump
into
this
New
Year
I'm
excited
to
I.
Think
kick
things
off
if
you
haven't
yet
already
I,
just
hope
to
the
attendees
list.
I
think
everyone's
on
there
as
far
as
I
can
see,
and
then,
if
you
have
something
you
want
to
talk
about,
add
it
to
the
agenda.
I
copied
over
pretty
much
a
lot
of
things
from
last
time
before
we
ended
the
year,
there's
still
an
open
issue
for
this
semantic
conventions.
Generation
change.
C
This
is
still
in
place.
Anthony,
I,
I,
don't
know
if
we
want
to
sync
on
this
issue
here,
but
other
than
that,
there's
only
one
approval,
even
though
Aaron
said
it
twice,
but
yeah
I
think
this
is
still
blocking
all
of
our
symmetics
conventions
generation.
There's
about
to
be
a
new
1.17
coming
out
as
well,
so
yeah
we're
pretty
far
behind
so
I
would
recommend.
C
A
C
Yeah
you're
telling
me
it
was:
it
was
challenging
trying
to
parse
the
whole
changes
to
the
net
and
HTTP
stuff.
For
this
one.
That's
a
good
heads
up
I
think
we
have
an
open
issue
for
116.
yeah,
okay,.
C
Okay,
yeah
I'll,
add
a
comment
there.
So
with
that
being
the
case,
I
think
if
we
do
113,
we
could
definitely
get
113
14
to
15
out
sounds
like
116
might
be
a
challenge,
and
then
117
is
probably
gonna
happen
today
or
tomorrow.
I
think
is
what
Carlos
said.
So,
oh
that's
kind
of
gosh
I'm.
So
with
you
Anthony,
it's
like
such
a
headache,
okay
and
then
I
think
there's
still
two
other
HTTP
based
issues.
These
come
from
the
113
changes
that
actually
went
out.
C
I
think
this
is
resolved
in
the
yeah,
the
113
semantic
convention
changes.
This
is
not,
though
this
has
to
do
with
how
we're
detecting
the
HTTP
schema.
C
Currently,
our
TLS
detection
is
by
just
looking
at
yeah
this
like
https
status
here,
but
this
is
not
addressed
in
these
changes
just
because
I
wanted
to
keep
them
at
a
they're,
not
they're,
not
really
that
comparable,
but
as
close
to
comparison
to
what
was
already
there,
where
we
were
doing
this
essentially
TLS
comparison
by
using
something
like
this
or
something
similar
I
do
think
this
is
a
really
quick
change
to
do
after
we
get
that
merged,
though
so
I
didn't
want
to
confuse
the
pr
by
adding
it.
C
Okay,
cool,
that's
semantic
conventions,
I
think
that's
one
of
the
big
things
that's
holding
up
this
1.12
release,
yeah!
That's
the
only
thing
holding
up
this
1.12
release,
so
just
a
heads
up
on
that
next
thing
up
is
I.
Think
this
is
a
metrics
API.
C
Yes,
this
is
it's
for
the
metrics
apis.
This
is
a
change
to
split
the
instrument,
callback
or
to
add
a
callback
for
the
asynchronous
instruments.
So
when
they're
created,
they
need
to
be
able
to
be
assigned
a
callback.
So
that's
part
of
the
specification
included
in
this
is
a
re-split
of
the
instrument
options.
Originally,
this
was
split
where
the
instrument
options
were
in
each
like
async
and
64.
C
Async
float
packages
that
kind
of
stuff
David
pointed
out
that
that
also
means
that
there's
going
to
be
duplicates
for
with
instrument
and
with
description,
and
so
the
preference
was
to
go
back
to
just
having
a
unified
instrument
option
that
encapsulated
both.
You
know
all
instruments
can
accept
that
instrument
option
for
with
description
with
the
unit
and
then
the
signal
specific
ones
are
technically,
there's
no
sync
ones
yet,
but
they
are
split
off,
but
the
async
ones
are
split
off,
so
they
can
do
the
callbacks
here
as
well.
So
this
has
been
updated.
C
Please
go
ahead
and
take
another
look.
If
you
have
the
time.
C
Cool
I
think
with
that,
then
I
wanted
to
take
a
look
at
the
projects
overall.
So
one
of
the
big
ones
that
I'm
trying
to
prioritize
here,
especially
at
the
beginning
of
the
year,
is
verify
and
going
through
each
part
of
the
specification
sections
excuse
me
and
and
actually
ensuring
that
our
API
is
compliant
with
the
specification.
C
Ideally,
then,
we
could
have
the
tce
sign
off
on
it
and
release
the
API
as
stable,
I,
don't
know
if
we
want
like
a
soak
period
or
something
like
that
afterwards,
but
so
that
I'm
prioritizing
that
right
now,
I've
been
starting
to
burn
down
some
of
these
verified
issue
tickets
and
opening
up
a
bunch
of
issues
that
I've
seen
actually
most
of
the
issues
are
with
the
specification,
because
it's
really
confusing
I
think
maybe
it's
worth
actually
asking
the
group
about
that.
C
So
one
of
the
things
that
I've
I've
noticed
in
verifying
the
specification,
especially
like
in
this
one,
also
in
the
meter
provider,
is
that
a
lot
of
the
specification
for
the
API
defines
has
language
for
sorry.
I
shouldn't
laugh,
has
language
for
normative
definitions
for
implementations
of
the
API,
which,
like
is
really
confusing,
because
if
you're
writing
the
SDK,
you
look
in
the
SDK
docs
and
you
think
that
you
have
all
the
normal
normative
requirements.
C
It's
not
actually
true,
because
then
you
have
to
go
back
to
the
API
because
normative
requirements
for
the
implementation
are
there
as
well.
So
my
thought
is
like
let's
just
move
that
all
into
the
SDK
so
that
it's
all
unified,
but
it
is
also
you
know
two
things
to
kind
of
point
out.
One
is
that
there's
a
no
op
implementation
as
well,
which
is
an
implementation
of
the
API
which
I
think
these
requirements
cover
and
I
think
this
is
the
important
part.
C
Open
Telemetry
actually
has
some
sort
of
authority
in
specifying
on,
and
then
I
opened
an
issue
in
this
in
specification,
and
it
sounds
like
Yuri
thinks
that
the
open
signature,
Community
well
I,
said
that
back
I
think
it
may
be
possible
that
Yuri
thinks
that
open
Telemetry
should
have
some
authority
over
all
third
party
implementations
of
the
API
as
well
and
I
am
really
confused
by
that
statement,
because
that
doesn't
make
any
sense
to
me,
but
that's
why
they
also
may
be
here.
C
I
I,
like
I'm
a
little
confused
on
that
one,
but
there's
potentially
two
reasons
why
they
were
included
here
and
so
in
going
through
this
I
am
I.
Do
think
that
the
specification
needs
work
like
ideally
the
way
I
see.
This
is
that
none
of
the
implementation
details
are
included
in
the
API.
The
API
is
just
defined
by
the
normative
requirements
for
the
API
I'm,
totally
cool
with
like,
if
you
want
to
add,
like
you
know,
expository,
like
supplemental
guidelines,
for
how
you
should
implement
it
or
like
recommendations
that
are
not
normative.
C
That
makes
sense
to
me
too,
like
you
know,
like
hey,
maybe
try
this,
but
to
separate
that
out.
I
think
it'd
be
a
key
I
think
it'd
also
be
really
key
to
explicitly
Define.
What
the
no
op
implementation
looks
like
you
know
like
this
is.
This
is
something
that
I
recently
opened
here.
C
Is
that
one
or
more
distinct
instruments
to
registered
with
the
same
name
for
identical
meters,
the
user
Plantation
should
emit
a
warning
and
the
user
informing
them
the
duplicate
registration
for
the
conflicts,
so
that
applies
to
the
no
op
I.
Don't
think
it
should
like
I
think
if
somebody
puts
a
no-op
implementation
in
there,
they're
saying,
like
literally
don't
do
anything,
but
you
know
like
I.
That's
actually
not
what
this
specification
says.
So
I've
opened
an
issue.
C
The
track
like
this
is
one
of
the
things
that
I've
opened,
that
we
need
to
fix
that
we
need
to
actually
do
this
in
the
know-up.
It
looks
like
Java's
actually
doing
this
as
well,
so
like
I'm,
a
little
confused
here
but
I'm
trying
to
Wade
through
it
I
guess
the
best
that
I
can
so
it's
kind
of
like
I
guess,
maybe
just
like
me
ranting,
but
maybe
I
was
hoping
to
also
like
a
status
update
and
seeing
if
other
people
had
ideas
on
this.
C
I
mean
that's
what
that
means
to
me
like
I'm,
literally
looking
at
how
to
implement
this
and
I.
Think
I.
Think.
Not
only
are
you
gonna
have
to
track
the
names
that
have
been
registered
prior,
but
you
also
need
to
track
the
options
because
it's
similar
to
the
SDK
like
if
you,
if
somebody
asks
for
the
exact
same
instrument,
then
we
can
give
them
back
the
exact
same
instrument.
It's
a
no
op
implementation,
but
if
they
ask
for
the
name
with
conflicting
details,
they
need
to
be
known
told
about
this.
C
So
we
need
to
do
a
bunch
of
operations
to
to
do
this
tracking.
So
like
yeah,
this
really
didn't
make
sense.
To
me.
I
created
I
thought,
I
created,
yeah,
I,
guess
I
created
this
issue,
which
is
more
in
general,
talking
about
the
implementation,
and
it
does
touch
on
like
this
no
op
as
well.
C
So
if
I
would
love
it,
if
you
can
maybe
go
comment
in
this
issue
and
and
provide
some
sort
of
like
feedback
that
you
have
on
it,
but
like
I,
agree,
Anthony
like
that,
doesn't
make
any
sense
to
me.
A
C
All
all
of
these
things
are
in
my
mind
as
well,
but
then
so
that's
like
the
hard
place
and
I
think
the
rock
is
like
the
specification
says
you
need
to
do
it
so
I'm
like
on,
like
one
of
those
has
to
change
right
like
so
I
and
also
Anthony
like
another
thing,
is:
if
it's
going
to
be
duplicative
like,
even
if
it
doesn't
do
something
because
you
didn't
register
a
global
yet
and
you
you
make
a
conflict
when
the
delegation
happens,
it's
also
going
to
log
another
warning
right,
because
the
SDK
is
going
to
do
a
logging
which
I
guess
you
can
solve
with,
like
you
know,
a
specific
logger
that
does
filtering,
but
like
I
mean
it's
just
it
really
is
not
a
great
user
experience
any
way.
C
Yeah,
so
there's
the
consternation
that
you
see
in
my
face
right
there:
okay
and
then
there's
a
few
other
things
this
this
one
in
particular,
I.
Think
I've,
like
captured
down
at
the
bottom,
there's
a
lot
of
guidelines.
All
the
things
that
actually
need
to
be
doing
need
to
be
doing
everything
that
is
still
an
open
issue
where
we're
not
compliant
is
captured
in
an
issue
I
plan
to
do
the
same.
C
If
you
have
time,
I
think
this
is
a
great
thing
to
prioritize
is
to
burn
down
these
verifies
and
build
issues
for
any
sort
of
gaps
that
we
find
in
our
compliance.
I
really
think
that
it's
something
we
should
prioritize
over
the
SDK,
because
I
don't
know
if
we
can
release
like
a
like
a
beta
SDK.
If
it's
not
compliant
with
a
specification,
that's
not
compliant
like
I
I,
don't
know
it
seems
like
the
specific
or
the
API
needs
to
be
locked
down,
I!
Think,
first!
C
Next
up,
I
wanted
to
look
at
the
metrics
beta
SDK.
Some
of
these
issues,
in
here
I
think
are
also.
This
is
again
from
the
API
there,
as
this
is
going
to
block
the
SDK.
I
am
trying
to
there's
some
overlap
here.
I
think
I,
don't
know
how
to
like
put
a
project
to
say
the
project
blocks
this
project,
but
so
I'm,
trying
to
track
that
a
little
bit
by
overlapping
and
putting
them
in
two
projects,
but
other
than
that.
C
I
think
that
the
only
thing
that
we
haven't
talked
about
here
is
this
pre-computed
values
yeah,
so
I
saw
Aaron.
Your
comment
here
is
is
based
off
of
I.
Think
exactly
the
summation
of
what
David
was
kind
of
asking
about
and
I
didn't
get,
and
so
there's
a
I
think
this
is
a
good
breakdown
of
what
David's
kind
of
talking
about
here.
So
the
problem
that
currently
exists
is
just
to
kind
of
remind
people
is
like
when
you
do
an
asynchronous
observation.
C
If
you
directly
do
that
asynchronous
observation,
there's
no
attribute
filters
or
anything
that
value
is
supposed
to
be
treated
as
the
user's
already
done.
The
pre-computed
some
they're,
giving
you
what
the
sum
total
is
like
you
just
set
the
value,
it's
cool.
The
problem
is
when
it
interacts
with
filtering
right.
Like
so
say
you
do
a
filtering
of
attributes,
and
now
some
sort
of
filtered
set
comes
back
and
it
Returns
the
equivalent
of
a
non-filtered
observation.
How
do
those
two
get
combined
is?
C
Is
the
ultimate
question
here
and
one
of
the
things
you
know,
there's
there's
an
issue.
It's
there's
also
yeah.
There's
a
specification
issue
to
clear
this
up
and
I
think
the
sentiment
that
came
away
from
this
was
those
filters.
Observations
need
to
be
added
to
the
existing
observation
for
the
value,
and
so
that's
what
I've
done
here,
but
the
problem
is
then
what
happens
during
the
reset
cycle?
C
So
if
you
make
an
observation,
say
I
think
I'm,
just
it's
been
a
while,
since
I
looked
at
this,
so
David
correct
me
if
I'm
wrong.
That
is
directly
of
something
like
this,
where
the
Fubar
is
the
the
thing
that
everything
gets
filtered
down
to
and
it
has
a
you
know,
pre-computed
value
of
two,
and
these
other
observations
are
then
added
to
that.
So
then
you
get
something
like
four
but
say
then
the
next
time,
the
next
cycle,
these
two
observations
are
actually
made.
C
If
you
reset
the
value
completely
or
you,
let's
say,
let's
say
you
don't
reset
the
value
you
say
like:
okay,
cool.
That
observation
was
now
four
and
then
you
go
through
another
callback
cycle,
but
these
two
observations
aren't
met.
So
then
the
observation
then
becomes
negative,
two
right
or
there's
there's
a
Delta
there
of
negative
two,
which
is
not
really
what
you
want
right,
because
it
still
is
the
user.
The
user
said
like
no.
C
So
there's
like
this
really
complex
interaction
between
the
observations,
the
filtering
and
then
the
resets
that
is
happening
here
and
this
is
I
think
where
we
landed.
So
what
happens
during
the
resets
now?
Is
that
anything
that
was
directly
observed?
The
last
value
wins
is
what
goes
on
here
and
then
that
value
is
preserved
through
the
next
cycle,
whether
it's
a
Delta
accumulative.
That's
all
how
it
gets
reported
like
there's
a
the
Delta
one.
Is
this
cumulative
to
Delta
transfer?
C
Sorry,
that's
probably
more
confusing
aside
than
helpful,
but
then
the
observations
since
their
their
additions
to
this
pre-computed
sum
their
their
reset
is
zero.
So
they
need
to
be
observed
every
single
time
at
their
same
value,
which
makes
sense
right
because
if
this
is
giving
you
a
pre-competed
sum
of
one,
this
is
giving
you
a
pre-computed
sum
of
one
the
next
time.
C
They
should
also
be
giving
you
that,
if,
if
they
exist
right-
and
so,
if
that's
the
case,
they
should
be
reported
every
single
time
and
if
they're
not,
then
that
needs
to
actually
be
removed
from
this
value,
because,
it's
no
longer
being
you
know,
said
by
the
user.
This
is
like
pre-computed
sum
at
this
value,
so
the
next
cycle.
C
If
these
two
are
not
existing,
it
would
go
back
to
two,
and
so
that's
what
this
PR
does
in
this
in
its
complexity,
I
think
I,
it's
it's
pretty
straightforward,
but
I
wanted
to
also
pause
here
and
see
if
that
makes
sense
and
David
correct
me.
If
I
said
that
wrong.
D
No
I
think
you
said
it
correctly:
okay,
just
to
make
sure
I'm
I'll!
Repeat
it
back
to
you
and
see
if,
if
we
agree
when
a
callback
needs
to
actually
give
you
all
of
the
precomputed
values
every
single
time,
no
matter
what
right.
C
C
This
yeah
yeah
I
mean
you
can
drop
it
by
telling
the
make
an
observation
that
says
like
this
is
now
zero,
but
that
just
drops
the
value.
But
yes,
that
actually
is
a
there's.
A
a
noted
bug
in
here
that
we're
tracking,
with
an
issue
that
you
can't
ever
actually
drop
an
observation
from
a
computer
or
a
cumulative
sum.
Both
cumulative
and
pre-computed.
C
Is
not
yeah
and
there's
there's
definitely
an
issue
to
track
in
a
specification
for
for
I,
think
X
number
of
Cycles
before
you
know
it
resets
or
allowing
some
user
specific
ways
to
reset,
but
yeah
like
it
is.
It
is
an
open
issue.
Yeah
I
could
I
could
try
to
find
it,
but
it's
yeah.
It's
a
post,
GA
thing
that
we
have
identified
as
well
by
the
way.
D
Okay,
cool
yeah,
one
thing
that
would
make
it
slightly
easier
for
me
to
review.
D
Maybe,
not
maybe
I
just
need
to
look
through
it.
I
just
don't
know
the
way.
The
interfaces
interact
well
enough
personally
to
verify
that
what
you're
doing
actually
fixes
the
bug,
I.
Think
you're,
because,
like
the
behavior
I'm
describing
is
really
high
level
and
I
I,
don't
remember
how
the
aggregators
interact
with
everything
else.
C
That's
Fair
it's
two
ways
now,
by
the
way:
it's
like
the
filter,
it
re-interacts
with
the
pre-computed,
because
it's
got
this
new
filtered
method
here,
which
does
something
different
and
so
I
I
mean
I.
Think
that
there's
something
unless
we
want
to
restructure
how
we're
doing
filtering
entirely
I,
don't
know
of
another
way
to
do
this,
I'm
open
to
suggestions
if
we
could
streamline
it.
So
that's
why
I
tried
to
make
sure
that
these
tests
here.
C
The
meter
tests
are
not
as
relevant.
These
are
kind
of
like
high
level,
but
this
this
really
shows
that
interaction
between
the
the
Aggregate
and
the
yeah.
B
So
I
I
was
facing
a
similar
thing
this
morning.
This
is
when
I
tried
to
do
this.
I
actually
sat
down
and
tried
to
run
write
some
high
level
tests
around.
B
Around
the
example
in
the
supplemental,
so
I
will
put
some
polish
on
them
and
send
them
over
to
you
Tyler,
to
see
if
you're,
okay,
with
including
those
as
part
of
this
I'm,
not
exactly
so.
The
supplemental
guide
in
the
specification
does
a
pretty
good
job
of
showing
what
the
cumulative
effects
should
be,
but
less
so
of
the
delta.
B
B
B
B
Well,
so
if
you
start
up
at
the
top
of
the
asynchronous
example,
it
gives
you
if
you
had
a
sum
counter
and
you
were
given
and
you
put
in
these
values
at
these
time
periods
right.
So
you
had
a
counter.
Pid1,
tid1
or
1001
tid1
gave
it
a
value
of
50,
then
53.,
Etc
and
then
down
at
the
very
bottom,
the
last
one
you'll
notice.
It
has
no
tid1
but
tid3.
C
B
So
I
was
going
to
put
in
like
just
do
an
example
of
literally
what
it
does
right
now
and
then
kind
of
re
go
back
and
see.
Is
that
what
we
expect
it
to
do?.
C
B
I
would
bring
it
up
right
now,
but
I
have
it
on
a
my
laptop.
So.
C
Yeah
yeah
yeah
definitely
send
it
or
I
didn't
yeah
post
it
in
the
the
pr
something
we
can
I
don't
know
if
we
would
add
it
as
a
test
or
whatever
we
want
to
do,
but
yeah
we
can.
We
can
definitely
look
into
that.
Yeah.
B
And
that
kind
of
helps
elucidate
the
higher
level
version
of
this
of
like
given
a
meter,
we
can
pull
in
and
remove
stuff
and
and
see
how
that
that
works
and
see
that
it
does
what
we
expect
it
to
do.
C
Yeah
cool
all
right
that
makes
sense
to
me.
Yeah,
please
send
it
over
whenever
you
got
it
done,
I'll,
add
it
in
work,
yeah
I,
don't
know
I.
You
might
just
want
to
commit
it
right
to
the
branch.
C
Okay,
cool
then
I
think
with
that.
That's
this
callback
type
also
I,
guess
we
didn't
talk
about
that.
This
is
something
from
the
API
as
well,
so
one
of
the
requirements
from
the
API,
which
is
where
I
think
they
might
have
actually
done
something
right,
is
that
the
Callback
type
needs
to
be
documented
in
a
particular
way.
I,
like
I,
created
its
own
type,
ensured
that
we
have
all
the
documented
things
required
for
the
Callback.
That's
added
here,
it's
pretty
I,
don't
know
it's
pretty
mundane
change
as
well.
C
It's
implicit
yeah.
The
only
thing
that
changes
is
that
the
function
method,
type
signature
changes.
So
if
you
already
had
a
register,
callback
method
defined
you
needed,
and
you
know,
and
have
this
as
a
parameter
instead
of
the
inline
function,
type
definition.
But
if
you
pass
just
a
function,
that's
not
of
this
type.
It'll
inline
course
that
that
yeah
I
mean
you
can
look
through
the
pr
like
there's.
No
actual
changes
to
calls
to
register
callback,
like
all
the
functions
that
are
passed
are
just
natively
right:
okay,
cool
yeah.
B
C
C
Man
there's
a
lot
of
things
involved.
Let's
see
where
is
it?
These
are
defined
down
at
the
instrument
level
right
now,
yeah
and
they
are
oops.
That's
not
okay,
perfect
yeah
they're.
In
fact,
this
was
recently
changed
because
I
changed
the
word
and-
and
this
also
needed
to
be
documented
as
well
so
they're,
similar
yeah
yeah,
one
of
the
things
that
I
am.
C
C
Okay,
cool
I
think
yep
that
we're
at
the
end
of
the
agenda
pause
here,
see
if
anybody
else
is
something
else,
I
want
to
talk
about.
C
I
do
have
projects
share
if
nobody
else
has
Hotel
specific
things.
C
Let's
see
here
we
go
so
I.
We
talked
a
little
while
ago.
There
was
that
structured
logging
proposal
for
go
that
gosh
Sean
I,
think
on
slack,
had
posted
that
he
built
a
wrapper
for
the
logging
of
that
structured
logger
to
go
to
otlp
and
I
was
like
oh
that's
kind
of
cool
and
we
had
initially
talked
about.
C
Maybe
there
would
be
some
cool
ideas
for
other
logging
interfaces
to
have
export
types
with
using
otlp,
and
so
one
of
the
things
that
I
created
was
this
otlpr,
which
uses
a
log
R
interface
and
it
exports
otlp.
So
it's
really
straightforward.
Essentially
it's
similar
to
our
other
otlp
exporters.
C
You
need
to
give
it
some
sort
of
connection
I
didn't
mess
around
with
trying
to
reinvent
the
wheel
and
build
their
own
connection
here,
like
we
do
for
our
exporters,
but
you
essentially
just
need
to
give
it
a
connection,
and
then
you
get
this
logger
back
that
implements
the
logar
interface.
There's
the
cool
functionality
here.
This
is
batching
functionality
like
by
default
it'll.
Just
like
every
message
you
log
gets.
You
know
a
grpc
request,
so
not
really
efficient.
C
This
is
hence
not
ready
for
production,
but
there
is
a
possibility
to
do
batching
here,
similar
to
like
our
batch
band
processor,
which
I
thought
was
kind
of
cool
you
can
you
can
pass
that
in
it
does
provide
this
option
where
you
can
do
automatic
span,
connotation
or
span
context
annotation.
C
So
any
message
that
you
log
will
also
have
if
the
context
that
you
passed
in
here
has
a
span
in
it,
it
will
annotate
the
trace
ID
and
the
span
span
ID
as
well,
which
is
something
that
is
supported
by
otlp
as
like
in
their
own
like
specific
field,
so
it
puts
logging
in
context
in
the
context
of
a
span
as
well.
I
thought
was
pretty
cool.
C
You
can
add
a
resource
because
there
really
isn't
this
concept
here
and
you
can
add
a
scope
which
are
pretty
straightforward.
These
are
I,
think
buggy,
actually
I.
Think
if
you
tried
to
share
a
logger
across
multiple
resources,
it
may
not
work,
but
it's
also
not
ready
for
production,
so
just
the
proof
of
concept,
just
a
heads
up
on
there.
This
is
cool
example,
kind
of
shows,
you
kind
of
just
a
high
level,
I
think
which
was
just
kind
of
a
good
idea.
C
You
have
some
sort
of
app
the
you
have
some
sort
of
setup
for
the
connection
here
to
some
sort
of
you
know
right
now,
it's
going
to
be
a
collector,
then
in
the
setup
itself
it
creates
not
only
this
grpc
tracing
exporter,
but
it
then
creates
this
logger.
So
it's
really
cool
because
you
can
use
the
exact
same
connection
to
the
to
the
same
destination
for
The
Collector
and
then
from
there.
C
It
takes
that
logger
it
you
know,
does
a
mock
thing
where
it
creates
a
span,
it
runs
an
app
and
that
apps
does.
You
know
some
logging
functionality
here
where
you
know
the
Tracer
starts
with
the
span
or
the
span
and
then
down
here
it
does
this.
C
You
know
with
context
thing
where
it
gets
that
logger
passes
it
in
gets
a
new
logger
and
from
this
context,
which
is
defined
here,
it
embeds
the
span
information
and
then
you
know
says
something
here:
it's
all
structured
as
well,
because
using
the
logar
interface
and
I
can't
remember
to
read
me
may
have
no,
it
doesn't.
It
had
an
example
output,
but
you
know
it's
pretty
simple
to
run
so.
C
Played
around
with
it
a
little
bit,
I,
don't
know,
I
think
it'd
be
really
cool
to
use
like
in
a
situation
where
you
want
to
unify,
like
on
the
collector
for
all
of
your
signals
like
logging,
tracing
and
metrics,
or
something
like
that
and
then
ship
them
wherever
you
want,
or
you
could
specifically
send
it
off
to
some
sort
of
other
endpoint
that
reads
otlp,
so
I
thought
that
was
kind
of
neat
I.
Don't
know
like
there's
this
interaction
of
like
do.
C
You
want
to
embed
this
in
the
open,
Telemetry
Global
logger
as
well,
like
I,
haven't
played
around
with
that
I.
Don't
know
if
there's
any
interaction
there.
That
would
cause
problem,
but
I
definitely
know
like
the
Import
Cycle.
What
won't
happen?
That
was
something
I
tried
to
make
sure
that
it
didn't
happen
so
yeah
just
kind
of
a
heads
up
on
that
one
I
haven't
really
shared
it
anywhere,
but
I'll
probably
try
to
share
it
on
like
slack
or
something
like
that.
After
that,.
C
Cool
all
right,
well,
I
think
with
that.
Then
anybody
else
have
some
cool
uses
of
open
Telemetry.
They
did
over
the
the
break,
or
maybe
they
just
stepped
away
from
code
entirely.
C
Did
anybody
complete
the
events
calendar
admin
with
code
or
something
like
that
right?
No
David's,
now
I.
B
Got
like
19
days
and
almost
that's.
A
B
I
did
the
first
star
and
I
think
like
two
or
three
things
at
the
end
and
then
I'm
like
no
it
just
it's
too
rough
for
me.
Also
at
my
parents
house,
with
pretty
lousy,
internet
and.
C
Well,
cool
all
right,
I!
Think,
then,
with
that
we
could
probably
end
it
early
thanks
everyone
for
joining.
We
will
be
back
on
the
regular
schedule
next
week
same
place
same
time,
see
you
then
thank
you.
Bye.