►
From YouTube: 2022-11-30 meeting
Description
Open cncf-opentelemetry-meeting-3@cncf.io's Personal Meeting Room
A
A
C
C
E
So
a
couple
of
Sig
meetings
ago,
maybe
in
October
I,
don't
remember
at
this
point:
I
I
asked
about
the
concept
of
exporting
the
collector's
traces.
Sorry,
sorry,
not
their
Tracer,
that
spans
the
collectors
instruments,
some
of
its
components,
I
think
right
now
is
just
receivers
and
exporters.
I,
don't
think
processors
are
instrumented,
but
Z
pages
Expo
like
has
access
to
those
spans
and
I,
would
love
to
be
able
to
export
those
fans
somewhere.
E
Just
like
we
have
the
capability
to
get
our
log
and
Metric
Telemetry
out
of
the
collector
and
into
some
sort
of
back
end.
So
I
opened
an
issue
for
that,
just
to
kind
of
start.
The
discussion
around
like
what
that
would
look
like
and
I
and
I
wanted
to
bring
that
discussion
here,
because
I
figured
that
people
would
have
opinions
on
that.
E
E
D
Reason
the
reason
sorry,
an
Hotel,
export
or
not
and
like
the
hotel
exporter,
the
library
exporter
to
that
is
otlp.
The
reason
why
to
not
put
it
into
the
pipelines
by
default
is
because
I
I
think
monitoring
yourself.
It
comes
with
a
lot
of
troubles
and
you
have
to
know
exactly
what
you
are
doing
and
usually
I
I
would
recommend
people
to
not
send
their
own
Telemetry
to
themselves
just
to
send
to
the
next
layer
for
good
or
for
bad.
If
you,
if
you
are
broken,
you're,
not
gonna,
emit
anything.
D
So
starting
with
that
idea,
I
think
we
should.
We
should
have
a
configuration
to
allow
users
to
choose
one
of
the
exporters,
but
the
problem
and
the
reason
why
we
postponed
this
Tyler
is
because
there
is
no
such
thing
as
the
config
for
hotel
libraries
that
is
not
via
environmental
variables
and
stuff
and
I
would
not
want
necessarily
to
support
that.
But
is
the
go
SDK
I
think
already
supports
that
so
I
I
give
me
an
configuration
and
that's
that's
the
only
thing
that
we
need
actually.
E
E
D
Couple
of
things
I
think
the
configuration
should
allow
us
to
select
multiple
exporters,
because
this
is
one
of
the
statement
of
hotel
that
you
can
export
in
multiple
places
so
make
sure
there
is
not
a
one-off.
Like
exporter,
we
we
can
select
multiple
exporters
and
each
exporter
has
its
own
configuration.
We
may
only
support
otlp
initially,
but
yeah.
D
E
F
Not
yet
I
think
it's
way
too
early,
but
I
I
did
want
to
ask
what
what
if
what
would
people
think
if
we
were
able
to
reuse
the
same
exporters
and
processors
like
the
configuration
that's
already
made
available
in
other
places,
so
say
someone
configured
otlp
exporter
and
had
an
endpoint
or
whatever?
What?
If
what?
If
we
just
allowed
them
to
reuse,
that
same
name
and
and
we
used
it
to
configure
the
SDK
like
it,
doesn't
have
to
be
the
same
path.
E
So
like,
if
someone
had
to
had
configured
in
their
exporter
section
like
an
otlp
exporter
that
went
to
some
vendor
back
end
and
it
had
all
the
the
headers
and
all
the
stuff
that
they
needed
in
the
Telemetry
settings
configuration
they
could
reference
that
named
exporter
and
the
the
Telemetry
settings
code
would
know
how
to
take
those
pieces
of
information
and
configure
the
go.
Sdk.
D
D
If
you
want
to
be
fully
fully
open
tremended,
essentially
you
can
define
a
pipeline
where
you
put
this
special
name.
That
represents
internal
Telemetry
as
a
receiver,
and
then
you
can
do
that,
for
maybe
we
should
support
for
metrics
traces
and
logs
okay
and
now,
if
you
have
an
exporter,
you
have
to
define
a
pipeline
internal
pipeline
internal
traces,
for
example,
Alex,
and
then
you
put
that
exporter
there.
D
F
Sorry,
just
just
to
be
clear:
I
wasn't
suggesting
that
we
reuse
the
the
components
themselves,
I'm
I'm,
suggesting
that
as
a
user,
I
can
configure
my
exporters
all
in
one
section
and
then
I
could
do.
As
you
know,
when
we're
parsing
the
when
we're
marshalling
the
data
for
the
Telemetry
pipeline,
we
would
just
use
the
same
named
exporters
or
name
processors,
so
that
the
so
that
the
user
doesn't
have
to
configure
an
exporter
in
the
in
the
Telemetry
pipeline
section
as
well
as
like
in
the
exporter
section.
D
F
D
It's
in
my
opinion,
the
most
flexible,
because
it
gives
us
all
the
the
possibility
and
I
think
that's
why,
when
I
started,
I
started
by
saying
I
think
we'll
end
up
supporting
both
I
think
we
should
allow
people
to
configure
a
specific
exporter
there
in
that
section
and
then
another
option
is
to
make
it
a
receiver
and
put
it
in
a
pipeline
and
user
whatever
they
want.
If.
E
We
start
with
just
being
able
to
configure
the
go
SDK
to
export
somewhere.
The
user
should
be
able
to
configure
that
to
go
to
from
backend
if
they
want
or
to
like
an
existing
otlp
receiver
on
The
Collector.
So
I
think
if
we
start
with
that
approach,
that'll
be
the
most
flexibility
of
start,
even
though
it's
maybe
a
little
inefficient
to
push
the
data
over
the
network
to
The
Collector
itself.
So.
H
G
I
think
dressy
mentioned
on
the
issue,
though
something
that
needs
to
be
kept
in
mind,
which
is
that
we
need
to
ensure
that
we
we
don't
or
make
it
very
hard
to
set
up
feedback
loops.
Because,
if
we're
exporting
traces
about
data
that
we've
processed-
and
that
goes
to
the
same
collector.
Where
that
processing
more
data,
which
is
going
to
cause
the
stacks
for
more
traces
which
just
gets
into
a
loop.
D
D
F
I
Just
as
an
update,
our
team
has
a
working
relationship
with
the
corelogics
team
and
I
reached
out
to
my
PM
this
morning
and
sent
him
the
issue
and
he
actually
has
a
meeting
with
them
in
an
hour
and
he
said
he'd
bring
it
up.
So
hopefully,
someone
does
pop
back
in,
but
I.
Don't
think
that
should
really
stop
kind
of
support
progress
until
they
show
up.
F
C
J
Hey
everyone
I
just
heard,
like
a
general
question,
basically
I'm
building
a
authentication
extension,
a
custom,
authentication
extension
that
is
supposed
to
work
in
like
a
multi-tenant
way
where
it
needs
to
dynamically
Set,
an
API
header
and
the
issue
that
I'm
running
into
is
that
the
functionality
that
we
need
it
needs
to.
Basically
dynamically
set
API
Keys
Based
on
data,
that's
in
Telemetry.
So
for
an
example.
J
But
I
haven't
found
a
way
to
actually
do
that.
So
what
I
ended
up
doing
is
I
ended
up
creating
a
brand
new
exporter,
getting
the
resource,
attributes,
updating
the
context
and
then
using
this
effectively.
The
header
Setter
extension
so
I'm
wondering
if
there's
like
a
better
approach
or
if
there's
a
way
for
extensions
to
actually
access
resource
attributes
who.
D
D
D
D
J
D
D
J
Oh
okay,
so
I
think,
okay,
so
I
think
I'll
have
to
double
check,
but
so
in
theory,
like
the
context
should
be
passed,
although,
but
it's
I
think
it's
it
has
to
be
in
the
client
context
right
so
like
I
was
basically
having
issues
where
I
was
setting
values
inside
the
context,
but
I
wasn't
setting
them
inside
like
the
client
context,
because,
like
there's,
a
client
object
that
there's
a
client
that
info
object
and
that
header
and
Setter
extension
basically
for
that
from
Context.
It's
reading
from
that
client
object.
J
That's
in
the
context.
So,
like
you
know,
in
a
processor
I
can't
just
I
can't
just
take
the
the
default
context,
object
and
use
like
the
golang,
with
value
like
that
doesn't
get
propagated.
All
the
way
to
so
I
guess,
like
my
question,
is:
is
this
client
object
copied
from
Context
to
context
as
it's
as
it's
propagated
through
the
pipelines
and
is
that
the
reason
why
I
can't
just
use
like
with
value
or
like
the
the
built-in
goal
in
context
value
of.
D
B
Everything
is
within
the
context
and
the
same
context
from
the
initial
connection
should
be
available
up
to
the
batching
processor
or
to
any
grouping
option
any
any
grouping
processor.
So
if
you're
not
having
any
Group
by
Trace
or
batching
processor
or
anything
like
that,
then
the
client
contacts
that
you
have
for
the
receiver
or
set
by
the
the
extension
should
be
available
at
the
exporter
site
as
well,
so
it
should
be
propagated
on
the
same
context.
So
the
client
information
should
be
made
available
throughout
the
pipeline.
J
Okay,
then
I
might
have
I
might
follow
up
with
like
a
bug
ticket,
because
I
have
a
specific
example,
where
the
context
objects
that
I'm
setting
in
in
a
processor
are
not
actually
available
in
the
extension
and
that's
kind
of
kind
of
where
my
problems
came
up.
So
I
can
follow
up
with
like
a
ticket
with
like
a
specific
example.
But
that's
the
reason
I
ended
up
having
to
create
my
own
exporter
is
because
I
wasn't
seeing
any
of
the
context
values.
A
J
So
I
can
follow
up
with
an
issue,
but
yeah
I
mean
that's,
that's
the
gist
of
like
the
problems
that
I'm
running
into
and
I.
Guess,
like
as
a
follow-up
question,
is
there?
Is
there
like
a
design
reason
why,
like
Telemetry
data,
is
not
available
in
extensions?
Is
that
like
an
intentional
kind
of
architecture
decision,
or
is
it
just
like
a
concept.
D
B
B
So
they
explicitly
pass
the
context
to
to
the
authentication,
extensions
and
based
on
that
the
auth
extension
wouldn't
put
data
into
the
context
like
the
client
info
is
one
of
the
examples,
but
that's
that's
the
only
way
for
extinctions
to
have
access
to
to
the
to
the
pipeline
data,
which
means
that
if
you,
if
you
have
in
your
component,
like
yours,
receiver
or
processor,
when
the
start
function
is
called,
you
receive
a
host
and
within
the
host.
You
get
a
list
of
extensions.
B
And
if
you
can
pick
up
the
extension
that
you
want
from
that
list,
then
you
can
get
an
instance
of
that
and
then
you
can
call
it
function
and
as
part
of
this
function
call
you
can
send
Telemetry
data
to
that.
But
that
requires
something
from
the
pipeline
to
call
your
extension
with
the
Telemetry
data.
J
B
The
health
education
extension
is
one
of
the
examples,
so
you
can.
You
can
pick
any
one
of
those
and
you
can
take
a
look
at
the
config
HTTP
package.
That
one
has
this
like
retrieval
of
extensions
and
then
verifies,
which
ones
are
our
authentication
extensions
and
do
the
matching
on
the
configuration
and
so
on.
I
can
send
you
the
link
to
that
specific
part
of
the
code
that.
D
J
D
A
D
Then
then
you
can
inject
them
at
random
points.
We
don't
have
any
control
about.
Who
is
the
mutation
of
the
data
and
I?
Don't
know
if
you
saw,
but
recently
we
have
a
lot
more
bugs
about
components.
Mutating
the
data
when
they
shouldn't
and
stuff
like
that,
so
so
I
would
discourage
you
to
design
something
that
that
makes
access
to
the
Telemetry
data
in
the
extension.
Do
it
as
a
processor
and
and
that's
fine.
C
B
Now,
if
it
helps
you
in
any
way
the
way
that
we
do
with
your
tenancy
in
Loki,
Tempo,
mirror
and
so
on,
is
we
send
the
tenancy
data
as
a
HTTP
as
an
HTTP
header?
So
it's
not
part
of
the
Telemetry
data,
because
we
see
that
you
know
every
everything
that
is
coming
from
a
specific
HTTP
call
or
share
PC
message
belongs
to
the
same
tenant.
D
And
by
the
way,
there
is
an
open
issue,
if
you
really
want
to
do
it,
where
I
explain
exactly
the
situation,
why
the
best
processor
shouldn't
be
a
processor
and
should
be
part
of
exporter,
and
we
should
allow
configuring
things
like
this.
If
you
wanna
work
on
that,
I
can
find
the
issue.
But
it's
a
lot
of
work.
G
J
G
H
E
D
J
K
You
here
yep
I'm
here,
oh
so,
yeah
on
Fridays.
We
have
the
collector
triage
sessions
that
are
scheduled.
I,
don't
know
that
there's
much
of
a
purpose
to
those
at
this
point.
Most
of
the
sessions
when
I
was
attending
were
for
routing
issues
and
at
this
point
that's
mostly
been
solved
by
Automation
and
we
call
it.
The
Sig
meetings
are
usually
free
enough
that
we
can
discuss
issues
here.
So
if
nobody
had
any
concerns,
I
was
going
to
request
those
get
taken
off
the
calendar.
E
Don't
know
I,
think
prioritization
for
most
of
the
con
contrib
components
comes
down
to
the
code
owners
like
what
they
think
about
the
prioritization,
and
we
definitely
don't
have
all
the
code
owners
here.
So
that
might
be
hard
for
contrib,
but
we
could
maybe
do
it
for
core.
If
you
want
I,
don't
think
we've
been
at
least
when
I
was
going
to
those
triagra
sessions.
We,
like
kind
of
weren't,
doing
anything
with
core.
Recently
we
were
really
focusing
on
contrib,
since
it
had
more
activity.
E
D
I
B
A
D
B
D
K
K
B
B
D
B
D
C
B
Yeah,
so
one
thing
that
I
would
I
would
like
to
so
one
thing
that
that
affected
me
on
the
GCE
meetings
and
I'm
I'm,
proposing
here
as
well,
is
to
change
the
calendar,
invite
to
not
re
not
be
affected
by
by
Daylight
Saving
Time
Changes,
so
that
you
know
whenever
the
US
has
DST.
It
won't
change
the
meeting
time
for
everyone
else
in
the
road.
G
G
D
G
B
A
F
D
H
B
B
Sean
the
movie
star
movie,
star
guy,
that
you
mentioned
so
Sean
mentioned
to
me
that
it's
very
hard
for
him
to
join
because
of
this
of
this
problem,
but
he
typically
adds
his
concerns
to
the
meeting
notes
beforehand,
and
he
typically
talked
to
someone
to
us
before
that.
So
I
think
it's
not
a
huge
problem
for
him,
but
I'm
sure
that
he
would
love
to
join.
D
B
E
Think
the.net
thing
every
other
week
is
like
a
different
time,
and
so
they
have
one
that's
in
the
morning
and
then
one
that's
in
the
afternoon
to
try
to
support
that
stuff.
I,
don't
remember,
I,
don't
know
who
or
what
time
zone
they're
targeting
but
like
every
other
week.
Their
time
is
different,
but.
G
B
I
C
Just
one
mention,
maybe
not
being
able
to
participate
in
meetings
like
this
would
be
easier
if,
if
not
participating,
will
not
be
a
block
or
two
anything
like
I.
Think
I
saw
that
PR
for
membership
or
traging
from
that
China
person
who
mentioned
that
they
attended
a
couple
six,
but
they
weren't
able
to
attend
all
of
those
and
I.
Guess
it's
natural
and
it
I
guess
it
wasn't
a
problem
for
them
to
be
still
accepted
right
for
the
community.
So
I
hope.
That's
that's
how
it
works.
B
C
D
Mean
that's,
that's
more
or
less
recommendation
to
get
in
touch
with
people
not
to
not
to
necessarily
enter
the
community
I.
If
it
is
a
requirement,
I
think
we
should
fix
that,
because
the
time
zones
should
not
be
a
problem
for
people
to
participate
into
the
community
or
to
be
members,
and
we
have
a
good
example
with
the
the
Australian
guy,
the
movie
star,
which
is
like
he
never
I've,
never
seen
him
in
any
meetings
here.
But
he's
he's
now
an
approver.