►
From YouTube: 2022-09-21 meeting
Description
Open cncf-opentelemetry-meeting-3@cncf.io's Personal Meeting Room
B
A
My
microphone
not
working
or
yours.
What
can
you
hear
me
yeah
now
it
works.
Yep,
yeah,
yeah,
I
think
we're
good
cool
nice
to
meet.
You
hey,
I'm,
just
eating
my
lunch.
A
C
D
D
We
report
our
own
metrics
and
today,
when
we
do
that,
we
add
service
instance
ID
and
service
version,
as
as
a
resource
attributes
when
we
report
our
metrics,
but
we
don't
add
for
some
reason:
service
name,
that's
probably
an
Omission
but
I
guess
that
implies
that
collector
is
a
service
and
that's
also
how
I
understood
it
but
I
think
it's
a
valid
question
to
ask:
is
it
a
service?
Do
you
want,
if
your
account,
if
your
Telemetry
backend
shows,
has
a
viewer
that
shows
services?
D
Do
you
expect
the
collector
to
appear
there
or
it's
it's
something
special
that
should
not
be
there
right.
D
So
is
it,
is
it
I
guess?
Is
it
so
is
it?
Is
there
any
alternate
view
on
this
like
The
Collector
is
something
special
that
is
different
from
all
other
services
and
doesn't
belong
there
I
mean
my
personal
opinion.
Is
that
no
I
agree
with
bogdam
but
I
think
it's
a
valid
question
to
ask,
and
if
that's
the
case,
why
are
we
not
populating
the
service
name.
B
B
B
E
Just
I
just
added
an
agenda
item,
there's
a
bunch
of
of
issues
that
are
marked
as
discussion
needed.
Should
we
discuss
them
here.
E
I
I
don't
have
a
favorite
one
I,
just
I
know
we
have
this
label
that
we
add
to
some
issues
and
I
want
to
make
sure
we
we
look
at
them.
D
Create
a
lightweight
we're
about
to
create
a
collector
config
yeah.
This
is
an
interesting
one.
I
I
saw
it
actually.
I
saw
the
demo
of
this
I
think
it's
can
be
useful
for
for
some
people.
Some
other
people
have
different
opinion
that
this
is
unnecessary,
so
I
don't
know
I.
B
Think
I
think
we
should.
We
should
have
another
lightweight
web
app
to
Constructor
collector
with
random,
with
the
with
random
components
from
from
our
repositories.
B
D
So
I
guess
it
would
be
maybe
interesting
for
for
Pablo
who
submitted
this
issue
to
do
a
demo,
I
guess
of
what
he
built,
because
it
does
exist.
This
thing
right,
he
created
the
issue,
but
I
think
he
already
did
some
work
there.
So
to
be
to
think
that
it
would
be
useful
to
see
it.
E
D
D
It's
just
I,
guess
easier
to
use
in
a
point
and
click
function
rather
than
I
guess
answering
questions
on
the
command
line.
The
net
result
is
the
same
thing
you
get
in
the
end
the
yaml
file.
Essentially,
so,
if
there
is
an
interest
in
seeing
this,
I
can
ask
Pablo
to
see
if
what
he
has.
D
If
he's
able
to
publicly
demonstrate
it,
I
don't
know
if
he
is
I'm
guessing.
He
is
because
he
created
the
issue
here
right.
Maybe
we
can
show
it
and
then
we
decide
I'm
guessing
seeing
it
is
maybe
going
to
convince
some
people,
it's
useful
and
convince
some
others
that
it's
not
so
useful,
I,
don't
know
you
can
have
maybe
stronger
opinion
of
opinion.
After
seeing
it.
C
Yeah
yeah
I
think
there
is
a
sort
of
large
question
about
the
usability
and
user
experience
of
you
know,
building
and
deploying
a
collector
that
this
is
part
of
that
conversation,
and
you
know,
I
like
it
involves
documentation.
It
involves
whether
the
tooling
is
adequate.
C
I
mean
like
right
now
using
OCB,
you
kind
of
need
to
be
not
only
you
know,
interested
in
collector,
but
reasonably
competent
with
go
to
even
consider
building
the
thing
using
that
tool
and,
and
so
like
I,
feel
like
we
ought
to
have
this
conversation
about
making
the
user
experience
of
this
better
and
whether
that's
part
of
the
collector
itself
or
just
a
link
off
to
a
place
where
you
go.
D
Yeah
I
think
there's
definitely
definitely
going
to
be
a
subset
of
users
who
would
really
love
to
have
this
sort
of
a
UI
where
you
build
the
the
config
right
instead
of
having
sort
of
going
into
digging
into
the
gold
code
in
some
cases,
or
even
if
there
is
a
good
readme
file
for
the
component,
the
best
of
the
cases,
but
sometimes
the
reason.
So
you
really
have
to
go
and
read
and
understand
the
the
competing
the
in
the
component
itself.
It's
just
probably
not
for
everyone.
B
Yeah
I
think
I
think
we'll
be
super.
Cool
can
be
built
outside
of
our
repo
for
sure,
I,
I
think
I
think
there
are
cool
things
we
have
that
we
have
that
command
to
generate
documentation
for
based
on
the
config
comments
and
stuff
I.
Think
a
combination
of
reflection
on
the
configs
for
every
component
and
and
whenever
people
are
writing
things,
we
can
display
them.
The
the
Go
Dog
of
that
field
and
and
stuff
like
that
and
I
think
we'll
make
it
a
cool
feature.
D
Yeah
makes
sense,
I
don't
have
a
strong
opinion
about
the
location
where
this
leaves,
but
if
we
want
something
like
this,
then
I
think
there
is
probably
at
least
some
portion
of
responsibility
on
us
as
maintainers
of
the
collectible
in
some
way
to
to
maybe
maintain
it.
I
don't
know
because
it
probably
can
can
live
completely
detached
from
The
Collector.
It
uses
it
uses
reflection
at
runtime
to
understand
what
the
configurations
of
the
components
are
so
I
guess
there
is.
D
B
D
D
D
A
I
wonder
how
much
of
this
is
just
like
people
struggle
with
the
ammo
versus
like
people
struggle
with
configuring,
the
yaml
for
the
open,
Telemetry
collector
and
then
additionally
like
how
much
of
it
can
really
be
like
how
much
of
it
is
really
invalid
configuration
rather
than
just
messing
up
the
regex
in
in
some
field,
or
something
like
that,
so
yeah
I,
don't
you
know
I'm
kind
of
dubious
about
the
effectiveness
of
this
and,
like
I,
think
the
devil's
in
the
details
with
like.
If
you
are
going
to
get
into
validation
like?
A
Are
we
really
don't
value
validate
like
tql
or
whatever?
It's
called?
We
change
the
name,
but
whatever
the
thing
is
that
word
on
a
call
our
transform
language
or,
like
you
know
it
just
becomes
it
just
feels
like
a
rabbit
hole
with
relatively
low
Roi,
whereas
I
feel
like
yaml
configuration
validation
like
just
like
yaml
me,
sorry,
ottl,
Hotel,
Ott
hotel
is
anyway
just
validating.
Yaml
itself
is
like
in
Maya's
Mission,
like
95
of
the
problems
with
yaml
configuration
issues,
not
specific
poetry,
but
yeah
I'd
be
curious
to
see
a
demo.
D
I
guess
you
have
a
good
point
there
right.
So
if,
if
I
need
to
write
what
is
a
TTL
or
ottl
inside
a
yaml,
no
tool
is
going
to
validate
that
what
I
wrote
the
the
in
that
language
is
actually
correct.
Right.
No,
no
I,
guess
generic
yaml
validation
tool
is
able
to
do
that,
whereas
a
purpose
built
tool
can
do
this
right.
If
it's
purpose
build
it
understands
the
language,
the
TPL,
then
it
can
do
that
for
me
as
well.
D
A
Yeah
I
mean
I,
think
not
terrible
I
think
we
should
move
on
but
like
because
it
seems
like
the
next
step
is
pretty
clear.
Would
you
like
to
show
a
demo
of
it
and
we'll
see
if
we
can
go
people?
Can
the
folks
here
who
contribute
and
maintain
the
collector
can
can
make
estimations
around?
It
is
like
for
me.
The
thing
that
was
challenging
was
actually
like,
generating
load
like
spans
in
a
certain
format
to
send
to
a
collector
to
validate
like
my
pipeline
was
CH.
A
You
know,
I
know
AWS
had
like
a
light
tool
around
it,
but,
like
you
know
that
was
challenging.
I
think
a
point-and-click
interface
for
generating
spans
would
be
you
know.
I
realized
we
were
talking
about
more
than
spans
would
be
more
valuable
than
config
validation,
but
I'm
glad
someone's
interested
in
the
stuff
and
look
forward
to
seeing
a
demo.
F
I'm
here,
I
just
wanted
to
bring
up
this
issue.
I
I
opened
it
in
March
and
I'm
we're
still
interested
in
it,
but
we
haven't
had
time
to
look
at
it
again
since
then,
since
we
patched
up
the
problem
a
different
way,
but
basically
the
issues
that
we
wanted
a
way
for
the
scraper
to
not
always
have
to
log
error
if
it
encounters
errors.
F
Basically,
we
were
seeing
scenarios
where
something
like
the
host
metrics
process,
scraper,
which
would
scrape
all
the
processes
and
the
kernel
thread
like
things
like
kernel
threads
or
like
the
registry
process
on
Windows,
it
would
read
and
fail.
It
would
fail
that
every
time
it
always
log
and
error,
and
that
became
incredibly
noisy.
F
We
found
our
own
way
to
to
silence
that,
and
so
this
hasn't
been
as
much
of
a
problem
for
us
recently,
but
it's.
We
still
think
it
would
be
good
to
try
and
solve
this
at
a
lower
level.
F
Since
I
can't
imagine
we're
the
only
people
running
into
stuff,
like
that,
I
think
the
original
idea
I
had
in
the
issue
was
lightly
rejected,
I,
guess
they're
people
who
were
interested
in
a
different
way
of
doing
it
or
solving
it
for
all
components,
instead
of
just
scrapers
and
so
I
wanted
to
touch
base
with
folks
in
the
group
who
might
also
be
interested
in
this
or
see
how
we
might
be
able
to
move
this
forward.
D
I,
like
the
suggestion
that
Josh
has
there,
where
you
essentially
heavily
sampled
right
based
on
the
call
site,
you
know
maybe
record
it
once
and
then,
and
maybe
once
a
minute
or
once
an
hour
after
that.
Maybe
something
like
that.
We
record
how
many
occurrences
of
that
same
load,
message
that
were
and
I
do
agree
that
it
could
be
very
valuable
to
provide
this
as
a
library
or
as
a
service
to
all
of
the
components
to
use,
because
it's
a
danger
that
every
other
components
may
start
doing
this
right,
flooding
the
logs.
F
This
yeah,
so
I've,
been
I've,
been
experimenting
with
something
on
our
distribution
of
The
Collector,
where
there's
a
a
new
zap
core.
F
That
will
it's
it's
kind
of
silly,
because
it's
kind
of
re-implementing
sampling,
but
it
will,
it
will
see
the
like,
where
certain
things
are
getting
logged
most
often
than
we
will
like
back
them
off
or
throttle
them
if
they,
if
they've,
been
logged
like
three
times
in
a
certain
amount
of
time
and
then
remove
them
from
that
from
like
a
back
off
cache
after
it's
been
a
certain
amount
of
time
since
the
last
time
it
was
logged,
it's
still
very
early
days
and
we're
not
even
sure,
necessarily
that's
the
way
we
want
to
end
up
going
and
the
other
things.
F
The
the
zap
blogger
also
has
us
like
a
sampling
config,
but
it
seems
like
we
might
need
a
bit
more
flexibility
than
just
being
able
to
change
that
sampling
config.
F
So
something
like
a
like
a
zap
core
that
others
might
be
able
to
benefit
from
could
be
something
here.
I'm
I'm
I
haven't
really
thought
about
trying
to
make
it
work
outside
of
our
use
cases.
Yet,
though,
I
don't
know,
if
that's
sort
of
what
you
had
in
mind
like
a
zap
core
or
something
along
those
lines,
buttons.
D
F
And
it's
configured
as
like
when,
when
you
make
a
new
collector
service
in
like
your
own,
like
in
our
distribution,
when
we
make
a
collector
service,
you
can
pass
in
zap
options
that
get
configured
and
it's
kind
of
just
like
wrapping
a
core
over
and
over
again
until
to
give
custom
functionality
to
zap
to
the
to
the
internal
logger
of
The
Collector.
D
Yeah
I
think
this
requires
a
bit
more
thought
and
some
sort
of
maybe
design,
for
example.
Maybe
so
at
startup
time
it
is
more
likely
that
I
would
prefer
not
to
have
sampling,
even
if
it's
so
I
would
want
to
see
all
their
messages,
even
if
they
they
come
from
the
same
cool
side,
whereas
after
the
startup
I,
probably
would
prefer
them
to
be
suppressed
if
they
they
are
emitted
repeatedly.
D
So
all
I'm
saying
is
the
logic,
may
not
be
as
simple
as
just
just
look
at
the
cool
side
and
and
the
frequency
that
that
pull
side,
outputs
and
and
do
some
sampling.
Maybe
there
is
there's
a
bit
more
intelligence
necessary
there,
or
maybe
the
call
side
needs
to
hint
about
what
is
it
doing
of
the
importance
of
the
thing
that
it
is
doing
or
maybe
based
on
the
level
of
the
log
right?
D
So
maybe
we
don't
suppress
this
for
errors,
but
we
do
it
for
foreign,
something
like
this,
so
yeah,
I
I,
think
there's
a
number
of
options
here
possible.
So
there
needs
to
be
some
sort
of
lightweight
design
here.
Somebody
needs
to
Think
Through
the
implications
and
post,
maybe
a
quick
talk
and
put
together
a
document
that
explains
how
this
all
works.
F
I'll
bring
that
I'll
bring
that
back.
We
might
be
able
to
do
something.
The
problem
is
I'm
I'm,
not
like
a
heavy
collector
maintainer
at
the
time
at
this
time.
That
may
change
in
the
future.
But
it's
hard
for
me
to
know
all
the
different
kinds
of
concerns.
So
if
there
is
someone
who's
more
experienced,
maintaining
The
Collector,
who
would
be
willing
to
collaborate
on
it,
I
would
definitely
be
receptive
to
that.
C
So
I
just
put
a
link
to
a
repository
that
we
have
at
honeycomb,
which
is
our
implementations
of
a
set
of
different
kinds
of
Samplers,
including
Dynamic,
Samplers
and
and
exponential
Dynamic
sampler
that
can
be
used.
You
can
give
it
a
set
of
keys
that
you
wanted
to
filter
on
and
it
will,
you
know,
try
to
maintain
sampling
rates
based
on
on
you
know
the
the
rate
of
data
that's
coming
through,
so
that
you're
always
going
to
get.
C
You
know
some
of
the
rare
events
and
many
feet,
many
less
of
the
not
rare
events
anyway.
That
may
help
to
educate
your
decisions.
What
you're
doing
there
there's
there's
there's
a
bunch
of
stuff
there
that's
operating
at
scale
within
honeycomb
now,
so
you
know
feel
free
to
leverage
those
ideas
or
reuse,
the
repository
or
whatever
you
need.
F
Yeah,
thank
you.
I've
started
that
I'll
make
sure
I
take
a
look
at
it.
I
appreciate
that.
Thank
you.
D
F
Yeah
back
back
when
I
posted
it
Dimitri
from
Splunk
said
that
he
was
interested
in
in
tackling
it.
But
I
haven't
heard
from
from
him
since
on
this,
so
we
could
probably
Market
his
health
wanted
or
maybe
talk
to
him
if,
if
possible
and
see,
if
he's
still
interested.