►
From YouTube: 2021-09-09 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
Good
yeah,
I
joined
the
one
last
week
and
we
kind
of
like
I
think
we
needed
more
time,
but
I'm
not
really
sure
see
if
jonna
joins
up,
because
she
was
kind
of
she
had
a
bunch
of
things
on
the
agenda.
B
A
Yeah,
I
think
we
have
a
longer
session
today.
The
idea
was
so
the
I
think
jonah.
I
don't
remember
if,
if
you
had
background,
if
we
gave
you
the
background
so.
A
The
work
group
was
built
to
make
recommendations
in
regarding
acceptance
of
the
this.
You
know
open
source
contribution
into
open
telemetry
the
flow
mill
collector
yeah.
So
we
had
several
questions
over
the
last.
I
think
couple
months,
three
months,
maybe
two
two
and
a
half
months,
and
I
think
we
figured
out
most
of
what
you
know
how
we
want
the
contribution
to
look.
What
is
the
road
map
and
to
get
it
accepted,
and
so
I
think
what
we
were
going
to
talk
today
was
to
summarize
those
I
hope.
A
B
A
I
don't
remember
what,
if
we,
if
we
said,
we'd
join.
A
We
did
say
make
it
this
time,
or
was
it
half
an
hour
later?
It
was
this
time
right.
A
B
A
more
bad
one,
yeah
yeah
yeah,
it's
kind
of
annoying
how
you
have
to
subscribe
to
it
like
through
google
groups
or
something
bizarre,
it's
a
weird
setup
to
get
the
invite
updates,
but
so
so
you're,
basically
waiting
for
janna
to
join.
B
A
They
are
the
quorum,
I
think
founding
members,
so
at
least
have
both
of
them
on
the
traffic.
B
Resolution
yeah-
and
you
were
at
flowmill
prior
to
here
at
splunk,
now
right.
A
B
A
And
my
co-founder
mike
is
doing
product
for
us
right
now
and
I'm
the
architect
and
we've.
C
A
A
A
Yeah,
it's
it's
a
great
opportunity.
I
think
this.
This
is
something
that
we
we
thought
the
community
should
have
for
a
long
long
time
and
we've
been
building
it.
You
know
being
as
a
business
having
a
company
around
it.
We
built
it
to
kind
of
enterprise
standards.
So
it's
not
sure
we
hope
it's
less
wonky
than
what
what
other
projects
might
might
do
kind
of.
If
a
it
it's
it's
not
like.
We
wanted
to
build
it
just
for
like
it's,
not
we're
netflix
and
we're
building
it
just
for
netflix.
D
B
A
B
A
Is
it
also
ebpf
related.
B
It's
flow
analytics
they're,
the
biggest
flow
analytics
company
out
there
in
terms
of
sas.
Yes,.
B
They've
open
source
yeah,
they
open
sourced
that
recently,
along
with
a
few
other
components
that
do
flow,
translation
and
other
things.
They
just
announced
it
a
few
weeks
couple
weeks
ago,
most
of
it's
in
rust,
the
collectors
and
a
lot
of
the
core
technology
that
does
all
the
high
throughput
stuff.
You
know
processing
billions
of
flows
per
second,
so
yeah
yeah,
it's
a
it's
a
pretty
cool
company,
the
scale,
but
the
service
provider
and
cdn
side
gaming
companies,
all
that
stuff,
so
yeah
definitely
fun.
A
Did
you
say
you
were
you're
now
at
logs
right
logs
io.
B
A
B
I've
been
here
for
a
year
and
a
half
or
so
yeah,
it's
good.
We
don't
do
any
ebpf
stuff,
but
we're
paying
close
attention
to
the
pixies
work.
That's
going
on
because
we're
interested
in
using
that
or
integrating
it
better
to
prometheus
and
jager
so
yeah.
I
work
on
jaeger,
more
jaeger
and
open
telemetry,
but
more
jaeger.
These
days,
so
yeah.
A
B
Collection,
but
it's
for
kubernetes,
so
it's
pretty
focused
on
debugging
and
profiling,
kubernetes
and
obviously
kubernetes
is
service
oriented
in
general,
but
that's
where
they
focus
they
just
they
kind
of
did
something
weird
where
most
of
the
data
collection
is
local
and
like
they
don't
have
a
lot
of
like
cloud
I
mean
you
can
integrate
it
to
cloud
services,
but
it's
generally
designed
as
like
a
more
of
a
local
debugger
but
yeah
it's
it's
pretty
cool
technology
and
yeah
they're
using
ebpf
for
a
lot
of
it
so
yeah.
B
Well,
I
guess
no
one
else
is
showing
yeah.
B
Today,
I'm
gonna
jump,
so
I
can
eat
a
little
something
here
before
my
next
call
in
20
minutes,
but
it
was
good
to
catch
up
and
that's.
A
B
Maybe
jana
will
join
in
at
half
past.
Who
knows-
I
don't
know
but
yeah
I'll,
keep
watching
and
see.
If
I
can
help
the
cause
out,
because
I
think
a
lot
of
cool
things
we
could
do
with
it
in
the
collector
for
sure
so,
yeah
thanks
john
cool.
Take
it
easy.
B
D
D
E
So
far
good
you
know
it's
always
busy.
So
yeah
we
should
still
sync
up
at
some
point.
Yeah
offline
be
good
to
chat.
E
I
know
last
time
I
said
I
was.
I
was
off
yeah
that
week,
but
anyways.
A
B
A
A
D
D
I,
like
your
polka
dot
mask.
I
like
had
trouble
parsing
what
it
was
at
first.
A
Yeah
well,
luckily,
I
found
a
room,
I'm
I'm
in
the
children's
museum.
Oh
really,
oh
yeah,
I'm
thinking
about
I'm
thinking
I
was
just
telling
you
I
mean
I'm
taking
a
break
from
my
break.
Yeah
break
from
the
kids
say
that
my
wife's
here
we're
we're
on
vacation
this
week,
but
I
want
to
to
join
this.
D
What
city's
children's
museum
are
you
in.
A
It's
a
manhattan
museum,
I'm
actually
like
we're.
Actually,
here
close
by
to
you.
E
Is
it
at
what's
the
capacity
like
what
are
their
rules,
partial
capacity
or
business
as
usual,
with
covid,
or
what.
A
No,
they
have
these
two
hour
windows
where,
where
you
need
to
get
a
timed
entry
ticket
yeah,
it's
fun.
A
Cool,
do
we
have
quorum.
C
A
Great,
so
I
think
what
we
wanted
wanted
to
do
today
was
was
go
through
kind
of
the
the
kind
of
the.
I
think
we
had
three
or
four
questions
that
we
wanted
answered
and
sorry
for
the
background,
noise
and
and
kind
of
maybe
start,
I
think,
we've
we
have
answers
for
some
of
these,
so
you
know,
maybe
we
could
you
know.
I
think
morgan
suggested
it
last
time
that
we
can
maybe
start
crafting
our
our
recommendations.
C
E
C
Example
was
like
hey
whether
we
want
this
agent
to
be
an
external
thing
or
it
could
be
a
receiver.
So
that's
one
decision
to
make
the
other
thing
is
like
hey.
We
need
to
like
resolve
some
metadata
about,
like
you
know
the
workloads
and
so
on,
like
where
are
we
going
to
be
doing?
This
is
the
other
thing
we
decided
to.
You
know:
do
it
in
the
in
the
collectors
as
a
processor.
C
The
other
thing
was
about
like
aggregations,
like
you
know
what
type
of
like
aggregations
we're
gonna
you
know
produce.
You
know
from
the
like
raw
events
coming
in
and
there's
like
one
other
thing
which
is
like
you
know,
the
are
we
going
to
be
like,
I
think,
documenting
the
the
events
like
is
a
spec
in
the
open
telemetry.
You
know
donate
that
piece
or
you
know,
is
it.
Is
it
not
going
to
be
a
spec,
maybe
for
now?
E
E
C
Not
like
extensively
there's,
nothing
like
you
know,
pros
and
cons
right,
jonathan,
like
the
meetings,
the
meeting
recordings
are
the
only
I
think,
artifacts
so
far,.
A
A
And
there
are
a
couple
of
documents
in
so
I
I
did
a
survey
of
the
processors
that
we
can
use
to
enrich,
and
so
I
think
that
there
are
a
handful
of
like
smaller
documents
at
the
beginning
of
the
our
meeting
notes.
But
they're,
it's
not
you
know
just
depends
on
what
you're
looking
for
yeah.
E
I
I
saw
that
document
about
the
processors
which
is
great,
but
I
was
wondering
like
these
four
points
we
have
like
like
exactly
like.
You
said
jana
like
do.
We
have
like
pros
and
cons,
and
why,
like
the
rationale
and
justification
of
which
way
we're
going,
I
find
it
often
helps
like
just
that's.
E
C
Like
we,
we
kind
of
came
feel
like
you
know.
We
at
least
came
to
a
conclusion
like
whether
we
want
to
have
it
as
a
separate
process,
or
not
like
at
least
for
now,
because
I
think
it's
an
easier
decision,
because
you
know
if
we
keep
it
as
a
split
you
know,
process.
We
can
always
write
a
receiver
that
you
know
bundles.
That.
E
C
Long
term
so,
like
I
think
that
decision
is
kind
of
like
you
know,
keeping
it
split
for
now.
For
that,
like
you
know,
particular
practical
reason,
and
also
like
you
know,
you
wanna,
you
sometimes
wanna
run
you.
E
C
Maybe
the
agent
like
separately
to
be
able,
like
you,
know
as
a
side
car,
maybe
you
know
like
so
the
collector
can
still
be
running
elsewhere.
You
can
just
you
know
export,
so
that
kind
of
like
enables
some
of
those
like
topologies
that
we
discussed
before
so
we
kind
of
like
agreed
like.
I
think
it
should
be
a
separate
process,
because
it's
an
easier
thing
to
turn
it
into
a
receiver
in
the
long
term.
The
other
way
around
it's
much,
you
know
complicated.
D
F
C
A
It
if,
if
you,
if
you
want,
I
I
wanted
to.
C
A
C
It
could
be
also
in
the
proposal.
That's
what
I
was
like
about
to
say
like
a
the
rational
could
be
like
an
appendix
or
it
could
be
in
the
proposal.
I'm
sorry
go
ahead,
sounds.
F
C
Okay,
the
the
other
thing
that
we
kind
of
like
came
to
an
agreement
that
like
we
should
resolve
the
you
know
the
metadata
in
the
collector
and
it's
possible
to
do
it
because
and
like
it's
more
effective
because
you
know
we
can
cache,
you
know
for
an
ip,
we
will
resolve.
You
know
the
the
names
and,
like
you
know,
the
labels
and
so
on.
C
We
can
cache
those
things,
and
you
know
rather
than
like
ask
like
if
you're
running,
for
example,
the
agent
as
a
sidecar,
you
will
have
to
like
query
an
api
endpoint
in
the
kubernetes
case,
like
from
too
many
sidecars,
at
least.
If
it's
in
the
collector.
You
know
it
would
aggressively
cache
that
type
of
like
metadata
and
it's
much
easier
to
write
these
things
in
go
then
you
know
c,
plus
plus,
so
we
we
started.
We
decided
like
we're
going
to
do
it
in
the
collector.
For
now
it's.
D
D
I
didn't
mean
to
interrupt
at
all
so
so
that
I
understand
the
architecture
we'll
have
a
separate
process
that
represents
some
ebpf
probe
of
some
sort.
It
will
pass,
it
will
collect
events.
It
will
pass
those
raw
events
to
the
collector
where
additional
processing
will
happen.
It's
not
like
that
little
process
will
ever
talk
to
a
back
end
directly
like
there's
always
that.
C
And
the
other
thing
I
think,
the
the
other
thing
that
was
on
the
list
is,
you
know
like
the
the
aggregations
like
hey.
Are
we
going
to
turn
any
of
these
events
into
anything
other
than
just
logs
like?
Are
we
going
to
be
producing
any
metrics
out
of
them
like
we
need
to
decide
on
that
like
we
haven't,
you
know
discussed
too
much
about
it.
It
could
be
again
a
long-term
thing.
The.
D
Beauty
of
the
collector
being
in
the
critical
path
at
by
necessity
is
that
you
can
take
advantage
of
the
processors
in
in
the
collector
and
then
aggregate
out
whatever
the
vendor
wants
for
their
back
end
rather
than
having
it
be
opinionated
in.
In
any
point
in
nope,
plummetry.
C
That's
completely
right,
yeah,
and
I
think
this
is
like
a
critical
item,
because
if
we
have
this
like,
if
we
produce
metrics,
open,
telemetric
collector
or
the
project
will
tell
us,
okay,
like
you,
are
giving
us
out
of
the
box,
you
know
metrics,
you
know
whatever
internal
protocol,
you
use
it's
great
that
it's
there,
but
you
are
also
giving
us
like
some
data
we
already
can
understand
so
like.
I
was
like
thinking
that.
Maybe
this,
like
event,
you
know
spec
could
be
an
internal
thing
for
now.
C
Is
we're
finalizing
it
and
like
thinking
about
it?
And
all
of
that,
like
you
know,
but
you
know
make
me
we
need
to,
I
think,
contribute
some
aggregations
in
the
first
phase
in
order
to
justify
that
and
it's
it's
hard
work
to
write
those
aggregations.
C
That's
why
I
kind
of
like
you
know
we
need
to
make
a
decision
to
see
which
way
we
want
to
go
like
we
can
do
both
the
first
option
would
be
integrations
and
keeping
the
you
know
the
events
spec
internal,
the
other
way
would
be
like
hey.
This
is
the
event
spec,
you
know
produce
consume
it,
but
we
have
to
document
it.
D
From
a
selfish
point
of
view,
although
I
think
we
made
these
product
decisions
intentionally,
we
aggregate
over
time
into
an
event.
So
we
take
the
raw
events.
We
aggregate
any
two
ipn
points
that
happen
during
a
very
short
window
period
into
a
flow,
and
then
we
export
the
flow
as
an
event,
not
as
a
metric
and
datadog.
At
least
our
backend
would
not
accept
these
as
metrics
because
of
the
cardinality
explosion
between
source
and
destination.
Ip
addresses
in
an
ephemeral.
E
D
But
it
works
beautifully
as
events,
because
we
can
do
ragged
queries
from
a
to
b
things
like
that
from
our
perspective
anyway,
so
so
opinionated
there
from
a
selfish
perspective,
but
I
do
think
we
made
these
these
decisions,
mine.
C
For
technical
reasons
as
well,
we
also
discussed
about
that.
Like
one
of
the
things
that,
like
you
know,
the
processors
could
do
could
be
just
picking
the
you
know,
maybe
the
dimensions
that
you
care
about
or
kind
of
like.
Well,
we
need
to
discuss.
You
know
there
are
different
pros
and
cons.
It
would
be
nice
to
just
you
know,
export
them
as
they
are
and
then
backhand
drops
or
aggregates
whatever,
based
on
whatever
dimensions
they
want.
Yeah.
E
Yeah,
do
we
have
any
idea
of
like
performance
impact
of
this
architecture
like
there
is
there's
a
trade-off
of
sending
too
many
events
and
then
filtering
it
out
later
right?
D
We
haven't
benchmarked
the
otlp.
I
mean
like
this,
this
obvious.
Obviously
we
haven't
benchmarked
something
that
doesn't
exist,
but
using
it.
The
way
I
just
described
it
for
p95
cases
keeps
things
under
one
percent
cpu.
We
have.
It
found
one
pathological
case
ever
that
the
the
impact
on
cpu
was
too
heavy
yeah,
but
ever
in
thousands
of
customers.
E
A
Yeah
yeah,
we
we
only
so
we
haven't
benchmarked
the
open,
telemetry
collector
either,
but
our
the
we
have
benchmarked
the
flomo
collector
extensively
and
they're.
Yes,
with
the
eventing
architecture,
we
you
could
get
under
a
court.
You
know
in
most
cases
you
can
get
more
under
a
quarter
of
a
percent
cpu
overhead.
That.
A
In
the
metrics
use
case,
is
I
don't
know
how
how
the
the
hotel
collector
handles
metrics?
If
you
try,
so
you
know,
we
just
made
a
decision
to
to
perform
enrichment
in
the
collector,
which
means
the
in
the
hotel
collector,
which
means
the
ebpf
collector
has
to
export
flow
data.
A
D
D
It's
just
like
an
enormous
amount
of
time
aggregation
if
you
do
aggregation
in
the
flow
mill
collector
again.
This
is
limited
experience,
but
using
kernel
space
ram,
especially
in
windows,
which
is
not
it's
a
driver
for
us
and
not
not
udpf.
Obviously
it
can
call
cause
hanging
and
you
don't
want
to
accumulate
there.
In
my
experience
you
just
want
that
to
be
stateless
and
flush
as
quickly
as
possible
and
never
accumulate
unless
yeah,
because
if
you
run
out
of
space
it
hangs
the
whole
whole
thing.
A
D
Am
not
opinionated.
Personally,
I
think
there
is
a
good
story
there
in
the
datadog
back
end.
We
can
convert
from
events
to
metrics
and
back
and
we
didn't
implement
that
for
the
network
performance
monitoring
product,
we
do
implement
that
for
other
log
based
products,
and
there
is
a
story
there
if
I
just
want
to
see
the
outpou
or
the
the
inbound
to
an
ingress
pod-
and
I
only
want
that
tag-
and
I
don't
need
two
from
queries-
ragged
queries,
then
you
can
reduce
the
cardinality
to
something
trivial.
D
D
I
also
see
it
as
a
nice
to
have
like
I
said
we
didn't
implement
it
yet
I
just
see
it
as
an
incredible
thing
to
implement
one
day.
A
The
the
though
you
know
where
I
was
going
with
this
is
going
to
be
anna.
You
you
asked,
can
we
create
aggregations
that
are
meaningful
from
the
collector
kind
of,
without
forcing
the
user
to
go
to
to
handle
kind
of
a
lot
of
these
high
cardinality
events?
A
C
Yeah,
I
was
kind
of
like
thinking
that
I
think
we
will
always
keep
maybe
keeping
that
option,
so
you
know
to
be
able
to
export
them
as
events,
but
on
top
of
that,
like
maybe
it
is
in
addition,
you
can
set
like
some
aggregations
if
you
want
to
turn
them
into
metrics,
and
in
that
case
maybe
people
can
say
yeah.
I
don't
need
this
as
logs
anymore,
but
you
know
it's
just
it's
it's
going
to
be
very
cpu
consuming.
You
know
all
of
that.
C
It's
just
kind
of
like
a
matter
of
like
where
you
want
to
do
this.
I
think
my
other
question
would
be
like
how
much
like
you
know
data
in
terms
of
like
you
know
you
will
put
on
wire.
If
you
want
to
do
the.
C
In
the
back
end,
that
could
be
also
a
concern
for
some
people
like,
especially
if
they
want
to
write
this
run
this
thing
as
a
sidecar,
you
know
not
on
kubernetes
example,
I'm
thinking
about.
Like
generally,
like
you
know
ecas,
and
all
these
things.
I
would
like
to
run
this
everywhere.
To
be
honest,.
A
Yeah,
so
the
the
design,
the
point
in
the
design
space
that
we
took
with
the
flowmo
collector,
was
create
an
encoding
that
was
efficient
enough.
This
is
why
we
normalize
the
data
right
like
create
an
encoding.
That's
efficient
enough,
so
you
can
ship
all
of
the
telemetry
to
a
back
end,
so
quarter,
four
percent
cpu
to
encode
to
collect
and
decode
and
less
than
one
percent
network
overhead
on
your
system
and
then
carry
all
that
data.
A
The
problem
is,
if
we're
trying
to
normalize
data
and
we're
enriching
the
enriching
telemetry
at
the
collectors
that
might
cause
the
volume
to
to
increase,
and
then
it
might
become
less
desirable
to
ship
the
wrong
telemetry
to
the
back
end.
So
you
want
to
do
the
aggregations
close
to
the
data
source
before
you
ship
them
yeah.
A
You
know
personally,
I
I
I
like
the
I,
like
the
architecture
of
of
you,
know,
keeping
the
overhead
really
really
low,
both
in
in
encoding,
size
and
cpu,
and
then
once
all
of
the
data
is
in
a
centralized
place,
then
you
can
do
a
lot
more
with
it,
because
now
you
have
the
flows
you
can.
You
can
match
the
flows
from
both
sides
of
a
connection,
for
example,
which
which
kind
of
the
the
flow
mole
back
in
does
the.
A
So
you
know
that
reading
some
of
the
open
telemetry
code,
you
could
run
open
telemetry
in
a
tiered
architecture,
where
you
have
the
lower
level
collectors,
and
then
you
ship
data
into
a
a
higher
level
collector,
and
maybe
that
collector
should
do
the
enrichment
and
the
aggregations,
and
then
you
can,
but
but
this
means
that
we
still
need
to
keep
some
some.
You
know
the
the
efficient
encoding
kind
of
converting
from
logs
to
metrics.
A
C
By
considering
some
of
these
capabilities
in
the
collector,
to
be
honest,
like
they
can
implement
everything
we're
talking
about
putting
into
collector
themselves
to
be
if
it
doesn't
fit
them
like
it's
just
kind
of
like.
Is
there
any
value
you
know
implementing
some
of
these
things
in
the
collector,
for
some
cases
like
for
good
reasons
that
people
might
find
it
useful
right.
D
C
C
C
D
I
mean
maybe
something
like
you
know,
just
network
output
from
a
meaningful
tag,
or
you
know
by
bipod
or
something
it
feels
like.
You
don't
need
vps
to
do
something
like
that,
so
it
might
feel
shoehorned,
but
just
to
throw
a
brainstorm.
D
Anyway,
we
can
take
it
as
homework.
I
think
yeah.
C
This
question
of,
like
you,
know
whether
we
should
do
any
aggregations
nicholas.
Is
it's
a
big
topic
to
us
like?
Even
though
you
want
to
decide
something
like
you
know,
whatever
we
want
to
propose,
it
could
be
just
like.
Also,
you
know
it's
a
tough
topic
like
we
need
to
see
how
it
goes.
We
need
to
run
some
experiments.
Probably
before
deciding
it's
just
it's
a
potential
thing
to
do
like
we
don't
have
to.
You
know.
C
E
A
The
collector
actually
collects
you
can
think
about
it
as
metrics,
but
high
cardinality
metrics.
So
it's
like
there's
like
a
table
of
all
the
sockets
in
the
system,
and
you
aggregate
these
events
of
you
know
I
got
another.
You
know
handful
of
packets,
sorry
about
that.
I
got
another.
A
few
handful
of
packets
worth
of
data
right
like
or
I
I
saw
a
retransmission
and
kind
of
the
collector
keeps
a
table
with
these
aggregated
metrics.
A
I
might
move
if
it's
still
noisy,
so
the
the
so
they
are
metrics
and
kind
of
whether
you
want
to
emit
them
as
metrics
into
the
hotel
collector
or
you
want
to
knit
them
as
logs
or
you
know
you
could
you
could
potentially
emit
them
as
traces.
You
know
the
the
the
signal
that
you
encode
them
in
is
not.
You
know
we
should
choose
kind
of
as
long
as
it
has
all
the
tags
that
you
can
make
use
of
it
downstream.
A
E
The
data
you're
collecting
you're
essentially,
as
I
said,
high
cardinality
kind
of
information
that
you're
holding
inside
the
full
mill
collector
like.
How
would
you
so
what's
the
plan
in
terms
of?
Are
you
shipping
these
out?
I
mean
obviously
you're,
not
shipping
it
out
every
time
that
there's
a
change
in
one
number
somewhere
right.
E
A
So
I
mean
you
know
what,
if
you're
looking
for
you
know
next
steps,
we
could
emit
some
of
these
events
as
metrics
and
then
you
know,
use
all
the
metrics
capabilities
in
the
in
the
hotel,
collector,
and
so
that
could
give
us.
D
So
to
clarify
before
we
go
too
far
down
the
metrics
rabbit
hole,
is
there
a
back
end
in
the
world
that
would
behave
well
with
the
time
series
database
that
accepts
a
thousand
ten
thousand
pounds
talking
to
ten
thousand
pods
fully
meshed.
D
A
The
thing
is,
you
could
convert
them
back
to
events
right
like
the
every
metric
has.
Has
these
attributes
you
can
flatten
it
to
an
event
and
then
use
an
eventing
system
to
look.
D
A
Yeah,
the
the
expectation
is
not
because
it's
high
cardinality
metrics
that
you
have
to
save
it
in
the
time
series
database.
As
is
you
could
you
could
decide
not
to
save
all
the
raw
data
into
a
time
series
database
right,
which,
which
kind
of
just
to
just
for
transparency,
kind
of
we
don't
either
right
like
the
flowmel,
the
flowmod.
A
So
I'm
so
for
the
aggregations
discussion,
kind
of
with
that
kind
of
would
outputting
as
metrics
be
kind
of
an
acceptable
way
and
then
using
some
of
the
processors
to
get
aggregations.
So
we
can
get.
You
know
this
pod
sent
out
this
many
bytes
that
sort
of
time
series
could
have
aggregated
time
series
out
of
the
box.
A
A
No,
no
just
sorry,
they
don't
want
me
to
put
you
on
the
spot,
so
the
the
kind
of
we
should.
Let
so,
let's,
let's
table
it
to
next
till
next
meeting
when
we're
back
I'll
try
to
to
do
some
research
into
what
it
would
take
to
write.
The
metrics
out,
as
you
know,
write
the
the
data
out
as
metrics
if
it
is
cost
prohibitive
for
the
hotel,
collector.
A
Try
to
take
it
on,
I'm
I'm
not
going
to
join
next
week,
so
it
might
be.
You
might
have
a
two-week
delay
for
that
answer.
C
A
C
The
other
question
was
whether
we
want
to
like
document
the
spec
like
the
the
age.
What
agent
is
going
to
produce
at
this
point
or
not,
but
I
think
we
will
have
to
you
know
document
it.
At
least
you
know,
because
we
give
people
the
flexibility.
Can
you
use
this
as
it
is?
Or
you
can?
You
know
bundle
all
these,
like
you
know,
enable
all
these
other
components
in
the
open,
telemetry
collector.
So
probably
we
have
to
document
the
spec,
the
spec
that
you've
already
written.
C
It's
not
actually
like
it's
kind
of
like
you
know
you
already
haven't.
You
know,
have
a
spec
right
like
the
spec
document
that
you've
written
is
just
kind
of
like
addressing
getting
the
well.
We
don't
have
to
do
the
work
right
now.
We
at
least
need
to
decide
whether
we
want
to
you
know,
make
it
a
part
of
the
project
or
not.
So
you
know
don't
feel
like
it's
another
action.
I
think
we
we
kind
of
can
assume
that
we
we
will
have
to
document
it
right.
C
Yeah,
the
big
question
is
now
the
egg
vibrations
and
I
think
it's
it's
kind
of
like
hard
to
find
an
answer
for
that,
like
my
actually
like
pragmatic
approach
would
be
maybe
telling
like
these
are
the
options
like
long-term
options
and
we're
looking
into
the
feasibility
of
those
things
and
like
it's
a
you
know,
we
can
always
have
those
pads
like
it's
not
like.
It's
gonna
break
anything
in
the
long
term,
so
we
can,
I
think,
kick
off
the
next
steps.
C
Like
you
know,
this
is
what
we're
thinking
and,
like
you
know,
does
that
sound
good
to
the
technical
committee
or
not
like
we
have
no
idea.
So
I
think
we
have
like
some
of
these.
Like
high
level,
you
know
details
about
what
we
are
building
right.
B
F
C
C
Who's
going
to
like
take
the
next
steps,
like
you
know,
taking
it
to
the
technical
committee
again
so
john
johnson,
you
you
will
do
that
right,
like
or.
A
Whatever
you
think
so,
I
I
why
we
can
start
a
document
and
maybe
we
can
collaborate
on
a
document
so
with
the
with
what
kind
of
the
these
points
that
we
discussed,
kind
of
and
the
trade-offs
why
we
made
the
decision
kind
of
in
this
group,
like
the
four
of
us
so
we'll
share
it.
C
That
would
be
great
like
I
can
contribute.
You
know
if
you
just
created.