►
From YouTube: 2021-12-15 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
A
Yeah,
it's
like
yeah,
it's
like
nine
o'clock
for
you,
9
p.m.
10
10,
o'clock,
10
p.m.
Right
now,
okay,.
A
Right
we
can,
we
can
get
started.
I
only
have
two
things
on
the
agenda
and
so
the
first
one
I
just
wanted
to
give
give
an
update
on
the
discussion
around
resources
or
the
attributes
on
resources.
A
So
there
is
now
a
long
running
discussion
around
using
source
name.
I'm
sorry,
that's
name
service,
name
and
severine,
who
who
was
here
a
couple
of
couple
of
weeks
ago
and
argued
for
service
name
to
be
the
common
descriptor
for
any
type
of
stomach
tree?
So
severine
opened
an
otep.
A
So
I
linked
I'll
link
the
old
tap
here.
If
you
have
a
chance,
have
a
look
at
it.
If
you,
if
you
have
opinions
about
this
chime
in,
I
think
the
proposal,
what
he's
proposing
is
similar
to
what
I
proposed
by
introducing
like
a
new
new
field
for
like
a
telemetry
source
name
or
something
similar
and
then
have
the
have
the
separation
of
service
and
app
attributes.
But
there
there
are
varying
opinions.
I
think
from
different
people
like
especially
from
the
maintainers
so
like.
C
I
think
it
so
I
think
this
discussion
is
good.
I
think
that
particular
issue
is
there's
a
little
bit
of
a
confusion
that
I
think
we
need
to
figure
out
how
to
tease
apart,
and
that
is
it
says
the
unique
identifier
right,
unique
identifier
and
it
sounds.
It
seems
like
they're,
more
trying
to
describe
a
unique
identifier
for
a
specific
instance,
whereas
I
think
what
we're
talking
about
is
something
that
identifies
the
app
the
app
or
the
service
right.
D
So,
even
in
the
case
of
a
back
end
for
a
given
service,
let's
say
in
a
kubernetes
environment,
the
pod
will
serve
as
the
service
instance
right.
So
there
is.
Are
they
talking
about.
C
That
it's
not
even
the
pod,
it
comes
a
pod.
A
pod
could
contain
multiple
sources
of
telemetry
right.
So
it's
not
the
pot,
because
the
pod
could
have
a
service
that
could
have
three
side
cars
it
could
have.
It
could
have
a
bunch
of
stuff
in
it
right
and
that's
multiple
planetary
sources,
so
it's
something
smaller
than
the
kubernetes
pod,
logically
yeah.
So
anyway,
there's
this
logical
thing
that
I
don't
know
how
we
even
name
what
that
is.
D
So
all
of
that
you
know
we
could
completely
ignore
right.
I
think
from
our
perspective,
you
know,
I
think
your
original
pr
had
introduced
app.name,
I
have
not
followed.
So
is
there
any
updates
on
that?
I
think
that
that's
what
we
care
about
right.
A
I
think
that
whole
conversation
got
sidetracked,
because
originally
we
thought
we
would
have
either
source
name
or
app.name,
but
I
think
right
now,
there's
some
people
think
I
don't.
I
don't
know
exactly
the
reality
of
this,
but
some
people
think
that
the
source
name
is
currently
required
and
used
as
like
the
common
descriptor
for
any
type
of
telemetry.
D
Yeah,
I
think
I
I
will.
Is
it
severan
that
if
it
is
severine,
then
I
can
reach
out
to
him
separately
and
clarify
to
him
that
service
name,
you
know,
will
not
serve
our
purpose
and
this
telemetry
source
id
telemetry
instance.
Id
is
a
completely
different
topic,
so
you
know
these
two
points.
I
can.
Let
me
reach
out
to
him
and
clarify
and
we
need
app.name
so.
B
C
I
think
severan
gets
it
when
he
was
here
a
couple
weeks
ago.
I
think
he
understands
what
we're
after.
I
think
the
issue
is
more
on
the
technical
committee
rather
than
on
the
severance
side.
A
C
I
will
try
to
add
a
comment
to
the
hotep
today
on
trying
to
trying
to
emphasize
that
we
need
to
separate
these
two
ideas
of
the
instance
id
and
the
more
generalized
source
of
telemetry,
which
again
I
don't
have
a
name
for
I
don't
know
what
that
is.
I
mean,
I
think
people
say
it's
a
service,
but
of
course
it's
an
app
or
a
service
or
a
network
device
or
a
load
balancer
or
I
mean
yeah
any
of
those
things
could
be.
This
thing
I'm
talking
about
it's
a
thing
with
a
name
that
emits
telemetry.
C
D
No,
I
think
I
think
the
this
group
fully
understands
that
so
should
we
create
a
new
tip,
I
think
the
current
one
that
seven
created
it's
for
a
different
issue
right.
Maybe
we
should
create
a
new
tip.
C
C
A
D
I
can
take
that
up,
we
just
initially
circulate
it
with
you
all,
and
then
we
can
create
a
whatever
issue.
A
E
A
This
is
this
is
the
this
is
the
pr
that
I
opened
to
add
to
add
the
telemetry
source
attributes,
which
is
similar
to
severin's
idea.
But
the
reason
for
this
was
that
there
was
there
was
yeah.
There
was
an
argument
whether
like
service
name
should
be
used
like
all
the
time
or
like
if
it
should
be
like
servicename
or
app.name.
A
So
what
I
so
part
of
the
things
that
I
did
here
like
I,
I
kind
of
some
like
summarize,
like
the
requirements
that
I
think
we
have
so
one
was
to
be
able
to
identify
the
type
of
telemetry.
A
So
that's
kind
of
like
one
of
the
our
original
needs.
Why
we
introduced
add
the
ad
attributes,
then
there
was
then
we
strongly
argued
that,
like
we,
we
don't
want
to
use
service
attributes
because
it's
not
intuitive
to
to
users.
So,
like
we
that's
one
of
the
reasons
we
want
to
use
app,
attributes
correct
and
then
I
think
severin
severin
was
trying
to
clarify
that
service
name
is
like
a
common
attribute.
That's
that's!
A
That
identifies
like
the
name
of
the
the
source
of
the
resource,
so
so,
like
part
of
this,
like
adding
adding
telemetry.source
kind
of
satisfies,
like
the
need
of
having
a
common
attribute
for
independent
of
the
type
and
like,
I
think
that
one
of
the
arguments
was
like
you
know
like.
Potentially
you
don't
want
to
have
like
multiple,
multiple
different
names.
A
You
know
like
you
would
have,
you
would
need
back-ends
back-ends
would
have
to
be
looking
for.
Does
it
have
a
service
name?
Does
it
have
a
app
name
like
which
ones
which
one
do
do
I
use
and
there
could
be
potentially
other
types
of
telemetry
in
the
future,
so
then
like
it's,
get,
could
potentially
get
complicated
for
back
ends
like
to
know
like
which
name
where
to
get
the
name
from.
A
So
that's
was
kind
of
the
reason
for
introducing
like
an
independent
kind
of
generic
set
of
attributes
for
ident,
identifying
the
the
telemetry
like
the
the
source
of
telemetry
independent
of
the
type,
and
then
the
last
thing
that
was
that
was
brought
up
is
that
service
dot
name
is
currently
is
currently
required
by
a
lot
of
back-ends.
A
I
think
correct
me
if
I'm
wrong
john,
but
I
think
it's
it's
prometheus
that
requires
it
and
I
actually
new
relic
requires
service
dot,
name
too
right
now,
so.
C
Most
most
back
ends
require
some
sort
of
way
to
group
together.
Your
telemetry
into
that
thing
that
I've
been
talking
about,
like
it's
been
service
name,
is
what
has
been
used
for
that
right,
like
I,
it's
a
it's
a
user
facing
identifier
for
this
thing
that
they
deploy
into
many
instances
almost
every
almost
every
back-end
that
I'm
aware
of,
require
or
needs
this
in
order
to
provide
a
user
experience.
That
makes
some
kind
of
sense.
D
Yeah,
so
actually
I
for
a
second,
if
we
think
about
using
service
dot,
name
for
the
mobile
applications
and
browser
applications.
D
A
Well,
I
think,
there's
people
who
think
that
it
should
be
used
that
it's
okay
to
use
service
dot
name,
but
I
does
that
mean
we
would
want
to
use
like
service
for
all
the
other
attributes
as
well
or
would
we
still
have
app
attributes.
D
D
Okay,
maybe
in
the
text
that
I
will
write
I'll,
maybe
I
should
I'll
I'll
make
that
explicit.
D
Okay,
so
this
pull
request
that
you
were
showing
was
that
a
pull
request
or
an
issue.
A
A
Yeah,
the
on
the
one,
the
one
last
piece
of
information
that
I
that
we
also
discussed
separately,
is
that
if
we
used
service
dot
name
and
then
add
for
everything
else,
then
then
all
the
other
app
attributes
are
optional.
Currently,
so,
if
if
they
were
left
out,
then
we
wouldn't
have
no
way
of
identifying
that
as
the
client-side
resource.
C
A
A
Okay
and
then
the
other
topic
that
I
wanted
to
just
quickly
ask
you
about
is
there
is
a.
I
don't
think.
There's
was
that
discussion
about
blog
name
field
santosh.
I
think
you
were
involved
in
that
discussion
yeah.
A
D
So
I
think
the
issue
that
issue
for
that
topic
was
closed
a
few
days
ago.
I
think
it
was
decided
that
the
name
field
will
remain
yeah.
It
was
being
debated
whether
the
name
field
should
be
you
know
removed,
and
I
think
it
was
decided
that
it
should
be
left,
as
is,
which
means
that
we
could
use
the
name
field
to
represent
the
events
name,
so
that
all.
D
So
now
it's
so
it's
a
matter
of
defining
semantic
conventions
for
for
different
events
that
are
of
interest,
and
we
should
just
define
standard
names.
Okay,.
A
Yeah,
so
I
think
the
the
confusion
still
was
around.
A
So
there
is
there's
a
need
for
for
like
like
distinguishing
regular
logs
from
from
events,
and
I
think
there
will
be
like
a
lot
of
different
use
cases
for
events.
There
could
be
when
there's
going
to
be
client-side
events,
there
could
be
like
a
custom
events.
There
could
be
events
coming
from
infrastructure.
A
D
No,
I
think
there
has
to
be
again
if,
if
the
requirement
is
that
the
back
end
processing
has
to
say
I
mean
has
to
segregate
logs
from
events,
then
then
we
either
need
or
if
we
know
that
the
logs
are
not
going
to
use
the
name
field,
then
maybe
name
if
the
name
field
is
present,
then
it's
even
but
given
that
we
are
talking
about
events
only
now,
but
name
always
existed.
D
That
means
that
the
log
records,
probably
you
know,
also
use
the
name
field.
So
there
has
to
be
some
other
way
to
distinguish
logs
from
events.
So
maybe
we
could
have
a
convention
that
you
know
all
the
events
have
some
standard
prefix
for
for
the
name
field,
it's
the
event
dot.
You
know
the
event
name
and,
and
the
log
records
you
know.
Hopefully
you
know
don't
start
with
event
dot.
B
D
A
Yeah,
so
I
think
so
so
someone
from
from
europe
is
going
to
try
to
open
an
issue
around
this
okay,
so
I
I
just
wanted
to
get
your
like
opinion
on
this
and
like,
if
you're
going
to
argue
from
our
client
side
like
what
would
work
for
us.
D
Yeah,
I
think
I
don't
think
it's
necessarily
to
do
with
the
client
side
as
long
as
it
is
whether
it
is
client
side
or
a
back
end.
I
think
the
the
first
thing
is
to
segregate
log
records
from
logs
from
events.
D
So
let's
say
if
the
name
space
is
events,
let's
say
event:
dot
is
the
name
space
for
the
name
field.
Then
that
is
the
first
thing
and
then
further.
If
you
want
to
distinguish
between
client
and
the
client
side
of
the
back
end,
I
think,
based
on
the
telemetry
source
type,
maybe
the
service
name
or
something
I
I
don't
know
it
could
get
complicated
from
there.
D
I,
I
probably
you
know
we
don't
need
to
further
distinguish
the
name
itself.
Is
globally
unique.
You
know
named
event,
so
the
entire
event
name
could
be
globally
unique,
like
the
backend
events
will
have
a
different
name.
The
client-side
events
have
a
different
name,
so
that
alone
might
be
sufficient
to
distinguish.
A
A
D
D
Open
an
issue
I
mean
what
kind
of
whether,
whether
should
it
be
an
issue
or
a
pr.
You
know
for
including
those
api
definitions
in
the
logs
spec.
What
should
it
be.
A
Yeah,
I
don't
know,
because
it
does
that
that's
like
that
kind
of
api.
What
is
what
is
like?
I
guess,
where
is
the
api
defined
right
now.
A
D
So
in
in
what
form
you
know,
should
we
submit
these?
This
should
be
like
some
written
general
text,
or
is
it
and
I
I
don't
know
how
to
take
this
forward.
C
Well,
so
I
I
think
this
sounds
like
a
perfect
opportunity
for
another
otep
to
start
defining
the
client
event.
I
mean
I
don't
know
if
this
needs
to
be
restricted
to
clients,
but
at
least
we
could
start
with
a
restricted
client
event.
Api.
C
C
A
D
A
So,
like,
I
think,
our
basically
from
from
our
perspective,
you
know
we
just
need
a
way
like
to
identify
like
separate
like
the
clan
side.
Client-Side
events
from
from
regular
logs.
A
And
santosh
thought
that
maybe
just
having
just
being
able
to
look
at
the
value
of
name
and
like
have
a
prefix
in
in
the
name
in
the
value
of
name
should
maybe
could
work
as
identifying
that
as
a.
E
So
this
is
using
the
the
new
proposed
logger
name
field.
Is
that
what
you're
saying.
D
If,
if
that
name
starts
with,
let's
say
event
dot,
then
you
know
those
are
named.
Events
using
the
log
recorder.
E
Is
landed
yet
so
the
name
field,
just
so
I'm
on
on
the
same
page
with
y'all.
What's
an
example,
then
of
a
value
for
that
field.
For
one
of
these
client-side
events.
C
E
So
we
were
talking
about
this
martin
and
myself,
and
a
few
others
were
talking
about
this
at
length
yesterday
and
I
had
an
idea
that
I
am
interested
in
passing
by
this
group
first,
but
you
know
maybe
moving
it
up
into
the
spec.
E
You
know
respect
discussion,
so
I
guess
if
I
were
to
frame
what
y'all
are
trying
to
do
and
I
haven't
to
be
honest,
been
present
with
many
meetings
so
like
I
might
not
have
a
100
accurate
picture,
but
if
I'm
to
attempt
to
frame
which
all
they're
trying
to
do
is
you're
trying
to
build
a
new
feature
upon
an
existing
data
model
designed
by
the
open,
telemetry
community,
the
log
data
model,
and
that
makes
complete
sense
to
me.
E
I
think
I
attended
the
first
of
these
meetings
and
morgan
mclean
came
on
and
I
think
said
it
clearer
than
I
heard
it
before.
He
basically
said
like
hey,
listen,
you
know
it
take
it's.
It
takes
a
long
time
to
create
a
new
data
model
and
to
have
all
the
conversations
necessary
to
settle
in
on
something
so
his
big
push.
His
recommendation
was
just
use
the
log
data
model.
E
If,
if
you
can
so
anyways,
it
sounds
like
it's
going
down
that
path,
and
now
I'm
thinking
like
you
know
there
might
be
other
things
in
the
future
like
client-side.
E
Instrumentation
is
just
one
thing
and
the
thing
that
just
kind
of
occurred
to
me
last
night,
as
I
was
thinking
on
this
some
more-
is
that
we're
basically
inventing
like
a
new
signal.
Maybe
you
know
we
got
metrics,
we
got
traces.
We
got
logs
right
that
are
super
codified
within
open
telemetry.
E
But
what,
if
we
fully
embrace
this
notion
of
making
the
log
data
model
extensible
so
that
it
can
represent
things
of
different
signal
types?
So
I'm
thinking
of,
like
that's
my
proposal
like
adding
something
to
the
log
data
model,
that's
like
signal
type
and
if
it's
empty,
like
I'm
a
log,
unless
I'm
told
that
I'm
something
else
basically
like,
I
have
a
signal
type
of
something
else,
because
the
open,
telemetry
community
has
decided
it's
going
to
build
a
new
new
functionality
so
like
in
this
case.
I
think
what
that
would
be
for,
like
the.
C
E
User
monitoring
would
be,
it
would
just
be
like
a
static
value
like
rum
or
something
like
that,
and
then
the
name
field
could
still
be
used
in
the
way
that
that
geologist
described
in
terms
of
like
there's
a
there's,
a
variety
of
different
events
that
fall
within
within
rum
but
like
just
like.
We
classified
trace
metric
and
log
data.
C
C
We
want
to
use
the
logging
data
model
and
we
want
to
create
a
new
event,
api
or
rom
api
or
something
api
that
sits
on
top
of
both
the
log
data
and
trace
data
and
potentially
metrics
data
as
well,
but
that
we
want
to
use
those
three
signals
but
then
create
an
api.
That's
very
specific
to
client-side
monitoring.
E
This
is
wrong,
like
I
don't
want
to
like
look
at
like,
I
don't
want
to
look
at
individual
attributes
on
that
payload,
I
don't
want
to,
like
you
know,
have
a
have
a
big
list
of
events
that
are
that
are
rum
events
and
constantly
be
maintaining
that
list.
I
just
want
to
know
like
this
is
a
rum
thing
like
put
it
over
here.
C
Yeah,
I
think
all
of
us
who
have
worked
on
on
rum
like
either
from
the
instrumentation
side
or
from
the
back
end
side.
I
mean
that's
how
my
job
is
working
on
the
back
end
side.
Like
the
analysis
you
do
on
that
data
is
very,
very
different
than
the
analysis
you
do
on
service
data
and
we
need
back-ends
need
a
way
to
distinguish
between
those
two
things,
and
I
think
this
is
the
whole
point
of
kind
of
what
martin's
been
working
on
trying
to
create
some
sort
of
resource
structure.
E
I
see
so
you
think
you
think
this
the
resource
doing
things
that,
like
attributes
at
the
resource
level,
is
going
to
solve
this
problem,
for
you
versus
this,
like
thing
that
I'm
rattling
off
like
just
like
this
signal
type
thing.
C
A
Yeah
I
mean
I
was,
and
that's
sort
of
like
why
I
was
I
was
asking
about,
does
will
client
side
produce
regular
logs
as
well
like
in
the
same
like
so
like
and
then
like?
If
it
does,
then
then,
like
you,
would
route
it
to
that
pipeline.
That
processes,
if
you
just
use
a
resource
to
identify,
then
like
everything,
would
be
routed
to
the
pipeline
for
a
client
side.
But
then
the
client
side
would
still
need
to
distinguish
between
logs
and
events
right.
C
Well,
that
is
an
interesting
that
is
an
interesting
question
like,
for
example,
if
we
somehow
are
able
to
take
the
android
logging
subsystem
and
grab
that
data
and
send
it
to
a
back
end
as
well.
For
example
like
we'd,
want
to
distinguish
those
android
kind
of
regular
old
android
logs
from
the
events
coming
from
wrong.
C
Yeah
I
had
not
pondered
it,
but
that
would
be.
That
is
something
that's
going
to
be
important
because
you
wouldn't
want
to
send
arbitrary
logging
data
to
your
generic
or
to
your
specific
rum
analysis
back
end.
I
don't
think
feels
like
those
we
need.
I
mean
something
somewhere
is
going
to
need
to
be
able
to
distinguish
between
those
things.
C
A
A
C
Perfect
example,
the
new
relic
like
event
like
custom
event,
api
right,
like
you,
want
to
be
able
to
distinguish
those
custom
events
and
send
them
to
your
insights
back
in
versus
your
logging
back
end,
which
we
all
know
it's
the
same
backhand,
but
we
know
we
want
to
actually
distinguish
it
differently.
Right,
like
you,
do
you
wouldn't
want
those
two
things
to
end
up
in
the
same
place
or
this
at
least
you
need
some
way
to
distinguish
between
the
two
of
them
so
that
they
can
be
properly
put
in
the
right,
uis,
etc.
C
E
E
That,
like
I,
just
don't
think
that
I
don't
have
a
good,
a
good,
persuasive
argument
right
now,
but
I
just
my
gut
says:
resources
and
resource
attributes
and
resources
is,
as
martin's
just
highlighted,
isn't
going
to
solve
the
problem.
All
the
time,
and
I
don't
think
attributes
on
the
actual
telemetry
is
gonna
be
sustainable.
E
They
make
their
own
effectively
like
an
open,
telemetry
terms,
their
own
signal
types
right
via
custom
events,
and
I
guess
the
beauty
of
using
the
log
data
model
in
terms
of
inflammatory,
is
that
if,
if
a
back
end
wants
to
display
that's
that
data,
as
in
whatever
their
log
user
experience
is
like
that's
pretty
legit,
but
if
a
backend
has
some
other
means
to
represent
that
data,
you
know,
that's
a
that's
a
that's
an
ability
for
a
vendor
to
differentiate
itself
in
a
in
a
way.
E
You
know
and
allow
customers
the
flexibility
of
defining
their
own
signal
types
if
they
want
to,
and
also
open
telemetry,
to
have
a
have,
a
more
standardized
way
to
build
other
solutions
in
the
community
like
rom.
I
just
don't
have
a
good
example
beyond
rum
today.
You
know.
C
I
know
that
there
I
haven't
followed
the
log
say
carefully,
but
I
thought
there
was
also
some.
At
least
there
was
a
pr
or
a
discussion
about
having
a
log,
a
log
type
or
log
source.
C
Maybe
it
was
a
log
source
and
maybe
the
log
source
would
be
a
way
to
distinguish
this
between
log4j
versus
custom
event
api
or
something
I
don't.
I
don't
know
I
again.
I
don't
I'm
not
super
super
familiar
with
all
the
details
of
the
logging
data
model,
but
it
might
be
worth
pouring
through
there
and
seeing
if
there's
a
handle
that
could
be
used
for
this
already
that
we
could
bring
up
for
discussion.
C
Okay,
I'll
look
at
that.
Is
it
log
source?
I
thought
it
I
mean
again.
This
is
just
I
saw
some
pr's
fly
by
or
something-
and
I
didn't
pay
too
much
attention
to
them,
but
there
was
something
like
describing
the
original
source
of
the
logs,
whether
it
was
coming
from
a
user
log
or
from
a.
I
don't
remember
the
details
anyway
I'll.
Let
you
look
into
it.
D
Also,
I
think,
when
you
use
the
term
custom
signal,
I
am
a
little
confused,
you
know
what
do
you
mean
by
a
signal
itself,
because
if,
when
we
look
at
the
traces,
metrics
and
logs,
you
know
these
are
very
high
level.
It's
clear
there
are
going
to
be
entire
backend
systems
that
will
be
built
to
interpret
these
three.
You
know
separately.
D
D
Is
it
at
the
same
level
as
the
metrics
crisis
log
records?
Is
it
going
to
be
completely
a
new
data
type
so.
E
In
some
sense,
like,
I
think,
the
I
think
the
fact
that
we
have
metrics
traces
and
logs
is
like
the
three
pillars
of
of
open
telemetry
and
we've
defined.
Those
as
signals
is
almost
kind
of
arbitrary.
I
mean
it
was
a
decision
that
was
made
but,
like
you
could
take
traces
and
you
could
take
metrics
and
I
believe
that
you
could
probably
shim
them
into
a.
E
You
could
probably
take
all
three
of
these
things:
traces,
metrics
and
logs
and
represent
them
in
a
more
general
data
model,
everything
about
a
metric
and
everything
about
a
trace.
You
know
you
could
you
could
capture
effectively
as
like
a
set
of
attributes
on
a
on
something
like
in
the
log
data
model,
so.
E
There's
already,
the
open,
telemetry
community
has
already
gone
beyond
and
said,
like
yeah,
but
we're
going
to
actually
create
traces.
It's
like
this
first
class
thing
and
we're
going
to
create
metrics
as
this
first
class
thing,
and
if
you
want
another
first
class
name
well,
then
you've
got
to
like
cooperate
with
open,
telemetry
community.
E
You
got
to
define
like
this
massive
data
model
and
so
on,
and
I'm
seeing
the
log
data
model
as
like
the
lightest
weight
of
all
the
things
and
have
has
the
biggest
potential
for
being
extensible
for
other
purposes
like
I
don't
in
some
sense,
like
alolita,
I
think,
is
put
the
first
like
proposal
out
there
for
rum
events
being
like
maybe
a
new
signal
type
right,
but
of
course
the
community
talked
about
that
and
was
like.
E
No,
you
know
we
can
use
this
data
model,
but
in
some
sense,
like
I'm
wondering
if
there's
still
a
little
bit
of
truth
in
that
that,
even
though
you
all
are
using
the
log
data
model
to
ultimately
represent
this
like
is
it
thought
in
people's
minds
that
it's
a
it's
a?
It
is
a
separate
signal
type.
It
kind
of
seems
to
me
that
in
some
way
it
is.
D
A
separate
signal
for
events-
and
maybe
you
know
a
session
so
session
we
said-
is-
is
another
type
of
an
event
itself.
D
So
essentially
it's
just
events
and
I
think
when
we
say
a
first-class
data
model
for
metrics
and
process
logs,
you
know
we
are
building
corresponding.
You
know
entire
subsystems
for
each
of
these.
In
the
background
so
for
custom
signal,
you
know
what
would
be
the
back
end
subsystem
that
you
would
build.
I
think
that
is
not
clear,
because
unless
the
back-end
processing
is
defined
on
how
to
process
the
data
coming
for
the
signal,
it
wouldn't
be
a
new
signal.
E
So
I
don't
exactly
know
how
things
will
pan
out
at
new
relic,
but
in
those
terms
right,
like
whatever
comes
of
the
client-side
instrumentation.
E
It
wouldn't
surprise
me
if
we
do
have
a
separate
set
of
services
and,
like
back
end
for
dealing
with
that
data
versus
regular
log
data,
which
we
process
very
differently
right,
like
structured
logs,
come
in,
and
we
do
a
bunch
of
like
pattern
matching
and
so
on.
An
interesting
processing
over
that
that
you
wouldn't
wouldn't
be
necessary
in
the
in
the
context
of
room
events.
So
that's
that's.
D
Yeah
now
I
think
fair
enough,
I
think
it
is.
It
is
already
agreed
that
events
is,
you
know,
should
have
been
a
separate
signal
and
we
are
using
in
a
log
record
for
that
purpose,
and
I
think
martin
already,
you
know
mentioned
that
we
need
a
way
to
distinguish
these
two
logs
and
the
events
so
that
back-end
systems
could
be
built
to
distinguish
these
two.
D
But
in
addition
to
this,
when
I
think
I'm
not
clear
only
about
the
term
custom
signal,
on
top
of
you
know
the
rum
events,
in
addition
to
ram
events,
when
you
say
custom
signal
what
back-end
processing
you
know,
do
you
have
in
mind,
would
it
be
common
or
would
it
be?
You
know,
on
a
case-to-case
basis,
I
think
that's
the
conclusion.
E
A
The
other
example,
like
I
think
we
mentioned,
was
from
from
let's
say
from
like
a
user,
an
analytics
perspective
like
even
in
the
client
side.
Let's
say
that,
like
you,
would
have
an
api
where,
like
some
event,
happens
like
point
of
sale
or
something,
you
know
that
that
they
want
to
capture
for
like
business
and
analytics
so.
D
Yeah
yeah
no,
but
but
at
the
end
of
it
these
are
all
all.
These
are
examples
of
named
events,
and
you
know
you
could
just
use
the
value
of
the
name.
Field
to
you
know
do
different
things
with
each
of
these
different
types
of
events,
but
the
you
know
there
could
be
one
common
event
store
or
an
even
processing
system.
D
You
know
which
could
have
be
plugins
or
extensions
to
you
know,
perform
processing
differently
based
on
the
name
of
the
event.
But
the
event
is
the
signal
here
and,
and
there
is
the
one
you
know
it's.
E
I
guess
the
it's
really
I
my
question
is
probably
best
posed
to
designers
and
operators
of
the
back
end
systems
that'll
be
receiving
this
data
and
routing
the
data
to
the
correct
system,
and
my
question
would
be
you
know
if,
if
you
have
this
name,
the
name
field
is
the
thing
you
know
you've
got
like
a
rum
is
like
a
class,
I'm
I'm
using
the
term
signal
because
I'm,
I
kind
of
think
of
it.
That
way.
E
It's
and
and
and
y'all
have
said,
like
there's
going
to
be
some
set
of
of
types
of
events
underneath
that
and
so
back
end
systems
are
going
to
need
to
one
be
aware
of
that,
set,
that's
going
to
need
to
be
decided.
E
Those
named
those
named
events
are
going
to
need
to
be
decided
by
the
community
before
any
back-end
system
can
necessarily
like
you
know,
know
yes,
so
yeah
yeah.
This
one
is
also
a
rum
thing,
so
put
it
over
here
and
that
to
me
introduces
well.
This
is
my
big
question.
I
think
that
may
introduce
a
maintenance
burden
right,
as
things
evolve
in
the
community.
C
E
As
back
ends
want
to
stay
on
top
of
that,
they're
gonna
need
to
stay
apprised
of
like
what
those
different
named
event
types
are
and
if
they
change
or
if
they
are
added
to
or
if
some
get
deprecated
like
that's
that'll,
be
a
continual
maintenance
burden.
But
if
I
just
had
like
this
single
kind
of
classifier,
saying
like
this
should
go
to
my
rum
back
end,
you
know-
or
this
should
go
to
my
infrastructure
back
end-
that
deals
with
kubernetes
events.
Then
at
least
at
least
that's
decided
right.
D
A
D
E
Yeah,
I
know
yeah
I'm
aware
of
that.
I
we
intend
to
talk
with
them
as
well.
In
some
sense,
I'm
I'm
thinking
that
like.
If,
if
what
I'm
proposing
has
any
legs,
you
know
that
it
would
be
an
additive
thing,
so
I
don't
know
that
it
would
be
the
end
of
the
world
if
it
didn't
it
landed
before
things.
E
E
The
just
for
a
little
bit
more
context.
Santosh
martin
mentioned
like
this
point
of
sale
type
of
thing.
That
is
a
thing
that
muralic
customers
do.
They
create
like
their
own
custom
events,
and
something
that
would
happen
today
is
if
a
customer
wanted
to
use
the
name
field
and
say
hey.
This
is
like
my.
This
is
my.
This
is
something
about
my
point
of
sale
system
right
today,
right
like
obviously
that's
not
going
to
be.
E
That
name
is
not
going
to
be
defined
in
any
of
our
like
communities,
semantic
conventions
right,
it's
going
to
be
totally
made
up
by
the
customer
like
for
their
specific
use
case.
So
today,
from
a
back
end,
operator's
perspective,
that's
going
to
get
lot!
That's
going
to
get
routed
to
our
to
our
logging
back
end.
E
You
know
which
does
it
has
all
this
like
functionality
about,
like
parsing
pricing,
structured
logs
and
doing
interesting
analysis
over
that
which
isn't
totally
invested
unnecessary
for,
like
maybe
this
customer's
use
case
of
this
of
this,
what
we
call
custom
events.
D
So
one
way
to
approach
that
would
be
to
not
expose
the
data
model
itself
to
the
customers
too
much,
but
only
the
api.
So
on
top
of
the
basic
apis
that
we
just
talked,
I
think
we
could
even
add
apis
for
custom
events
for
customers
to
use
where
you
know
in
the
implementation.
You,
you
know
you,
you
add
the
prefix.
You
know
to
indicate
that
you
know
these
are
customer
defined
custom
events.
E
D
How
do
you
say
it?
It
is
accommodating
it.
You
know
it
defines
the
data
type
to
be,
let's
say
binary,
whereas
the
api
says
it's
a
string
right.
So
if,
if
customers
start
looking
at
the
protobuf
and
it
has,
this
has
been
a
confusion,
even
within
our
organization,
where
people
look
at
the
data
model
and
say
hey,
you
know,
the
attribute
name
can
be.
D
You
know
binary,
whereas
the
api
specification
says
it
has
to
only
be
a
string
attribute
value,
so
it
is
very
confusing
and
and
therefore
it's
important,
that
when
we
it
is
confusing
to
us
developers
itself.
So
you
know,
customers
are
like
three
layers
later
and
if
they
start
looking
at
the
data
model
definition,
I
think
it's
going
to
get
very
confusing.
It's
going
to
go
wrong.
E
E
E
E
One
there's
another
member
of
our
team
that
we've
been
discussing
with,
and
he
was
thinking
about
putting
an
issue
I
think-
and
at
least
starting
with
open
telemetry
specification,
an
issue
just
about
this
about
this
proposal,
which
of
course,
you
know,
we
have
varying
kind
of
ideas
and
thoughts
already.
E
But
do
you
mind
if
we
at
you
santosh,
just
to
kind
of
like
get
your
get
your
input
there
it'll
be
about
it'll,
probably
be
a
specification
issue
about
like
the
log
data
model
is
just
to
get
this
conversation
a
little
broader.
D
Sure
definitely,
I
think
you
know
in
case
you
want
to
join
the
log
sig
meeting.
I
think
they
meet
at
10
o'clock
pst
today,
oh
okay,
okay,.
D
Yeah
but
today
I
won't
be
able
to
join
I'm
currently
in
india
it's
late
already,
but
if
you
are
interested
you
could
join
it's
at
10
o'clock,
psp.
E
I
think
I
will
today
and
jack
from
our
team,
who
has
been
actually
attending
that
sega
he'll
he'll
probably
be
there
as
well.
So,
okay,
okay
yeah!
Thank
you
sure.
A
Okay,
great
discussion:
we
are
at
time
so
thanks
for
your
time
and
yeah
santosh
are
you
gonna
be
able
to
attend
next
week
or.
D
I
I
next
week
I'll
try
yeah.
A
Okay,
yeah
it's
it
might
be,
it
might
be
probably
short
but
I'll
attend
next
week
as
well.
Yeah.
D
Yeah
in
case,
I
cannot
I'll
send
you
a
message
but
I'll
I'll
I'll.
Try
all.