►
From YouTube: CNCF SIG Observability 2021-04-27
Description
CNCF SIG Observability 2021-04-27
A
A
A
C
A
D
D
B
A
A
B
B
The
first
would
be
to
generate
a
list
of
vendors
in
the
observability
space
and
have
some
sort
of
look
at
what
projects
that
they
actively
contribute
to.
This
sort
of
forms,
the
source
material
for
an
observability
who's
who
so,
if
a
smaller,
medium
business
or
even
a
large
business,
you
know,
wants
to
engage
with
the
cncf
broad.
You
know
a
set
of
projects,
particularly
in
the
observability
space.
B
They
have
a
starting
point
and
system
feedback
from
end
users,
in
particular,
is
that
the
space
is
broad,
difficult
to
grok,
there's
a
lot
of
players
and
a
lot
of
options.
So
so
just
a
a
fundamental
like
you
know,
starting
with
a
list
of
of
who
who,
in
the
vendor
space,
where
much
of
the
technical
contribution
is
paid
for
by
these
vendors
right
and
we
all
come
together
in
this.
B
I
don't
want
to
say
vendor
neutral
space,
although
that
term
is
used,
but
just
generate
a
list
of
vendors,
what
they're
working
on
what
their
roadmaps
might
be
with
limits
to
what
projects
they
contribute
to
the
second
and
this
there's
a
couple
things
here.
This
is
the
first
of
them
where
we
could
really
use
contribution
from
product
or
program
managers
that
are
technical.
That
can
work
in
concert
with
engineers
but
develop
a
serious
plan
for
how
the
sig
will
engage
with
other
projects.
B
If
you
go
to
the
landscape,
cncf
puts
out,
obviously
there's
there's
a
huge
amount
of
projects.
Many
of
them
are
doing
fairly
complicated
things
and
sometimes
engaging
with
those
from
personal
experience.
An
example
might
be
flux
right
it.
It
does
a
really
cool
thing,
with
git
ops
but
understanding
how
and
why
things
work
or
didn't
work
ends
up
with
log
diving
combined
with
you
know,
a
requirement
that
somebody
be
deeply.
B
You
know
have
deep
technical
understanding
of
what's
happening
and
the
project
in
version
two
is
doing
work
around
observability,
but
many
many
projects,
I
think,
could
benefit
from.
You
know
the
sig
reaching
out
and
saying
hey,
you
know,
perhaps
a
very
small
new
project
in
the
sandbox
or
even
some
of
the
more
established
projects.
You
know
there
are
vast
opportunities
to
to
help
people
understand
what's
happening
in
that
project
as
it
runs
and
does
whatever
it
does
so.
B
Here
again,
I
think
we
have
an
opportunity
to
start
building
up
relationships
and
to
leverage
our
existing
professional
networks
to
reach
out
to
those
projects.
We
receive
positive
feedback
from
this
notion
late
last
year
from
the
toc,
but
I
would
like
to
put
in
a
program
so
that
we
could
have
you
know
a
horizontal
scale
out
if
you
will
and
we
can
leverage
the
connections
that
we
we
already
have.
So
so
you
know
developing
what
that
plan
is
and
how
we
do
that.
B
That's
an
opportunity
for
someone
to
really
step
up
and
and
really
define
a
program
for
the
year
and
beyond
and
to
drive
it
third
develop
another
pragmatic,
serious
plan
for
how
the
sig
will
foster
in-person
meetups
in
a
scalable
way.
Once
the
world
reopens
from
the
pandemic,
I'm
sure,
documentaries
and
movies
will
be
made
about
2020,
but
you
know:
kubecon.
B
B
B
You
know
a
set
of
meetups
that
can
then
kind
of
bubble
up
interesting
findings
or
reports,
or
presentations
or
talks,
or
what
have
you
so
again?
This
is
a
this.
Is
someone
where
someone
with
experience
with
you
know
particularly
cross-organizational
outreach
and,
or
you
know,
just
defining
what
that
program
is
in
a
way
that
is
welcoming
to
new
contributors,
so
that
we
can
horizontally
scale
our
efforts
in
an
asynchronous
way.
There's
two
more.
I
think
that
we
should
be.
B
These
projects
that
are
within
the
scope
for
our
a
second
would
be
vendors,
like
you
know
they
they
again
typically
foot
the
bill,
if
you
will,
by
by
paying
for
engineering
time
to
let
this
the
project
that
this
ecosystem
is
built
around
thrive
right.
So
what
are
their
expectations
for
for
the
sig
and
and
what
opportunities
or
needs
do
they
have
that
we
can?
We
can
we
can
structure
our
activities
to
to
engage
with
to
make
this
truly
welcoming?
B
For,
for
us
all
to
come
to
come
together,
make
sure
needs
are
met.
Third
would
be
individual
projects,
as
I
had
mentioned,
and
and
their
contributors.
You
know
it
could
be
a
sandbox
project
that
has
a
great
technical
idea
with
an
initial
implementation,
but
no,
you
know
no,
no
observability
stuff,
no
metrics
or
they're
struggling
with
you
know,
as
as
many
companies
and
many
products
start
to
engage
with
other
modalities
of
communicating
what's
happening
with
with
the
services
that
comprise
that
project.
B
You
know
they
might
want
to
use
ar
or
vr
or
other
other
types
of
things
that
are
not
simply
logs
metrics
traces
right
that
are
emerging,
so
so
vendors
would
be
a
second
persona.
I'm
sorry
projects
and
their
contributors
would
be
a
third
persona,
and
then
you
know
at
the
at
the
chair
and
technical
lead
level.
You
know
where
there's
a
fourth
person
there,
that's
the
toc
right.
What
does
the
toc
need
from
the
sig?
B
What
are
their
expectations,
and-
and
so
I
think,
just
like
you
know-
just
like
personas-
are
useful
for
defining
a
project
stakeholders
for
a
products,
stakeholders
and
and
and
customers.
You
know
these
personas
could
help
us
figure
out
when
we're
doing
something
like
a
white
paper
like
which
persona
is
it
for
or
is
it
for
multiple?
B
But
here
again
some
non-pure
coding
type
folks
who
might
have
expertise
in
product
or
project
or
platform
management
or
and
definition
could
really
contribute
here
in
concert
with
the
engineering
folks
and
and
others
that
have
been
joining
the
calls
so
again
here
I
think
we
can
broaden
our
tent
and,
as
we'll
have
a
lot
of
eyeballs
in
kubecon.
I
would
like
to
extend
a
welcome
to
those
you
know,
other
disciplines
that
are
really
necessary
to
have
a
pragmatically.
B
You
know
multidisciplinary,
successful,
special
interest
group
and
then
and
then.
Lastly,
if
anyone
throws
a
rock
on
youtube,
there's
a
wealth
of
deep
technical
talks,
as
well
as
higher
level
architectural
talks
or
or
product
talks
in
the
observability
ecosystem,
everything
from
cortex
and
thanos
and
prometheus
to
you
know
open,
metrics
and
and
open
telemetry,
and
you
know
how
all
of
these
pieces
are
put
together.
I
did
a
quick
look
through
my
youtube
playlists
and
I've
got
you
know
50
or
60
talks
that
are
the
ones
that
I
would
recommend
that
I've.
B
You
know
of
of
many
more
that
I've
watched.
So
I
think
we
could
curate.
You
know
a
list
of
these
or
a
compendium,
so
to
speak
of
additional
resources.
You
know:
does
somebody
really
want
to
really
get
into
metrics
and
understand?
You
know,
what's
red
you
know
or
how?
What
metrics
should
I
define
or-
or
you
know
how
should
I
put
these
pieces
together?
B
So
some
combination
of
a
curation
of
case
studies
or
talks
that
are
in
effect
case
studies
again
for
for
folks
new
to
this
space
and
new
to
the
domain?
It
could
provide
a
nice
starting
point
to
existing
content
that
that's
summarized
in
in
some
discernible
way
that
doesn't
involve
the
sig
generating
content.
B
We
can
leverage
a
lot
of
existing
things
in
the
cncf
ecosystem,
so
I
just
wanted
to
put
that
in
in
the
minds
of
the
folks
listening
and
those
that
might
be
watching
this
talk
from
kukan
or
or
or
otherwise
that
you
know
there's
a
lot
we
can
do
in
2021
and
I'll
follow
this
up
with.
You
know
a
pr
in
concert
with
richie
and
we'll
and
we'll
iterate
and
and
and
talk
about
it
offline,
I
suppose
or
in
slack,
but
that's
really
just.
B
You
know
almost
like
not
to
leverage
a,
I
suspect,
there's
a
lot
of
gamers
in
the
cloud
native
space,
but
you
know
you
could
almost
think
of
it
as,
like.
You
know
hey
looking
for
group
like
I'd
like
to
do
the
thing
who
else
is
interested
in
this
thing
too,
reach
out
to
your
network,
to
folks
that
aren't
already
here
and
bring
them
in
right.
B
I
I
would
like
to
see
that
sort
of
be
the
nature
of
our
of
our
special
interest
group
like
a
a
place
where
interesting
things
might
happen
and
and
little
dopamine
hits
can
be
had
as
we
as
we
learn
about
the
ways
that
people
are
using
the
project
in
the
cncf
umbrella
and
how
we're
welcoming
new
projects
into
it.
So
that's
it
I'm
back
sort
of
full-time,
after
maybe
a
quarter
doing
some
self-care
and
I'm
happy
to
get
up
to
my
eyeballs
and
all
of
this
all
over
again.
B
B
A
I
I
was
just
about
to
make
one
point
of
order.
I
have
just
been
informed
that
I
might
need
to
drop
into
a
super
super
urgent
and
important
call
privately,
so
I
might
drop
at
any
point
during
the
remainder
of
this
call,
but
yeah
as
this
everything
what
matt
just
talked
about
needs
people
and
it
needs
both
owners
and
and
people
who
just
help
or
who,
who
give
feedback
or
or
whatever.
A
So
this
is
very
much
a
call
for
people
to
step
up
and
just
do
what
they
think
they
want
to
be
doing
either
from
this
list
or
if
you
have
some
other
ideas,
go
wild.
I
mean
within
the
constraints
of
the
sick,
but
this
is
very
much
a
call
for
for
more
hands.
Of
course,
that
is
how
how
we
can
start
paralyzing
more
historically,
the
last
year
the
group
was
relatively
static,
that
has
changed
towards
the
end
of
last
year
and
that
has
become
better
and
better.
A
F
E
Everyone
here
was
following
the
white
paper
when
we
started
late
2020,
we
had
really
small
contributor
base
and
we
were
thinking
about
how
we
can
get
more
from
tears,
and
then
we
did
a
tweet.
We
created
a
threat,
a
trend
on
twitter.
We
got
a
few
retweets
and
suddenly
we
had
more
than
20
volunteers
for
the
white
paper.
E
A
B
Really
anytime
right,
I
mean
not
now's
great,
but
you
know
as
as
just
a
normal
operation
of
the
sig
like
this.
This
can
happen
at
any
time
and-
and
I
hope
it
does
so
yeah
bring
it
bring
your
ideas
if
you're
passionate
about
something
as
arthur
mentioned,
just
just
throw
a
hand
up,
and
you
might
be
surprised
at
who
comes
out
and
wants
to
jump
in
and.
G
F
B
Yes,
there
is
so
in
the
cncf
charter.
I'm
sorry
in
the
state
observability
charter
in
our
in
our
repo
there's
a
link
to
the
specifics,
but
there
are
technical
leads
and
working
groups,
and
working
groups
in
particular,
I
think,
are
how
many
other
sigs
will
do
this.
Some
of
the
things
that
we've
been
doing.
If
you
look
back
through
the
calls
over
the
last
couple
of
months
around
due
diligence
for
cortex,
open,
metrics,
open
telemetry,
etc.
B
So
some
some
sigs
do
these
in
the
context
of
a
working
group,
a
working
group
is,
you
know
it's.
It's
meant
to
be
a
project
with
defined
outputs
and
a
time
boxing.
If
you
will
that
that
runs,
you
know
as
a
as
a
work
stream
and
then
reports
back
back
up
to
the
sig
on
its
status
and
and
really
when
the
cncf
they
have
a
sigs.md.
B
B
Makes
sense
for
us
we
can
do
and
and
and
those
those
groups
that
might
form
around
those
could
be
called
working
groups
formally
up
up
until
now.
We
we
have.
We
have
not
had
the
happy
problem
of
of
having
more
work
than
we
could
do.
You
know
an
hour
together
all
at
once
in
a
single
meeting
and
and
the
white
paper
is
an
example
of
that,
where
the
folks
actually
contributing,
are
defining
how
they
meet.
B
G
B
Yeah
I'll
follow
up
this
sort
of
verbal
onslaught.
If
you
will
not
to
be
too
self-deprecating
with
with
the
with
something
that's
a
little
more
concrete,
we
can
look
at,
but
again
we
control
our
own
destiny
here
and
that's
one
of
the
nice
things
about
a
sig.
It's
it's
a
coalition
of
the
willing
right.
So
you
know
newcomers
and
and
additional
folks
are
gonna
bring
your
friends.
You
know.
Let's,
let's
do
it's,
there's
no
shortage
of
interesting
work
right
so.
A
And
you
don't
need
to
you
don't
like
you
can
put
all
of
this
in
async,
but
precisely
this
kind
of
initial
coordination
and
such
in
my
experience
is,
is
great
to
do
live
if
people
want
to
so
you
can
easily
just
take
some
time
out
of
out
of
this
call
for
people
to
synchronize.
On
this
I
see
shelby
wants
to
talk
about
the
personas,
for
example.
So
if
you
want
to
start
this
now,
now
is
the
time
else
we
move
on
to
the
white
paper.
B
Yeah,
I
would
encourage
folks
to
if
you
want
to
see
a
model
for
how
this
can
work
once
we
actually
do
scale
up
and
we're
doing
more
in
parallel.
You
know
without
having
a
choke
point
of
a
single
meeting
where
we
walk
through
one
thing.
At
a
time
we
can
look
at
the
tlc
meetings.
They
have
a
pretty
nice
structure
that
facilitates
that.
G
Yeah
sounds
I
mean
I
think
that
sounds
like
a
plan.
I
don't
know
shelby
or
whoever.
Whoever
else
might
be
interested
if
we
want
to
maybe
take
time
now.
I
don't
know
if
we
have
enough
thoughts
put
together
for
how
this
might
work.
I
would
also
be
interested
in
helping
out
with
some
of
these,
but
maybe
maybe
we
coordinate
a
little
bit
first
on
slack
offline
and
then
next
meeting
we
can
come
with
more
of
like
a
plan,
I'm
not
sure.
G
A
F
F
E
F
F
F
E
F
Right
jurassic
left,
he
basically
built
this
section
and
I
think
one
comment
that
people
had
was
about
the
figures
that
was
like
too
small
and
hard
to
to
read
something.
I
agree
with
that.
We
are
going
to
have
to
fix
this
at
some
point,
but
is
anybody
else
writing
anything
about
distributed
tracing
or
volunteering
in
any
form.
H
H
F
F
For
the
crash
dumps,
I
have
already
something
I
volunteered
for
this
section.
I
just
didn't
paste
the
content
for
the
continuous
profiling.
We
don't
have
anybody,
but
we
had.
We
had
someone
suggesting
continuous
profiling
as
part
of
the
as
part
of
the
section
that
describes
the
observability
signals,
and
I
think
this
should
appear
in
the
introduction
as
well
when
we
talk
about
the
three
pillars,
but
we
shouldn't
say
that
the
three
pillars
are
the
only
things
that
we
have.
I
I
I
didn't
know
like
what
the
deal
was
if
it
was
like
a
thing
that
just
like
anybody
could
add
so
I've
been
so
yeah.
I've
been
working
on
like
a
continuous
profiling
project
and
yeah.
I
stumbled
on
this
white
paper
randomly
and
then
it
just
said
tbd
for
continuous
profiling,
so
I
went
ahead
and
just
like
added
my
thoughts,
I
don't
know
these
are
like
slightly
based
off
of
also
like
google
has
like
a
continuous
profiling
paper
and
then
also
yeah,
just
my
general
thoughts
on
where
it
like
fits
into
the
whole.
F
E
I
No,
I
just
suggest
so
it
said
tbd
and
then
I
just
like
suggested
instead
of
tvd
that
next
and
then
I
guess
somebody
like
merged
it
in
or
whatever
I
don't
know
who,
but
it
was.
It
was
great.
It
was
kind
of
like
like
where
perry
is
right.
Now
it
was
kind
of
like
that,
except
I
just
replaced
tbd
with,
like
the
full
text
that
you
see.
F
B
I
could
speak
briefly,
I
think
so.
I
had
pasted
in
a
couple
diagrams
just
as
like
not
like.
This
should
be
the
diagram
but
like
we
could
have
something
like
this,
that
I
had
stolen
from
richie's
talk
from
kukan
last
year,
but
the
con
prof
project
is
actually
distinct
from
the
stack
driver.
Profiling
stack,
they're,
two
different
projects.
What
con
prof
is
is,
I
believe,
it's
a
young
project.
B
I
don't
know
if
it's
in
the
cncf,
I
don't
think
it
is,
but
in
a
nutshell,
it's
the
guts
of
prometheus
hacked
up
a
bit,
I'm
not
doing
it
justice,
I'm
sure,
but
so,
instead
of
the
value
being
a
metric,
that's
tracked
over
time.
You
know
in
n64
it's
a
a
go,
profiler
a
go
profile
and
I
believe
they're
working
on
python
as
well.
So
it's
basically
what
you
described,
but
as
an
mvp
early
early
project.
B
I
wasn't
sure
if
that
was
a
project
you
were
referring
to,
but
I
think
at
the
most
recent
graphonic
con.
I
want
to
say
earlier
this
year
or
late
last
year
there
was
a
talk
on
that
project
called
con
prof,
which
is
effectively
this,
but
it's
very
early-
and
I
don't
I
don't
know
the
details,
not
personally
but
I'd
love
to
hear
what
you're
working
on
ryan.
It
sounds.
Super
cool.
I
Yeah,
I
actually
didn't
add
the
references
I
didn't
want
to
like
yeah
like
promote,
but
I
mean
it's
an
open
source,
so
we
also
similar
to
compro
we're
doing
it.
I
guess
like
slightly
differently
but
yeah.
It's
basically
continuous
profiler
works
for
go
python,
ruby
and
ebpf
and
yeah
we
just
like
released,
or
we
just
open
source
it
at
the
beginning
of
this
year
on
like
january
1st,
and
have
just
been
working
on
it.
I
Since
then
me
and
one
of
my
friends
awesome
yeah
but
similar
thing
yeah,
just
like
you
know,
comproph
just
does
it.
I
think
comprop
uses
yeah
like
prometheus.
More
heavily.
We
like
basically
did
our
own
sort
of
like
custom,
storage
and
compression
and
yeah
and
use
that
as
our
sort
of
like
back
end,
but
both
of
them
use
like
sampling
profilers
to
be
able
to,
like
you
know,
have
low
overhead,
get
the
profiling
data
and
then
send
it
to
the
server.
B
Yeah,
this
to
me,
is
an
exciting
area
of
observability.
Generally
I
mean
continuous
profiling
is
something
that
has
been
a
dream
for
like
the
better
part
of
20
25
years,
but
we
could
never
do
it
before
because
network
bandwidth,
storage,
compute,
blah
blah
blah
and
now
in
this
new
kind
of
in
this
new
cloud
native
world
that
has
been
rapidly
expanding.
We
have
all
these
new
capabilities
to
do
things
that
we
couldn't
do
before.
So
I'm
very
enthusiastic
to
see
what
happens
in
the
space
yep.
E
B
Know
the
process
thus
far,
I
mean
we're
really
in
content
generation
mode
here
you
know
we're
just
shaping
up
and
it's
been
really
cool
to
see
all
the
contributions.
Broadly,
I
think
at
some
point
I
don't
want
to
speak
for
arthur
or
simone,
but
I
believe
at
some
point
we'll
put
a
a
pin
in
it
and
we'll
we'll
probably
do
like
a
rewrite.
I
had.
I
thought
to
do.
F
B
The
last
week,
but
I
kind
of
it
didn't,
seem
ready
yet,
and
I
had
some
questions
around
like
the
high
level,
the
high
level
goals
and-
and
I
didn't
feel
like
word
smithing-
without
letting
the
rest
of
the
content
come
through.
First
made
sense,
it's
always
easier
to
prune
things
and
remove
duplication
than
to.
I
Yeah,
that
was
also
one
of
the
things
I
was
kind
of
interested
in
coming
to
this.
To
learn
more
about
is
sort
of
like
what
is
the
ultimate.
I
guess
yeah
like
goal
of
these
like
white
p,
or
I
guess
kind
of
like
yeah.
I
don't
know
just
some
extra
context
from
I
guess
the
people
who
work
on
it
more.
I
guess
you
know
seriously
just
like
how
you
guys
think
about
it
and
and
where
it's
sort
of
like
what
its
role
is
in
the
whole,
like
you
know,
cncf
landscape
and
everything.
F
But
it's
not
the
only
outcome,
I
would
say
so.
There
is
another
document
that
has
been
under
review
or
generated
about
it's
more
about
tracing
and
how
you
you,
as
an
application,
developer,
get
from
zero
to
start
using
tracing
and
how
it
works.
This
is
more
like
looking
at
the
application
developer
perspective,
instrumentation
and
data
like
looking
at
the
apis
and
the
data
collection.
F
B
You
know
for
reasons
discussed
in
the
paper,
so
so
I'm
really
excited
that
that
we're
we're
coming
together
on
just
helping
folks
that
are
new
to
this
dizzying
set
of
different
projects
and
signals
and
metrics
and
terms-
and
you
know,
let
alone
how
you
operationalize
it
or
implement
it.
But
just
what
is
this
stuff?
This
paper,
I
think
at
least
again,
like
from
a
fresh
reader's
perspective,
aims
to
do
that,
so
the
audience
is
like.
Are
you
new
to
this
space?
B
B
B
The
other
things
I
mentioned
and
w3c,
as
well
as
like
perhaps
additional
links
to
references
in
the
w3c
ecosystem
of
folks
that
have
implemented
things
to
that
standard
like
in
particular,
as
I've
talked
to
various
companies
over
the
last
month,
as
well
as
other
stakeholders,
I
think
distributed
tracing
is
probably
you
know.
It
is,
and
perhaps
always
will
be,
one
of
the
more
complicated
things
that's
hard
for
newcomers
to
develop,
and
sometimes
even
just
common
terms
and
definitions
are
lacking,
and
so
yeah.
H
I
think
also
this
is
something
from
like
talking
with
customers
that
many
get
wrong
yeah,
so
distributed
tracing
is
often
misunderstood
as
a
whole,
and
I
will
try
to
fill
in
the
blanks
here.
I
don't
know
if
it
should
be
a
separate
section
or
if
you
can
tuck
it
into
traces,
completely
sure
about
that.
B
B
We
have
a
lot
of
vendors
that
are
selling
a
sas
variant
of
their
own
back
end,
so
I
don't
know
if
it's
in
scope
or
out
of
scope,
arthur
and
savone
and
others,
but
perhaps
something
that
talks
about
the
trade-offs
of
you
know
what
the
true
costs
are
of
running
your
own
tracing
full
stack,
locally
versus
leveraging
vendors
that
have
economies
of
scale
that
can
provide
a
lower
total
cost
of
ownership.
I
mean
in
our
case
in
every
quote:
we've
used
both
vendors
as
well
as
for
some
things,
our
own
in-house
things
that
we're
prototyping.
B
In
our
case
you
know
jager
and
tempo
and
some
other
stuff,
I
think
in
r
d.
But
you
know
the
total
cost
of
running
everything
yourself
can
be
quite
high
and
is
oftentimes
not
talked
about
in
purely
technical
papers
that
talk
about?
Well,
you
do
this
that,
but
you
know
I
I
don't
know,
though,
if
that
crosses
out
of
the
technical
and
into
the
operational.
That's
it
here's.
What
I
think.
E
I
think,
like
the
costing,
is
a
really
important
factor
to
decide
for
beginners
that
don't
know
what
what
to
choose,
because
it's
a
very
important
thing
to
analyze.
So
I
I
do
agree
that
it's
an
important
topic
to
to
to
add
like
different
vendors,
have
different
back
ends
and
they
can
manage
traces
or
metrics
differently
with
different
costs.
So
yeah
I
I
do
agree.
That's
a
great
topic.
B
Just
to
be
specific,
I
am
categorically
not
suggesting
we
build
a
big
table
of
vendors
and
what
they
cost
and
what
the
cost
would
be.
I
more
mean
just
at
a
meta
level
discussing
that
the
total
cost
of
ownership
involves
implementation,
you
know
support
and
then
just
and
then
we
can
reference
some
of
the
other
things
I
mentioned
at
the
top
of
the
hour.
B
You
know
if
there's
a
rich
ecosystem
of
vendors
that
can
help
in
contractors
and
everything
else
or
you
could
do
it
yourself,
but
I
would
want
to
be
stereo
very
clear
of
like
specific
costs
or
making
any
kind
of
king
making
or
favoritism,
but
just
talk
about
as
a
as
a
technology
leader.
Here
are
the
things
that,
when
implementing
distributed
tracing
for
your
business,
that
one
should
consider
sort
of
a
look
before
you
leap
but
yeah.
H
Yeah
I
mean
this
is
a
this
is
a
journey
and
or
also
a
kind
of
worms.
That
is
sometimes
some
things
you
want
don't
want
to,
but
anyways
it's
I'm,
I'm
not
opposed
to
it,
but
it's
extremely
difficult
discussion.
This
cost
of
honor
ownership
discussion,
because
it's
it's
pretty
complex.
After
all,
you
never
know
it.
It
also
depends
very
much
on
the
use
case
and
then
the
size
of
the
business
and
what
you
really
want
to
achieve,
and
whatever.
B
I
I
kind
of
have
a
question
about
this
too,
like
when
you're
talking
about
like
costs
like
one
of
the
things
also
yeah
like
that,
I'm
interested
in
this
space
is
like
the
almost
like
the
benefits
as
much
as
the
cost
or
the
benefits
in
context
of
the
cost
of
like
you
know,
yeah.
We
know
that
tracing
allows
you
to
like.
I
I'm
also
kind
of
just
curious
what
you
what
you
guys
think
just
like
in
terms
of
like
the
yeah
like
how
do
you
weigh
the
benefits
of
adding
tracing
to
your
system?
Basically,
so
it's
like
yes,
you
can,
you
know,
track
something
down,
but
is
that
worth
the
amount
that
like
you're
talking
about
that
it
ultimately
costs
to
add
something
like
this
to
to
your
systems?.
C
B
Yeah,
I
think
that's,
I
think
also
the
personas
that
I
mentioned
might
help
here
because,
like
what
we've
just
been
talking
about,
is
the
cost
to
a
developer,
to
instrument
their
own
code,
which
is
a
concern
or
or
to
to
do
whatever
is
necessary
to
make
traces
happen
for
their
service
or
for
their
code.
I
was
actually
talking
more
from,
like
the
from
the
business
perspective
like
if
I'm
going
to
run
my
own
trace
stack.
B
G
B
Those
total
costs
can
be
really
hidden
sometimes,
and
you
end
up
having
you
know,
half
your
develop.
You
know,
half
of
your
development
resources
might
be
going
to
tooling
that
you
didn't
really
think
that
you
had
to
do,
because
you
didn't
know
going
into
it
that
these
could
be
some
some
hidden
costs
around,
so
not
just
from
a
developer
persona
but
from
from
a
business
persona
as
well.
H
H
Company
but
the
personas
we
like
to
work-
and
I
think
that's
pretty
common,
I
think
meanwhile,
is
we
have
first
we
have
developers.
We
have
a
cloud
architects
that
have
like
the
bigger
picture
in
mind.
Then
we
have
the
ops
s,
sre
or
ops
is
almost
one
person
on
its
own.
Then
we
have
desiree
that
has
again
different
needs,
so
maybe
I
don't
know
I
I
think
it's
common
knowledge.
If,
if
we
discuss
personas
many.
H
E
F
One
thing
I
suggested
back
in
the
days
was
also
to
talk
about
because
in
tracing
you
have
even
in
cloud
native,
you
have
two
dimensions.
You
have
the
dimension
where
you
trace
vertically
your
application.
Let's
say
it's
an
application
that
it's
only
an
application
working
inside
its
own
pod
container,
but
you
could
have
an
application
that
interacts
with
a
bunch
of
other
services.
So
you
have
the
time
dimension,
so
this
was
back
in
the
day,
more
treated
like
system
tracing
when
you're
working
with
monolithic
systems.
F
This
was
one
suggestion
I
made
back
in
the
days
because,
at
least
from
the
corners
that
I
come
from,
it's
usual
a
confusion.
When
you
talk
about
trace-
and
you
are
not
specific,
if
the
pers,
the
the
person
can
think
about
that,
I'm
talking
about
perth
or
things
that
are
monolithic
tracing
instead
of
distributed
tracing.
F
F
F
Okay,
but
we
came
up
forwards,
then,
if
we
don't
have
any
any
other
comments,
so
the
crash
dunk.
I
said
that
I'm
going
to
add
at
least
apart
from
the
crash
dumps.
There
were
other
people
talking
about
other
sort
of
dumps,
heap
dumps
or
whatever
other
dumps,
and
I
added
here
the
section
they
can
of
course
suggest
as
subsections
what
they
would
like
to
write
about,
but
I
still
have
to
add
my
text
here.
E
B
I
had
another
suggestion
for
a
new,
a
new,
a
new
section,
if
it's
not
already
there
and
that's
the
correlation
of
activity
data
and
costing
data,
there's
a
couple
open
source
projects
like
if
you
actually
go
to
aws
and
say:
hey,
I'm
running
aks.
How
do
I
correlate
this?
They
point
you
at
cube
costs
for
other
kind
of
vendors.
Some
of
them
have
some
beginnings
of
things.
Google
had
a
beta
a
while
back
that
used
some
stack
driver
bits
to
do
the
same
thing.
B
Take
audit
data
from
the
kubernetes
activity,
stream
and
audit
mechanisms
and
then
correlating
that
with
other
things,
but
that
general
topic
of
you
know
using
this
observability
data
I
and
then
mixing
it
with
other
other
things.
I
don't
know
if
that
gets
again
out
of
sort
of
the
the
scope
for
the
paper
or
if
it
makes
sense
to
just
introduce
the
concepts
that
you
know
hey.
This
is
a
thing
people
do
and
here's
some
links
to
examples
of
that,
but
it's
still
nascent
right.
F
F
E
B
I
think
we
can
decide.
I
mean
it's
up
for
y'all
to
decide
if
it's
in
the
context
of
this
or
not,
but
I
do
think
that
alerting,
specifically
sort
of
what
to
alert
on
so
not
so
much
like
water
metrics,
but
like
what
measures
should
I
define
and
there's
like
red
and
usc
red
and
news
are
two
common
frameworks
for
for
that.
So
I
wasn't
sure
based
on
his
comments,
if
he
was
talking
about
sort
of
writing
a
section
on
best
practices
around.
B
Where
should
you
instrument
her
of
the
many
metrics
you
could
pull
out
of
you
know
kubernetes
or
anything
else?
What
should
you
do
or
if
that
was
not
what
he
was
talking
about
with
alerting,
so
I'm
not
sure
either,
but
I
do
think
that
that
is
something
that
most
people
that
once
they
deploy
these
tools.
B
They're
like
great
now
I
have
you
know
two
million
time
series
like
what
do
I
actually
alert
on
so
that
I
don't
make
people
crazy
and-
and
here
again
there
is
a
wealth
of
existing
tech
talks
that
go
deep
into
this-
that
we
could
simply
reference,
or
maybe
we
could
introduce
some.
You
know
read
and
use
as
as
as
as
concepts
or
as
nouns
and
then.
F
And
I
I
took
notes
here
from
the
remaining
sections
that
are
kind
of
abandoned.
There
are
no
owners
or
nothing
rea
or
I
mean
some
have
no
owners,
for
example
the
zero
two
heroin
observability,
but
the
remaining
ones.
They
have
some
body,
but
no
content.
So
we
can
ping
these
people
on
the
slack
and
then
we
see
we
see
if
they're
still
entrusted-
or
they
just
forgot
about
it.