►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Lightning Talk: 5 Minutes to Value, Strategies for Faster Observability Onboarding
5 Minutes to Value, Strategies for Faster Observability Onboarding This session will cover strategies and best practices for improving Time To Value for observability onboarding, learned from helping onboard thousands of users with the instrumentation packages that are now a core part of most OpenTelemetry clients. Primarily, it will focus on novel configuration strategies when creating client instrumentation packages. These approaches help solve one of the biggest Onboarding challenges: How can users augment their telemetry with context specific to their business use case, without having to maintain huge chunks of custom, hard to maintain OpenTelemetry manual instrumentation code in their application?"
A
Hey
everybody.
Thank
you
for
taking
the
time
to
come
to
my
open,
telemetry
community
day.
Lightning,
talk
called
five
minutes
to
value
strategies
for
faster
observability
onboarding,
so
real
quickly,
we'll
just
go
over
what
I'll
discuss
today.
Do
a
little
introduction
talk
a
little
bit
about
what
five
minutes
to
value
means
and
how
it
relates
to
onboarding
in
open
telemetry
talk
about
some
really
useful
client
configuration
options
for
onboarding
and
then
provide
a
few
suggestions
for
future
contributors
when
they
think
about
how
to
treat
onboarding
when
it
comes
to
writing
open,
telemetry,
instrumentation.
A
So
a
quick
introduction,
my
name
is
eric
mustin
hello,
nice
to
meet
you
all.
I
work
over
at
datadog
is
a
software
engineer
on
the
apm
integrations
team
and
I'm
also
active
in
the
open
telemetry
community,
I'm
a
contributor
and
approver
on
open,
telemetry
ruby,
and
I
have
committed
to
a
number
of
other
open
telemetry
repositories,
so
whether
it
is
at
work
helping
customers
on
board
to
the
vendor.
I
work
at
or
it's
in
the
getter
channel
or
in
sig
meetings.
Listening
to
users,
talk
about
how
they're
getting
started
with
open
telemetry.
A
I've
had
a
chance.
Recently
to
learn
a
lot
about
onboarding
pain
points
and
what
we
can
do
as
a
community
to
make
that
easier
for
our
users.
So
first,
let's
talk
about
this
term
five
minutes
to
value
right,
it's
a
catchy
term!
So
what
does
it
mean?
It's
first
off,
it's
a
goal
in
the
opent
open,
telemetry,
collector
roadmap,
but
more
broadly,
it's
just
an
extension
of
the
onboarding
concept,
time
to
value
it's!
It's
just
the
idea.
A
How
long
does
it
take
for
our
user
to
start
to
realize
value
out
of
a
product
from
the
moment
they
begin
to
use
it
and
get
it
set
up
for
the
open,
telemetry
collector.
Specifically,
a
lot
of
the
road
map
goals
are
around
sort
of
just
working
out
of
the
box
right,
so
distributions
for
common
targets,
whether
you're
running
on
docker
or
windows,
just
giving
you
easy
ways
to
get
up
and
running.
A
It's
also
about
giving
you
data
sort
of
out
of
the
box
to
start
to
play
with
so
it's
automatic
collection
of
cloud
provider,
metrics
or
tags,
k-8s,
telemetry
or
even
just
host
metrics,
and
then
it's
also
about
getting
and
gathering
application
specific
metric
collections.
So
if
you're
running
kafka
or
hadoop
or
you're
running
sidekiq
a
lot
of
these
pieces
of
popular
open
source
software
emit
data
out
of
the
box,
and
we
can
collect
that
information
automatically
and
populate
it
in
your
back
end
of
choice.
A
So
that's
one
concept
of
five
minutes
to
value
sort
of
like
just
magically
working
out
of
the
box,
but
as
we
all
know,
when
it
comes
to
onboarding,
it's
never
just
as
easy
as
just
working
out
of
the
box
right.
The
difference
between
theory
and
practice
is
always
real
on
the
left.
You
can
see
sort
of
onboarding
in
theory,
you
invest
a
little
bit
of
time
and
you
get
this
great
value
and
then
you
get
incremental
gains
as
you
invest
more
time,
but
in
practice
there's
peaks
and
valleys
right.
A
A
You
gain
some
more
value
and
then
something
else
goes
wrong
and
it's
sort
of
this
poland
push
and
pull,
and
each
of
those
valleys
in
this
graph
on
the
right
is
an
opportunity
or
an
area
where
the
user
might
turn
the
user
might
just
throw
up
their
hands
and
say
you
know
what
I'll
just
stick
with
what
works
for
me
and
so
for
open
telemetry.
We
want
to
limit
those
situations.
A
Why
does
onboarding
matter
to
open
telemetry,
because
onboarding
speed,
5
x
many
minutes
to
value,
helps
adoption
the
faster
a
user
can
onboard
and
sort
of
get
the
data
exactly
the
way
they
want
it
in
open
telemetry?
That
means
the
more
time
they
have
to
actually
prove
the
value
of
all
this
rich
data
to
their
stakeholders
internally.
It
means
they
have
time
to
more
time
to
actually
dig
in
and
start
to,
diagnose
issues
or
understand,
root
causes,
and
it
also
gives
them
more
time
to
configure
their
setup
for
specific
business
use
cases.
A
So
onboarding
matters
for
open
telemetry
and
we
want
to
make
sure
that
that
onboarding
process
is
as
seamless
as
it
can
be,
and
so
a
lot
of
the
ways
this
has
been
done
historically
is
sort
of
with
magic
defaults,
and
that
was
talked
about
a
little
bit
in
the
roadmap
earlier,
but
there's
more
to
onboarding
than
just
magic
defaults
right.
Magic
defaults
are
wonderful.
A
They
give
you
a
really
wonderful
sort
of
demo
view
or
or
view
write
a
getting
started
view,
but
a
user
is
only
actually
onboarded
when
they
have
all
the
data,
they
need
formatted
exactly
the
way
they
need
it,
and
anyone
from
a
vendor
can
tell
you
that
the
questions
don't
stop
once
something
starts
working
it
only.
They
only
stop
once
everything
is
exactly
the
way
user
wants.
A
We
just
want
to
be
able
to
have
them
use
open,
telemetry
software
out
of
the
box,
with
these
really
great
configuration
options,
and
so
I've
just
gone
through
and
quickly
want
to
quickly
highlight
a
few
of
the
really
useful
configuration
options
specifically
request
response
configuration
hooks,
allow
deny
lists
and
the
ability
to
toggle
on
and
off
different
tracing
of
middleware
or
unimportant
spans.
So,
let's
start
with
the
one
I
think
is
most
useful
is
configuration
hooks,
I'm
using
open,
telemetry.js,
specifically
their
node
packages
as
an
example.
A
Here
we
want
to,
for
example,
have
a
user
is
making
requests
to
the
github
api?
The
github
api
is
very
heavily
rate
limited,
and
so
they
want
to
be
able
to
know
if
a
request
is
four
or
fouring
or
returning
a
400
or
500
response
code
due
to
rate
limit
issues.
But
the
issue
is
that
the
automatic
instrumentation
of
h,
node
http
clients,
doesn't
automatically
capture
every
single
response
header.
A
So
normally
this
would
be
an
issue
that
have
to
write
a
wrapper
around
their
http
calls
or
they'd
have
to
be
able
to
hook
into
some
sort
of
after
request
hook
in
their
http
client
and
be
able
to
grab
the
current
spam
context.
But
instead
there's
this
really
great
configuration
option
called
apply,
custom
attributes
on
spin
and
it's
a
hook
that
takes
this,
both
the
span
and
the
request
and
response
objects
as
arguments.
A
A
We
don't
have
to
store
the
response,
object
anywhere
to
access
it
later
and
now,
as
you
can
see
in
my
vendor
back
end,
I
have
that
x
rate
limit
remaining
span
attribute
available,
so
I
can
filter
and
slice
and
dice
based
on
you
know,
rate
limits,
and
this
is
a
really
great
option
and
makes
it
easy
for
users
to
extend
their
instrumentation
to
any
use
case
right.
We
don't
know
ahead
of
time
that
it's
going
to
be
rate
limits.
A
We
just
want
to
be
able
to
make
it
easy
for
them
to
define
the
information
they
need
without
having
to
roll
their
own
custom
code,
besides
being
able
to
just
augment
your
telemetry
with
useful
extra
metadata.
Another
really
important
aspect
of
onboarding
configuration
is
giving
users
flexibility
when
it
comes
to
security,
performance
and
data
ingestion
costs,
and
that
means
being
able
to
control
really
precisely
what
actually
gets
instrumented
and
doing
so
via
configuration.
A
You
can
set
that
can
exclude
urls
based
on
regex,
so
it's
called
hotel
python,
django,
excluded
urls
and
in
the
example
here
you
can
see
we're
excluding
urls
for
a
specific
client's
metadata,
which
might
be
a
particularly
sensitive
client
and
we're
also
not
tracing
health
check.
Endpoints,
because
there's
a
relatively
low
value
pieces
of
telemetry
data,
and
then
you
can
also
see
in
open
telemetry
js
express
the
express
instrumentation
has
options
to
not
instrument
specific
pieces
of
middleware.
So
here,
for
example,
using
the
option
called
ignore
layers.
A
We've
chosen
to
ignore
the
body
parser
middleware,
and
so
this
is
really
important
if
let's
say
you're
getting
charged
or
you're,
storing
the
data
yourself
and
so
every
additional
span
you're
storing,
has
has
cost
to
it
and
something
like
a
body
parts
or
middleware.
Middleware
is
almost
never
going
to
have
any
value,
and
it's
just
not
necessary
to
trace.
So
you
can
optionally
choose
what
you
want
to
instrument
and
what
you
don't
want
to.
A
So
those
are
just
a
few
examples
of
areas
where
client
configuration
which
lets
users
augment
their
span.
Data
can
help
onboarding
tremendously
and
so
for
future
contributors
here
who
want
to
add
their
own
instrumentation
or
contribute
instrumentation.
Some
lessons
to
think
about
are
one
is
treat
onboarding
as
a
first
class
citizen
users
don't
want
to
write
glue
code,
they
want
to
be
able
to
use
officially
supported
configuration
options
when
available.
A
A
If
not
better,
also
when
you're
writing
instrumentation
take
a
look
around
at
what
other
language
client
implementations
may
have
done
for
similar
libraries,
it's
important
to
try
to
borrow
best
practices
from
some
of
the
other
languages
when
you
can,
and
that
also
means
looking
around
and
seeing
what
are
the
existing
naming
conventions
and
environment
variable
conventions
that
exist
here.
We
don't
want
to
add
to
the
cognitive
overload
of
folks
who
might
be
running
multiple
clients
in
multiple
languages
in
their
production
systems.