►
From YouTube: 2023-03-02 meeting
Description
OpenTelemetry Prometheus WG
A
B
A
D
C
E
D
What
did
you
say?
Ted
said
he
won't
be
able
to
join
okay,
but
it's.
D
Reese,
do
you
want
to
wait
till
like
five?
After
before
we
start
or
give
it
a
couple
more
minutes,
we
can
probably
get.
E
Started
I,
imagine
you
know
if
people
do
pop
on,
they
can
probably
catch
up.
Hopefully.
D
All
right
well
in
in
that
case
we
shall
get
started
so
Welcome
to
our
I
guess.
Second,
q,
a
of
the
year
and
this
time
we
have
Doug
Ramirez
from
uplight
who
has
enthusiastically
volunteered
to
share
his
experiences
in
adopting
open
Telemetry
at
up
late,
so
welcome
Doug,
hi.
C
Thank
you,
Adrian
I'm,
really
glad
to
be
here
and
I,
because
you
and
I
were
talking
the
other
day.
C
C
The
reason
we
got
into
computer
programming,
computer
software,
whatever
you
want
to
call
it,
is
that
that
kind
of
immediate
sense
of
gratification
that
you
got
when
you
started
writing
your
first
few
lines
of
code,
like
you
wrote
some
code
and
depending
on
how
young
or
old
you
are,
you
might
have
compiled
it
and
linked
it
and
executed
it
or
you
just
might
have
run
it
in
some
kind
of
interpreter,
but
that
that
initial
feedback
that
you
get
where
you're
like.
C
Writing
software
in
the
70s
like
for
me,
observability,
is
really
kind
of
about
scratching
that
edge
and
that
idea
of,
like
I,
want
to
see
the
thing
that
I'm
building
you
know
executing
in
some
kind
of
runtime
environment
I
want
to
get
feedback,
and
so
for
me,
observability
speaks
a
lot
to
that
kind
of
initial
excitement
that
that
I
remember
having
and
was
one
of
the
things
that
really
got
me
excited
about
computers
and
software
and
computer
programming
and
is
I've
talked
to
people
over
the
decades.
C
I
think
that's
a
familiar
story
for
a
lot
of
people.
Just
the
idea
of
like
oh
I
did
something
that
was
really
cool,
and
so
for
me,
observability
in
a
lot
of
ways
is
about
like
that.
That
childlike
excitement
that
you
got
when
you
wrote
your
first
program
and
actually
got
to
see
it
run
for
the
first
time.
D
C
Yeah
and
you
know,
and
again
like
you
know
it's
you
know
today
right
wrong
or
indifferent
right
and
in
cloud
computing
and
the
way
that
we
do
things
today.
C
It's
interesting
how
it's
actually
kind
of
gotten
hard
to
see
your
software
running
and
so
like
more
than
ever,
I
think
observability
is
important.
You
know
for
technical
reasons
and
business
reasons,
but
I
think
also
just
for
developers
to
be
able
to
kind
of
have
that
same
sense
of
excitement
that
you
had
when
you
first
wrote
your
first
program,
but
get
it
every
day
all
day
as
a
professional.
D
Yeah
yeah,
most
definitely
and
with
that
I
think
it's
a
good
segue
for
us
to
launch
into
into
our
questions.
C
Sure
so
my
title
is
principal
architect,
I
work
specifically
on
the
part
of
our
Engineering
Group
around
our
our
platform.
C
It
uplights
a
very
interesting
company.
You
can
go
to
uplight.com
our
our
mission
is
to
save
the
planet
and
we
do
that
by
helping
utilities
operate
their
grids
as
efficiently
as
possible,
so
that
you
know
we
can
minimize
resource
consumption
really
at
the
end
of
the
day
and
offset
do2
and
so
a
lot
a
lot
without
going
into
a
whole
lot
of
detail
about
about
what
up
light,
how
those
platforms
actually
work.
C
But
we
have
some
Central
platforms
where
we
centralize
a
lot
of
our
large
data
sets
around
utilities
and
so,
as
we've
grown
through
mergers
and
Acquisitions,
the
the
data
platform,
the
utility
data
platform,
the
uplight
data
platform
is
very
important
component,
that
that
enables
a
lot
of
our
applications
and
the
things
that
ultimately
deliver
value
to
our
customers.
And
so
my
role
as
principal
architect
on
the
platform
is
to
help
you
know
essentially
design
and
architect
that
in
ways
that
you
know
satisfies
the
things
that
the
business
needs
it
to
do.
C
C
Is
a
big
part
of
that,
and
so
you
know
my
role
as
principal
architect
and
thinking
about
building
out
this
platform.
Extending
this
platform
you
know
observability
is
is:
is
one
of
the
most
important
things
that
we
optimize
for
as
an
architecture
characteristic
and
so
I
have
spent
a
lot
of
time
in
the
last
year.
C
Thinking
about
observability
talking
about
observability
trying
to
make
observability
into
everything
that
we
do
so
that's
that's
my
role
at
at
uplight.
D
Cool
cool,
and
so,
like
you
mentioned,
you
know
wanting
like
making
sure
that
observability
is
is
baked
in
to
the
organization,
given
that
you
know,
you've
prioritized
observability,
which
I
think
we're
all
excited
about.
What?
How
does
it
factor
in
terms
of
like
some
of
the
challenges
that
you
have
experienced
in
in
at
up
late
in
so
far
as
like?
What?
What
do
you
think
observability
will
help
to
solve.
C
So
I
think
for
for
us
and
given
sort
of
where
the
different
levels
of
maturity
are
with
different
aspects
of
our
our
software
ecosystem.
Like
there's,
you
know
said
there
are
places
where
observability
is
well
validated
and
it's
going
very
well,
there's
other
places
where
it's
not
going
so
well
and
we're
you
know:
I
we're
a
company
that
is
actually
a
conglomerate
or
we're
made
up
of
several
other
companies
that
were
brought
together
as
part
of
a
the
uplight
brand.
C
So,
as
you
can
imagine,
you
know
a
couple
of
different
companies
all
coming
together.
There's
different
technology,
Stacks,
there's
different
design
patterns
that
were
implemented.
There
were
different
different
ways
essentially
to
approach
the
same
problem,
so
one
of
the
things
that
that
our
platform
does
and
one
of
the
things
that
I'm
trying
to
help
enable
in
all
the
other
applications
and
services
that
use
our
platform
is
to
have
a
common
path
to
creating
observability
and
so
specifically,
as
it
relates
to
observability
with
an
uplight
I.
C
Think
the
one
of
the
problems
I'm
working
to
to
solve
is
to
try
to
create
a
single
path
for
giving
developers
the
ability
to
see
their
code
executing
in
a
runtime
environment
and
for
us
that
means
really
leaning
into
open
telemetry
as
a
standard
of
specification
and
a
set
of
tools
to
get
there
so
again
kind
of
zooming
out
the
idea
is:
okay:
we've
got
all
these
different
systems,
they're
built
with
different
Stacks.
We
need
to
observe
them
all
running
together
as
a
cohesive
unit.
How
can
we
do
that?
C
Let's
really
lean
into
the
specification
in
this
in
this
API,
and
if
we
do
this
well,
we
can
create
the
same
experience
that
every
developer
in
the
company
has
when
it
comes
to
observing
their
code,
irrespective
of
the
tech
stack
that
they're
using
I
think
that's
one
of
the
design
goals
that
open
Telemetry
has
and
I
feel
like
that
is
actually
going
to
enable
us
and
has
been
enabling
us
to
achieve
the
things
that
we
want
to
achieve,
specifically
as
it
relates
to
that
developer.
Experience.
D
Yeah,
that's
fair,
fair!
Now
what
about
like
the
architecture
that
you
guys
are
working
with
you?
You
did
mention
that
there
was
like
some
disparate
disparate
systems,.
A
D
C
B
C
Everything
you
know
we
in
some
ways
we
do
we
we
have
a
lot
of
you
know.
We
have
a
lot
of
Ruby
applications.
We
have
a
lot
of
java
applications.
We
have
a
lot
of
python
applications,
I'm
sure
there's
some
.net
stuff
floating
around,
so
it's
it's
hard
to
describe
like
the
tech
stack
I
think
that
we
we
are
trying
we
kind
of
have
a
a
standard
internally
that
says:
okay,
any
new
development
we
want
to
leverage
python,
especially
as
it
relates
to
our
microservices.
C
So
what
that
meant
for
us
is
okay.
Well,
how
do
we
get
observability
and
how
do
we
get
open,
telemetry
injected
or
baked
into
the
all
these
different
platforms,
given
the
fact
that
they,
some
of
them
are
old,
some
of
them
are
new.
Some
of
them
use
different
languages,
some
some
of
them
use
different
Frameworks
and
so
the
way
that
that
we
decided
to
kind
of
increment
our
way
to
really
using
open,
Telemetry
and
really
creating
a
really
solid
observability
experiences
to
start
a
structured
logging.
C
C
One
is
it
it
gives
developers
like
the
most
basic
thing
they
need,
like
most
developers
want
to
be
able
to
just
write
a
log
write,
a
log
record,
so
I
can
see
what's
happening
yeah
so,
in
my
mind,
like
if
I
think
about
like
levels
of
maturity
as
it
relates
to
observability,
and
we
think
about
the
three
pillars
of
observability
like
logs
metrics
and
traces.
C
C
So
what
it
meant
was,
how
can
we
go
about?
You
know
getting
people
to
understand,
open,
Telemetry,
understand
what
the
long-term
Vision
around
observability
is
but
begin
with
structured
logging
and
start
to
get
the
sdks
into
our
applications
and
our
services
and
our
our
repos
So.
The
plan
has
been
well.
We
have
this
aspirational
vision
for
observability
right
now.
C
Another
line
of
code,
another
two
lines
of
code
and
now
I'm,
actually
creating
traces,
I
already
and
I'm
able
to
do
that,
because
I
already
have
the
the
software
development
kits
baked
into
my
my
application
right,
I've
kind
of
gotten
over
that
big
hurdle
of
like
what's
open
Telemetry.
What
is
this
SDK?
How
do
I
instantiate
this
so
I
can
just
say,
logger.info
once
we're
getting
once
we've
gotten
over
that
hump
the
path
to
really
then
leaning
into
those
other
pillars
of
observability
become
really
easy,
because
all
of
that
scaffolding
is
already
done.
C
It's
kind
of
part
of
my
pipeline.
You
know,
I've
got
it
in
my
packages,
I'm
running
it
locally
Etc,
so
that
for
us,
or
at
least
for
me
as
I,
think
about
observability
and
kind
of
where
uplight
is,
it
seemed
like
a
nice
way
to
kind
of
increment.
Our
way
to
you
know
what
we
really
ultimately
want
to
get
by
simply
solving
the
problem
of
let's
get
structured
logging
done.
Let's
get
the
sdks
baked
in
the
repos.
D
Cool
and
now
taking
just
a
a
bit
of
a
step
back
and
going
back
to
to
like
your
understanding,
your
stack,
your
Tech
stack.
Can
you
can
you
describe
like
what
like
what
your
build
process
is
like,
for
example,.
C
It
depends
yeah
favorite
thing
that
we
say
in
in
engineering
right.
It
depends
yeah.
D
Yeah
I
guess
building
deployment
actually,
which
I'm
sure
also
depends
right.
C
Yeah,
it
does
boy
I,
don't
think
it's
anything
terribly
unique
I
think
we
leveraged
Circle
CI
a
lot
and
and
Jenkins
in
certain
areas,
so
I
think
the
the
deployment
process
is
pretty
familiar.
C
We
we
run
everything
in
containers.
We
we
use
all
the
cloud
providers
and
so
I
think
you
know
so
so
it's
it's.
It
depends
on
the
business
that
you're
in
and-
and
it
varies,
we're
we're
working
on
trying
to
normalize
and
unify
all
that
around
a
single.
C
You
know
set
of
tools
that
allow
us
to
deploy
to
whichever
cloud
provider
we
want
to
use
the
the
good
news
is
that,
as
it
relates
to
observability
that
you
know
from
from
what
we've
seen
so
far
it
like
using
open,
Telemetry
and
using
the
sdks
that
we
have
it,
it
hasn't
impacted
or
really
kind
of
informed
the
pipelines
in
a
way
that
makes
us
do
anything,
weird
or
wonky,
like
it's
it's
for
from,
like
from
our
perspective,
it's
just
importing
it
and
using
a
different
Library.
C
You
know
there
are
some
things
that
you
know.
We've
had
to
consider
specifically
around
using
the
open
Telemetry
collector.
Like
do
we
deploy
a
single,
open,
Telemetry
collector,
alongside
an
application
where
it's
already
running,
let's
say
in
you
know
AWS
or
gcp,
or
do
we
start
to
build
out
some
kind
of
infrastructure
so
that
when
an
application
lands,
someplace
there's
an
end
point
where
there's
an
open,
Telemetry,
collector,
listening
and
perhaps
a
bunch
of
them
behind
like
a
load
balancer
or
something
like
that.
C
D
Now,
how
how
has
it
been
in
terms
of
getting
that
buy-in
on
folks
using
those
sdks
and
getting
them
using
the
structured
logging.
C
Yeah
I,
so
you
know
it
was
interesting.
The
conversations
around
this
a
lot
of
the
conversations
that
we
had
again,
because
my
my
my
Approach
was,
let's
start
with
loggers.
So
we
talked
a
lot
about
just
structured
logging
and
what
we
ended
up.
You
know.
Obviously
we
ended
up
with
you
know,
deciding
to
really
lean
into
the
log
signal,
even
though
it's
still
new,
but
one
of
the
things
we
realized
was.
You
know
somebody
solved
this
problem
like
structuring
a
log
record
like
there's
a
bunch
of
different
ways.
C
C
They've
already
thought
about
these
things.
You
know
from
our
perspective,
structured
logging
doesn't
really
differentiate
Us
in
the
marketplace.
It
really
is
kind
of
a
means
to
an
end.
So
we
had
lots
of
internal
debates
like
well.
Should
we?
How
should
we
structure
the
log?
What
should
we
do?
Does
open
Telemetry
really
give
us
what
we
need?
Do
we
need
to
extend
what
open
Telemetry
has
given
us,
but
at
the
end
of
the
day
it
was
like.
Well,
this
is
actually
really
good
and
it
satisfies
everything
we
need.
C
Let's
just
adopt
the
specification
and
not
reinvent
the
wheel,
and
if
we
do
that,
then
we
have
that
path
to
the
other
pillars
of
observability,
and
then
we
can
see
a
clear
path
to
what
we
really
want
to
get
around
observability.
And
so
you
know,
if
you
fast
forward
from
those
conversations
to
then
the
conversations
are
on
metrics
and
traces,
the
conversations
kind
of
started
to
sound
the
same,
but
a
little
bit
quicker
like
do.
We
really
want
to
create
something
new
I,
don't
think
we're
doing
anything,
terribly
unique
or
different.
C
D
B
D
I'm
quite
curious
because,
like
logs
are
probably
like
the
one
of
the
newest
specifications,
yeah.
C
D
So
I've
never
I've
not
spoken
with
anyone
thus
far,
who
is
actually
guinea
pig,
the
logs
so
yeah
like?
What
can
you
talk
a
little
bit
about
how
that's
been
given
that
it's
so
new
out
there.
C
C
I
think
where
I
think
where
we
became
comfortable
with
it
was
when
we
started
to
peek
ahead
a
little
bit
and
started
to
really
kind
of
test
out
law.
Correlation
I.
Think
that
I
think
at
least
in
my
experience
and
I
could
be
wrong
about
this.
But
my
observation
was
that
when,
when
people
started
to
people
I'm
sorry,
people
became
comfortable
I.
Think
with
the
newness
of
the
log
signal
when
they
saw
logs
being
correlated
to
traces.
B
C
At
that
point,
I
think
people
were
like.
Oh
okay,
this
works
I
get
log
correlation,
which
is
what
I
want
I
really
want
to
get
to
right,
yeah
and
so
I
think,
once
people
were
able
to
see
the
the
the
the
new
spec
for
logs
working,
very
well
with
traces,
I
think
that
kind
of
let
everybody
relax
into
the
idea
of
that.
We
like
this,
isn't
as
risky
as
we
think
it's
going
to
be,
and
the
worst
case
scenario
is.
C
C
It's
like
okay!
Well,
we're
no
worse
off
than
we
are
today,
which
is
essentially
being
Our.
Own
Worst
vendor,
which
is
one
which
was
one
of
our
goals,
is
that
we
didn't
want
to
be
our
own
worst
vendor
for
something
that
is
I,
don't
want
to
say
just
purely
tactical,
but
it's
kind
of
tactical,
like
it
doesn't
really
differentiate.
C
Us
in
the
market,
it
enables
us
to
be
a
different
differentiator
so
anyway,
I
think
that
when
I
think
when
people
saw
law,
correlation
happening,
I
think
it
kind
of
allowed
people
to
relax
into
the
idea
and
feel
really
good
about
where
we
were
going.
I
did
I
I,
don't
know
if
I
answered
your
question
or
not.
Adriana
was
I.
D
A
D
Traces,
the
traces
are
the
end
to
end
the
the
logs.
Tell
you
what's
happening
at
this
point
in
time,
so
having
yeah
in
that
correlation
is
is
is
definitely
key.
Now
I
I
do
I
do
want
to
Circle
back.
You
did
mention,
like
you
alluded
to
some
challenges
in
terms
of
getting
folks
to
adopt
open
Telemetry.
D
What
are
some
of
the
challenges
in
general
that
you've
experienced-
and
you
mentioned,
like
you-
know
some
of
some
of
the
strategies
that
you
implemented
to
get
people
more
comfortable.
If
you
can
expand
on
on
yeah.
C
What
I
think
one
of
the
big
challenges
we
had
was
essentially
deviating
from
deviating
away
from
what
our
APM
APM
vendor
was
giving
us.
C
So
you
know
initially,
you
know
I
think
like
a
lot
of
companies,
we
all
feel
like
we're
spending
a
lot
of
money
on
our
APM
vendors,
so
we're
very
we're
very
sensitive
to
that
relationship
and
because
of
that
I
think
there
was
definitely
some
people
within
the
company
who
saw
the
vendor,
giving
us
a
solution
and
thought
like
well.
Why
don't
we
just
use
the
vendor
solution,
and
so
again
it's
that
kind
of
that
typical
debate
or
a
very
traditional
debate
that
we
have
internally
is
like:
how
do
we
defend
against?
C
You
know
vendor
lock-in,
but
still
kind
of
do
what
we
need
to
do,
and
so
we
spent
some
time
thinking
about
this
I
think
at
the
end
of
the
day
after
I
think
after
we
saw
the
structured
logging
working,
we
saw
the
trace
correlation
Trace
law
correlation
working.
We
saw
metrics
working,
we
would
begin.
We
were
at
the
point
now,
where
we're
beginning
to
see
the
benefit
of
using
context
propagation
to
see
spans
and
traces
that
you
know
interact
across
different
processes.
C
I
think
we
started
to
realize
that
you
know
we.
We
actually
have
a
way
to
defend
against
Fender
lock-in
and
it
the
risk
seems
minimal,
so
I
think
I.
Think
one
of
the
big
one
of
the
big
challenges
we
had
was
just
trying
to
make
that
distinction
like
do
we
go
with
what
the
vendor
is
giving
us
use
their
sdks
know
that
we're
being
locked
in
but
have
a
path
or
do
we
spend
the
time
to
step
back
and
say?
C
So
I
think
once
developers
were
able
to
kind
of
see,
oh
I
can
achieve
all
the
things
that
I
want
and
I
can
help
the
business
by
defending
against
the
spender
lock-in
and
I'm
learning
a
skill.
That's
very
portable
and
most
people
I'm
talking
to
these
days
about
observability
or
talking
about
open
Telemetry
anyway.
This
is
going
to
end
up
being
a
really
wonderful
thing.
So
let's
go
down
this
path
right.
D
Right,
yeah,
yeah
and
it's
I
I
think
it's
such
a
good
position
to
be
in
I
mean
I
I'm,
biased,
because
I'm,
a
huge
fan
of
open
Telemetry
but
like
open
Telemetry
is,
is
in
a
really
good
place
right
now,
because
I
think
there
is
so
much
that
has
been
hashed
out
and
there's
so
much
buy-in
from,
like
all
the
major
vendors
that
it's
kind
of
hard
to
like
you
know,
justify
using
like
vendor
sdks
for
for
your
Telemetry.
When
there's
this
nice
little
standard
that
everyone's
supporting
over
here.
C
Yeah
yeah,
I
I
think
that
the
other
thing
that
was
that
was
interesting
about
our
kind
of
our
internal
debates
and
conversations
were
really
kind
of
around.
This
idea
is
open
until
I'm
a
tree
mature
one
of
the
things
that
I
found
myself
doing.
A
lot
of
was
kind
of
you
know
like
unwinding
the
history
of
open,
Telemetry
and
then
letting
people
know
that,
like
this,
isn't
something
that's
Half
Baked
that
just
came
about
last
year
like
this
is
actually
you
know
this.
C
Is
you
know,
years
of
thinking
up
and
designing
and
coming
up
with
the
specification
like
there's
some
maturity
behind
this
that,
if
you
start
to
really
kind
of
understand
the
history
of
open,
Telemetry
I
think
it
started
to
make
people
feel
a
little
bit
better,
that
we
weren't
on
the
bleeding
edge
per
se,
and
that
you
know
some
big
companies
and
some
very
smart
people
have
been
thinking
about
this.
C
For
a
while-
and
you
know
this,
this
concept
of
like
or
this
this
kind
of
litmus
test,
like
our
other
Titans
of
the
industry,
bought
into
this
thing
because
then
I'll
feel
comfortable
using
it
yeah
and
so
I
feel,
like
a
lot
of
my
a
lot
of
what
I
was
doing
internally
while
trying
to
sell
this
idea
was
saying
things
like
hey:
let's
go
look
at
the
APM
vendors
out
there
and
let's
go
look
at
their
blog
posts.
What
do
you
know?
They're
all
talking
about
open
Telemetry,
these
projects
came
from,
you
know,
other.
C
Like
relax,
so
I
think
I
think
understanding
the
maturity
of
open,
Telemetry
and
understanding
the
history
of
it.
I
think
helped
a
lot
with
you
know,
selling
it
internally
and
getting
people
to
buy
into
it.
The
idea
of
it,
not
only
you
know,
amongst
Engineers,
but
also
within
our
leadership,
because
not
everybody
in
our
engineering
leadership
was
as
familiar
as
with
some
of
these
things
as
I
am
and
so
I
think
being
able
to
explain
the
history
and
being
able
to
show
them
like
hey.
You
know,
there's
books
written
about
this.
C
Look
at
the
blog
post
from
all
the
APM
vendors.
Look
at
what
Google's
doing
look
at
what
you
know.
The
other
open
source
projects
are
starting
to
like
kind
of
shed
some
things
and
starting
to
say,
like
we
don't
need
to
do
that
anymore,
because
now,
open
Telemetry
is
doing
this.
Yeah
I
think
I.
Think
me
me
being
in
a
position
to
kind
of
go
and
do
that
research
and
kind
of
bring
it
back
to
uplight
and
then
share
internally
I.
Think
that
helped
a
lot
with
the
adoption.
D
C
C
You
know
I
I,
I
people
have
heard
me
talk
a
lot
about,
but
this
idea
of,
like
that,
uplight,
like
the
the
three
major
architecture,
concerns
that
we're
optimizing
for
right
now
are
observability
deployability
and
security,
not
at
the
expense
of
anything
else,
but
like
we're
kind
of
sequencing,
our
work
a
little
bit
and
putting
more
time
and
attention
into
observability,
deployability
and
security.
So,
as
I've
been
talking
about
these
architecture,
these
overarching
overarching
architecture
concerns
you
know,
I've
been
using
that
those
opportunities
to
talk
about
open,
Telemetry
and
show
people
how
it
all
works.
C
We
we
rely
on
are
going
to
continue
to
rely
even
more
on
using
loom
as
a
as
a
way
to
capture
short
videos
that
we
can
share
internally.
I,
don't
know
if
how
many
people
remember
channel
nine
at
Microsoft,
but
Channel
9
was
this
thing
that
Microsoft
did
where
they
started
to
record
videos
to
disseminate
information
internally
very
quickly.
So
the
idea
was
like
you
tune
into
channel
nine,
and
you
can
see
these
videos
of
what
everybody
else
is
doing
at
the
company,
pretty
sure.
C
If
I've
got
I'm,
pretty
sure
I
got
that
right.
You
can
go
to
Wikipedia
and
double
check
my
math
there,
but
so
we're
trying
to
kind
of
create
that
same
mechanism
to
share
information
really
quickly
like
when
people
say
something.
It's
like
great
go
record
a
loom,
five
minutes
or
five
minutes
or
less
talk
about
something
show
some
code
and
just
do
that
quickly
and
share
information.
C
So
I've
recorded
a
bunch
of
looms
on
you
know:
structured
logging,
metrics
traces,
I've
just
been
started
to
do
some
videos
around
distributed
tracing
integrating
with
some
web
hook
platforms.
So
that's
been
another
a
way
to
do
it.
We
also
at
upload
we
do
hackathons.
So
we
have
internal
hackathons
which
are
awesome
so
awesome.
Everyone
should
do
it,
and
so,
during
our
during
our
hackathons
I've,
been
able
to
make
sure
that
open
Telemetry
gets
used
quite
a
bit.
Nice.
D
That's
awesome,
yeah
and
how
have
the
response
has
been
towards
the
the
Loom
videos.
C
Really
positive,
I
think
I
think
I
think
I
think
you
know
there
definitely
are
people
who,
like
long
format,
writing
and
reading
I'm,
not
one
of
those
person.
People
I
I,
don't
like
to
write
I,
don't
like
to
write
text
I'd
rather
just
code,
something
and
show
it
to
you,
and
so
like
video
is
just
a
great
way
for
me
as
an
author
to
to
explain
things
and
I
also
just
like
the
I
like
consuming
things
quickly
in
short,
bites
asynchronously
and
I.
C
D
That
is
very
cool
I!
That's
the
first
time
I've
heard
of
folks
using
loom
internally
for
that.
So
that's
that
kudos
to
you
guys
for.
A
D
For
for
getting
the
enthusiasm
up
around
that
pool
now
one
thing
that
I
wanted
to
ask
around
like
implementation
of
open
Telemetry,
you
said
that
you
started
using
the
the
open,
Telemetry
sdks
house.
How
has
the
overall
experience
been
around
integrating
that
into
the
application
code?
D
I
know
you
and
I
talked
about
python,
so
maybe
you
could
start
with
python
languages
as
well.
We'd
love
to
hear
your
thoughts
around
that.
C
You
know
it's,
it's
been
an
interesting,
it's
it's!
It's
put
on
lens
on
some
of
the
idiosyncrasies
that
a
lot
of
software
Engineers
have
you
know
this
is
this
is
a
debate
that
I,
you
know,
I've
been
I.
Guess
I've
been
dealing
with
for
probably
35
years
now,
but
this
idea
of
like
does
a
shared
Library
help.
C
So
for
us
we,
we
spent
a
fair
amount
of
time
trying
to
think
about
the
developer,
experience
and
the
benefits
of
a
shared
Library.
So,
for
example,
when
when
we
so
at
uplight,
when
we
make
architecture
decisions,
there's
always
a
few
artifacts
and
outcomes
that
we
produce,
we
produce
an
internal
RFC,
so
that's
or
a
dacey,
and
so
we
capture
our
decision
in
some
kind
of
documentation.
C
We
produce
a
hypothesis
for
a
fitness
function
so
like
how
do
we
test
our
architecture
to
assert
that
it's
that
it
is
satisfying
some
kind
of
characteristic
that
we
have
and
then
we
we
produce
a
reference
architecture
or
a
reference
implementation
when,
when
I
first
started
showing
off
some
of
the
reference
implementations,
like
you
know,
we
had
the
the
code
that
kind
of
instantiated
the
logger,
the
meter
and
the
Tracer
for
open
Telemetry,
just
in
a
common
module,
common
dot,
pi,
and
so
you
know,
of
course,
when
developers
see
that
they're
like
oh,
should
we
tease
that
out
and
put
that
into
a
library
that
other
people
import?
C
And
so
then
we
had
this
debate
of
okay
like
well.
It's
the
seven
lines,
eight
lines
of
code,
nine
lines
of
code
like
do.
Do
we
put
that
into
a
library
or
do
we
just
let
people
copy
and
paste
it
or
or
do
we
let
them
go
on
their
own,
because
at
the
end
of
the
day
the
SDK
is
there
and
like
what
effort
do
we
spend
to
reduce
that
to
something?
That's
even
smaller,
even
fewer
lines
of
code
so
I?
C
You
know
we
spent
a
lot
of
time
trying
to
think
about
like
how
do
we
make
it
easy
for
people
to
adopt
this?
Do
we
come
up
with
a
you
know,
an
uplight
library
that
people
can
import
and
then,
with
one
line
of
code
they
can
instantiate
a
logger.
Do
we
let
themselves
serve?
Do
we
let
them
pull
from
a
common
module?
I,
don't
know
if
we've
really
landed
on
a
popular
path,
but
I
think
right
now
the
answer
is
well.
C
Let's
just
let
everybody
kind
of
self-serve
like
if
you
want
to
create
a
lot
like
there's
a
group
of
people
that
have
created
an
uplight
library
that
kind
of
sits
on
top
of
the
SDK,
we'll
see
how
that
goes.
We
have
people
that
are
just
writing.
You
know
directly
to
the
SDK
I
think,
there's
people
that
have
probably
gone
back
to
my
reference
architecture
and
copied
that
common
module
and
brought
it
into
their
applications
may
be
fuss
with
it
a
little
bit.
C
But
yes,
but
I.
Think
if
you
zoom
out
the
the
good
news
is
that
it's
really
easy
to
adopt
it
and
that,
depending
on
your
organization,
you
could
benefit
from
a
shared
library
or
not
or
some
code
that
you
can
copy
and
paste.
But
again,
the
good
news
is
that
all
the
heavy
lifting
has
been
taken
care
of
and
that
you,
you
can
start
with
open
Telemetry
in
the
sdks
today,
and
that
would
be
my
recommendation.
C
It's
like
start
using
it
today,
like
any
other
package
or
any
other
language
that
you're
dealing
with
and
over
time.
If
you
see
opportunities
to
refactor
things
and
put
them
into
a
package
and
make
it
so
that
it
developers
really
can
use
that
package
seamlessly
and
that
that
package
is
going
to
be
maintained
and
it's
going
to
use,
you
know
the
new
versions
of
the
sdks
that
are
coming
out
and
not
get
old
and
crusty
and
blah
blah
blah.
C
D
C
C
Think
where,
where
I'm,
where
my,
where
I'm
thinking
right
now,
is
as
we
move
as
we
move
past
structured
logging
and
get
into
tracing
the
idea
of
doing
it
manually,
meaning
within
like
a
code
block,
let's
say
for
a
for
an
API
endpoint:
do
I
instancing
a
trace
there
or
do
I
use
a
decorator
and
something
else,
that's
part
of
a
framework
to
do
some
of
that
work.
C
For
me,
you
know
I,
think
kind
of
going
back
to
what
I
said
before
I
think
my
my
advice
to
everybody
would
be
like
to
try
one
of
the
maybe
try
manual
first
like
try
it
manually.
First.
Like
start
your
tracer
like
within,
within
a
with
block,
let's
say
and
just
see
how
it
goes,
and
if
you
you
start
to
see
the
benefit,
there
then
start
to
extract
that
out
into
a
decorated,
let's
say
or
some
middleware.
C
Maybe
that
works
well
with
your
with
your
framework,
but
you
know
again:
the
good
news
is
that
the
sdks
give
you
everything
you
need,
how
much
you
decide
to
optimize.
On
top
of
that,
I
think
is
you
know
up
to
you
and
whatever
use
case
you're
solving
my
advice
would
be:
do
whatever
do
the
minimal
to
get
it
plugged
into
your
code?
C
Do
the
minimal
to
get
traces
being
emitted
and
your
logs
admitted
and
correlated
and
then
go
back
and
do
that
refactoring
later
it's
you
know
it's
it's
I
mean
we've
all
seen
this
right,
like
you
sit
down
as
a
developer
like
oh,
like
how
can
I
reduce
this
to
like
the
ultimate
thing,
and
sometimes
you
get
value
out
of
those
exercises.
Sometimes
you
don't.
D
Yeah,
fair
enough,
fair
enough
cool
I,
one
thing
that
I
wanted
to
Circle
back
on
was
you
talked
briefly
about
your
hotel,
collector
deployment.
A
D
Feel,
like
that's
always
a
very
interesting
Hot
Topic
among
us,
because
it's
always
interesting
to
see
how
folks
choose
to
deploy
their
collectors.
So
I
think
you
mentioned
earlier
about
like
tinkering
with
a
couple
of
different
ways
to
deploy
your
collectors.
C
C
So
you
know,
we've
we've
been
spending
a
lot
of
time,
really
kind
of
thinking
about
like
how.
How
can
we
enable
fso?
How
can
we
lean
into
some
of
the
things
that
we
think
are
really
valuable
as
it
relates
to
team
topologies,
but
at
the
same
time
not
have
to
have
every
team
have
like
a
mini
Ops
group
inside
of
it
or
a
mini
infrastructure
group?
Inside
of
it
and
and
like
a
lot
of
companies?
You
know
our
infrastructure.
People
are
really
tapped
out
and
you
know
the
demands
on
our
infrastructure.
C
People
will
outpace
their
availability
for
the
next
several
years
and
so
trying
to
find
a
balance
between
you
know
what
I
would
ultimately
like,
which
is
just
an
endpoint
that
I
hit.
That's
up,
has
a
greater
availability
to
my
application.
I
know
that
I
can
just
send
things
to
it,
meaning
the
open,
Telemetry
collector
is
just
going
to
handle
stuff
versus
you
know
letting
people
get
started
today.
C
Maybe
they
run
the
open,
Telemetry
collector
as
kind
of
a
sidecar
in
their
deployment,
and
they
just
hit
that
and
then
later
on,
they
can
point
to
something
else:
I,
don't
I,
don't
know
if
we
have
enough
experience
yet,
where
I
feel
like
I
could
tell
people
like
what
a
really
good
way
to
approach
it
would
be
I
think
if
I
could
give
anybody
advice,
I
would
say
just
start
using
it
like
it's
the
good
news
about
the
collectors
that
it's
already
packaged
up
for
you.
C
If
you're
familiar
with
running
a
container
which
most
of
us
are
these
days,
you
can
get
started
with
open,
Telemetry
and
what's
also
really
nice
about
it.
Is
that,
like
as
a
developer,
I
can
run
it
locally
like
I'm
doing
a
lot
of
stuff
with
Docker
or
Rancher
anyway,
so
like?
If
I've
got
this
little
thing
running
over
here
and
I'm,
just
shooting
stuff
towards
it,
then
I'm
able
to
develop
I
can
offload
that
cognitive
load
I
can
think
about
the
one
line
of
code.
C
I
want
to
write
to
emit
a
log
record
and
know
that
when
I
deploy
it,
you
know
I'm,
probably
going
to
have
a
sidecar
nearby
which
is
going
to
get
sent
to
maybe
there's
a
centralized,
collector,
that's
running
someplace
or
maybe
even
better,
there's
just
an
endpoint
with
a
bunch
of
collectors
running
behind
it
scaling
out.
However,
they
need
to
scale
long
way
of
saying
I
don't
know
yet.
A
D
C
So,
like
some
of
our
larger
kubernetes
clusters,
like
those
platforms
like
there's,
a
collector
running
inside
of
it
so
like,
if
you
deploy
to
it,
you'll
know
that
it's
there
or
you
can
rely
on
the
fact
that
it's
there.
But
you
know
again,
like
the
the
we
still
have
a
lot
of
code
running
outside
of
gke
or
or
the
equivalent
at
AWS,
and
so
those
those
applications
and
services
need
to
pack
and
so
they're
they're
deploying
collectors
close
to
them.
C
So
a
little
bit
of
both
like
we
have
it
running
Standalone
as
some
side
cars.
We
have
it
running
in
a
few
Central
locations.
I
I
ultimately
would
like
for
any
deployment
at
any
cloud
provider
just
to
know
that
there's
going
to
be
an
end
point
with
some
kind
of
name
and
listening
on
a
port
and
regardless
of
where
I
deploy
my
code
and
irrespective
of
the
cloud
provider
I
can
rely
on
the
fact
that
that
thing
is
going
to
be
there
and
it's
going
to
handle
the
receiving
processing
and
exporting
of
those
signals.
D
Well,
and
who,
who
typically
maintains
the
the
collectors?
Is
that,
like
your
infrastructure,
team,
yeah.
B
D
C
So
it
I
think
we're
still
kind
of
I,
don't
know
if
we
have
enough
history
yet
I
think
like
ask
me
in
a
year
after
their
collectors
might
have
died
or
gone
offline
or
something
at
some
point.
They
maybe
maybe
we'll,
have
a
different
perspective
on
it,
but
right
now
I
think
people
are
I.
Think
people
are
happy
to
have
the
agency
to
run
the
collectors
locally,
because
it's
super
easy,
most
people.
C
C
You
know
what
it's
arguable,
whether
or
not
that's
really
the
best
use
of
a
developer's
time,
but
right
now,
I
think
it's
giving
people
a
path
to
success.
So
we
can
go
with
that
and
refactor
later.
B
D
I
know:
we've
got
like
11ish
minutes
left
on
the
clock.
It
I
would
love
to
get
your
feedback
as
we
wrap
up
on,
like
your
experiences
with
the
open
Telemetry
project,
because
you
know,
like
we
love
hearing
the
positive
user
stories
of
open
Telemetry,
but
we
also
want
to
hear
candid
feedback
on
like
you
know
where,
where
are
things
Rough
Around
the
Edges?
What
can.
A
C
Yeah
I
can
share
a
couple
things.
A
couple
thoughts.
One
is
I
I've
been
very
happy
with
the
activity
on
the
slack
org.
It's
it's
been
nice
to
chat
with
people
there.
C
So
you
know
that's
awesome.
Thank
you
all
for
doing
that
really
appreciate
the
the
visibility
into
like
what's
happening
and
be,
and
again
being
able
to
look
and
just
watch
the
conversation
because
it
definitely
informs
it
definitely
has
informed
my
thinking
and
the
decisions
that
I've
been
making
at
uplight
being
able
to
watch
to
see
what's
happening
and
kind
of
like
understand
where
things
are
going
and
and
and
to
also
to
understand
what
to
avoid.
C
You
know
I've
definitely
gotten
some
really
good
feedback
from
the
slack
Channel,
where
people
have
said
like
hey,
Doug,
I
know
what
question
you're
asking
I
know
where
you're
going
with
this,
but
you
really
don't
want
to
go
down
that
path.
For
these
reasons,
and
it's
been
like
man,
that's
what
a
lifesaver
like
I
was
able
to
avoid
making
a
mistake,
because
someone
is
able
to
kind
of
give
me
a
gentle
nudge
in
a
different
direction.
C
I've
I've
contributed
a
little
bit
to
the
the
open
source
project.
The
python
SDK
I
will
say
that
it.
C
It
took
me
a
little
bit
of
time
to
understand
like
how
do
I
really
get
engaged
and
like
who
do
I
speak
to
in
the
slack
Channel
and
like
how
do
I
like
how
do
I
stick
my
neck
out
and
say,
like
hey,
you
know,
I
opened
a
PR
and
like
can
somebody
please
look
at
it
and,
like
I
hate,
to
bother
you
please
be
nice,
so
I
think
anything
that
could
be
done
to
like.
C
Let
people
know
that
and
not
to
say
that,
like
my
stuff
wasn't
accepted
with
open
arms,
but
anything
that
we
can
do
to
make
it
super
easy
and
super
obvious
for
people
to
contribute.
I
think
that
would
be
helpful.
C
One
area
where
and
I
can
understand
why
this
is
a
challenge,
but
one
area
where
I
think
a
lot
of
Open
Source
projects
kind
of
deal
with
this
is
like.
Where
do
we
have
the
conversations?
C
Do
we
have
the
conversation
in
Slack
like
what's
appropriate,
to
go
where
I
don't
want
to
be
duplicative,
but
I
also
want
to
have
the
conversation
in
the
right
place,
and
so
I
don't
know
if
there's
good
guidance
or
good
practices
that
help
people
understand
like
where
do
where
do
I
raise
my
hand,
as
maybe
somebody
who's
new
and
wants
to
contribute
or
somebody
who's
new
and
is
seeing
a
problem.
C
So
that's
that's
an
area
that
I
think
that
that
could
that
could
help
some
with
some
clarification
and
again
I
think
that's
through
for
a
lot
of
Open
Source
projects
like
how
do
I
get
involved.
Where
do
I
have
the
conversations.
D
Yeah,
that's
that's
a
really
really
fair
point
and
I
think
we're
we're
still
trying
to
sort
that
out
ourselves,
but,
oh
also
like
we
are
open
to
any
suggestions.
Yeah.
C
Having
the
conversation
span,
you
know
the
code
repos
and
and
slack
sorry
down
yeah
like
if
I
can
think
of
a
way
to
do
that.
I
will
certainly
let
you
know,
let
you
all
know.
C
Oh
you
know.
The
other
thought
I
had
was.
C
C
C
I
think
that
I
think
that
might
help
with
some
of
the
adoption,
yeah
and
again,
and
that
way
people
can
really
kind
of
think
about
open,
Telemetry
and
the
spec
and
the
API
and
the
tools
and
not
have
to
sit
there
and
go
like
you
know,
banging
your
head
against
Docker
networking
and
things
like
that.
Yeah.
D
Absolutely
one
one
thing
that
I
think
can
help
with
that:
somewhat
is
I,
don't
I,
don't
know
if
you've
had
a
chance
to
play
around
with
the
open,
Telemetry
demo
app.
C
D
D
Demonstrates,
like
all
the
cool
stuff
that
you
can
do
with
open
Telemetry
in
different
languages,
so
like
different
microservices
written
in
different
languages,
there's
a
Docker
compose,
so
you
can
get
it
up
and
running
nice
and
fast,
and
then
there's
also
the
there's
a
a
Helm
chart
for
deploying
it
in
kubernetes.
If
you
are
so
inclined,
so
definitely
a
cool
one
to
point
Folks
at
up
late
to
for
the
extra
wow
factor
of
like
look
at
the
cool
stuff.
That
can
happen.
A
C
D
D
It's
being
updated,
yeah
and
then
there's
also.
You
talked
about
like
Central
libraries
for
configuring,
like
for
configuring,
open
Telemetry,
there
is
some
work.
There's
a
channel
called
Hotel
config
file,
which
I
mean
it
doesn't
take
the
place
of
centralized
library,
but
it
does
aim
to
make
it
a
little
bit
easier
to
configure
your
open,
Telemetry
sdks,
to
make
it
less
less
of
a
challenge.
Okay,
good,
depending
on
the
language.
It's
like
okay,
but
certain
languages
are,
are
more
difficult.
So
that's
another
good
channel
to
check
out.
B
C
I,
so
one
of
the
things
and
I
think
Adriana,
you
and
I
might
have
talked
about
this,
but
I'm
working
on
to
start
I'm,
trying
to
to
create,
like
the
the
most
minimal
example
of
two
python
Services
talking
to
each
other
and
and
leveraging
context
propagation,
so
that
you
can
see
that
distributed
tracing
and
so
I'm
trying
to
do
something
that
really
should
allow
anybody
with
you
know
a
modern
operating
system
in
Docker.
C
Let's
say
to
clone
a
repo
Docker
compose
up,
hit
a
service
and
then
see
the
two
Services
talking
to
each
other
and
just
and
surfacing
that
stuff
with
jaeger,
so
that
you
know
people
can
download
something
and
just
really
kind
of
focus
on
the
Core
Concepts
of
context
propagation
and
how
that
is
how
that
helps
enable
distributed
tracing
which
is
trying
to
push
everything
away
like
the
most
minimal
python,
fast,
API
Services,
talking
to
each
other,
but
doing
something
really
powerful
and
in
a
way
that,
like
there's,
very,
very
minimal
infrastructure
that
you're
going
to
need
to
run
it
like.
C
If
you
got
a
moderate,
if
you
have
a
modern
operating
system
in
Docker,
you
can
clone
this
repo
and
within
a
few
moments
you
can
run
a
command
and
be
like
ooh
now,
I
see
what's
happening.
This
thing
created
a
Trace
that
Trace
lived
over
there
and
I
can
see
how
these
two
processes
are
communicating
with
each
other
across
those
process,
boundaries.
D
C
Know
for
for
me
and
I
think
for
a
lot
of
other
developers.
Well,
I
should
say
I'm
a
developer,
that
is
a
tactile
learner
and
so,
like
I
like
to
read
a
little
bit,
but
then
I
like
to
look
at
code
a
lot
a
bit
and
so
for
me,
the
best
way
to
learn
something
like
this
would
be
to
like
to
skinny
it
down
like
I
like.
B
A
D
Well,
I
know
we
are
at
time.
So
thank
you.
Everyone
for
joining
Doug
I.
You
know
in
case
anyone
wants
to
keep
the
conversation
going.
You
know
we
can
always
take
the
conversation
to
our
slack
Channel.
D
We
can
Reese
Wren,
where
which
of
the
channels?
Do
you
think
we
can?
We
can
continue
the
conversation
in
if,
if
anyone
has
any
questions
for
for
Doug
or
if
you
know,
we
want
to
have
any
any.
E
C
C
D
We
wrap
up
Doug
you're,
doing
an
hotel
in
practice
session
at
the
end
of
the
month,
so.
D
Your
eyes
peeled
for
for
announcements
around
that
with
details,
yeah.
C
Yeah
I'm
hoping
that
that
will
be
largely
based
on
this,
this
little
reference
architecture
that
I'm
building
around
context,
propagation
and
distributed
tracing
so
I'm.
Looking
forward
to
that
very
much.
D
Awesome
and
also
we
will
be
you're
okay
with
us
posting
the
recording.
For
this
sure.
C
D
Absolutely
yeah,
and
we
will
also
be
doing
a
blog
post
summary
for
folks
who
prefer
to
read
rather
than
watch
so
you
have
many
ways
there.