►
From YouTube: 2023-02-15 meeting
Description
Open cncf-opentelemetry-meeting-3@cncf.io's Personal Meeting Room
A
B
B
So
it
looks
like
you
just
got
a
page
from
Dimitri:
that's
going
to
be
late
bugged
in
as
well
by
20-30
minutes,
so
we
should
probably
we
can.
We
can
go
through
some
items
if
you
like
and
we
think
that
needs
to
wait
for
them.
Let
me
know.
B
Hey
everybody
again
so
Dimitri
and
bugdon
will
relate
to
speaking
the
the
busiest
where
I'm
not
sure.
What's
up
but
they're
going
to
be
late
by
20
to
30
minutes
so
they've.
Let
me
know
about
this,
and
it
said
that
Alex,
if
you
wouldn't
mind
reading
it
would
be
awesome.
C
Yeah
no
words:
okay,
I
guess
we
can
get
started,
is
Evan
already
here.
Yep
yep.
E
All
right
so,
basically
we're
looking
to
redo
how
OTL
function
factories
are
defined.
We
want
to
Define
an
interface
right
now
you
get
the
DSL
function,
signature
through
a
go
function,
so
you
take
the
go
function,
signature
and
just
map
it
directly
to
the
DSL.
This
has
some
limitations,
so
we're
looking
to
instead
implement
the
function
factories
as
interfaces
we're
basically
looking
for
input
on
how
this
works.
E
Field
order
is
important
to
structs,
so
we
can
depend
on
that
to
define
the
function.
Signature.
The
downside
is
that's
kind
of
weird
I.
Don't
think
that
it's,
you
know
a
commonly
known
fact
that
goes
not
going
to
rearrange
the
field
order
on
compilation.
The
upside
is
it's
very
like
it's
usable
so
through
or
when.
So,
if
you
define
an
argument,
struct
on
a
factor
you'll
be
able
to
use
an
optional
interfaces,
and
things
like
that
read
the
issue
for
more
I.
Don't
want
to
go
into
it
too
much.
The
opposite.
E
End,
though,
is
that
we
continue
to
use
function
signatures.
This
does
have
some
downsides,
namely
we
need
to
use
reflection
a
lot,
but
overall,
what
we're
looking
to
do
is
we're
looking
to
allow
factories
to
implement
optional
interfaces.
So
the
goal
is
that
if
we
have
functionality
that
a
factory
wants
to
implement
in
the
future
we'll
be
able
to
provide
an
interface
and
do
that
in
a
non-breaking
and
optional
way,
and
additionally,
I
just
provide
some
default
function
default
function,
arguments
so
anything
that
basically
every
function
should
have
so
yeah.
E
Take
a
look
at
the
common
I
have
there
are
other.
There
are
other
things
in
that
thread,
but
overall
the
thread's,
pretty
big,
so
I
just
want
to
summarize
it
there
but
yeah.
If
anybody
has
any
input
in
this
call
or
on
the
issue,
it'd
be
welcome.
F
E
So
it's
part
of
the
specification,
so
the
specification
is
so
for
the
type
identity
of
a
struct
for
it
to
be.
You
know
for
two
structs
to
be
equal.
They
have
to
have
the
same
field
ordering
if
you
define
a
second
struct
with
a
different
field
ordering
it
is
a
different
struct.
G
I
I
believe
that,
in
my
heart
and
I
also
agree
with
Anthony
that
it
feels
weird
so
yeah
I
I
put
my
thoughts
out
on
the
issue
as
well,
so
like
I,
compelling
Arguments
for
the
struct
I
think
it
it
reduces
an
amount
of
Border
plate
versus
the
solution,
I've
coded
up
but
yeah.
It
just
feels
nice.
This.
G
To
the
end,
user
discussion
has
no
impact
to
the
user,
writing
ottl
statements
and
transform
processor,
routing,
processor,
filter
process
or
anything
in
the
future.
It
does
have
an
impact
on
users
who
would
like
to
contribute
a
function
to
the
project
or
any
individuals
who
are
using
ottl
in
custom
components.
This
is
an
API
change
only.
E
G
E
G
When
it
comes
to
optional
interfaces
and
then
your
question
of
what
would
be
an
optional
interface
I,
really
like
the
idea
of
allowing
a
way
for
the
functions
to
identify
themselves
today
we
have
function
names
and
you
could
in
in
the
filter
processor
you
could
use,
you
know,
function
a
and
you
could
call
it
whatever
you
wanted
and
then
transform
function.
Processor.
You
could
use
the
same
function
and
call
it
something
completely
different.
G
It's
actually
nothing
enforcing
the
similarity
between
the
functions
and
different
processes
right
now,
except
for
the
fact
that
we
have
done
it
ourselves.
So
I
like
the
idea
of
using
the
function
interfaces
to
enforce
some
sort
of
this
is
what
I'm
named,
and
this
is
what
I
should
be
referenced
as
in
the
DSL
I.
I
would
definitely
want
to
add
that
to
the
to
this
interface.
G
I
I
G
I
E
Was
going
to
say
what
would
what's
the
sort
of
interface
that
only
some
functions
would
want
to
implement
I
mean
we
want
to
say,
like
this
function
is
thread
safe
or
this
function?
Has
you
know
X
capability
like
it
seems
like
there
should
be
some
or
maybe
at
a
different
component
level.
Your
component
can
Implement
something
the
Otto
could
handle
that.
G
E
Bogdan
you
open
the
issue.
Do
you
have
any
thoughts.
J
J
J
J
Let's
say
more
flexibility
in
the
future,
plus
more
being
a
bit
more
types,
if
possible,.
G
One
thing
I
like
with
the
with
the
Factory
is
we
can
start
passing
in
a
standard
struct.
That
represents
like
the
extra
arguments
that
we
expect
to
have
like
Telemetry
settings
and
context
and
that'll
allow
us
to
remove
the
extra
like
DSL
indexing
in
our
parsing,
which
would
be
nice
and
then
that
can
grow
pretty
easily
versus
having
to
grow.
The
parsers
interpretation
of
like
the
index
that
we're
on
so.
I
J
That's
really
nice,
that's
that's
nice
that
we
can
pass
some
standard
arguments
and
then
have
a
physical
thing.
Maybe
the
factory
signature
would
look
like
something
fixed
and
then
you
have
a
settings
for
for
every,
for
every
function
in
that
settings
is
the
one
that
we
do
reflection
and
all
the
magic
that
we
right
now
do.
But
we
limit
to
a
very
small
part,
and
we
do
it
standard
way.
G
And
Evan's
actually
done
a
lot
of
work
with
like
what
that
can
look
like,
and
it's
coming
out
well,
I
think
I
think
our
takeaway
today
is
to
to
experiment
with
tags
to
define
the
order
of
the
structs
parameters.
I
think
that's
kind
of
like
the
last
piece
once
that's
in
place,
I
think
we
can
actually
move
forward
on
this.
So
thank
you
for
that
idea.
Anthony.
G
Right,
I
open
an
issue
or
not
an
issue,
opening
a
PR
without
an
issue
earlier
this
week
around
starting
to
deprecate,
non-ttl
configuration
in
the
filter,
processor
and
rightfully
so.
I
was
called
out
for
not
having
a
lot
of
details
on
why
I
was
doing
that.
So
I
wrote
up
a
really
big
issue
about
a
filter
process
specifically
and
then
I
wrote
up
a
bigger
issue
about
ottl
and
the
transform
processor.
G
We
can
talk
about
I.
Guess
it's
all
kind
of
related,
but
I
think
the
question
today
is:
how
does
the
community
feel
about
deprecating
non-octl
filter
configurations
options
in
the
filter?
Processor,
specifically,
let's
just
talk
about
the
build
processor
for
a
second
and,
most
importantly,
what
should
the
timeline
for
that
deprecation?
Look
like
how
long
do
we
want
to
give
users
to
transport
transfer
their
configuration.
I
J
Will
know
no
longer
using
that?
That's
that's
one
thing
second
thing
is
about
configuration,
I,
think,
I
think
there
we
should
first,
we
should
have
a
a
feature
gate
that
initially
we
put
it
in.
J
Let's
say
we
put
it
in
Alpha
or
we
can
put
it
in
better
later
with
a
mindset
that,
if
you
configure
any
of
these
will
fail-
and
you
have
to
set
the
feature
gate
in
order
to
continue
to
use
this
so
so
essentially,
instead
of
removing
that
one
immediately,
we
better
re,
remove
them
in
a
way
that
we
start
failing.
If
you
have
that,
but
but
these.
J
G
J
Yeah
I
think,
but
but
that
should
be
probably
later
so
we
should
just
for
the
moment,
start
with
logging
warning
in
let's
say
in
two
versions:
We
put
this
feature
gate
that
crashes.
Unless
you
put
this
you,
unless
you
enable
this
feature
gate
and
then
later
we
we
remove
it
completely.
I.
G
Could
go
the
op
like
I
could
do
the
opposite
with
the
feature.
Gate
and
I
could
I
could
add
a
feature
gate
where
it's
enabled
by
default
and
the
like.
It
also
will
log
out
like
hey.
This
is
deprecated
and
then
in
the
future,
when
we
upgrade
it
to
Beta,
it
would
be
off
by
default
and
you
would
have
to
enable
it
if
you
wanted
to
use
the
old
config
options.
Yeah.
J
It's
it's
I,
it's
implementation,
it
is
for
me
the
the
most
important
part
is
for
few
for
a
couple
of
versions:
We
log
error
for
another
couple
of
versions:
We
we
entered
without
a
flag
or
without
something
like
that,
and
then
after
some
versions,
We
we
remove
it
completely
and
that's
it.
That's
that's
the
the
timeline
that
I
would
see.
G
Okay,
follow-up
or
not
follow-up
question
additional
questions
on.
That
is
what
what
support
should
we
provide
users
to
transfer
the
config,
and
this
is
this-
is
kind
of
a
larger
question
of
of
conditions
with
ottl
and
The
Collector
as
a
whole?
Do
we
want
to
provide
documentation
that
helps
convert?
You
know
one
to
one
if
you're
using
these
filter
configurations-
and
this
is
exactly
what
it
looks
like
in
ottl,
okay,.
J
J
So
I
I
really
I
what
I
was
trying
to
do
actually
was
essentially
remove
all
the
logic
from
this
drugs
and
essentially
have
a
have
only
one
method:
two
or
TTL
that
will
generate
ottl.
So
this
is
on
us
a
bit
to
implement
okay.
So
so,
if
we
have
instead
of
the
logic
of
filtering
or
or
applying
these
conditions,
we
just
have
a
two
ottl
thing
that
generates
the
string
now,
the
implementation.
G
J
What
I
was
thinking
with
that,
like
I?
Do
I
I
hit
two
things
in
the
same
time
like
one
I,
remove
the
logic
and
move
the
logic
to
ottl,
but
second
I
also
tell
the
user.
Hey
here
is
the
config
and
then
once
we
have
this,
we
can
even
build
something
like
a
standalone
tool
that
transforms
a
config
if
we
want,
but
I
think
we
need
this
anyway.
First
first
thing
for.
J
This
converter
from
from
one
to
another
and
then
and
then
yeah,
that's
that's
what
I.
G
Think
I
think
that
is
definitely
doable.
Do
you
think
that
that's
a
requirement
before
we
put
a
PR
PR
out
there
that
starts
logging
that
hey
these
config
stuff
is
deprecated
and
I.
J
G
J
J
Then
then
later
we
can
build
this
tool
with
conf
map,
converters
and
stuff
like
that.
But
before
doing
that,
I
think
just
printing.
The
log
is
is
an
awesome
step
to
to
to
this.
G
Okay,
I
will
look
into
that
when
I
can
I'll,
probably
close
to
the
pr
now
with
comments
on
what
direction
we're
gonna
go.
Yeah
I'll
look
into
what
that
conversion
is
like
programmatically,
okay,.
A
I
have
a
question
here:
Tyler
you
mentioned
that
there's
an
idea
that
the
the
ottldsl
can
be
scary,
and
maybe
it
would
be
worth
to
expose
users
to
a
simpler
interface,
but
is
that
even
an
option
are
we
should
we
be
discussing
it?
I
mean
I
think
it
would
be
worthwhile.
G
It
it
is
possible
I've
written
a
PR
for
it
before,
although
things
have
matured
since
since
that
original
PR
it
it's
definitely
like
the
behind
the
scenes.
The
grammar
is
ends
up
just
being
struck
anyways,
like
the
interpretation,
so
like
it's
pretty
natural
to
get
things
into
that
declarative,
struct
format
we
just
it's,
really
really
verbose.
If
you
were
to
use
the
underlying
grammar
structs
themselves
as
the
config,
so
we
will
need
something.
G
G
It
sounds
like
it's
a
way
to
convert
it's
an
interface
to
convert
between
one
config
style
to
another
I
bargain.
Is
that,
like
a
is
there
anything
using
it
today?
Do
we
have
any
examples.
J
We
can
we
can
I
can
show
you
how
this
can
be
used.
Splunk
has
couple
of
examples
inside
that
is.
J
So
so,
essentially,
we
have
two
solutions
here,
and
one
of
them
is
that
one,
the
other
one
is,
is
implementing
a
custom
and
modular
on
the
config
so
and
and
I
think
the
contribute
went
more
towards
that
direction.
It's
plugged
the
other
opposite
now.
J
The
the
conf
map
thing
is
interest
is
good,
since
if
you
are
a
distribution
and
you
wanna,
you
wanna
maintain
it
for
a
longer
a
longer
time,
assuming,
for
example,
contribute
remove
that
support,
but
me
as
a
distribution
Splunk,
we
still
want
to
support
that.
I
cannot
override
that
on
Marshall
function
inside
contribute,
so
I.
J
G
G
Internal
stuff,
yeah,
okay,
sweet
and
I
do
think
that
if
we
do
go
forward
with
some
sort
of
declarative
syntax
as
an
option
for
ottl,
that
would
be
a
permanent
thing
that
would
like,
as
the
grammar
evolves,
that
syntax
would
need
to
evolve
with
the
with
the
grammar,
so
I
think
there's
a
lot
of
people
that
would
like
the
declarative,
syntax
there.
That
was
in
the
original
processing
dock
that
was
written
up
for
this
like
whole
concept.
That's
that
goes
and
lives
in
collector
core
right
now.
G
I
think
there
was
a
lot
of
discussion
on
it
that
I
remember
correctly,
like
reading
through
when
I
first
started
doing
this
stuff.
It
wasn't
like
hasn't
moved
forward
yet,
but
I
do
think
that
people
are
interested
in
that,
or
at
least
they
were
in
the
past.
People
are
love
the
SQL
syntax
and
just
like
don't
want
to
deal
with
a
declarative
syntax.
Then
we
don't
have
to
deal
with
it,
but
I
do
agree
that
some
people
would
prefer
that
style,
and
so
it's
probably
going
to
be
valuable
to
support.
A
So
yeah
my
concern
when
I
asked
was
that
if
we
start
deprecating
the
current
filter
processors,
normal
detail,
configuration
then
it's
like.
Maybe
we
should
first
think
whether
we
want
to
provide
another
style
of
configuration
other
than
ottl
and
then
either
the
filter.
Processor
current
config
will
fit
into
that
or
not.
Why.
I
H
I'm
not
sure
it
is
necessarily
easier.
Certainly
I
see
people
trying
to
do
configurations
like
this,
and
they
make
a
lot
of
mistakes
mostly
having
to
do
with
indentation
and
things
not
belong
hitting
where
they
belong.
H
H
You
know
a
a
SQL
like
syntax
in
my
view,
is
preferable,
but
I
also
think
I
think
that
if
we
are
gonna
do
multiple
ways
of
specifying
it,
we
should
make
sure
that,
like
one
derives
from
the
other
or
that
they,
you
know,
there's
an
automated
way
to
convert
between
them
that
we
can
test,
because
we
certainly
don't
want
the
semantics
to
drift.
Yeah.
J
And
we
certainly
don't
want
to
have
two
different
I
mean
I
would
rather
stop
ourselves
on
releasing
yet
another
way
of
of
doing
things,
because
we
are
just
trying
to
consolidate
on
one
thing
and
now
we
are
just
discussing
about
yet
another
one
Andre
as
much
as
I,
like
your
proposal,
I
would
tend
to
say
no
on
this
until
we
have
a
very
strong
argument
to
have
another
way,
so
so
that.
G
Issues
out
there
for
anyone
wants
to
comment
on
it
and
and
push
it
forwards
there
that
she's
been
out
there
for
a
long
time,
I
think
since
May
or
June.
So
if
anyone's
interested
in
declarative
syntaxis
there
I
will
say
that
at
honeycomb
we've
got
an
open
source
tool
called
Refinery
where
there's
a
rules
engine
in
there
and
the
configuration
is
in
the
ammo,
and
so
you
specify
left
operator
right
and
all
that
kind
of
stuff
and
users
do
get
that
wrong.
Sometimes
and
there's
other
implications
with
type
and
stuff
like
that.
G
G
Time,
maybe
not
I
I
do
have
comfort
in
the
fact
that
when
users
ask
about
ottl
and
they
do
ask
I
could
improve
the
docs
I,
don't
I,
don't
get
repeat
asks
so
like
once
a
user
has
started
understanding
the
syntax
I,
don't
see
the
same
users
coming
back
and
asking
for
more
clarifications
on
things.
So
that's
that
seems
like
good
edification,
but
it
could
also
be
they
find
someone
else
to
ask
and
I'm
just
ignorant
so
I
don't
know.
A
C
Yep
Evan
it's
next
in
line.
C
E
Yep,
this
is
a
Pierre
I've
had
out
for
a
while
on
all
my
extensions
to
access
the
effective
configuration
of
The
Collector.
So
this
is,
after
all,
of
the
config
providers
have
run
getting
basically
the
the
expanded
the
ammo
as
it
were,
providing
it
to
an
extension
mainly
for
op
amp
to
report.
You
know
what
is
the
collector
running
to
the
server
there's
just
a
couple
of
contention
points
here.
That
would
be
good
to
get
across.
Basically
it's.
E
How
do
you
provide
from
the
config
provider
the
like
a
serialized
or
serializable
version
of
the
collector's
config
I?
Think
that's
the
last
kind
of
point
we
need
to
iron
out,
so
I
just
wanted
to
bring
that
up
either
for
discussion
or
either
here
or
on
the
pr.
J
Ick
I
even
I
mean
you
responded
for
at
least
five
days
ago.
Sorry,
this
week
was
crazy
for
me,
with
promo
on
my
side.
I
have
a
lot
of
promo
committees
and
stuff
in
in
Splunk,
so
I'll
I'll
just
respond
to
to
that
I
mean
I'm,
sorry
that
it
took
five
days
but
I
don't
know
if
I
have
an
answer
for
you.
I
haven't
checked
your
responses.
There.
E
Oh
good,
just
making
sure
it's
moving
along
they're
we're
getting
some
questions
on
trying
to
move
up
and
alongside
I,
just
want
to
make
sure
that
we're
not
blocked
on
anything.
E
Subsequently,
the
the
other
one
was
on
getting
the
basically
any
kind
of
like
resource
attributes
for
Telemetry
two
extensions
kind
of
for
the
same
purpose.
We
can
either
add
a
an
interface
onto
the
host
for
extensions
to
I,
guess:
query
this
essentially
or
we
could
add
it
to
the
component-
the
creation
settings,
if
we
have
a
preference
on
that
I
think
that
might
set
some
direction.
J
It
is
a
bit
of
continue.
J
Resource
sees
are
some
telemetry
specific
things
so
far
and
the
problem
that
you
are
asking
for
them
for
for
non-telemetry
reasons,
because
we
expose
them
into
the
providers
that
we
have.
We
have
a
meter
provider,
we
have
a
trace,
Tracer
provider.
We
have
all
these
providers
that
are
already
configured
with
the
right
resources,
so
I'm
struggling
a
bit
to
understand
why
it's
a
need
to
access
the
resource
and,
for
example,
if
we,
if
we
allow
users
to
set
up
Auto
detectors
for
resource,
do
you
need
access
to
those?
J
E
So
I
don't
know
that
I'd
be
able
to
answer
that
right
now.
It
does
seem,
though,
that
we
should
be
able
to
share
that
with
the
sdks
I
believe
that
those
should
be
passable
to
those,
and
so
everything
can
share
the
same
IDs.
But
if
that's
not
clear,
I
will
do
a
little
bit
of
looking
into
that
and
get
back
to
you
on
the
issue.
J
Yeah,
so
so
for
me,
it's
not
clear.
There
is
a
way
we
allow
people
to
add
more
resource
things
and
I.
Think
that's
what
you
need,
but
but
there
are
other
things
in
the
resource
that
we
may
have.
We
may
configure
like,
for
example,
the
auto
go.
Has
this
this
environment
variable
that
accepts
extra
resource
things
which
will
get
configured
automatically
to
the
auto
libraries?
J
So
yeah
that's
I,
mean
I.
Think
what
you
actually
need
is
that
instance
ID
that
we
generate.
If
not
none
is
provided.
That's
that's
exact.
That's
actually
what
you
need
and
I
think.
If
that's
the
only
thing
you
need,
maybe
we
find
a
way
to
expose
that
or
share
that
with
with
something
but
not
like,
like
asking
for
the
entire
resource
you
have
to
to
fix
all
these
use
cases
like
all
these
edge
cases.
J
C
Good,
thank
you
based
on
reading
the
the
op
amps
back
and
the
issue
it
does
seem
like
what's
really
required
here
is
service
information
rather
than
resource
information.
J
C
J
I
B
B
There
was
a
to-do
comments
in
in
the
code
today
we
should
just
you
know,
make
sure
to
sing
the
logger
before
we
stood
down
and
when
I
I
was
going
to
work
on
that
so
on
that
area
of
the
code,
so
I
started
working
on
this
and
I
realized
that
in
the
test
started
to
film.
B
The
reason
for
that
is,
if
you
try
to
sync
your
logger
in
your
in
a
non-ttwa
process,
you
don't
get
access
to
stdr
and
then
all
of
a
sudden
that
all
the
tests
are
there
start
to
fail
because
we're
running
a
number
of
them
so
because
of
that
I
added
another
option
to
the
logging
levels
that
it
now
accepts
a
non-value
that
then
allows
you
to
shut
off
entirely
login.
B
So
that's
a
change
in
public
API
as
both
in
commented
and
then
I'm.
Not
sure.
Are
we
doing
this?
Yes,
for.
J
Me
for
me,
there
are
a
couple
of
problems
here
with
this.
First
of
all,
we
are
inventing
a
new,
a
new
level
that
zap
doesn't
have,
so
we
are
deriving
from
their
config,
which
I'm
not
necessarily
comfortable
with,
but
second
and
more
important
is
or
can
be
done.
J
I,
don't
know
Anthony
with
that,
but
the
second
problem
for
me
is:
we
have
another
level
in
this
Telemetry
level
and
I
want
I,
don't
want
to
add
yet
another
level
on
our
side,
so
so
I
think
we
should
probably
look
into
consolidate
all
these
levels
that
we
have.
You
can
look
into
config,
slash,
config,
Telemetry,
I
think
is
called
and
we
have
a
level
there
as
well.
J
Maybe
get
rid
of
I,
don't
know,
but
somebody
has
to
propose
to
give
me
a
solution
where
we
don't
add
yet
another
level
per
or
if
that's
the
case.
We,
because
that
level
we
use
it
in
metrics
and
none
is
for
disabling
that,
but
is
not
for
here,
like
I
I,
don't
know,
I
I
just
need
a
solution
where,
where
I'm
not
gonna
have
10
levels
in
the
configuration.
J
I'm
not
saying
I'm
just
saying
that
somebody
has
to
give
me
a
story
across
that
that
takes
care
of
all
these
levels
and
tell
me
what
will
be
the
user
story
in
in
three
months?
Do
they
have
to
configure
10
levels?
Is
it
going
to
be
just
one
level
to
disable
all
Telemetry?
What's
what's
the
story
for
us
like,
we
are
just
keep
adding
new
levels
and
I.
B
Yeah
I
have
a
view
of
the
of
the
in-game
for
sure.
I'll
agree
with
that
I'm
just
trying
to
get
by
on
making
sure
we
got
the
Deferred
sync
done
so
sure.
J
Maybe
maybe
maybe
we
can
use
that
level,
none
if
it's
configured
To
None
to
disable
this
I
don't
know
just
come
up.
J
B
F
B
J
The
the
the
to
trace
the
the
they
do
apply
because
you
can
have
in
the
span.
You
can
annotate
the
span
with
different
things
and
based
on
the
level
you
can
annotate
more
or
less,
but.
F
Basically,
he
was
reading
the
trace
log
level,
not
tracing
as
a
signal
but
I
think
in
tracing
the
the
control
you
have
over.
Verbosity
is
sampling
in
logging.
It's
the
log
level
in
metrics.
It's
what
aggregation
do
you
do?
Do
you
drop
labels
or
not
they're,
very
different
domains
and
have
different
ways
of
controlling
verbosity.
D
B
Level
discussion
or
thanks:
okay,.
B
J
Was
needed
for
those
tests
right,
but
but
let
me
explain
the
other
thing
in
all
these.
The
other
signals,
the
knobs
that
you
have
let's
say,
sampling
in
metric
in
tracing
or
aggregations
in
in
metrics,
are
not
completely
disabling
things.
Maybe
maybe
maybe
if
you
want
to
completely
disable
things
and
initialize
with
a
knob
there.
Maybe
the
the
the
right
thing
is
to
add
the
configuration
saying,
disable
or
enable.
J
J
B
All
right
that
sounds
like
a
good
approach:
okay,
I'll,
look
into
that.
The
second
PR
is
about
adding
additional
configuration
options
for
logging,
and
it
allows
two
additional
configuration
fields.
B
One
is
it
allows
you
to
use
a
zap
filter,
so
it's
actually
importing
a
new
library
called
that
filter
into
the
collector,
which
allows
you
to
filter
by
level
in
namespace,
which
may
be
useful
in
some
cases
where
you
want
to
have
a
box
cuter
blogger
being
more
verbal
than
others,
and
the
the
other
option
allows
you
to
explicitly
exclude
some
log
statements
from
being
logged
at
all.
So
are.
F
J
B
F
F
I,
don't
know
if
the
connectors
now
give
us
an
ability
to
to
do
that,
but
we
have
some
some
way
to
not
ship
this
out
over
a
network
and
hairpin
back
in
we'll
ship
it
to
some
other
collector.
That
has
to
do
the
processing,
but
just
keep
a
processing
pipeline
completely.
They
can
do
that
and
then
send
it
wherever
it
needs
to
go
just.
H
J
B
We've
had
done
enough
issues
with
customers
that
report
that
in
some
settings,
even
though
there
is
no
error
in
the
like
the
behavior
of
The
Collector,
we
are
logging
errors
for
specific
reasons,
which
has
some
bad
scraping.
Something
like
that.
We're
fixing
those
errors,
but
it
takes
multiple
Cycles
to
to
get
around
to
fixing
those
errors
right
and
a
release
takes
a
couple
weeks.
B
D
K
Issue
happened
a
lot
with
the
python
Tracer
and
they
implemented
like
a
throttler
on
logs,
so
noisier
spammy
Logs
with
log
like
maybe
10
or
20
times,
and
then
they
would
be
throttled
if
they
weren't
seen
and-
and
you
know,
the
implementation
would
change.
I
can
point
to
the
code,
but
that
was
like
a
really
effective
stop
gap
for
this.
K
You
know
it
was
like
a
weird
issue
where
just
like
customers
were
just
like
hey
this
sucks
and
we're
like
okay,
give
us
six
weeks
to
cut
a
version,
whereas
in
the
meantime
you
could
get
really
far
by
just
being
like
cool
like
it
throttles
after
10
messages,
and
if
that's
super
not
effective,
you
can
always
bump
the
throttling
that
way.
Higher
I
can
link
to
the
the
code
it
was.
It
was
a.
It
was
a
Nifty
feature
that
that
took
us
a
long
way
at
the
time,
so
passing
it
along.
D
I
B
We
can
try
anything
just
didn't
know.
There
were
sampling
for
logs
in
place
already.
B
D
L
Should
we
move
on
to
the
next
one,
then
cool
all
right,
so
this
is
a
proposal
to
extend
the
connectors
framework.
It's
really
in
my
mind.
This
is
sort
of
the
last
major
need
within
the
framework.
L
So
we
can
we
can
today
we
can
write
connectors
now
we
can
enable
them
with
a
feature,
gate
and
use
them
in
pipelines,
but
one
type
of
I
would
say
class
of
connectors
that
we
can't
right
today
would
be
routing
connectors,
if
you
just
imagine
the
routing
processor
as
a
connector,
where
we
have
like
a
routing
table,
and
we
want
to
be
able
to
say
you
know
when
the
when
the
signal
looks
like
this,
send
it
over
here
to
that
pipeline,
otherwise,
send
it
to
this
pipeline
and
I
think
there's
some
other
use
cases
that
all
boil
down
to
that
same
idea
of
I
want
to
send
it
to
a
subset
of
the
pipelines
that
it's
cons,
that
it's
consider
that
it's
sitting
in
so
I
proposed
a
solution
here,
which
is
basically
there's
sort
of
two
versions
of
it.
L
One
is
a
little
more
restricted
than
the
other,
but
the
idea
is
that
when
the
when
constructing
a
connector,
it
will
get
a
a
consumer.
That
is
where
you
can
basically
ask
it
for
a
consumer
to
the
specific
pipelines
that
you
want,
and
these
have
to
be
pipelines
that
you
can.
You
would
normally
be
admitting
to
by
default,
if
you
weren't
asking
for
a
more
specific
subset
of
pipelines.
J
So
then
I
was
not
as
I
said.
I
did
I
know
that
you
pointed
to
these
this
to
me
this
week
and
I'm.
Sorry,
as
I
said,
I
I
have
lots
of
work
and
meetings
this
week,
but
is
it
possible
to
hack
it
around
the
follow
in
the
following
way?
J
If
we
expose
the
fan
out
component
consumer-
and
you
just
try
to
convert
to
that,
then
you
have
access
to
all
your
next
things,
so
it's
a
hacky
way
necessary,
but
it's
minimum
change
to
everything.
So
we
will
still
pass
you
only
one
consumer
this
and
you
can
check
if
you
are
a
component,
that
you
need
access
to
see
if
you
are
sending
out
to
multiple
things
you
can
check.
J
L
I
think
that
works.
It
was
actually
kind
of
where
I
went
with
this
in
the
first
place.
But
you're
always
telling
me
to
minimize
the
API
service
area
and
I
thought
that
this
proposal
was
a
little
bit
more
surgical,
in
that
it
just
basically
adds
one
method
to
the
connector
consumer,
but
adding
they're
exposing.
D
L
Yeah,
so
it's
just
the
it's
just
a
regular
consumer,
dot,
logs
or
whatever
signal,
and
then
it
adds
one
method
to
it,
which
just
asks
just
basically
does
what
you
describe
or
just
goes
into
the
fan
out,
connector
and
asks
it.
You
know
it
builds
the
inappropriate
fan
out
connector
to
the
subset
of
pipelines
that
you're
requesting,
so
it's
just
kind
of
making
it
easy
for
the
connector
implementation
to
work
with
it,
and
it's
also
can
be
very
restrictive
because
there's
just
there's
not
much
else,
there's
nothing
else.
You
can
do
with
it.
Really.
J
Yeah,
but
the
same
thing
is,
is:
if
we
convert
this
to
Fan
out
things,
you
will
have
access
only
to
the
ones
configured
you
to
to
be
there
like
yeah,
okay,
I
will
I
will
read
it,
but
this
is
so
it
matches
with
my
understanding
that
we
can
trick
it
to
not
have
to
change
so
because
initially
I
saw
a
PR
from
you.
That
was
changing
the
interface
to
accept
a
list
of
consumers
which
I
was
worried.
I
think
that
was
one
of
the
version
earlier
version
correct,
yeah,
yeah
that.
J
J
It's
still
the
same
amount
of
public
API
to
to
be
honest,
then
we
either
expose
this
interface
or
we
expose
that
struct.
In
my
opinion,
it's
kind
of
the
same
amount
of
of
public
API.
L
J
It
will
be
in
the
under
consumer
package
as
a
package
in
that,
like
or
or
even
directly,
there
I
think
we
will
be
a
sub
package,
the
way
how
we
do
exporter.
You
know,
exporter
has
its
main
package
and
then
you
have
ottl
Ott
or
TLP
exporter
as
one
of
the
sub
packages
or
and
maybe
even
a
sub
module
like
we
can
even
split
it
in
a
module
that
is
Standalone
module,
10
out.
Okay,.
L
I'll
put
together
an
implementation
like
that,
you.
J
Don't
have
necessary
to
implement,
but
unless
it's
trivial
but
think
think
about
this
I'm
I
mean
I'm
trying
to
to
get
others
involved
into
this.
L
Cool
well
I'll
wait
for
you
to
take
a
look
at
this,
but
then,
and
then,
if
necessary,
if
you
think
that
that's
the
better
way
to
go,
I
will
we'll
implement
it.
That
way
and
we'll
be
able
to
compare
a
little
bit
more
clearly.
L
I
think
so
I
mean
I'm.
Sure
they're
are
probably
a
few
little
things
we
haven't
thought
of,
but
this
is
the
seems
like
the
last
big
piece
and
then
it's
just
more
about
individual
implementations,
so
I've
already
been
working
with
like
Bristol
and
two
reported
over
the
span.
Metrics
and
service
graph
processors
basically
implemented
a
connector
version
of
them
within
the
processor.
It
was
nice
and
clean
and
easy
cleaned
up.
The
config
reduce
the
code
and
it
seemed
more
performant
too.
Actually
so
nice.
J
J
Nice
One
Thing
by
the
way
I,
would
encourage
you.
Maybe
this
version
or
next
version
stabilize
the
the
feature
gate
for
the
graph,
so
I
think
that
that
can
be
stabilizing.
The
other
code
can
be
removed
faster
because
that
doesn't
enable
the
the
new
pattern,
but
that
but
actually
switches
us
to
the
new
way
of
constructing
the
graph
which
yeah
it's
ninety
percent
of
the
code
that
we
require
to
enable
this
yeah.
L
Okay,
so
you
think
stabilize
in
the
next
release
and
then
start.
G
J
And
load
balancing
I
think
you
should
be
the
load
balance.
Exporter
is
called
but
I
think
load
balancing
in
general
can
be
also
implemented
as
a
connector.
L
I
think
so
I'm
not
very
familiar
with
the
load
balancing
exporter.
If
it
does
it
does
it
interact
with,
does
it
go
to
otlp
format
and
then
back
onto
receivers
on
the
same
collector
or
so.
J
No,
so
so
the
the
load
balancing
what
it
does
is.
Essentially
you
have.
Let's
assume
you
want
to
send
it
to
10
instances
and
load
balance
between
the
10
of
them
right
now,
I
think
what
it
does
is
essentially.
J
You
configure
all
these
exporters
and
then
it
it.
It
does
routing
essentially
based
on
the
trace
ID
I,
if
I'm
not
mistaken,
or
something
like
that
and
routing
to
to
different
things.
So.