►
From YouTube: 2022-09-06 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
A
A
B
Yeah
I'm
still
checking
the
attendees
list,
I
think
we're
almost
at
Quorum
here.
So
we
could
probably
start
just
a
little
bit.
I
guess
just
to
kind
of
kick
it
off.
Please
make
sure
you
open
up
the
agenda
doc.
Actually
let
me
post
that
also
in
the
chat
just
in
case
you
don't
have
the
link
handy
and
then
add
your
name
to
the
attendees
list.
If
you
have
anything
else,
you
want
to
or
please
go
ahead
and
review
the
agenda.
B
If
you
have
anything
else,
you'd
like
to
add
to
the
agenda,
please
go
ahead
and
add
it
and
I
think
we'll
give
it
just
another
minute
just
for
people
to
trick
in
trickle
in
I
think
we
have
the
Quorum
of
people
we
were
looking
to
include
in
the
meeting.
I
did
schedule
this
for
an
hour,
so
currently
I
think
our
agenda.
We
can
accomplish
that
at
this
point,
so
I'm
just
gonna
give
it
just
a
second.
B
Okay,
I
think
at
this
point
we
can
jump
into
it.
Welcome
everyone
definitely
welcome
to
the
first
kickoff
meeting
of
the
overtime
to
go
Auto
instrumentation
meeting
guessing
everyone
on
the
call
understands
what
we're
here
to
discuss.
I
just
want
to
like
kind
of
start
off
the
meeting,
with
some
administrative
and
more
meta
questions
about
the
project.
B
One
of
the
things
just
for
people
who
may
not
be
familiar
with
open
Telemetry
is
a
lot
of
the
structure
of
open
Telemetry
is
designed
around
special
interest
groups,
and
currently
this
is
being
wrapped
in
with
the
open
television
go
Sig,
it
likely
is
going
to
be
its
own
sake,
but
just
wanted
to
kind
of
like
ask
questions
around
the
administration
of
this
new
Sig,
because
it
will
I
think
in
itself
be
a
spin-off
one
of
the
first
things
that
I
wanted
to
ask.
B
Everyone
is
with
on
the
regular
meeting
Cadence
I
I
wanted
to
see.
Obviously
we
want
to
have
these
sort
of
meetings
where
we
could
have
synchronous
conversation
about
particular
issues
or
discussions
on
topics,
and
to
do
that
we
usually
do
this
over
Zoom
I.
Don't
think
we
necessarily
need
to
have
a
particular
date
and
time
in
mind,
but
I
wanted
to
ask
everyone
specifically
a
regular
Cadence.
B
If
anybody
had
any
opinion
if
this
should
be
a
monthly
weekly,
bi-weekly,
everyday
sort
of
thing
and
and
see
if
anybody
had
any
strong
opinions
there,
foreign.
B
Yeah
I
was
thinking
bi-weekly
as
well
sounds
pretty
reasonable.
Okay,
that
sounds
good
I
think.
Is
there
any
strong
opinion?
I
guess,
maybe
a
good
question
to
start
it
off
with
is
I
wasn't
going
to
do
an
introduction,
but
maybe
that's
probably
the
best
way,
because
it
might
be
helpful
to
understand
like
where
everyone
is
geographically
located.
B
Somebody
will
stop
sharing,
really
quick
if
we
can
just
go
around
and
maybe
just
do
some
some
introductions
just
so
everyone
is
familiar.
I
definitely
see
a
lot
of
familiar
faces
on
here,
but
maybe
we
could
just
talk
about
who
you
are
if
you
work
for
a
company,
that's
related
to
open
Telemetry.
B
Please
mention
that
where
you're
located
I
think
would
also
be
really
helpful
to
understand
this
and
then
I
guess
maybe
what's
your
interest
in
the
project
are
I
could
start
it
off
by
saying
I'm,
Tyler
Tyler
young
I'm,
a
maintainer
for
the
open,
Telemetry
go
Sig.
I
have
a
strong
interest
in
this,
because
I
care
a
lot
about
ghosts,
ability
to
actually
support
ottawa's
rotation
in
open,
telestream
and
I'm
located
in
the
Pacific
time
zone
in
North.
America
dinesha
see
your
next
on
the
attendees
list.
A
Hey
hi,
this
is
Dinesh,
so
I
just
joined
the
open
Telemetry
team
at
datadog,
so
we
are
at
deadro.
We
are
trying
to
solve
open
Elementary
issues,
so
go
has
been
my
language
for
the
last
two
years.
The
reason
I'm
interested
in
this
thing
is
because
we
have
lots
of
onboarding
issues
when
people
try
to
use
data
dog
and
I
think
this
is
a
right
place
to
solve
those
kind
of
things.
B
Great
Robert
I
see
you
on
the
call
as
well
I.
D
Know
yeah
so
if
I'm
Robert
so
I'm
working
with
Tyler
at
spline
I'm,
also
a
maintainer
of.net
I'll.
Do
this
fermentation
an
approval
in
dotnet
SDK
and
go
go
SDK
in
hotel.
So
basically,
my
interest
is
because
I
want
to
like
share
also
my
knowledge
and
my
expertise
in
outlooking
summation,
which
comescom.net,
which
is
also
kind
of
hard
from
the
runtime
perspective,
and
also,
at
the
same
time,
the
compile
time.
Not
it's
not
the
same,
because
it's
not
like
as
much
statically
typed
the
go
but
yeah
I.
Think
I.
D
I
also
have
some
experience,
because
Auto
instrumentation
was
is
very
popular
in
in
our
dotted
customers.
So
I
hope
that
I
can
give
some
thoughts
here
and
my
time.
So
it's
pretty
hard
because
I'm
located
in
Poland
so
right
now,
it's
6
30
p.m.
So
this
time
is
perfect
for
me
to
be
honest,
compared
to
go,
seek
meeting
do.
B
Yeah
thanks
Robert,
that's
actually
a
good
point.
I
know
we
have
mihal
as
well
as
also
in
Poland
but
I'll.
Let
him
introduce
himself
yeah.
E
And
also
based
in
Poland,
so
Central
European,
Time
Zone,
but
I,
don't
think
I'll
be
joining
this
meeting
on
a
regular
basis.
I
was
most
interested
because
this
is
a
kickoff
I
wanted
to
see.
What
are
you
guys
going
to
be
working
on.
E
B
Awesome
thanks
who's
on
the
next
Eden
I,
see
you
next
on
the
agenda
list.
E
Yeah
sure
so,
I'm
Eden
I'm,
the
creator
of
the
adpf
based
instrumentation
yeah
I,
worked
for
keyboard.
It's
a
new
South
company
I'm
best
in
Israel,
so
like
almost
similar
to
Poland.
So
this
time
also
works
great.
For
me.
B
Awesome
Ari
I
see
you
next
on
the
agenda
list.
A
Yeah
I
hope
you
guys
can
hear
me
because
I
was
having
some
trouble
with
my
internet
connection,
I
think
I'm
Eden's
partner
and
Keegan
I'm,
probably
the
least
technical
person
on
the
call
I'm
I've
been
following.
All
people
live
with
me
now
for
close
to
two
years,
excited
about
the
stuff
that
Eden
is
developing
and
we're
waiting
to
hear
so.
What's
next.
B
Awesome
glad
to
have
you
prismac
I,
see
you
next
time.
The
attendees
list.
E
B
E
B
A
Yeah
I'm
Mike
I
just
started
on
the
open
Telemetry
team
at
Google.
For
about
six
months
ago,
I've
been
getting
ramped
up
on
just
things
open
until
I'm
a
tree
in
areas
that
I
can
contribute
go
is
my
main
language
I've
been
working
on
kubernetes
for
the
past
couple
years,
so
I
come
from.
A
You
know
that
kind
of
background,
so
the
auto
instrumentation
stuff
was
interesting
to
me
from
a
from
the
go
perspective,
but
also
you
know,
I
was
looking
at
the
operator
a
little
bit
and
trying
to
learn
about
how
like
Auto,
instrumentation
kind
of
works
and
how
it
can
help
people
on
board
to
open
telemetry.
A
Cool
we
have
to
do
a
little
handoff
because
we're
in
the
same
room,
I'm,
David,
ashpol
I,
have
I'm
an
approver
at
the
in
the
open,
telemetrico
Sig
and
I
lead
the
instrumentation
Sig
in
kubernetes
I'm,
here
mostly
out
of
curiosity
I'm,
not
sure
yet
whether
I'll
be
attending
regularly
but
I.
Think
auto
transportation
in
go
is
really
exciting
and
looking
forward
I
didn't
think
it
was
possible.
But
here
we
are
so
you
know
looking
forward
to
see
what
we
can
come
up
with.
B
Yeah
absolutely
and
I
guess
I
know,
but
just
for
everyone
you're
also
in
the
Eastern
time
zone
right
I
am
yeah
yeah.
Okay,
unless
on
the
list
is
Josh.
C
Hi
I'm
Josh
I'm,
an
open,
Telemetry,
technical,
Committee,
Member
and
I
also
reviewed
the
original
donation
proposals
and
discussed
this.
This
team
formation,
with
some
of
the
maintainers
before
proceeding
so
I'm,
mostly
here
as
a
interested
party,
an
improver
and
a
reviewer
of
things
and
looking
forward
to
following
the
group's
progress.
B
Awesome,
yeah,
Josh
I'm,
pretty
sure
you've
been
with
open
Telemetry
since
the
start
right.
C
Yes,
roughly
I
mean
there
are
a
few
people
who
predate
open,
Telemetry
and
open
census.
This
formation,
but
I've,
been
here
about
three
years
outside
on
the
on
the
west
coast,
I
left
San
Francisco,
but
I'm
still
in
California
and
I
work
at
lightstep,
who
has
an
interest
in
tracing
a
metrics,
at
least
for
now,
mostly
in
open
telemetry.
B
Awesome:
okay!
Well
thanks
Josh
nice
to
meet
you
all.
I,
definitely
think
that
we
have
a
little
bit
better
understanding
of
the
geographic
diversity
here.
So
I
think
this
bi-weekly
idea
for
a
Sig
meeting
sounds
like
a
good
one.
I
think
we'll
try
to
shoot
for
the
same
time.
In
fact,
this
is
a
pretty
open
time
on
the
open
television
calendar
as
well.
So
this
might
be
a
really
good
time
as
well.
B
So
I
will
take
that
as
an
action
item
to
set
up
the
Sig
meeting
and
I'll
make
sure
that
if
you,
if
you
aren't
already
there
is
a
open
television
calendar
group,
I
think
it
is.
That
will
be
the
group
that
I
invite
to
these
meetings.
So
if
you
want
to
get
notifications
to
all
open,
Telemetry
invites
that's
a
good
one
to
go.
Join
the
group
I
think
it's
an
open
group,
so
I
don't
think
it's
that
hard
to
get
on.
Okay,
let
me
start
sharing
my
screen
again.
B
I.
Think
there's
a
few
more
administrative
questions.
I
wanted
to
ask
I!
Think
next
on
the
list
I
had.
Is
this
question
of
open
Telemetry
go
instrumentation
Josh
created
this
repo
for
us
thanks
again
Josh
for
setting
this
up?
B
C
There
was
a
precedent
already
set
in
in
across
open
Telemetry.
We
just
followed
it.
Java
and
net
already
have
that
pattern.
Yes,.
B
Okay
and
the
last
thing
I
wanted
to
talk
about
I,
don't
necessarily
need
to
resolve
this,
or
it's
not
going
to
be
resolved
in
this
meeting
for
those
not
familiar
with
the
consumerator.
We
have
maintainers
and
approvers
of
these
repositories
and
the
the
Sig
in
itself
right
now,
we've
seated
this
with
existing
members
from
the
open
Sound.
B
Let
you
go
projects
and
other
people
that
have
proposals
on
the
project
if
I'm
not
mistaken,
but
I
think
that
in
the
next
meeting
or
two,
we
should
discuss
the
the
construction
of
these
maintainers
and
recruiters
teams.
One
of
the
things
that
I
want
to
make
sure
is
that
they
are
staffed
with
people
that
are
able
to
dedicate
time
to
them
overloading
the
Optometry
dough.
Community
is
not
something
I
want
to
do
as
it's
a
maintainer
I'm,
also
extremely
interested
in
this
I'm.
B
Not
saying
I
want
to
remove
myself,
but
I
do
want
to
make
sure
that,
like
anybody
who
is
in
the
Optometry
goes
space
right
now
has
the
option
to
remove
themselves
also
for
new
community
members,
I'd
like
to
make
sure
that
there's
an
opportunity
for
them
to
collaborate
on
this
and
be
part
of
this
organization's
Administration.
So
just
a
heads
up
on
that
one
I
think
this
is
this
is
going
to
be
something
for
next
week.
A
B
Awesome
these
next
action
items
I
think
are
more
stream
of
conscious
now
that
I'm
reading
them
again,
but
I
think
that
we
should
probably
just
jump
to
this.
Currently
the
project
has
a
few
open
issues,
one
of
which
is
this
kickoff,
which
I
think
we're
doing
right
now
and
I'm
going
to
try
to
I.
Think
close
this
after
this
meeting
with
some
of
the
takeaways
from
this
meeting
so
I
think
that's
that's
kind
of
my
goal.
B
One
of
the
things
that
I
did
notice
here
is
that
our
readme
is
missing.
So
I
think
that
I
already
have
an
answer
to
one
of
my
questions,
which
is
why
I
think
that
was
more
of
a
stream
of
Consciousness.
This
should
probably
be
added,
so
I
will
fill
out
this
issue
later.
B
This
is
a
great
place
for
an
issue,
but
I
wanted
to
jump
into
this
and
I
think
this
is
actually
kind
of
what
Eden's
comment
is
as
well
as
our
open
questions
here
of
what
the
actual
project
will
con
consist
of.
I
think
these
are
all
captured
in
issues,
but
maybe
we'll
just
jump
into
this
as
a
good
overview.
B
If
that
makes
sense,
so
if
you
haven't
already
there's
a
set
of
issues
here
around
instrumentation
and
the
configuration
focus
on
that
you
go
as
well
as
just
in
the
go
ecosystem
trying
to
instrument
go
applications
and
there
I
think
are
at
a
high
level
some
big
projects
that
are
outlined
in
these
issues.
B
Two
instrumentation
options
that
are
are
different
and
definitely
big
projects
for
themselves,
some
of
which
are
are
feature
complete
or
close
to
it,
and
then
we
would
just
need
to
be
integrating.
Others
are
just
this
idea
of
an
there's
a
configuration
one
in
here,
I'm
gonna
see
any
configuration,
there's
other
configuration
issues
as
well,
so
I
definitely
wanted
to
try
to
go
through
all
of
those.
B
At
this
point
with
that,
I
wanted
to
maybe
just
jump
into
this
topic
here
Eden
you
had
runtime
Auto
instrumentation
as
the
first
action
item
compile
time
automatic
instrumentation
go
yeah.
This
is
the
configure
I,
don't
see
an
issue
for
that,
but
maybe
I'm
missing
it
and
then
better
integration
between
go
built-in
diagnostic
features
like
P
Prof
and
some
interesting
I
think.
D
C
Thank
you,
foreign
I
might
want
to
say
something
like
I
feel
like
I
made
a
proposal,
at
least
when
in
the
response
to
the
original
donation,
proposals
that
there'd
be
an
umbrella
here,
that
kind
of
covers
different
approaches
to
Auto
instrumentation
I
I,
there's
a
chance
that
that
was
a
bad
move
from
the
start.
However,
they're
I
feel
like
there's,
probably
something
essential
that
belongs
in
a
shared
place.
That
involves
how
you
decide
if
instrumentation
will
or
will
not
be
applied
when
it
could
potentially
come
from
more
than
one
source.
C
That's
mostly
the
premise
behind
putting
these
groups
this
group,
together
with
a
bunch
of
different
approaches
in
the
same
place,
and
then
Tyler
I,
think
you've
kind
of
hinted
at
it
already,
but
the
the
item
Point
C
here
about
this,
there's
this
parallel
effort
going
on
it's
currently
located
in
the
go
contrib
repository
about
configuring.
C
These
things
we
might
call
launchers
or
Auto,
auto
initialization,
which
is
another
form
of
a
different
type
of
Auto
instrumentation,
meaning
the
sort
of
Auto
auto
configuration
of
the
SDK
and
whether
whether
or
not
that
does
belong
in
this
conversation
or
in
this
repository
is
certainly
debatable.
But
it's
been
a
pose
that
go.
The
go
Project
work
on
something
like
that
and
I
can't
see
it
not
being
at
least
somewhat
interacting
with
this.
This
group
here.
So
if
I'd
say
that
and
then
drop
out
to,
let
you
discuss
it.
B
Yeah
thanks
Josh
and
I
think
that
to
Josh's
Point
around,
especially
this
configuration
topic,
this
is
included
in
the
like
the
Java,
SDK
instrumentation
right.
C
As
I
understand
it,
yeah
there's,
you
know
when
you
have
that
jar
file
that
includes
Auto
instrumentation,
there's
a
bunch
of
interpretation
of
the
properties,
the
system
properties
that
you
get
through
through
the
command
line
environment,
and
so
on.
C
That
dictates
what
is
going
to
happen
and
to
the
extent
that
a
user
certainly
places
that
jar
file
intentionally,
they
had
some
control
over
it
over
it,
but
but
they
also
probably
need
some
runtime
configuration
to
like
make
it
not
happen,
or
at
least
have
some
control
over
faulty
components
is
usually
the
inner
issue
that
people
come
up
with,
like
oh
I
turned
on
auto
instrumentation
and
all
of
a
sudden
something
broke.
How
do
I?
How
do
I
recover
something
working
from
that
situation?
For
example,.
B
Right
right,
yeah
and
I
think
that
yes,
I,
think
this
is
kind
of
getting
to
something
that
I
would
really
like
to
have
decided
for
this
group,
maybe
not
necessarily
in
this
meeting,
but
what
I?
What
I
was
kind
of
alluding
to?
B
The
fact
is
that
I
see
there's
a
lot
of
big
projects
here
and
let's
see
how
many
do
I
see
for
eight,
so
10
people
on
the
call
right
if
everyone
on
this
call
was
able
to
dedicate
100
of
their
time
I,
don't
think
that
we
could
handle
all
of
these
simultaneous
simultaneously
either.
You
know,
I
think
that
there's
just
a
reality
of
how
much
developer
Focus
can
actually
be
attributed
to
the
project.
B
Obviously
it's
going
to
vary
by
person
and
by
how
what
they
can
actually
contribute,
but
I
want
to
make
sure
that
we
have
some
some
priorities.
I
think
it's
an
open
source
project
so
obviously
like
these
priorities
are
something
that
need
to
be
agreed
upon.
They
can't
just
essentially
be
dictated
and
so
I
think
it's
really.
It's
really
key
that
we
try
to
focus
our
effort
personally.
B
I
see
it
as
trying
to
provide
some
sort
of
value
like
we
have
users
and
the
sooner
that
we
can
actually
get
value
to
those
users
and
and
have
them.
B
You
know,
maybe
even
defining
what
that
value
is,
but
in
my
eye
seeing
that
they
can
actually,
like
you
know,
without
having
to
modify
their
code
or
maybe
just
running
a
in
the
case
of
the
auto
creation
function
like
running
something
during
the
compiler,
the
minimal
amount
that
a
user
can
have
their
go
code,
instrumented
and
up
and
running
I.
Think
is
the
first
step
configuring.
B
What
that
SDK
looks
like
and
sampling,
and
all
these
other
things
that
are
associated
with
the
open
culture,
SDK
I,
think,
are
also
going
to
be
really
important,
but
I,
don't
necessarily
see
those
as
our
first
option
and
our
first
barrier
I
do
see
that
we
have
two
approaches
as
well
being
submitted
as
proposals
right.
One
for
those
that
are
familiar
is
in
the
annotation
of
source
code
itself
during
the
compilation
in
everyone.
Correct
me
when
I
say
something
things
that
are
incorrect.
B
Is
using
ebpf
to
at
runtime
instrument
functions
that
are
actually
being
run
by
the
operating
system
and
so
I
think
both
of
those
are
going
to
both
produce,
Telemetry
and
I
think
that
it
seems
like
both
of
them
actually
have
a
proof
of
concept
that
already
exists.
So
my
question
to
the
to
the
community
is:
how
do
we
actually
want
to
go
about
structuring
and
prioritizing
what
I
think
larger
projects
we
are
working
on.
D
D
E
For
me,
it
makes
sense
and
I
think
that
these
two
approaches
are
compliment
complements
between
to
each
other.
So
we
can,
as
you
said,
we
can
use
them
both
and
some
one
will
be
better
for
for
specific
cases
and
the
other
will
be
better
for
other
cases
and
also
maybe
we
can
use
mix
of
them,
because
I
think
that
also
in
Eden
proposals,
we
can
generate
code
that
is
used
in
a
ebpf.
E
Did
this
code
that
is
currently
written
by
by
hand?
We
can
also
generate
it,
and
this
is
C
code
and
it's
also
possible
to
generate
it
automatically.
E
Yeah
I
agree:
I,
think
that
the
main
use
case
is
I
can
see
that
those
two
approaches
that
complement
each
other
is,
for
example,
like
Windows
machines
that
are
not
really
sure
have
a
very
good
evpf
support.
E
Yet
so,
for
example,
Windows
users
will
be
able
to
easily
use
the
compile
time
approach
and
for
for
other
use
cases,
we
can
combine
these
two
together
yeah,
but
regarding
the
features
I
think
that,
like
context,
propagation
and
integration
with
the
with
the
manual
instrumentation,
let's
be
capable
so
possible,
something
that
is
already
in
work
and
yeah.
D
A
D
Think
people
link
was
like
discussed
in
parallel
and
I
think
it's
postponed,
but
by
Tyler,
maybe
as
a
maintainer.
You
know
more
as
a
specialized
thing.
I
think
Josh
knows
a
lot
more.
Regarding
profiling
signal.
B
Yeah
I
I
think
that
that's
a
that's.
The
key
thing
is
it's
it's
a
signal
that
is
I
think
a
little
bit
divorced
from
the
concept
of
tracing
your
metrics
a
little
bit
and
I
think
there's
overlap,
but
I
I.
Think
that's
kind
of
the
key
thing
is
that
the
the
compile
time
in
the
evpf
packet
filtering
allow
you
to
do
tracing
of
context
through
distributed
applications
and
I.
B
Think
if
that's
something
that
P
Prof
is
not
going
to
be
able
to
actually
achieve,
although
I'm
not
the
most
familiar
with
people,
maybe
there's
some
way
you
can
pass
context,
but
I
I,
don't
think
so,
but
yeah
I
think
that's
kind
of
like
it's
a
good
point.
I
think
profiling
is
an
important
thing
that
is
going
to
be
addressed.
B
I
would
say
that
profiling
itself,
I'm
trying
to
remember
State
at
this
point,
is
something
that
the
open
television
project
as
a
project
is
trying
to
provide
a
solution
for
as
well,
and
it's
a
signal
that
I,
don't
think,
is
defined
yet
but
I.
If
I
know
there
is
a
working
group,
so
another
Sig
itself
dedicated
to
actually
defining
that.
B
For
the
specification
level,
so
I
would
probably
say
that
profiling
elements
are
are
out
of
scope,
at
least
initially
for
this
Repository
and
maybe
in
in
perpetuity,
if
it's
I
think
a
better
fit
for
the
open
club
to
go
project
itself,
but
that's
my
understanding
of
the
project,
if
others
understand
it
differently,
please
jump
in.
A
B
Project
does
have
a
a
runtime
instrumentation
package
that
I
think
under
the
hood.
I,
don't
even
know
if
it
uses
P
Prof
but
definitely
uses
a
lot
of
the
go
metrics
that
are
exposed
through
the
standard
Library.
In
fact,
Josh
knows
a
lot
about
that.
He's
got
an
openpr.
C
B
See
Josh
but
yeah,
but
Dinesh
to
your
point
like
I,
think
that's
something
that
is
a
concern
of
the
the
open
symmetrico
project
and
we
are
actively
discussing
it.
I
would
definitely
recommend
if
you,
if
you
were
interested
to
check
out
the
oppochico,
contrib
repo
and
specifically
Josh's
PR
there,
but
yeah
I
think
we
could
probably
I
think
restrict
this
to
more.
The
the
topics
of
the
automatic
instrumentation,
so
yeah
I
I,
think
maybe
that's
a
good
thing.
B
Is
we
really
need
to
make
sure
that
we
have
this
like
concept
of
what
the
goal
of
this
project
is
is
intended
to
solve
and
I
think
that
in
my
mind
and
so
I'm
just
going
to
put
this
out
here
and
please
people
that
have
different
opinions,
save
their
opinions
but
like
it's,
for
especially
new
users
of
that
are
authors
of
go
code
that
are
new
to
open,
Telemetry
and
want
instrumentation
to
be
generated
for
them
without
them
having
to
go
into
their
code
and
and
to
write
that
instrumentation
and
whether
that
means
in
the
compiler
or
just
using
some
packet
filtering.
B
The
the
goal
is
essentially
to
not
have
them
write
code,
but
have
the
the
Telemetry
and
the
tracing
and
potentially
metric
signals
be
automatically
created
for
them
and
sent
to
open
tongue
tree
endpoints.
I
think
is
so
what
I
see
this
project
is
encompassing.
A
Yep
makes
sense,
I
think
that's
in
line
with
the
other
dot
net
and
Java
instrumentation
as
well
right
right,
correct.
B
Correct,
but
also
to
your
point
around
how
maybe
we
could
try
to
solve
this
and
I
think
the
you
know
the
easiest
way
I
think
comes
back
to
that.
There's
two
proposals
here:
do
we
want
to
try
to
tackle
both
of
those
or
we'd
like
to
try
to
incorporate
one
and
then
the
other
right,
because
I
don't
see,
as
people
have
already
said,
I
think
they're,
both
complementary,
in
fact,
I
think
they're
very
complimentary
parts
that
one
may
not
be
able
to
do
well.
B
The
other
can
definitely
do
well.
So
I
definitely
think
that
they're,
both
worth
pursuing
personally
I,
don't
think
it's
going
to
be
really
hard
to
effectively
incorporate
both
of
these
into
the
Project's
simultaneously.
So
I
guess
my
question
is
which
one
would
you
like
to
tackle
first
and
then,
which
one
would
you
like
to
follow
on
with.
B
B
I
have
no
problem
with
that.
I
I
just
want
to
know
what
the
team
composition
would
be
open.
Symmetry
and
other
cigs
have
a
pretty
strong
standard
to
have
review
of
the
code.
That
actually
is
contributed
in.
B
That
review
needs
to
be
a
diverse
set
of
approvers
approvers
that
don't
all
work
at
the
same
company
that
are
I,
think
from
different
backgrounds
is
ideal,
and
so,
if
we
wanted
to
separate
this
out
into
teams,
we
need
to
make
sure
that
we
have
teams
that
are
at
least
three
or
more,
and
there
need
to
be
very
active
developers
because
they
need
to
you
know,
that's
the
entirety
of
it,
there's
no
backup
at
that
point,
so
you
know
one
person
can
submit
something
and
two
people
can
actually
review
it.
D
But,
to
be
honest,
I
think
that
every
like,
like
contributor
here,
will
need
to
understand
at
least
the
basics
of
the
two
approaches.
Can
I
just
share
a
screen
for
a
little
moment?
D
Yes
yeah,
because
so,
for
instance,
we
have
a
similar
problems,
Auto
instrumentation
and
we
have
I'm
not
sure
where
it
was
the
instrumentation
libraries
were
yes,
so
we
have
different
those
two
types
of
instrumentations
one
is
called
in
our
language
source
code,
instrumentations
and
resource
code.
It's
just
using
it's
just
using
dotnet
API,
which
can
be
which,
which
we
can
hook
into
Auto
instrumentation
and
grab
something.
D
So
you
can
see
it's
more
like
like
interior,
more
like
ebpf
in
code,
and
we
have
bytecode
instrumentation,
which
is
injecting
code
as
a
profiler,
and
we
have
even
instrumentation
types
which
are
need
to
be
instrumented.
Using
both
approaches,
as
in
like
here,
is
one
and
second,
as
well,
so
to
implement
it
correctly.
What
needed
to
understand
both
and
implemented
both
approaches
as
well
and
without
having
one
of
them.
E
Yes,
so
what
you
are
saying
is
that
we
should
rather
have
one
team
that
will
work
on
on
one
solution.
Right
that
may
be
mix
both
approaches.
D
D
You
know
we
are
in
open
source,
open
source
project
and
it's
extremely
important
to
describe
the
like
the
the
design
in
a
way
that
not
only
important
it's
not
only
important
for
the
newcomers,
but
you
know
imagine
you're
going
from
from
holidays
in
Europe
going
back
after
a
month,
and
you
want
to
check
what
what
has
changed
like
on
the
high
level.
Apis
and
high-level
apis
I
mean
these
things:
how
how
this
evpf
is
working,
how
it's
interacting
and,
for
example,
source
code.
D
This
main,
like
those
main,
you
know
these
main
things
which
are
doing
the
magic.
These
are
the
most
important
things
that
needs
to
be
understood
how
it
works
because
concrete
instrumentation
libraries,
these
are
just
you
know.
These
are
just
examples
that
doesn't
need
to
be
documented
as
well.
Someone
can
just
understanding
the
basics,
look
into
the
code
and
understand
them.
That's
at
least
my
experience
here.
D
E
Yeah
I
totally
agree.
I.
Think
that's
like
the
the
UPS
approach
is
a
little
bit
of
Niche
like
it's
technology-wise,
and
it's
also
using
like
a
a
feature
of
pdpfs
that
are
not
many
people
are
familiar
with
called
you
probs,
so
things
like
a
better
documentation
is
key
for
more
people
to
be
able
to
maintain
and
improve
this
approach.
I
was
wondering
you
could
not
how
like
how
did
it
work
for
the.net
Sig?
Did
you
walk
on
these
two
approaches
in
parallel,
or
you
know,
finished
one
of
them
and
then.
D
Walked
on
the
other
one,
so
we
start
with
an
approach,
but
at
some
point
we
just
made
up
the
second
approach
and
then
it
occurred
that
we
could
combine
the
combine
them
together.
So,
but
it
wasn't
like
that
that
we
know
about
the
second
Approach
at
start,
I
think
it
was
not
even
available.
It
was
I
will
simply.net
at
that
an
option
to
add
some
hooks
at
the
application
startup
which
we
could
reuse
later.
But
when
we
started
I
think
it
was
not
even
not
there
in.net.
D
E
So
maybe
we
can
do
the
same
thing
here,
so
you
know
work
in
some
bottom
way
approach
and
then
we
we
will
combine
these
two
solutions
together
at
some
point,
when
this
will
be
clearly
visible
that
we
need
to
do
that.
B
Okay,
so
I'm
gonna
say
from
that.
The
the
goal
is
to
have
the
next
Sig
meeting
give
demonstrations
of
the
two
approaches.
D
B
B
So
demo
both
projects
and
then
I'm
guessing
we
need
to
decide
on
something.
So
what
is
the
decisions?
That's
going
to
come
from
that
demo.
B
A
B
B
D
Might
be
I'm
not
sure?
Maybe
it's
not
about
demo,
but
also
about
this,
describing
what
are
the
constraints
of
the
approaches,
because
otherwise,
if
we
do
not
know
the
limitation,
it
will
be
even
hard
to
judge
which,
on
the
focus
as
the
first
one,
so
one
I
remember,
I
was
not.
I
was
one
month
on
PTO
and
I.
I
lost
a
lot
of
little
bits
of
traction,
but
I
don't
know
if
how
about,
for
example,
working
together
with
the
SDK
like
for
in
other
instrumentation
libraries
and
other
languages.
D
The
most
important
one
of
the
most
important
feature
is
to
be
able
to
like
interopolate
with
the
exist
and
have
possibility
also
to
use
manual
instrumentation
of
top
of
the
auto
instrumentation,
because
this
is
the
one
which
usually
has
the
business
logic.
Etc
often
the
project
starts
without
instrumentation
and
if,
when
people
gain
experience-
and
they
have
their
important
application,
then
start
doing
manual
instrumentation
for
the
most
important
pieces.
B
Yeah
and
I
think
that
that's
always
going
to
be
the
case,
I
think
I,
think
you're
exactly
right.
Robert
and
I
I
see
it
the
same
way
as
a
progression
of
a
user's
Journey
with
open,
telemetry
and
I.
Think
it
again,
this
kind
of
goes
back
to
that
starting
point
like
eventually
those
users
will
graduate
to
using
the
open
Trigo
project
for
direct
manual
instrumentation
that
they're
going
to
write
around
their
business
logic,
or
something
like
that
right.
B
But
this
needs
to
be
I,
think
a
really
easy
to
get
up
and
running.
Launching
point
for
for
new
users
of
open,
telemetry
and
I.
Think
that's
kind
of
the
thing
that
I'm
I'm
getting
at
is
I
would
I
definitely
think
we
have
a
great
plan
to
demo
both
of
these
applications.
B
B
Can
we
take
like
a
subset
of
one
and
and
say
that
we're
going
to
focus
on
that
in
the
next
month
or
two
and
get
that
merged
in,
and
that
is
like
a
what's
the
cliche
like
a
durable
set
of
value
right,
like
whatever
that
is,
like
a
user,
can
then
start
using
this
project
like
there?
B
There
is
going
to
be
something
that
a
user
can
do
to
Auto
instrument,
their
code
and
they're,
going
to
be
able
to
see
tracing,
maybe
even
metric
data,
but
that's
a
that's
a
whole
other
question,
probably
just
let's
just
say,
tracing
data
right
right
off
the
bat
they
can
get
tracing
data
of
their
of
their
code
without
them
having
to
manually
instrument
it
like.
B
What's
the
minimal
amount
of
a
project
that
we
can
actually
get
up
and
then
can
we
build
from
that,
I
think
is,
is
what
I
hope
our
goals
for
the
next
League
meeting
would
be
I
I
would
I
would
really.
Just
you
know,
I
think,
is
something
to
our
detriment.
B
To
say,
like
we
go
into
the
project,
we
say:
let's
choose
one
of
them
and
like
one
of
them
includes
like
at
least
you
know,
five
to
ten
of
these
small,
like
cycles
of
getting
things
actually
out,
and
we
don't
actually
provide
users
with
any
sort
of
project
for
the
next.
You
know
six
months
or
ten
months
or
something
like
that.
Like
that's,
you
know
it's
open
source,
so
maybe
that's
just
what
it
happens
but
like
I
I
would
like
to
not
do
that
like
personally
I.
B
So
I
guess
I'm.
Just
asking
is
that
something
that
we
we
think
is
possible
for
this
next
Sig
meeting
is
if
we
could
find
a
subset
of
compiled
annotations
or
the
ebpf
filtering
that
we
can
get
out
within
four
weeks,
something
like
that.
I
I,
guess
that
is
that
possible
for
people?
Do
they
see
that,
especially
for
people
who
understand
these
approaches.
E
B
Okay,
then,
both
of
those
answers
made
me
extremely
happy
and
optimistic
about
this
project.
I
think
I
think
that
that's
great
news,
okay
and
I
mean
and
honestly,
like
I-
do
want
to
make
sure
that
people
that,
on
the
call
who
haven't
seen
the
approaches
like
there
are
working
examples
of
both
and
they're.
These
These
are
projects
that
are
used
so
I
do
think
that,
like
our
cycle
time,
I
would
love
it
to
be
really
fast,
because
I
think
that
we
already
have
working
examples
to
actually
get
Incorporated.
B
I
think
the
only
other
thing
that
I
would
want
to
talk
about
is
the
security
element
right,
I.
Think
if
it's
something
that
we
need,
we
need
to
build
into
this
from
the
the
get-go,
but
I
think
that's,
maybe
also
something
we
could
talk
about
at
the
next
Sig
and
just
making
sure
that
we
have
it
clearly
documented.
B
You
know
what
are
security
policies
for
these
sort
of
its
rotation
are
going
to
be
obviously
like
we're
modified
code
base.
We're
we're
doing
something
you
know
with
EPF
filters
like.
We
want
to
make
sure
that,
like
we
provide
a
secure,
runtime
environment
for
for
users
that
are
using
this
because
I
think
is
the
only
other
thing.
I
wanted
to
talk
about.
B
B
B
B
Dinesh
is
this
okay,
yeah
thanks:
okay,
cool
yeah
and
so
set
up
sign
meeting
so
I'm
in
the
setup
of
the
Sig
meeting.
I'm
gonna
have
the
agenda
V
demo
discussion
on
MVP
and
and
maybe
even
a
breakdown
of
how
we
can
see
some.
You
know
the
next
steps
after
the
MVP.
B
D
I'm
not
sure
if
there's
something
that
you
can
which
we
want
to
discuss
during
next
segmenting
or
now
personally,
I
have
right
now
a
strong
opinion
that
this
automatic
go
open
terms
is
the
configuration
seen
as
some
Go
Go
Launcher
library
is
out
of
scope
for
for
auto
instrumentation,
because
it
people
need
to
probably
write
some
more
than
one
line
of
code.
D
B
I'm
I
just
want
to
make
sure
I
understand
because
I
think
I
agree
strongly
with
you
you're
saying
the
automatic
go
open
solution.
Sdks
configuration
should
be
out
of
scope.
Is
that
what
you're
saying
I'm.
D
B
I
I
agree,
so
I
I
I
realize
people
on
the
call.
Probably
don't
have
the
context
here,
but
yeah.
We
kind
of
talked
about
the
beginning
and
I
think
that
Josh
was
wondering
if
this
is
going
to
be
included.
I
I
definitely
agree
that
the
configuration
is
out
of
scope
for
the
initial
proposal.
B
The
long-term
solution
of
where
this
is
going
to
live,
I
I,
don't
know,
but
that
long
term
I'm
also
talking
about
like
a
year
from
now,
I
honestly
I
think
that
we
can.
We
can
probably
all
agree
that,
like
these
two
things
are
the
the
main
scope
of
this
project.
D
D
We
just
want
from
the
from
the
user
perspective
in
the
auto
instrumentation
to
not
care
where
this
code
lives.
They
we
want
just
to
have
the
possibility
that
they
can
configure
the
SDK
without
touching
the
code.
C
B
To
say
that,
let's
take
the
configuration
out
of
the
initial
scope,
I
I
can't
say
that
the
long-term
scope,
that
is
the
case
Okay
exactly.
D
D
So
in
even
in
the
dot
methodology
instrumentation,
we
even
initially
hardcoded
the
configuration
to
use
the
open
Telemetry
defaults,
like
otlp
everything
Etc,
to
make
things
easier
to
keep
off
yeah
one
question
mark
because,
regarding
the
source
code,
instrumentation,
do
you
have
do
you
know
if
you
do,
you
have
already
customers
using
it?
No
not
yet
the
problem
is
From
legal's
perspective.
D
I
know
that
a
lot
of
companies-
you
know
when
you
touch
the
source
code
and
recompile
stuff-
may
have
problems
with
with
you
know
with
licenses
Etc,
do
you
have
some
expertise
here?
Do
you
have
any
knowledge
from
your
I?
Don't
know
legal
system
or
things
like
that.
If
it's
a
problem
or
not.
E
B
So
also
Robert
on
that
one
I
think
that's
one!
That's
really
good
for
this
documentation
right
as
long
as
we
have
users
understanding
what
they're
doing
I
think.
That's
that's
fair
if
we're
saying
to
them
that
it's
going
to
be
rewriting
code
and
their
company
says
like
hey,
that's
not
good
for
us.
B
I
I
think
that
that
may
immediately
evolve
that
customer
into
writing
their
own
manual
instrumentation,
but
I
still
don't
want
to
disqualify
them
from
using
it
just
to
get
their
their
toes,
wet
I.
Think
is
a
good
way
to
do
it.
B
D
I
was
just
asking
because
indoctant
also
instrumentation,
we
see
two
use
cases.
One
use
case
is
that
people
use
the
auto
instrumentation
for
their
own
apps
and
then
there's
not
a
problem
to
add
some
stuff,
but
there's
a
second
problem
they're
using
existing
apps
that
are
written
in
some
language
and
they
just
want
to
add
and
they
lack
the
monitoring
and
they
just
use
Auto
instrumentation
to
monitor
them.
D
For
instance,
things
like
active
directory,
in.net
and
they're
just
using
how
to
instrumentation
to
as
instrumentation
so,
for
instance,
you'll
have
some
go
application
which
you
use.
For
example,
ssre.
You
do
not
have
code,
and
do
you
just
want
to
use
Auto
instrumentation
to
have
some
more
insight
there,
which
is
not
available.
E
B
Yeah
I
think
that's
a
good
point
and
again
I
think
this
kind
of
comes
back
to
this
idea
that,
as.
D
B
As
it's
communicated
to
the
user,
what
it
is,
then
they
should
be
able
to
handle
their
their
own
legal
requirements.
I.
Think
at
that
point,
but
yeah
that's
a
good
thing
to
point
out
to
make
sure
that
we
do
have
this
documented,
because
it
would
be
a
problem
if
somebody
came
in
and
just
expected
this
to
not
have
any
implications,
and
it
did
so
I
think
that's
good
foreign.
B
I've
captured
all
that
in
the
notes,
I
think
we
have
eight
minutes
left
can
I
I
was
gonna,
send
out
another
doodle
poll
for
this
next
meeting,
but
I
think
the
majority
of
the
stakeholders
are
already
on
the
call.
So
two
weeks
from
now
at
the
same
time,
would
people
be
able
to
meet
at
the
same
time.
A
B
Let
me
just
double
check:
okay
works
for
me
as
well
I'm,
seeing
a
lot
of
Thumbs
Up,
okay,
cool,
then
I
will
just
tentatively
create
the
sick
meeting
for
two
weeks
from
today.
Just
to
make
sure
I
understood
that
correctly,
that's
going
to
be
the
20th
of
September.
Okay,
awesome!
Let
me
jot
that
down.
B
Okay,
cool,
then
I
will
take
that
as
an
action
item.
It
also
means
that
we
need
to
set
up
the
Sig
through
our
community
issue,
so
wow,
something
just
went
wrong.
I
will
I'll
take
that
on
and
make
sure
that
this
dock
gets
migrated
to
whatever
the
dock.
That
opensometry
then
owns
so
cool
I
think
that
we've
made
it
through
everything
on
the
agenda,
but
there's
a
lot
still
to
go,
but
one
one
meeting
at
a
time,
so
I
will
stop
here.
B
If
there's
anything
else,
anybody
wanted
to
talk
about
open
up
the
floor.
Otherwise
we
can
jump
off.
B
Okay
with
the
level
of
excitement,
how
excited
are
everybody
so
I'm
really
excited
about
this
I
think
this
is
actually
gonna.
Yeah
we've
got
a
thumbs
up
from
Ari,
get
some
thumbs:
UPS,
yeah,
okay,
cool
that
I.
Think
that
we're
all
in
the
same
level
of
excitement
at
this
point
awesome
everyone!
Well,
thanks
for
joining
in
this
kickoff,
like
I,
said
I
will
try
to
copy
all
these
notes
as
well
to
the
new
Sig
meeting
doc,
but
also
close
out
the
initial
kickoff
issue
in
the
repo.
B
If
you
haven't
already
start
following
the
repo-
and
we
will
see
you
all
in
two
weeks,
Time
same
place
same
time.