►
From YouTube: 2022-01-19 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
D
Okay,
great,
let's
get
started
so
I
put
three
things
on
the
agenda.
I
don't
know
if
that
is
gonna
join.
He
couldn't
join
last
week.
So,
let's
just
come
back
to
that
if
he
joins
so
the
one
thing
that
we've
been
working
on
this
week,
we
put
some
examples
of
the
of
events
that
and
looked
at
if
they
could
be
parented
to
other
events.
D
So
in
this
group
we
we
feel
strongly
that
that
the
service
doesn't
describe.
It's
not
is
not
intuitive
to
describe
a
client-side
application
and
we
proposed
adding
a
different
set
of
attributes
to
to
describe
the
resource
coming
from
side,
which
would
be
like
ad
dot
name
or
app.
Dot
bundle.
D
And
yeah
there
have
been
now
multiple
discussions
and
I
think
issues
and
prs
we
proposed
originally.
If
you
propose
adding
about
name,
then
there's
a
separate
pr
for
introducing
like
a
neutral
attribute
which
would
be
like
element
telemetrysource.name
so
like.
I
think
we
would
just
like
to
come
to
a
resolution
on
this,
and
I
you
know
that
you
had
opinion
on
this.
Actually.
C
Morgan
last
week
mentioned
of
one
more
situation
where
service
dot
name
may
not
be
present,
which
is
the
infrastructure
scenario
where
the
infrastructure
agents
they
work
in
the
back
end
but
outside
of
a
you
know,
service
instance,
which,
let's
say
in
a
kubernetes
environment
the
kubernetes
agent
is,
is
talking
to
the
api
server
and
getting
information
across
all
services.
C
So
what
what
would
they
use
for
service
dot
name?
So
it
may
not.
E
I
think
the
answer
is
today
is
nothing
right
like
like,
if
you
use
the
hotel
collector
to
pull
in
like
regular
database
metrics
from
like
my
sequel
or
cpu
metrics
from
a
host,
I
don't
think
that
anything
is
centered
for
service
name.
I
think
john
had
had
spoken
on
that
authoritatively,
so
that
is
another
example
where
of
course,
service
dot
name
is
not
used.
E
B
B
Yeah-
and
you
know
I
would
throw
out
if
we
ever
get
into
like
extreme
internet
of
things
by
extreme
internet
of
things,
I
don't
mean
spotify
running
on
car
os
right,
I
mean
light
bulbs
and
like
giant
sensor,
arrays
embedded
systems
like
like
that,
where
you
know
the
the
message
size
is
32-bit,
so
forget
about
service
name
where
you
put
the
trace
id.
So
so
there's.
Definitely
when
you're,
when
you're
talking
about
like
the
greater
world
of
of
programming,
there's
there's
definitely
stuff
out
there.
B
A
computer
process
participating
in
transactions
as
transactions,
as
we
define
you
know
traces
in
the
current
open
telemetry
model
like
there's,
definitely
stuff
out
there
that
doesn't
doesn't
fit
that
model.
B
I
think
I
haven't
been
part
of
this
group,
but
I'm
guessing
like
a
service
name
aside,
like
a
lot
of
the
work,
it's
I
know
you
guys
are
calling
it
rum,
like
you,
know
real
user
modeling,
but
what
I
think,
when
I
hear
john
mentioned,
like
it's
like
difficult
to
figure
out
how
to
fit
this
into
the
current
model.
B
The
thing
that
comes
to
my
mind
is
gui
right,
like
when
you
have
a
user
interface
like
a
graphical
user
interface
that
that
imposes
so
much
on
what
that
program
is
doing
and
how
it's
designed
that's
very
different
from
how
a
a
program
that's
not
doing
live
interaction
like
a
gui,
so
I
wouldn't
be
shocked
if,
like
a
lot
of
the
stuff,
this
group
ends
up
having
to
figure
out
is
like
how
do
you
you
model
programs
that
are
written
in
that
more
kind
of
reactive
pattern,
of
responding
to
gui
inputs
and
updating
some
state
and
slamming
it
back
out
onto
the
display?
B
60
frames
a
second,
so
there's
like
all
this
stuff
where
things
are
different,
but
then
there's
areas
where,
where
things
are
the
same
and
in
those
cases
from
the
perspective
of
modeling
the
data,
so
we're
talking
about
an
analyst
on
the
other
side
who
wants
to
take
all
of
this
open
telemetry
data
in
and
do
some
kind
of
analysis.
B
We
we
want
to
make
sure
that
we're
giving
that
person
clean
data.
I
don't
want
to
say
like
it's
like
a
vendor
problem
and
they
should
like
munch
data
together
to
figure
it
out,
because
I
want
to
respect
the
idea
that
it
might
not
be
a
vendor
with
a
bunch
of
staff.
On
the
other
end,
it
might
be
a.
B
It
might
be
a
data
scientist
who
just
wants
to
like
take
all
this
data
and
slam
it
into
some
cool
computer
program
that
they
wrote
or
it
might
be.
You
know
someone
who
works
at
an
end
user
company
who
wants
to
do
something
interesting
with
the
data
and
so
areas
where
we
see
something.
That's
that
is
effectively
the
same,
and
I
would
say
one
of
those
areas
is
when
you
have
a
transaction
you're
trying
to
model.
So
you
have
like
this
distributed,
trace
and
you're
trying
to
model
everything
in
that
every
component.
B
That's
participating
in
that
trace
tends
to
be
like
a
process
like
that
some
kind
of
application
that
has
a
name
it
has
an
instance
id
it
has
a
version.
It
has
all
of
these
qualities,
and
so
my
guess
is
like
like
what
this
group
is.
Not
arguing
is
saying,
like
hey
the
ios
apps
for
writing
the
browser.
Apps
are
writing.
They
don't
have
this
concept
of
a
name
or
a
version
or
an
id
like
that's
not
what
they
do,
but
yeah.
B
That
sounds
weird
to
us,
because
service
is
the
thing
you
talk
to
it's,
not
it's
not
my
thing
and
I
I
totally
get
that
I
do
think
there
is
this
unfortunate
quality
that
there
is
no
one
good
name,
one
good
namespace,
to
put
these
these
resource
attributes
under
simply
due
to
the
fact
that
all
of
the
programs
that
participate
in
these
transactions,
the
people
who
work
on
them
tend
to
use
like
a
different
lingo,
even
when
they're
effectively
doing
the
same
thing.
B
So
you
know,
for
example,
like
what
gets
called
an
app
in
my
like
20
years
of
programming
has
like
kind
of
like
moved
around,
even
like
the
things
that
get
called
like
services
now
or
like
front-end.
Services
used
to
be
called
like
the
application.
The
person
who
worked
on
that
thought
of
that
as
the
application
and
thought
of
the
browser
is
just
not
the
app
but
some
kind
of
like
thin
client
or
something.
B
So
so
these
terms
don't
even
like,
like
stay
put,
you
know,
database
applications
used
to
be
a
thing.
No
one
really
talks
like
that
anymore.
So
the
question
for
me
is
like:
how
do
we?
How
do
we
do
both?
B
That
basically
means
I.
It
would
be
really
really
great
if
we
didn't
have
app.name
app.namespace,
app.version
and
service.name
service.namespace
servicedup
version
and
those
two
things
actually
were
were
attributes
that
you
were
trying
to
compare,
because
at
a
certain
level,
you're
just
talking
about
nodes
in
a
graph
when
you're
doing
trace
modeling-
and
I
don't
know
what
the
right
name
space
for
that
is.
B
You
know
app,
doesn't
work,
because
not
everything
there
would
be
called
as
an
app
service
doesn't
work,
as
you
all
have
mentioned,
like
people
who
work
on
some
of
these
things,
don't
think
about
the
thing
they're
working
on
as
a
service,
especially
if
it's
like
a
gui
application
like
calling
it
a
service
seems
weird
telemetry
source
also
doesn't
work,
because
that
sounds
like
the
sdk,
which
also
has
a
name
and
a
version.
B
F
Ted
I'd
like
to
I'd
like
to
disagree
with
one
of
the
assertions
you
made,
which
is
that
this
thing
is
just
another
component
in
a
trace,
because
this
data
is
very
different
in
shape
and
at
least
all
of
the
vendors
that
currently
have
that.
I
know
of
that
currently
have
a
rum
product
for
this
monitoring.
F
They
send
this
data
to
a
different
backend.
It
does
not
go
through.
The
same
analysis
does
not
go
is
not
analyzed
in
the
same
way
at
all.
It's
a
very
different
process
to
analyze
that
data,
because
the
shapes
of
the
data
are
so
significantly
different
and
the
volumes
of
data
are
immensely
greater
because
there
are
millions
of
devices
out
there
running
these
apps.
So
there
is
a
difference
in
kind.
It's
not
just
that
this
is
another
thing
contributing
to
a
trace,
they're
very
significantly
different
and
the
data
has
to
be
processed
in
a
different
way.
B
Yes,
so
I
I
totally
totally
agree
that
there
is.
There
is
more
going
on
in
this
realm.
There
is
additional
stuff
happening
in
this
realm.
That
is
not
happening
on
server
side.
There
are
additional
issues.
The
fact
that
this
data
has
to
get
sent
over
the
public
internet
is
like
a
whole
other
ball
of
beeswax,
like
this
there's
plenty
about
this
domain.
That
is
additional.
B
I
guess
what
I'm
trying
to
describe
is.
There
is
an
aspect
where
you're
trying
to
draw
just
like
a
graph
of
everything,
that's
talking
to
everything
else
or
you're,
just
trying
to
render
a
trace
or
you're
trying
to
do
trace
analysis
not
run
not
all
of
these
additional
things.
When
you're
doing
that
kind
of
analysis,
then
these
are
all
effectively
the
same
kind
of
building
block
in
the
sense
that
when
you're
analyzing
that
data,
you
are
actually
trying
to
compare
these
things
in
an
apples
to
apples
manner.
I
don't.
F
B
E
Will
be
circumstances
where
you
look
like,
I
think
the
application
topology
map
is
another
where
you're
you
are
going
to
use
sort
of
the
data
from
john.
Even
even,
if
you
sort
of
have
two
buckets
where
the
rum
data
is
sent
and
the
the
backend
service
data
center,
there
will
be
a
few
contexts
where
you
you
want
to
look
across
those,
but
we.
F
G
I
have
been
up
in
this
pre-sales
organization
now
for
the
last
five
years,
and
one
of
the
issues
we
ran
into
again
and
again
is
exactly
the
separation
of
data
that
customers
said
like
hey,
we
have
a
performance
issue
and
here's
what
we
see
in
the
end
user
monitoring,
here's
what
we
see
in
the
in
in
the
back
end
and
at
the
end
the
solution
were
somewhere
in
between,
because
we
had
a
slowdown
in
the
server
and
every
every
hx
transaction
was
slowed
down
by,
let's
say
five
milliseconds,
but
that
added
up
in
the
front
end
to
to
to
blow
up
the
numbers
and
figuring
out
like
and-
and
I
think
I
agree,
that
processing
is
an
issue,
but
at
the
end,
at
some
point,
having
like
this
end-to-end
view
in
one
graph
in
one
data
view,
especially
if
you
do
some
advanced
data
analysis
is
definitely
something
people
are
looking
for.
C
B
Yeah,
I
I
think,
there's
a
lot
of
additional
data
analysis.
I
guess
the
point
I'm
trying
to
make
is
this
particular
set
of
resources
actually
describes
the
same
thing,
whether
you're
in
an
ios,
app
you're,
a
browser
or
you're
in
a
java
app
when
you're
saying
this
is
the
name
of
this
thing.
This
is
the
version
of
it
like
when
you're
saying
this
is
the
version
of
this
thing.
We're
not
talking
about
something
different.
That's
that's
my
point
and
it's.
Actually.
B
So
as
long
as
like
we're
saying
that
these
attributes
mean
the
same
thing
like
if
you
look
up
the
definition
of
an
of
a
name
currently
and
like
the
restrictions
that
are
put
on
it
like
why
you
would
model
the
name
a
certain
way,
as
you
know,
a
class
of
application
within
a
name
space
that
I
don't
doesn't
seem
like.
That's
that's
happening
differently
over
here,
and
you
know
I've
done
plenty
of
front-end
programming
in
my
background.
B
So
it's
that
that's
like
a
unusual
like
an
unfamiliar
domain
for
me
and
it
seems,
like
the
maybe
there's
a
way
to
split
the
difference
here
where,
when
it
comes
to
like
the
data
being
emitted,
it
would
be
helpful
for
it
to
be
uniform
here,
but
when
it
comes
to
like,
as
far
as
I
can
tell,
the
area
where
this
would
be
confusing
to
people
would
be
when
they
are.
You
know
creating
a
new
sdk
right
there,
they're.
B
If,
when
they're
booting
up
open
telemetry
and
as
the
application
developer,
I
need
to
like
enter
some
information
there
saying,
like
go
put
in
your
service
name,
now
sounds
really
weird
and
having
that
be
the
sort
of
ui
for
for
how
you
would
set
up
the
sdk
is
the
place
where,
where
there
would
actually
be
like
some
cognitive
dissonance
that
that
would
matter
like
that's,
not
the
place
where
you
want
to
sit
down
and
explain
to
a
new
user
like
yeah,
we
call
this
service
name,
because
we
have
to
pick
something
we're
sorry,
you
want
that
to
be
like
a
nice
experience,
and
so
I'm
just
wondering
if,
like
that's
the
place
where,
where
we
could
solve
it
and
make
everyone
happy.
B
In
fact,
these
these
attributes
are
so
important
when
you're
creating
a
new
sdk.
It's
not
actually
helpful
to
have
these
buried
under
resources.
You
want
to
pull
these
things
up
and
kind
of
make
them
like
first
level.
Citizens
like
when
you
create
your
app,
you
want
to
say,
what's
the
name
of
this
app,
what's
the
version
of
it,
what
what's
the
instance
id
of
this
thing,
and
we
really
really
really
want
end
users
to
to
fill
that
information
out.
B
It's
extremely
extremely
helpful
that
they
fill
that
information
out
and
it's
a
big
bummer
if
they
don't
include
things
like
the
application
version
right.
There's,
like
all
of
this
analysis,
that
you
want
to
do,
comparing
things
across
versions
out,
you
can't
do
it
if
they
don't
include
the
version
so.
A
B
F
F
F
F
B
E
E
F
So
this
is,
this
is
sounds
like
it's
getting
even
more
muddled
and
muddy.
Now
it's
only
things
that
participate
in
traces
that
this
matters.
For
because
we
have
three
goals.
We
have
three
signals
right.
We
have
traces,
metrics
and
logs
and
two
like
metrics
and
logs
you're,
saying
we
don't
need
to
have
a
service
name
for
it
and
but
for
traces
we
do
so
things
are
gets.
F
Things
are
starting
to
get
very
confused
in
my
head
about
what
we're
trying
to
assert,
but
I
do
want
to
say
there's
something
I
think
we
fundamentally
disagree
on
and
that
I
think
we
thought
I
fundamentally
agree.
I'm
not
going
to
don't
speak
for
everybody,
but
I
fundamentally
disagree
that
just
because
it
participates
in
a
trace
means
it's
somehow
the
same
kind
of
thing,
which.
B
B
Right
like
this
is
not
the
end-all
be-all
of
programming,
but
when
we're
talking
about
the
kind
of
internet
services
that
that
we
build
and
provide
for
people
like
this
kind
of
transactional
distributed
transaction
is
like
a
big
fundamental
part
of
that
model,
and
it's
true
that
when
you
bolt
a
gui
onto
something
it
changes
how
you
program
that
thing,
but
but
they're
actually
like
I.
B
I
would
push
back
on
the
idea
that
there
is
something
hugely
different
about
a
mobile
app
versus
like
a
a
node.js
app
or
you
know,
a
server-side
swift,
app
or
something
like
that.
Like
I
don't,
I
don't
think
these
things
are
like
we're.
Comparing
you
know,
java
apps
to
light
bulbs
when
we're
doing
this
so.
E
I'll
say
this
like
I,
I
actually
agree
with
both
of
you
in
some
sense
like
like
john,
I
think
ted
makes
a
really
strong
point
that,
like
yes
often,
these
fans
get
processed
in
different
places
by
a
lot
of
vendors.
But
I
I
think
I
think
it
would
be
nice
to
be
in
a
world
where
you
could
send
all
of
the
spend
from
from
a
client
application
to
something
like
jaeger,
and
it
would
still
render
them
out,
like
maybe
it's
not
designed
for
that
purpose.
E
But
there
will
be
some
scenarios
where
you
want
to
just
build
the
mother
of
all
traces
from
some
giant
distributed
transaction
that
includes
all
the
client-side
stuff
and
all
the
back-end
stuff,
all
in
one
giant,
waterfall
graph,
because
that's
what
you
want
and-
and
so
there
are,
I'm
not
necessarily
agreeing
with
ted's
assertion
that
the
ids
need
that
the
names
and
things
need
to
be
identical.
E
But
there
will
be
some
scenarios
where
having
the
data
model
be
predictable
and
clean
and
processed
in
one
place,
even
that,
if
that's
not
the
norm,
I
think
that's
something
we
should
strive
for
as
a
project
that
the
data
comes
out
in
a
predictable
sort
of
manner
that
that
sort
of
traces
generally
or
spans
look
predictable.
E
At
the
same
time,
I
do
think
that
there
are
enough
scenarios
where
the
metadata
the
resource
metadata,
will
not
always
be
the
same
from
every
single
scenario
right,
so
we
talked
about
one:
that's
the
metrics
and
logs
coming
from
a
host
os,
yeah
they're,
not
gonna,
have
service
name,
because
it
doesn't
necessarily
make
sense
and
and
if
metrics
are
coming
from
something
like
mysql
that
are
captured
through
the
collector,
I
don't
expect
us
to
use
service
dot
name.
E
Maybe
we
should,
I
don't
know,
but
like
I
think
there
will
be
scenarios
where
the
resource
metadata
is
going
to
be
shaped
differently,
depending
on
where
the
data
is
captured,
and
I
I
fundamentally
agree
with
john
but
like
for
a
rum
scenario,
client
scenario.
The
resource
metadata
is
not
going
to
be
the
exact
same
shape
as
the
resource
metadata
from
a
back
end
service.
What
do
we
use
service
dot?
Name
to
describe
the
name
and
like
service
dot
version,
describe
the
version
or
or
not?
E
However,
I,
like
my,
I
guess,
I'm
of
two
minds
over
this,
like
I,
I
ted
you're
certain
that
we
need
like
something
consistent
to
to
pull
off
of,
does
seem
nice,
because
you
send
all
this
data
or
something
and
it
can
just
render
out
a
name
at
the
same
time
if
these
are
going
to
be
shaped
differently
and
we
can
probably
come
up
with
other
non-rum
scenarios,
I
guess
we
already
did
with
the
infrastructure
metric
scenario
where
you're
going
to
have
just
frankly,
fundamentally
differently,
shaped
metadata
and
I'll.
E
Add
one
last
thing:
the
there
will
also
be
scenarios.
I
think,
where
we're
layering
this
metadata
on
top
of
itself
right
like,
if
I
think
of
I
guess
my
model
of
what
I'd
love
to
see
for
like
span
metadata,
would
be
coming
off
of
a
ec2
host
in
amazon.
Would
be
the
service
information
service,
name,
service
version,
all
that
stuff
and
the
resource
like
the
actual
compute
resource
information?
Alongside
that
you
can
compose
them
together
in
rum.
E
E
G
I
think
I
think
it
gets
complicated
when
you
think
about
headless
browsers
running
in
a
syntactic
application,
or
something
like
that,
where
you
maybe
also
want
to
stack.
So
I
I
added
a
comment
into
this
pull
request.
Where
I
said
like
I
had
a
customer
once
they
had
like
a
headless
browser
generating
pdfs,
which
was
part
of
microservice.
So
is
this
an
app
or
a
service,
or
is
this
two
entities?
So
how
would
you
model
that
in
open
telemetry.
F
I
think
there's
another
another
thing
that
is
being
asserted
repeatedly
in
that
that
somehow
these
end
user
applications
need
to
talk
to
the
network,
which
they
don't
there's
no
requirement
that
these
participating
traces
whatsoever
they
could.
We
could
just
be
generating
realm
events
that
have
nothing
to
do
with
the
network
at
all.
There
may
not
be
there
may
not
be
traces
being
generated
out
of
a
given
application,
and
this
is
also
true,
I
will
just
say
for
any
given
open
telemetry
service,
there's
no
requirement
that
there's
any
network
connectivity
whatsoever.
F
F
B
I
guess
john
I'm
not
trying
to
conflate
it
to
tracing
I'm
just
I'm
just
putting
on
my
data
analyst
hat
and
saying:
please
don't
make
me
mudge
this
data.
Please
don't
make
me
mung
across
a
bunch
of
different
name
spaces
so
that
I
can
just
do
my
analysis
and
if
this
data
is
the
same
data,
if
we're
talking
about
the
name
of
this
thing
and
it's
version
and
a
namespace
that
it
might
be
in
and
an
id
instance
id
if
it
has
one
like
I
just
when
I
have
those
things
I
want.
B
I
want
that
to
be
uniform
when
I'm,
when
I'm
doing
my
data
science,
so
that,
I
guess
that's
that's,
I
see
three
roles
in
open,
telemetry.
There's
the
application
developer.
Let's
deal
with
the
code,
there's
the
operator
who
has
to
deal
with
running
all
of
these
things
and
then
there's
the
analyst
who
has
to
deal
with
the
data
coming
in,
and
I
guess
I'm
coming
to
this
group
wearing
my
analyst
hat
saying
like
please
don't
make
me
have
to
to
munch
this
stuff.
It's
it's.
F
B
Like
if
we
can
come
up
with
with
a
name
space
for
this,
that
makes
everybody
happy.
That's
great,
I'm
like
a
little
skeptical,
because
you're
you're
naming
your
thing
like
this
name.
Space
describes
like
your
thing
like
your
baby,
and
it
seems,
like
everyone,
has
like
a
different
different
name
for
what
they're
the
way
they
talk
about
their
babies.
Some
people
call
it
their
app.
Some
people
call
it
their
service
and
they're
in
the
90s.
They
call
it
their
program.
B
G
What
what
if
what?
If
what?
If
would
it
be
possible
to
say
like
hey
if
you
use
app,
if
you
use
service,
we
just
make
one
out
of
it,
but
you
can
do
both.
I
mean
that
that
could
be
one
solution
or
using
something
like
underscore
dot.
I
mean
there's
other
standards
using
something
like
without
a
meaning
or
dollar
or
whatever,
or
not
even
putting
something
in
front
of
it.
So
I'm
not
sure
I
would.
I
would
probably
have
issues
with
that
because
then
yeah
you,
you
have
to.
C
G
Like
is
this
a
value
or
an
attribute
to
have
it
to
drill
in
or
not,
but
but
maybe
some
something
like
that,
that's
or
common
dot
or
generic
or
main
or
whatever,.
C
G
Something
like
that
which
is
as
as
openness
as
possible,
covering
because
I
agree.
C
C
G
Version
instance
or
namespace,
I
think
it
was,
I
mean
that
was
the
other,
the
the
old
tab
I
tried
to
to
get
into,
and
this
is
a
separate,
but
for
me,
related
topic
is
just
like.
I
want
to
know
what
the
namespace,
the
name
and
the
ideas
of
this
thing
here,
because
here's
here's
another
thing.
I
always
worry
about
the
moment.
I
set
up
this
thing.
Let's
say
my
browser
instrumentation,
my
application.
Instrumentation
things
can
go
wrong
and
maybe
some
data
reaches
my
con
collector,
maybe
reaches
my
back
end.
G
B
E
Issue
like
name
and
version-
I
don't
know
if
there's
disagreement
on
here,
that
we're
talking
at
least
about
like
common,
like
a
common
thing
that
could
be
repeated,
I
think,
there's
an
assertion
from
john
and
others
that,
like
service
dot
name,
it's
not
the
way
we
should
express
it.
But
john,
like
do
you
just
do.
Do
you
agree,
at
least
like
like
name
could
be
a
common
thing?
Well,.
F
F
F
B
Right
and
right
now
we
have,
we
tend
to
look
at
the
telemetry
sdk
stuff
to
do
that,
distinguishing
that
may
not
be
sufficient.
Like
there's
the
telemetry
sdk
language
is
the
thing
that
that
we
use
we
look
with.
We
look
whether
there's
the
presence
of
of
device.
If
it's
a
device
running,
there's
the
device
name
space.
I'm
not
saying
this
is
like
perfect,
I'm
just
I
like.
I
completely
agree
with
you
that,
like
we
should
figure
out
a
way
to
make
sure
stuff
that's
going
to
be
analyzing
mobile
data
and
rum.
B
You
know
are
able
to
to
easily
without
having
to
do
a
lot
of
data.
Munching
identify
that
so
having
like
a
single
field
that
they
can
switch
off
of.
Is
the
ideal
not
having
to
compare
across
like
concatenating
a
set
of
fields
and
looking
at
that
which.
B
Yeah-
and
so
I'm
totally
down
with
that-
I
just
I
just
don't-
don't
want
to
end
up
with
app
name
service
name
as
like
two
separate
things:
that's
that's
just
the
one
thing
I'm
asking
for
and
then
there's
just
this
one
other
unfortunate
thing,
which
is
just
the
legacy
issue,
which
is,
if
we're
talking
about
changing
this
to
to
food.name
or
or
anything.
B
That's
been
part
of
open
telemetry
for
a
long
time
and
is
like
really
out
there,
and
a
lot
of
things
depend
on
it
already
so
so
like
if
we
do
want
to
to
actually
change
the
way
this
looks
in
the
data,
then
we
have
to
wrangle
with
that
that
legacy
issue
like
we're
past
the
point
where
I
feel
comfortable,
just
just
breaking
people's
data,
you
know
we,
we
can
use
the
collector
to
do
data
munching
and
schema
versioning,
but
I'm
reluctant
to
to
force
people
to
use
the
collector
yet
and
that
would
be
forcing
them
to
use
it.
B
G
But
even
if
we,
if
we
would
come
up
with
the
name,
let's
say
it's
foo
dot
name
I
mean
you
still
can't
could
have
something
in
this
bag.
Like
hey
service,
dot
name
is
also
okay,
but
expect
this
being
deprecated
with
open,
telemetry
2.0,
or
something
like
that.
So
there
is
no
2.0
we're
not
we're
not
going
to
do
it
to
that
whatever,
but
but
let's
say
fading
it
out
in
somewhere
or
the
other.
So
yeah.
B
I'm
just
saying:
that's,
that's
a
huge
lift
when
you're
talking
about
these.
These
core
fields,
like
you
you're
talking
about
data,
that
that
is
like
really
deeply
relied
upon
and
so
doing
doing
a
migration
on
that
data
is
is,
is
is
a
serious
subject
and
as
we're
moving
into
stability
on
a
lot
of
these
semantics,
like
they're
they're,
all
becoming
serious
subjects
like
I,
I
help
run
the
instrumentation
working
group.
B
That's
really
focused
on
trying
to
to
nail
down
things
like
http
and
sql
and
messaging
semantics,
because
of
how
nervous
people
are
getting
that
we're
gonna
come
back
and
switch
them
around
later
they're.
Looking
a
thing
we
get
from
our
end,
users
is
like.
Please,
please,
please
tell
me
you're
not
going
to
pull
the
data
rug
out
from
under
me
and
and
change
this
stuff.
I
want
to
hear
from
you
that
it's
stable
and
I
can.
F
F
The
the
ask
that
I
would
have
is
you
haven't
asked,
don't
ignore
this.
I
think
our
ask-
or
my
ask
is
please
don't
just
keep
on
saying.
Well,
the
rum
group
or
the
client
group
needs
to
figure
this
out,
because
that's
what
we've
heard
over
and
over
again
is
the
client
group
needs
to
figure
this
out
and-
and
I
think
we
need
to
figure
this
out
as
a
community
and
not
just
push
it
on
to
this
group.
Who's
relatively
inexperienced
in
the
project
yeah.
C
F
B
Well,
I
think
part
of
the
reason
why
there
is
pushback.
I
hope
I've
made
somewhat
clear
is
is
just
because
of
like
how
central
some
of
this
stuff
is.
So
when
you
go
trying
to
like
fork
it
or
change
it,
you
are
going
to
get
a
lot
of
people
running
and
being
like
whoa
and
then
there's
the
question
of
like
well.
B
What
aspects
about
this
do
actually
suck
for
for
client
developers
like
the
thing,
the
main
thing
that's
been
brought
up
is
like
it's
like
a
confusing
term
and
there's
concern
that
application
developers,
like
our
users,
are
gonna,
be
confused
by
that
thing.
That
that's
been
the
main
thing
I've
heard
from
you.
B
John,
is
like
why
it's
why
it's
bad,
so
I
would
love
to
like
work
with
you
all
to
do
more
requirements
gathering
on
that
front
and
and
figure
out
like
like
okay,
what
what
about
this
actually
is
problematic
and
how?
How
can
we
like
alleviate
that,
while
still
ensuring
we
have
a
unified
model
and
ideally
not
doing
a
giant
data
migration?
C
B
To
make
everybody
happy
without
doing
a
huge
data
migration,
then
then
that
would
be
awesome.
So
so
I
guess
I'm
coming
to
this
group
saying
like
that.
That
to
me
is
kind
of
the
scope
of
this
issue
and
I
really
want
to
work
with
you
all
to
to
get
it
sorted,
because
I
do
value
this
group.
I
wish
I'd
been
able
to
to
come
to
this
group
more
often,
I'm
actually
late
for
the
collector
group,
which
has
its
own
circuits
going
on
right
now.
F
I'm
I'm
slightly
puzzled
by
the
the,
not
100
puzzle,
but
slightly
puzzled
by
the
assertion
that
we
need
to
do
today
in
the
data
migration.
Up
to
this
point,
open
telemetry
is
only
specified
how
services
are
supposed
to
report
data
and
not
how
end
user
applications
are
supposed
to
report
data
so
for
end
user
applications.
We
don't
have
any
legacy
in
which
we
that
we
need
to
support
like
it's
a
new
field
that
we're
trying
to
figure
out
for
the
first
time.
B
Well,
there
I
mean
there's,
there's
a
lot
of
stuff
out
there.
Already,
I
guess
is
what
I'm
saying:
there's
a
there's,
a
lot
of
android
there's
a
lot
of
browser
stuff,
ios
stuff
is,
is
really
getting
out
there
and
a
lot
of
the
people
who
are
using
open
telemetry
today
in
those
worlds,
are
using
it
because
they're
trying
to
send
that
data
to
something
that
does
distributed
tracing
analysis.
B
I
know
that's,
not
the
end-all
be-all,
I'm
just
explaining
that's
why
they
installed
it
today
and
they're
using
it
today,
because
open
telemetry
doesn't
do
anything
else
for
them
today.
That's
the
only
thing
it
does
and
then
and
so
they're
sending
that
data
to
these
systems
like
jager
and
and
looking
at
it
there
and
a
lot
of
people
are
actually
doing
that.
C
B
B
Like
that's
the
thing
we
work
with
like
like
you
know,
I
try
to
not
be
like
light
step
customers,
because
you
know
that
sounds
like
I'm
just
like
trying
to
protect
some
corporate
interests,
but
but
those
are
the
the
the
people
in
production
I'm
most
familiar
with,
and
I
can
tell
you
like,
like
there's
a
bunch
of
them
and
when
they're
like
cool,
we
want
to
understand
performance
hits
across
like
versionings
of
this
thing,
then
we
say
cool
well,
if
you
said
like,
are
you
setting
the
stuff?
B
We
we
really
push
them
to
to
set
these
things,
and
likewise,
if
they're
doing
analysis
in
yeager
and
other
places
like
that's
just
the
they
they
go
in
and
set
that
stuff,
so
that
they
can
get
access
to
the
features
of
those
tracing
programs.
So
so
there's
there's
a
fair
bit
of
it
out
there.
I
guess
is
what
I'm
saying
and
if
we
talk
about
going
to
like
a
new
namespace
that
makes
everybody
happy.
Then
we
are
talking
about
all
of
the
backend
services
changing
what
they
emit
from
service.name
to
foobar.name.
B
So
that's
why
I'm
saying
it's
like
it
would
be
a
big
data
migration
if
we,
if
we
changed
at
the
data
on
the
wire
level,
if
we
change
the
the
name
space
that
these
fields
were
in.
So
if
there's
a
way,
we
can
do
this,
that
that
makes
fits
a
solution
for
you
know
mobile
and
browser
applications
that
doesn't
change
the
way
that
data
is
represented
on
the
wire.
B
That
to
me
would
be
ideal
and
to
be
clear,
that's
not
me
saying
like
there's
no
problem
like
just
just
be
quiet
about
it
like.
I
want
to
figure
out
like
what
what
the
actual
problems
are
on
this
end,
and
ideally,
is
there
a
way
we
can.
We
can
fix
those
problems
without
changing
the
way
the
data
works
on
the
wire
right
now
that
to
me
would
be
like
the
ideal
solution.
B
If
we
just
can't
do
that,
then
we
have
to
go
to
some
less
ideal
solution,
which
is
not
me
saying
no,
but
I
just
I'm
just
hopefully
painting
a
picture
of
like
all
the
different
pieces.
G
Can
can
I
can
I
make
make
a
suggestion
so
just
today
I
add
a
comment
into
one
of
the
issues
discussing
that
where
I
said
like
hey
one
option
to
change,
the
stack
would
be
to
say
like
instead
of
saying,
like
you
have
to
use
service
name,
you
have
to
use
one
of
the
following
service,
name
or
app
name,
and
then
because
with
that
you
can
say
like
hey
and
with
that
there
comes
requirements
for
service
name
space
service
instance
id.
So
so
from
that
I
mean
there's,
then
follow-up
requirements.
G
Now
this
does
not
solve
the
problem
very
cli
yeah.
But
then
you
have
app
name
and
service
name
I
mean,
then
you
could
add
a
comment
where
you
say
like
hey
in
the
processing
so
service,
then
you
could
maybe
say
something
like
that:
app
name
service
name,
all
those
things
they
just
are
interchangeable,
and
then
you
have
to
expect
people
using
the
same
and
then
in
the
collector
or
in
the
back
end.
G
Let's
say
pushing
that
problem
down
the
pipe
and
saying
like
hey
this
is
this
is
a
problem
for
for
for
other
people,
so
I
mean
that's
also
not
a
perfect
solution,
but
at
least
it
leaves
it
to
gets
it
away
from
from
the
end
user,
and
then
someone
who
says
like
yeah,
but
this
is
not
a
service.
This
is
a
app
and
maybe
they
have
some
whatever
server
application
that
that's
that's
an
app
for
them.
Then
then,
just
just
throwing
this
out
there.
B
Yeah
I
mean
I
think
that
makes
sense,
but
that's
me,
the
the
sir
not
appearing
in
this
film
is
often
the
the
data
analyst
right,
because
those
people
are
super
underrepresented
at
open
telemetry,
and
so
that's
that's
where
I
say
like
hey:
let's
not,
let's
not
just
shove,
this
problem
on
to
analyst
person
who's
who's,
not
on
the
call
because
they're
not
here
so,
but
I
I
agree
with
you
that
like
if
the
issue
is
like
the
application
developer
persona
like
the
person
who's,
the
app
developer,
who's
having
to
wrangle
with
open
telemetry
from
their
perspective,
if
having
this
terminology
come
up
for
them
is
like
what's
what's,
if
that's
like
the
person
we're
trying
to
change
things
for
so
it
makes
sense
for
them.
B
B
Can
we
present
this
information
to
them
there
in
a
way
that
makes
it
clear
how
important
it
is
for
them
to
to
set
it
like
you
mentioned,
like
not
having
a
name
space,
and
this
is
the
stuff
that
I
would
love
to
see
lifted
up
into
not
being
buried
down
in
like
the
resources
that
you
set,
but
as
like
something
a
little
more
primary,
possibly
along
with
other
things
that
you
were
mentioning
john
around
saying
like
if
you
damn
well
need
to
know
this
information
about
this
app
and
it's
not
a
thing
the
sdk
can
set
for
you
automatically,
for
whatever
reason
then,
like,
we
really
want
to
make
the
ui
of
how
you
you
install
and
set
up
open
telemetry
in
these
environments,
like
let
the
end
user
know
that,
like
the
stuff,
is
important.
F
There's
a
there
is
another.
There
is
someone
else
besides
the
end
user.
Well,
I
think
everybody
needs
to
know
the
differences.
Actually
here,
like
I
said
already,
the
analyst
actually
does
need
to
know
that
there's
a
difference
and
the
the
operator
or
the
person
who's
actually
looking
at
the
output
of
the
telemetry
and
whatever
visualization
tool
they
have,
they
would
like
to
know
just
like
we
in
almost
every
tool,
I've
seen
you
see
a
database
icon
when
you're
talking
to
a
database.
F
C
F
F
Just
like
we
know,
there's
something
different
about
a
database
and
then
we
know
there's
something
different
about
a
service,
and
you
know:
there's
there's
also
something
different
about
these
kind
of
end
user
apps.
So
I
think
everybody
actually
needs
to
know
this
information.
It's
not
just
the
application
developer.
B
I
I
I
totally
agree
with
that.
If
the
way
people
are
identifying
that
information
today
is
not
great,
I'm
saying
like.
If
then,
I
would
be
totally
down
with
adding
some
kind
of
additional
resource
that
that
made
that
data
modeling
problem
simpler,
like
if
and
again
it
often
comes
down
to
like
I
can
figure
this
out,
but
I
have
to
munch
stuff
like
if
I
see
like
stuff
from
the
database
namespace,
then
I
know
this
is
a
database.
B
I
see
stuff
from
the
sql
namespace
then
I
know
this
is
a
sequel
thing,
but
if
that's
like
obnoxious
and
actually
like
resource
intensive
to
do
that
for
people
or
even
if
it's
just
the
person
trying
to
render
the
ui,
you
know
on
the
the
other
end,
if
like
having
a
field
or
or
some
small
set
of
fields,
added
that
everything
sets
so
that
you
could
do
that
modeling.
I
I
think
that
would
be
great,
I'm
just
trying
to
avoid
something.
F
It's
worth
thinking
a
little
bit
about,
I
think
something
we
haven't
actually
talked
about
very
much
in
open
telemetry.
Maybe
maybe
the
instrumentation
group
has
I'm
not
sure
but
like
if
I'm
actually
instrumenting
a
database
like
I'm,
not
instrumenting
the
application
talking
database,
but
I'm
inserting.
F
Like
cassandra,
which
is
written
in
java,
you
can
instrument
it
like
easily
right
like
should
we
be
reporting
service
out
of
a
database?
I
maybe
maybe,
but
we
also
would
like.
I
think
I
mean
I'm
just
thinking
from
a
user
experience
perspective
like
it
would
be
really
cool
if,
in
my
map
of
services,
it
was
really
clear
that
this
cluster
of
things
over
here.
That
was
my
cassandra
database,
because
the
cassandra
database
has
lots
of
different
nodes
running
in
it
right.
F
It's
really
nice
to
be
able
to
have
some
uniform
way
across
all
of
these
different
types
of
things
in
the
big
overarching
space
of
an
app
a
world
of
application,
whatever
that
even
means
that
this
thing
is
an
end
user
app
and
there's
like
three
million
instances
of
it.
This
thing
is
a
database
and
there
are
seven
instances
of
this
cassandra
cluster
in
the
in
the
ring
and
that
these
things
are
all
services
in
the
traditional
services
sense.
F
The
database
would
we
put
database
dot
name
in
those
stands.
I
don't
know
actually
it's
a
weird
case
right,
because
that's
that's
a
semantic
convention
for
a
client
call.
That's
a
database
call,
so
it
feels
like
open
telemetry
as
a
whole
needs
some
thing
that
we're
missing,
which
is
like.
How
do
I
distinguish
the
class
of
of
range.
B
Yeah
we
currently,
we,
you
would
use
namespace
the
namespace
field
to
do
that,
but
I
agree
that
that's
that's
kind
of
generic
and
and
will
get
over
over
accessed,
and
it
would
be
better
to
I'm
always
nervous
of
adding
a
field
called
type
service
type.
That's
always
sets
off
a
smell
for
me,
but
but
something
along
along
those
lines
right
so
that
for
one
example,
mongodb
spiked
a
while
back
and
instrumented
all
their
stuff
in
like
they
were
doing
it.
B
You
know
like
a
coding
challenge
kind
of
thing,
but
and
they
were
like
super
happy
with
what
it
came
out
with,
but
and
it
was
but
exactly
the
world
you
say
which
is
they
have
all
these
different
services
that
make
up
a
big
mongodb
thing
to
do
different
stuff
and
that
wasn't
a
problem
for
them.
But
you
would
want
to
know
that
everything
over
there
was
now
on
the
mongodb
side
of
the
fence.
C
F
So
I
guess,
if
we
don't
like
you
say
you
resist
the
type
and
it
smell
it
has
a
funny
smell
to
it.
I'm
not
100
sure
why
yet,
but
if,
if
we
don't
have
type,
then
we're,
I
think
all
we
can
fall
back
on
is
some
sort
of
sets
of
attributes
like
app
name
versus
service,
name
versus
database,
name
yeah
in
the
resource
like
we
don't
see
either
we
have
a
type.
F
B
F
B
People
use
it
because
what
what
happens
is
you
end
up
with
app
names
that
are
the
same?
But
for
whatever
reason
you
need
to
actually
pull
them
apart
in
your
data,
modeling,
and
so
the
name
space
field,
and
you
need
to
do
it
in
a
way
where
the
back
end.
B
B
They
do
do
a
lot
of
that
stuff,
so
so
that
it's
just
one
of
those
like
big
production
system
problems
you
run
into
where,
for
whatever
reason
you
need
to
be
like
these
web
apps
and
these
web
apps
they're
all
web
apps,
but
like
I
just
need
to
put
them
in
two
different
buckets
or
like.
F
B
Exactly
yeah
and
that's
like
teams
is
like
an
example
there
but
which
I
think
is
all
great,
but
I
was
I'm
just
a
little.
If
you
call
it
name
space,
then
it's,
it
becomes
a
little
confusing
about
like
how
you
use
it
as
opposed
to
being
like
is
this.
You
said
teams
like
service
owner
is
that,
like
is
the
owner
field,
actually
what
you
were
looking
for
there.
D
But
if
you
realize
that
it
doesn't
apply
to
all
types
of
client-side,
telemetry
like
browsers,
will
not
have
a
device,
but
mobile
will
have
device.
So
that's
why
we
also
introduced
the
ad
namespace
uh-huh.
You
know,
so
that's
that's
the
guidance
we
got
like.
We
didn't
want
to
introduce
a
type.
We
wanted
to
be
able
to
identify,
run
telemetry
by
presence
of
app
attributes,
yeah
so
yeah
so
like
so
like.
If
you
move
like
name
or
all
these
attributes
to
service
like
we
lose
that
ability
to
do
that.
B
Well,
but
as
and
this
is
where
I
think
this
group,
having
more
crossover
with
with
the
other
groups
would
be
helpful,
is
what
you
described
is
actually
really
useful,
but
even
from
like
the
examples
we're
talking
about,
it's
also
clearly
useful
in
domains
outside
of
of
client
development.
For
example,
when
you
you
have
your
your
database
services,
you,
you
actually
need
to
be
able
to
to
identify
that
all
of
those
things
are
part
of
that,
and
so
maybe
one
I
guess
what
I'm
saying
is.
F
B
Yeah,
it
would
be
good
to
check
in
about
evpf
is
a
whole
other
ball
of
beeswax,
because
I
want
to
figure
out
a
way
to
integrate
that
stuff
without
it
just
being
like
bolted
onto
the
side,
which
is
kind
of
the
natural
way
to
do
it,
but
not
to
like
throw
a
total
curveball
in
the
last
minute.
But
another
reason
why
I've
been
interested
in
joining
this
group.
That's
coming
up
again
from
talking
to
back-end
service
people
is
the
rum
event
stuff.
B
You
all
are
modeling,
because
it's
about
a
lot
of
it.
I
think
the
reason
why
it
doesn't
fit
into
transactional
models.
It's
because
it's
more
of
this
reactor
pattern
kind
of
thing
where
we're
seeing
another
domain
is
like
when
you
get
into
like
modeling
a
messaging
system
like
kafka
or
something
the
transactional
model
is
great
for
kind
of
describing
the
messages
moving
through
the
system.
B
But
when
we
start
modeling
the
like
the
processing
nodes
right
like
the
stuff,
that's
actually
like
processing
the
kafka
cube
like
the
kafka
components,
not
the
end
user
components.
B
Those
systems
often
tend
to
to
have
this
same
kind
of
like
reactor
pattern
of
like
they're,
constantly
getting
just
tons
and
tons
of
input
and
storing
a
bunch
of
internal
state
and
chopping
things
up
and
slamming
them
out,
and
I'm
not
saying
like
they
should
use
rum
but
yeah
it
was.
It
was
like
a
form
of
like
doing
events
where
it's
the
interesting
question
that
it's
like,
okay,
you
could
just
be
like
fine
there's,
just
events
like
we're
just
emitting
logs
again,
but
you
know,
I
think
the
question
is
often
well.
F
Last
so
we
missed
last
week,
but
we
and
we're
out
of
time,
but
we
had
a
fairly
lengthy
discussion
about
the
fact
that
we,
the
into
the
event
space
some
events,
sometimes
can
actually
have
duration,
depending
on
whether
you're
measuring
them
on
android
versus
ios
versus.
B
B
Which
is
the
exact
same
conversation
that
came
up
in
the
instrumentation
sick
talking
about
modeling?
These
messaging
systems
was,
it
was
like.
B
Maybe
we
should
use
zero
duration
spans
for
some
of
this
stuff
and
I'm
like
I'm,
I'm
hearing
like
the
same
problem
getting
expressed
in
a
couple
different
domains
here,
and
so
I
was
actually
encouraging
one
or
two
of
those
people
to
maybe
start
showing
up
here
as
well
or
at
least
getting
some
cross-pollination
going,
because
it
sounds
actually
like
a
general,
a
general
problem
that
that's
popping
up
and
it
would
just
be.
It
would
just
be
interesting.
It
would
be
great
if
we
had
some
some
more
cross-pollination
going
there.
F
Me
it
makes
me
feel,
maybe
even
more
strongly
that
we
shouldn't
be
trying
to
have
all
of
these
conversations
in
little
isolated
groups,
even
if
there
is
a
little
bit
of
crossover
like.
Maybe
we
need
this
to
be
a
like
a
first-class
spec
issue
that
we
kind
of
wrangle
out.
We
we
let
every
like-
maybe
everybody-
should
all
these
old
groups
should
come
with
their
weird
or
their
corners,
that
don't
model
quite
right
and
have
a
bigger
discussion
in
the
spec.
I'm
not
sure
how
to
coordinate
any
of
that,
though,.
B
Yeah,
I
think
part
of
it
is
just
like
a
a
backlog
problem
or
just
a
context,
switching
issue
like
with
metrics
not
being
fully
done
and
being
in
like
the
final
stages
of
getting
done
like
that,
takes
up
just
so
much
freaking
time
and
space.
My
my
hope
is
that
we
can
clear
metrics
off
the
deck
soon
and
that
would
create
more
s,
mental
space
for
people
to
be
like
okay,
I
can.
B
I
can
look
at
like
this
proposal
for
like
like
rum
events
and
this
other
stuff
and
like
have
some
brain
cycles
to
to
to
think
about
it,
but
it's
like
it's
kind
of
tough
with
with
metrics
and
logs
still
getting
processed
through,
though
I
mean
I
don't
want
to
like
halt
the
log
train,
but
man,
if
we're
talking
about
like
like
more
kinds
of
event
stuff,
I
do
feel
like
slightly
nervous.
F
B
Sure
and
then
you
know,
there's
like
like
downsides
to
just
tacking
on
another
data
stream.
You
know
but
yeah
the
I'm
suspicious
of
the
log
model,
just
because
it
is
so
basic
and
flexible
is
easy
to
just
be
like
well
everything's
a
event
now
and
then,
like
you,
can
do
that.
But
then
you
you
end
up
creating
a
huge
cost
and
pressure
somewhere
down
the
system.
B
D
So
we're
actually
we're
actually
in
process
of
putting
together
as
an
otep
for
for
this,
for,
like
we,
I
think
we
have.
We
haven't
finalized,
like
decided
like
what
we
want
to
use,
what
kind
of
signal
you
want
to
use
for
client-side
events,
but
maybe
like
in
the
other,
we
can
list
some
examples
and
the
options
that
you
can
think
of
with
pros
and
cons.
Would
that
be
useful.
B
I
think
it
would
be
useful
and
like
when
you're
ready,
like
yeah
a
presentation
at
like
the
the
spec
meeting
like
like
going
back
and
just
like
presenting
you
know.
The
thinking
that's
going
on
over
here
would
be
like
a
super
helpful
step
to
to
start
getting
more
participation
and
cross-pollination
going
yeah
yeah.
I'm
excited
to
read
it.
D
And
so
I
also
want
before
we
before
we
leave.
I
wanted
to
just
get
your
input
on
like
the
next
steps
for
the
service
name,
discussion
yeah.
What
do
you
think
we
should
do
next.
B
So
I
guess
my
request,
and
I
can
I
can
write
this
up
into
more
of
a
proposal.
If
that's
helpful
is
I
think,
to
if
the
case
is
that
we
want
the
application
developer
in.
You
know
the
interfaces
they're
using
to
set
this
stuff
up
to
look
at
it
differently
right
to
to
not
have
to
call
it
like
resource
service
name.
B
If
that,
if
that
is
like
a
helpful
solution
to
this
problem,
then
I
would
love
to
look
at
at
solving
it
that
way
and
leaving
it
as
the
service
name
space
on
the
wire.
B
If,
if
like
that's
like
really
not
going
to
work,
then
I
would
love
to
to
understand
like
what
the
what
the
requirements
are
and
how
they're
being
missed
by
by
doing
that,
because
that
to
me
would
be
the
least
disruptive
way
to
deal
with
it
from
the
data
analyst
point
of
view,
while
also
hopefully
making
it
extremely
clear
to
the
application
developer
about
what
information
they're
supposed
to
put
here
and
also
they
really
should
fill
this
information
out,
because
it's
super
important
and
it's
not
information
that
the
sdk
can
just
figure
out
on
its
own.
B
So
I
could
I
could
write
that
up.
If
that's
that's
helpful,
but
I
would
love
maybe
for
people
to
to
go
off
and
like
think
about
that
as
a
as
a
solution-
and
this
is
what.
F
That
would
work.
This
is
what
we
do
with
our
splunk
from
instrumentation
library
right
now,
because
we
don't
have
an
option
right.
It's
the
only
thing
we
can
do
is
we
expose
app
like
we
tell
the
user
to
set.
We
require
the
user
to
set
their
application
name
yeah,
but
then
we
map
it
into
service
name
when
they
actually
do
it.
Okay,
I
mean
it's,
it's
not
great,
but
it's
what
the
only
thing
we
can
do.
F
That's
why
it
sucks,
because
the
back
end,
like
you
said
your
back
end,
is
gonna.
Well,
we
actually
have
to
do
that
like
because
we
don't
want
to
display
it
in
the
ui
as
a
service
name,
so
we
turn
it
into
an
app
when
it
gets
in
our
processing
pipeline,
because
we
send
it
to
it's
completely
different
different
place,
yeah,
so
yeah
yeah,
that's.
F
We
have
to
spend
a
bunch
of
back-end
processing
cycles,
which
are
you
know
expensive
compared
to
a
end
user
device.
Would
I
mean
literally
zero
zero
information?
They
have
to
do
whether
it's
setting
one
attribute
or
another.
It
doesn't
change
anything,
but
the
back
end
actually
does
have
to
do
more
work.
B
Yeah
yeah
yeah
I
mean
this
is
the
thing
about
open
telemetry.
Is
we
support
a
lot
of
different
back-ends
to
our
different
stages
of
whatever
okay
I'll?
Try
to
think
about
that
more
and
come
back
come
back
next
week
I'll
try
to
see
if
there's
a
way
to
thread
the
needle
on
this
one,
but.
B
D
Yeah
thanks
for
joining
yeah
great
talking
to
you
guys
so
see
you
next
week
and
everyone
else
like
just
really
quick
before
we
leave,
I
we
made
some.
We
added
some
examples
of
client-side
events
to
the
plan,
doc.
So
take
a
look
at
it
if
you
haven't
yet
we'll
just
discuss
next
week
and
I
also
drafted
or
started
a
draft
of
the
otep
for
the
client-side
spans.