►
From YouTube: 2021-08-18 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).
C
C
C
I
didn't
hear
any
of
that,
but
quite
possible,
and
every
country
has
different
different
kind
of
stuff
going
on
with
boarding
planes
and
entering
always
a
surprise.
It's
quite
interesting.
C
Like
in
italy,
like
you
know,
on
the
plane
they
gave
us
like
from,
I
was
flying
from
warsaw
to
italy
right
and
gave
us
this
really
scary.
Looking,
you
know,
self-indicting
form
that
you
had
to
sign
and
an
initial
and
blah
blah
blah
that
you
would
be
quarantining.
You
know
there
was
no,
you
know,
there's
nothing
about
vaccination
and
stuff
and,
like
I
had.
C
An
online
thing
with
that
had
all
of
that
covered,
including
you
know,
vaccination
exemptions
and
all
that
and
then,
but
I
was
like
you
know,
I'm
not
gonna
sign
and
give
it
to
them.
That
will
be
pretty
bad
because
you
know
I'm
obviously
not
gonna,
be
able
to
quarantine
right.
I'm
gonna
be
going
to
the
office
every
day
and
stuff.
C
And
then
the
germans,
like
basically
forced
me
to
basically
show
at
the
check-in
a
vaccination
proof
in
this
particular
case
addition
would
have
already
worked
as
well.
So
only
then
would
you
get
your
boarding
pass.
That
was
in
milan
and
then,
when
I
was
trying
to
check
in
for
the
flight
back
from
frankfurt
to
to
san
francisco,
it
turns
out
that
in
the
u.s,
no
matter
whether
you
vaccinate
it
or
what
you
need
to
actually
show
a
pcr
test,
a
negative
pcr
test.
C
I
found
that
out
the
day
before
so,
thankfully,
there's
rapid
testing
all
over
the
place,
but
every
country
different.
C
A
D
Yeah,
there's
there's
just
one
item
on
the
agenda
as
far
as
I
can
tell
the
one
I
have
put
there-
and
this
is
more
like
an
open
question-
I'm
just
wondering
what
do
you
guys
think
about
that?
But
currently
we
have
in
the
in
the
log
data
model.
We
have
the
timestamp
that
is
associated
with
the
log
record,
and
this
timestamp
can
be
can
be
there
like
put
through
different
means,
like
it
can
be
passed
out
from
the
raw
log
record.
D
This
this
records,
if
there's
no
data
available
or
like
or
parsing
fails,
I
think
it's
typically
a
receipt,
timestamp
and
so
forth,
and
the
question
here
really
is
that,
if
maybe
it
would
make,
it
would
be
beneficial
to
have
two
time
stamps
like
one
that
is
associated
with
the
log
record
and
the
second
that
is
the
received
timestamp,
and
then
that
would
give
a
more
let's
say,
opportunities
to
make
a
decision
which
one
should
be
should
be
used.
D
For
example,
when
there's
a
back
end
somewhere,
it
can
have
some
additional
parsing
rules
and
knowing,
if
the
time
stamp
associated
with
record,
was
the
receipt
timestamp
or
the
sometimes
time
that
was
set
by
some.
I
know
library
or
something
else
would
be
helpful.
I
think,
but
then
this
brings
two
time
stamps
and
two
things
is
more
than
one
which
might
bring
confusion,
and
I'm
wondering
what
what
do
you
think
about
that.
A
Yeah,
I
remember
having
this
conversation
in
the
past.
No,
no
internally,
when
you're
working
on
stanza,
I
mean
I
yeah
to
me:
it's
not
something,
that's
a
clear.
A
A
One
thing
I
would
point
out
is
that
I
think
this
could
be
cross-cutting.
It
could
include
metrics
as
well,
so
this
might
be
something
that
they
would
want
to
weigh
in
on
I'm
not
sure
about
traces,
but
but
I
imagine
if
we
were
to
go
this
route
with
logs,
the
metrics
guys
might
want
to
go
that
way
as
well
or
they
might
push
back
and
say
we
should
you
know
we
shouldn't
do
it
unless
we're
both
doing
it,
but
and
then
the
other
thing
you
can
spend
their
thought
on
it.
A
Really
come
up
like
like
where
it
matters.
Of
course
you
can
have
this
one
with
your
back
end
when
it
was
suggested,
but
you
know
in
terms
of
when
the
collector
picked
it
up
and
between
the
time
between
that
time
and
when
it
gets
to
the
back
end.
Is
that
a
significant
is
that
significant?
In
most
cases
you
know?
Can
we
just
use
an
attribute.
E
I
know
we've
we've
had
some
substantial
problems
around
that
you
know.
I
don't
know
overall,
but
you
know
kind
of
our
take
on
it.
Is
that
the
time
in
the
event
is
the
time
that
we
care
about
which
I
think
is
probably
generally
true,
but
the
problem
that
comes
out
there
is
especially
when,
because
if
you
can't
parse
the
date,
then
you
use
the
received
date.
That's
no
problem,
but
if
you
misparse
the
date,
then
you
lose.
E
Both
is
one
of
the
things
that
we've
really
come
into
a
lot
so
yeah.
I
don't
know
as
far
as
that
goes.
You
know
if
you
misrecognize
the
date
somehow
right
now,
you're
really
in
trouble.
C
You
know,
from
my
perspective,
I
think,
from
summer's
perspective.
I
think
we
have
a
similar
stance,
which
is
you
know
what
matters
most
is
the
time
in
the
event,
and
we
do
add
like
what
we
call
receipt
time,
which
is
the
time
the
back-end
receives
it
right
that
one's
used
for
also
you
know
you
can
kind
of
you
compute
latencies,
based
on
that
and
so
forth.
You
know,
assuming
of,
of
course,
assuming
the
clocks
were
reasonably,
you
know
close,
but
but
yeah
jimmy.
What
were
you
thinking
here?
D
Yeah
that
doesn't
well.
This
is
not
a
silver
bullet,
but
this
is
like
one
of
the
solutions
that
could
be
put
here.
Another
could
be,
let's
say,
having
some
optional
tag
that
could,
let's
say,
describe
how
this
time
stamp
ended
up
with
the
record
like
if
this
was
like
provided
by
some
api,
or
maybe
this
was
parsed
or
maybe
this
is
received,
timestamp
actually
and
nothing
was
parsed
but
yeah.
D
But
then
I
think
that
I,
I
think
I've
seen
this
pattern
several
times
that
there
was
the
parse
timestamp
and
the
receipt
timestamp
present
or
associated
with
the
record
and
yeah,
because
they're
like
several
edge
cases,
for
example,
with
mobile
or
like
whatever,
when
there's
like
some
issue
with
buffering
the
back
end
might
actually
receive
locks
many
hours
after
those
were
collected
and
the
closer.
This
is
to
the
source
of
the
locks.
Then
the
chances
are.
D
D
Yeah,
I
think
at
this
point
it
would
make
sense
to
file
an
issue
and
continue
this
discussion
there
in
the
broader
group
and
see
if,
if
this
makes
sense
but
yeah,
I
just
wanted
to
run
this
idea
with
with
you
first
and
see
if
this
is
something
that
makes
some
sense
or
maybe
we
want
to
avoid
that
for
reasons
I
was
trying
to
look
through
the
discussions
we
had
on
log
data
model
and
I
think
that
this
was
not
discussed
actually,
but
maybe
I
I
wasn't
able
to
find
it.
C
No,
it
just
says
it
just
says:
basically,
timestamp
is
supposed
to
be
the
event
time
or
mp
or
null
or
whatever.
If
it
can
be
determined-
and
I
think
we
basically
said
all
the
backends
are
doing
different
things
with
rc
time
and
so
forth,
and
I
think
generally
at
least
the
sumo
characters
don't
actually
stamp
it
themselves,
which
is
probably
a
miss.
Actually,
we
should
have
already
done
that.
C
So
I'm
sympathetic
to
it
because
there's
an
additional
dimension
here
that
if
you
have
a
collector
timestamp
that
could
potentially
help
you
debug,
you
know
collection
issues.
You
know
including
meta
issues
such
as
a
timestamp
of
collections
completely
off.
D
Yeah,
so
I
think
so
from
I
think
that
it
will
make
more
sense
to
the
first
option.
So
whenever
this
log
record
comes
in
and
this
field
is
set
to
zero,
the
first
thing
that
says
it
it's
it
it
was,
it
puts
a
time.now
value
into
that
field
and
then
it
will
be
passed
down
the
stream.
Whatever
is
the
pipeline.
There.
E
A
Yeah
I
mean
it
seems
like
something
that
could
definitely
be
useful
in
a
lot
of
circumstances
in
terms
of
the
cost.
I
think
we
should
look
at
that.
You
know
maybe
some
benchmarking,
but
I
wouldn't
anticipate
much
there.
It's
just
a
feeling.
It's
gonna
ride
along.
C
E
C
Well,
matrix
is
interesting
right,
I
mean
I
think
I
looked
at
the
prometheus
business
and
there
there's
not
even
a
timestamp
it
just
you
just
like.
I
think
when
you
hit
that
matrix
endpoint
on
prometheus.
It
doesn't
even
give
you
a
timestamp.
You
just
assume
to
take
the
one
that
you
have
locally
when
you
do
the
scraping
business,
which
is.
C
F
D
Yeah
so
with
with
tracing
the
timestamps,
come
from
the
client
like
so
from
the
instrumentation
library,
and
you
always
get
like
each
time,
you
are
getting
the
trace
record.
You
assume
that
it
has
the
pretty
accurate,
timestamp
and
duration.
One.
E
D
From
the
monotonic
clock,
the
other
is
from
the
world
block
and
and
yeah
and
you
you
cannot
have
traces
without
timestamp,
but
with
logs,
as
we
all
know
like.
There
are
many
different
sources
of
logs.
Some
might
have
this
timestamp
associated
via
some
library,
and
we
know
that
it's
accurate
but
more
commonly
we'll
be
dealing
with
something
that
came
through,
for
example,
file
log
receiver
and
that
there
might
be
some
parsing
that
went
wrong
and
you
know
things
will
break,
and
this
is
where
these
things
are
becoming
interesting.
D
Yeah,
I
think
so
like
for,
for
being
able
to
make
to
you
to
use
some
heuristics
to
select
which,
for
example,
timestamp
you
should
apply
with,
because
if,
if
you
see
the
receipt
timestamp,
let's
say
august
18th
and
then
the
parsing
said
that
it's
september,
then
you
can
tell
clearly
something
went
wrong
here.
D
But
also
like
with
with
time
zones,
but
we
know
all
this
tricky
stuff
that
happens
with
with
with
parts
with
parsing
and
inaccuracy
of
data.
D
I
I
think
that
from
what
I
can
tell,
and
then
please
correct
me
if
I,
if
I
misunderstood
something
here,
I
think
that
if
you
do
not
have
a
parsing
operate,
timestamp
operator
associated
that
record
is
associated
with
the
received
timestamp.
E
C
Speak
to
a
debug
flag
of
some
sort
right
also
mean
that
would
basically
allow
us
to
capture
where
the
time
stream
come
from
right.
E
D
So
then,
like
the
record,
would
hold
this
information
that
I
I
I
I
couldn't
tell
what
was
the
time
stamp
accurately
for
that,
and
you
could
then
repairs
this
on
the
on
the
back
end,
for
example,
and
and
try
to
associate
it,
but
when,
when
it
works,
the
way
it
works
like
now,
you
can't
tell
if
this
timestamp
was
parsed
and
this
is
what
you
should
associate
with
the
record
or
this
is
or
this
is
receipt
timestamp
times
time,
which
is
not
accurate
but
more
or
less,
probably
not
not
very
far
from
when
the
lock
record
was
or
even
was
generated,
or
this
was
something
set
in
the
in
the
library,
for
example,
and
you
you
should
assume
it's
accurate
and
we've
received
timestamp
as
a
separate
field.
D
D
A
A
C
C
Yep
yeah,
because
obviously
this
time
stuff,
if
you
miss
parse,
it's
completely
lightweight
for
the
second,
because
it
blows
up
all
of
your
time-based
aggregation.
It
just
becomes
very
bad,
especially
if
you
have
a
flapping
parcel
or
something
it
just
becomes.
This
is
a
total
idea,
yep
yeah,
so
I'm
a
fan
of
actually
both
ideas.
You
know
I
would
even
go
as
far
as
saying
you
know,
maybe
propose
even
an
enum
or
something
where
whoever
gets
responsible
for
determining
the
timestamp.
C
C
C
D
Yeah,
let
me
start
with
an
issue
and
I
will
update
the
the
notes,
the
meeting
notes
with
the
with
the
issue
after
I
finish
it
and
yeah,
and-
and
I
think
that
open
telemetry
specification
is
the
right
place
to
file
this
issue,
and
then
you
can
take
it
from
there
so
yeah.
So
I'm
going
to
describe
the
problem
the
way
I
see
it
and
then
the
possible
solutions
and
feel
free
to
update
it
and
add
more
use
cases
or
ideas
how
to
solve
it.