►
From YouTube: 2022-10-10 meeting
Description
Open Telemetry Meeting 1's Personal Meeting Room
A
A
C
Yeah
Julie
I
know
it's
funny.
You
wear
that
shirt
because
I
was
talking
with
a
colleague
last
week
about
how
we
should
really
be
implementing
open
feature
for
our
future
flag
service
and
that's
maybe
a
goal
for
like
future.
Let's,
let's
focus
on
version
1.0
right
now,
but
I
really
think
that's
something
that
we
should
think
about.
A
D
D
A
second
so
see.
Let's
start
it's
the
only
open
items,
I'm
really
aware
of
so
I
think
we
have
a
couple
python
PR
is
closing
this
week,
so
I
think
Miko
put
one
together
and
then
Adriana
put
one
together
around
the
auto
instrumentation
and
then
I
know.
I
know
we
have
to
do
the
default
grafana
issues
as
well,
so
I
want
to
spend
some
time
on
that
today.
Does
anybody
else
have
any
kind
of
top
of
mind
or
any
other
items
we
potentially
need
to
close
our
documentation
can
always
be
improved.
A.
C
C
D
Yeah
I
think
some
of
the
pushback
was
like
What.
If
we
have
a
python
service
that
calls
like
C,
plus,
plus
and
I
was
like
well
I
mean
I,
guess
that's
good
to
plan
for,
but
we're
pretty
far
away
from
that.
So
what
does
our
experience
look
like
today
in
terms
of
giving
customers
a
good
signal
or
a
user
is
a
good
signal
so.
B
D
C
B
The
research
I
did
was
basically
reading
the
the
docs
for
for
different
languages,
how
to
create
the
manual
metrics
and
there
wasn't
much
I.
Think
python
was
the
only
one
really
documenting
it
and
and
some
examples
I
saw
that
using
this
underscore
instead
of
dot
in
the
names
and
but
but
not
not
much
so
yeah
not
much
here
there.
You
can
see
the
underscores
in
the
in
the
metrics,
and
this
seemed
to
be
one
of
these
naming
practices,
but.
E
Just
from
my
perspective,
if
you
build
metrics
that
are
going
to
be
even
if
it's
custom,
if
you
do,
let's
say
I,
don't
know
a
number
of
products
and
we
have
two
Services
dealing
with
the
product,
it's
better
to
have
the
the
app
as
a
dimension
on
the
label
in
the
metrics.
Then
we
don't
store
extra
stuff.
In
your
time
series
database.
C
D
Yeah
I'm
curious
with
all
these
runtime
metrics
too,
like
if
we
have
like
a
DOT
or
a
card
service,
or
you
know
the
checkout
service
dashboards
I'm,
not
sure
how
repeatable
some
of
this
information
is
based
on
like
what
each
runtime
gives
you
or
I.
Guess
it's
a
slightly
different
naming
conventions
for
each
one.
C
A
D
It
looks
like
they're
just
going
based
off
the
language
right,
I
guess
maybe
they'll
have
an
attribute
underneath
like
the
actual
metric
I
would
have
to
look
into
but
and
the
naming
at
least
it
seems
to
just
go
by
language.
So
we
have
like
the
the.net
runtime
and
then
we
have
like
the
runtime
kind
of
Etc
wash
grafana
but
able
to
scroll
better.
B
C
A
C
E
C
C
I'm
not
looking
into
anything
language
I
mean
applications
like
I'm,
counting
product
requests
or
product
ID
or
product
cops
right.
That's
that's
something
specific
to
my
app
that
has
nothing
to
do
with
really
the
language
or
anything.
You
could
add
a
language
label
to
it
if
we
feel
like
it,
I
think,
that's
fine,
but
the
metric
name
itself,
because
the
custom
metric
I
want
to
name
space.
All
my
custom
metrics
under
something
app
underscore
custom
underscore
I
like
app
underscore.
It
makes
a
lot
of
sense.
D
D
C
A
C
A
D
Well,
I
think
we're
I
think
we're
okay,
giving
it
another
week,
but
it
would
have
to
be
an
essential
item,
so
I
figure
we'll
kind
of
cut
version,
I'm
open
to
discussion.
Of
course,
the
version
like
0.6
this
Friday
and
then
we'll
just
have
a
week
of
bugs
fixes
and
things
like
that.
So
if
we
need
to
slide
in
like
one
feature
to
the
bug
fix,
we
I
think
I'm
personally,
okay
with
it
but
open
to
open
a
discussion
on
it,.
C
This
would
need
a
change
to
the
feature
flakes
well
just
to
add
the
feature
flag
as
part
of
its
startup,
and
we
would
then
just
need
we
would
have
to
have
logic
to
check
for
the
existence
of
that
feature.
Flag,
I
think
what
we
said:
we're
just
going
to
fill
up
a
cache
and
just
keep
on
filling
it
up.
Yeah
yeah.
C
C
D
I
guess
the
question
is:
are
we
okay,
just
cutting
a
hero
scenario
and
having
good
basic
instrumentation
support,
but
not
not
necessarily
guided
experience,
we're
looking
for
it's
a
question,
but
just
based
on
kind
of
what
I
was
looking
at
grafana
I
think
it's
going
to
be
tough
to
build
generic
dashboards
that
has
flipped
between
a
lot
of
data
we
have
out
of
the
box,
but
the
big
thing
we
do
need
some
sort
of
default
dashboard,
even
if
we
don't
have
a
default
scenario.
It's
being
like
pointed
to.
C
D
D
A
C
Like
to
yeah
I
have
a
feeling
we
might
break
more
things
I'm
all
for
us,
creating
a
whole
separate
Branch
like
tag
branch
and
starting
to
work
on
it
right
away,
and
we
we
merge
PR's
into
that
other
Branch
until
we
have
it
all
flashed
out,
and
then
we
bring
that
into
Maine
but
I'm.
Just
a
little
fearful.
This
close
to
the
end
of
us
making
all
these
changes.
D
D
D
D
C
E
They've
been
defined
for
sure.
It's
just
that
if
you
have
a
limited
I
mean
if
you
want
to
deploy
in
this
environment
in
your
cluster,
then
the
app
itself
requests
100
Milli
core
per
service.
Basically
it
eats
the
namespace
after
the
1012
Services
plus
The
Collector.
It
hits
quite
a
lot
of
the
resources.
So
that's
why
I
thought?
Maybe
we
could
figure
out
to
shrunk
it
down
just
to
make
it
work
for
a
couple
users
and
avoid
requesting
for
lots
of
memory
or
CPU
and
memory
from
in
the
end
user
perspective.
C
C
I
think
it
makes
sense
that
you
know
for
for
reasons
like
this
thing's
kind
of
a
pig.
Let's,
let's
reduce
how
much,
how
much
resources
it
it
requests
and
limits
itself
to
on
Startup
so
that
you
could
run
it
on
a
modest
cluster
I
think
at
first,
he
we
say
Hey,
you
know:
do
we
take
a
swab
at
300,
Megs
everything,
or
do
we
kind
of
try
to
tailor
the
limits
for
each
service
and
and
keep
it
a
little
bit
tighter.
C
E
A
C
My
goodness
and
Geiger
keeps
on
going
up,
I
think
that's
a
runaway
I.
We
need
to
really
figure
that
one
out
but
300
Meg
sounds
perfectly
reasonable
to
try
to
like
shoot
for,
except
for
I.
Think
like
postgres
and
Jaeger,
maybe
give
those
a
little
bit
more
to
start,
and
then
we
tailor
it
down
as
we
go.
A
C
Probably
get
that
set
up
all
right,
I
got
it
running
somewhere
already
in
eks,
I'm
gonna
go
merge
and
make
it
the
latest
build
and
we'll
just
run
it
and
we'll
look
at
the
data
and
I'll
post
the
data
on
Friday
and
and
we'll
figure
it
out
we'll
go
from
there
yeah,
so
I'm
gonna.
Also
in
the
meantime,
I'm
gonna
figure
out
real
quickly.
If
there's
a
way
to
hold
down
Jaeger
because
Jagger
just
kept
on
climbing
when
I
last
looked
at
it,
it
was
I
got
six
gigs
and
I
was
like
wow.
C
D
A
D
D
Yeah
so
going
back
to
grafana,
though
I'm
not
really
a
grafana
expert,
so
I'll
probably
need
a
little
bit
of
help
here
if
I
get
more
familiar
with
it,
but
we
have
a
ton
of
information
kind
of
out
of
the
box.
We
have
no
dashboards
really
built
and
we
also
need
to
create
some
sort
of
default
experience
here.
So
I'm
not
sure
if
anyone
is
particularly
passionate
or
interested
in
grafana,
but
we
could
definitely
use
some
help
and
then
I'll
be
curious.
D
C
We
should
definitely
provide
an
open
television,
collector,
dashboard,
yeah
I,
think
that
is
that
raising
my
hand,
speaking
with
prospects
and
customers.
That's
actually
a
thing.
People
want
so
I
I
think
that
that
would
provide
value
across
the
board
for
for
a
wide
audience
and
and
perhaps
even
invite
others
to
help
make
us
the
perfect
version
of
it.
D
C
Think
more
tries
from
a
vendor
perspective
retries,
because
you
get
like
limited,
you
know
when
your
back
end
starts
getting
getting
in
bad
shape.
You
want
to
make
sure
that
your
exporter
is
healthy
or
your
export
news
are
healthy.
It's
definitely
something
I
heard
about
people
would
also
want
to
know.
Just
you
know
how
many
spans
per
second
am
I
running
through
this
thing
or
traces
per
second
metrics
per
second,
whatever
it
is
so.
A
D
A
D
See
what
their
default
collector
dashboard
gives
us,
and
it's
probably
will
be
a
pretty
good
starting
point
and
with
just
some
minimal
changes
on
top
of
that,
is
there
anything
else
we
want
to
add
out
of
the
box,
I
mean
I
feel
like
we
should
potentially
have
some
protocol
related
stuff,
but
just
with
the
service
coverage.
It's
so
sparse
that
it's
not
even
generic
at
that
point
and
just
be
like
an
HTTP
dashboard
for
the
cart
service
or
something
like
that.
E
D
Yeah,
that
would
be
great,
so
speaking
of
the
the
metrics,
you
probably
want
to
Spotlight
there,
so
latency
we'd,
probably
just
get
from
these
latency
metrics
I'm,
not
sure
if
we
want
to
bring
in
any
protocol
specific
information,
retries
and
failures
and
queue
size
I
think
we
have
okay
yeah.
That
would
be.
E
A
C
A
Cpr
you're
actually
right
the
even
though
I
agree
with
Henrik
on
his
approach
with
labels
and
the
the
spec
just
say
you
should
use
some
hierarchy.
I
put
a
link
on
the
the
chat
there
as
well.
Actually
that
Link's
a
bit
further
down
Zuckerman
but
higher
up
in
that
document.
It
does
talk
about
having
a
hierarchy
of
naming
for
a
system,
OS
applications,
Etc.
D
D
We'll
improve
our
our
metric
documentation,
make
sure
we're
capturing
any
out
of
box
metric
and
also
kind
of
routing
back
some
of
the
default
metrics
we're
producing
to
various
Services
we'll
get
the
collector
dashboard
example
from
Angus
and
see
how
that
fits
our
scenarios.
Does
anyone
want
to
take
a
look
at
the
generic
service
dashboard
and
talk
to
CJ
about
that
too?
I
think
he
has
some
interest,
but
if
anyone
on
the
call
feel
free
to
call
out
now.
A
D
C
Yeah,
it's
I'm
just
going
to
run
it
on
the
eks
cluster
that
we
run.
I'm
I,
don't
think
the
load
is
anything
that's
too
over
significant
either.
It's
like
10
users
and
I
think
there's
a
10
second
weight
between
them.
So
it's
maybe
one
request
per
second,
which
isn't
bad
but
I
I'll,
monitor
it
real
closely
and
I'll
produce,
charts
and
graphs.
I
I
know:
I
have
some
fancy
honeycomb
metric
collection,
things
running
on
that
cluster,
so
we'll
get
it
all
figured.
D
C
Well
right
now
we
have
a
per
service
and
we
have
three
outstanding,
Services
kind
of
I
guess:
low
generator
yeah.
The
only
part
of
that
would
be
baggage,
I
think
for
now
it
makes
sense
just
making
multiple
service,
because
we're
almost
done
that
and
then,
if
we
go
to
language
you'll,
be
submerging
of
those
files.
I
I
do
think
we
should
go
to
language,
but
that
would
be
step
1.1.
D
Yeah
yeah:
we
can
cover
that
in
the
pr
okay,
so
I
guess
the
answer
is
we
do
want
to
cover
every
service
with
some
sort
of
documentation
so
Oscar.
If
we
have
a
request,
if
you
wouldn't
mind
documenting
the
front
end
like
the
other
services
or
document,
we
kind
of
have
just
a
default
doc
layout
and
then
we'll
probably
get
this
updated
with
some
cleanup
post
or
probably
this
week
or
next
week.
But
if
you
could
just
produce
a
similar
document
for
the
front
end
instrumentation.
That
would
be
fantastic.
D
C
A
A
A
A
Yeah
I
think
that's
also
nice
and
I.
I
would
also
like
to
see
the
trace
test
one
here,
because
in
the
blog
post
from
Oscar
they
have
a
chair
there.
So
I
think
it
would
be
cool
here
so
yeah,
just
my
two
cents
and
of
course
the
the
one
from
Diamond
trees
that
I'm
missing
and
pushing
any
code
for
a
couple
of
weeks
already.
D
F
F
C
B
I,
like
the
I
like
the
little
prompt
to
use
Cube
proxy
when
you
run
the
helm,
chart
I
think
it
would
be
nice
to
document
the
process
of
of
just
changing
those
services
to
load
balancers,
because
it's
pretty
straightforward
and
it
might
be
useful
to
people
foreign
like
one
of
the
first
things
I
do
when
I
spin
it
up
is
to
change
Jager
into
a
load.
Balancer.
C
C
I
think
there's
two
parts
of
that
to
expose
something
kubernetes
externally.
You
need
the
infrastructure
to
provide
it
either.
You
need
something
like
a
metal,
lb
load,
bouncer
controller
or
the
elb
controllers
on
eks
or
ALB
controllers
for
Ingress
routes.
So
you
need
some
kind
of
info
to
make
it
work.
C
B
C
C
F
So
there's
some
what
I
I
don't
know
if
they're
considering
this,
but
also
the
the
open
telemetic
collector
in
the
configuration
needs
to
allow
the
incoming
request
from
the
browser,
as
well
as
our
course.
So
we
need
to
know
ahead
from
which
endpoint
the
auto
collector
is
going
to
be
requested
from
or
from
which
URL
I.
C
So
there
is
a
way
today
where
you
could
override
the
collector's
config
and
we
could
specify
it
ourselves,
but
we
should
do
it
by
default
and
I.
Think
Oscar
we're
probably
going
to
need
another
environment
variable
for
you
right.
Would
you
call
like
next
open,
Telemetry,
collector
or
something
like
that.
F
C
C
D
But
with
that
I
think
we're
pretty
much
good
for
today.
I
think
we
did
hit
a
couple
different
Milestones
recently,
partly
thanks
to
piers
and
I.
Guess
all
the
different
blog
posts
and
things
like
that,
but
we're
at
200
slack,
channel
members,
30
000,
doctor
polls
and
I
think
175
stars
and
over
100
forks.
So
a
lot
of
recent
kind
of
round
numbers-
I
guess
don't
mean
anything
but
sound
kind
of
nice.
So
it's
cool
to
see.