►
From YouTube: Panel: Meet The Maintainers - Moderated by: Daniel Dyla, with Jack Berg, Amir Blum & Aaron Clawson
Description
SAVE THE DATES!
ArgoCon – Register Now | September 19-21, 2022 | Mountain View, California - https://events.linuxfoundation.org/argocon/
KubeCon + CloudNativeCon North America | October 24-28 | Detroit, MI - https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/
KubeCon + CloudNativeCon Europe 2023 | April 17-21 | Amsterdam, The Netherlands - https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/
OpenTelemetry is a collection of tools, APIs, and SDKs. Use it to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) to help you analyze your software’s performance and behavior. Go here to learn more: https://opentelemetry.io/
Panel: Meet The Maintainers - Moderated by: Daniel Dyla, Dynatrace; Jack Berg, New Relic; Amir Blum, Aspecto & Aaron Clawson, Lightstep
303+304 (JW Marriott Austin | 110 E 2nd St, Austin, TX 78701)
Speakers: Aaron Clawson, Daniel Dyla, Amir Blum, Jack Berg
Link to join the virtual event: https://www.accelevents.com/e/otel-community-day-na-2022
The virtual event concludes at 1:50PM CDT; In-person event concludes at 5:00PM CDT
This panel will be a deep dive into the OpenTelemetry Metrics specification, a discussion on why it differs from past metrics APIs, Prometheus interoperability and where we expect it to go in the future - bring your questions for Q&A!
A
C
C
A
D
A
C
C
But
we've
had
problems
with
them
being
maintained
long
term
right
like
making
sure
that
security
updates
still
get
applied
and
that
they
are
viable
in
in
the
long
term,
so
just
being
able
to
manage.
That
has
been
both
really
awesome,
seeing
the
cool
stuff
that
comes
out
of
it,
but
also
like
everything
that
we
accept
creates
more
burden
more
more
other
toil.
C
A
Yeah
and
one
thing
that
the
javascript
sig
has
done
in
in
the
line
of
maintaining
those
the
contrib
instrumentations
is
sort
of.
I
guess
what
I
would
call
distribution
of
ownership.
So,
in
the
early
days
everything
was
just
in
the
contrib
repo.
It
was
on
the
maintainers
and
it
was
like
five
instrumentations
ten
instrumentations
and
it
was
like
okay,
we
can
maintain
these
and
then
it
was
20
and
then
it
was
30.
A
So
now,
what
we
have
is
individual
contributors
who
own
or
maintain
a
single
instrumentation
in
the
the
contrib
repo
and
the
people
that
that
do
those
and
are
willing
to
say
I'll,
maintain
one
I'll
maintain
two
I'll
maintain
three
like
those
people
do
not,
if
any
of
you
are
in
the
room.
Thank
you.
You
do
not
know
how
much
that
helps
me.
If
you
take
even
just
one
or
two
that's
been
huge.
E
All
right,
we
got
a
question
from
the
chat
here
for
the
panel.
How
do
you
relate
your
work
on
a
vendor-neutral,
open
source
project
to
your
employer
or
to
the
people
that
sign
your
paychecks?
In
other
words,
if
there's
not
someone
above
you,
that's
already
kind
of
enlightened
to
the
value
of
contribution,
how
have
or
would
you
advocate,
for
making
a
certain
percentage
of
your
time
be
devoted
to
open
telemetry.
A
That's
a
tough
one.
I
think
most
of
us
here
come
from
companies
who
are
already
enlightened.
I
guess
you
would
say
to
that,
but
to
those
that
aren't,
I
would
say,
the
open
source
projects
don't
exist
without
contributors
and
everybody
who
works
here,
I'm
sure
works
at
companies
who
depend
on
open
source
projects.
B
B
So,
if
if,
if
your
business
has
a
strategic
dependency
on
some
sort
of
open
source
project,
I
think
you
wouldn't
feel
comfortable
if
you
had
a
proprietary
software,
that
you
didn't,
have
expertise
in
and
have
the
ability
to
change
in
response
to
you
know:
security,
vulnerabilities
or
other
sorts
of
events,
so
why?
Why
are
companies
more
open
to
not
having
that
understanding
and
the
ability
to
change
the
open
source
projects
that
they
have
the
same
dependencies
on
so
yeah?
B
C
C
But
you
don't
always
work
for
those
companies
and
my
one
recommendation
is
start
small.
It's
a
very
big
ask
to
say:
hey.
Can
I
even
get
10
of
my
time
to
dedicate
towards
helping
and
improving
the
open
source
projects,
but
it's
a
lot
easier
to
ask
for
hey.
I
made
a
fix,
like
this
package,
had
a
problem
that
we
had
we
are
experiencing.
I
made
a
fix.
Can
I
release
that
and
go
through
the
process
of
getting
that
and
just
training
that
muscle
within
the
organizations
so
start
as
small
as
you
can
and
work
up?
E
D
G
Hey
y'all,
I'm
ariel
from
the
ruby
sig,
so
just
wondering
from
y'all.
What's
your
experience
been
working
with
trying
to
build
instrumentations
that
have
first-party
support
in
libraries
versus
doing
things
like
third-party
support
and
adding
stuff
like
byte
code
manipulation
or
in
our
case
monkey
patches
really
for
for
a
lot
of
these
libraries
and
what's
been
the
appetite
of
library
maintainers
for
wanting
to
try
to
accept
contributions
and
changes,
I
think
you
were
alluding
to
that
a
little
bit
just
now,.
A
A
Unfortunately,
a
lot
of
a
lot
of
people
run
older
versions
where
we
can't
always
do
that,
but
the
I
think
the
the
instability
is
probably
the
wrong
word,
but
the
the
the
project
has
only
recently
gotten
to
a
point
where
I
think
a
lot
of
package
maintainers
feel
like
this
is
stable.
It's
going
to
be
around
long
term.
There
are
a
lot
of
users
and
we're
just
reaching
the
point
where
I
think
we
are
going
to
have
that
critical
mass
of
users
where
a
library
vendor
looks
at
it
and
says
wow.
B
B
We
can
modify
the
code
at
runtime
and
you
know
a
lesser
extent
is
library,
instrumentation,
so
libraries
that
provide
specific
extension
points
or
that
we
wrap
and
then
a
very
few
number
of
libraries
micro
profile
is
one
of
them
have
have.
You
know,
embraced
open,
telemetry
and
added
direct
instrumentation,
and
I'm
hopeful
that,
as
as
the
we
have
api
stability
around
the
the
core
signals
that
there's
more
of
those
that's
that's
kind
of
a
future.
I
look
forward
to
in
my
head
so
we'll
see
where
that
goes,
though,.
A
H
Yeah
yeah,
I
just
wanted
to
pretend
to
be
a
maintainer
for
a
second
and
mentioned
that
we
haven't
really
been
pushing
for
library
developers
to
add
native
instrumentation,
mainly
because
it
hasn't
felt
like
the
project
has
been
stable
enough,
yet
to
do
that,
not
just
the
apis,
but
also
the
semantic
conventions.
I
feel
like.
We
really
want
to
get
that
stable
before
we
start
kind
of
like
actively
pushing
that
idea
out
there,
but
it's
really
cool
to
see
some
people
just
dive
on
in
and
go
for.
It.
A
Yeah
I
mean
I
just
tackle
that
a
little
bit.
We
don't
want
to
make
a
big
push
to
say
you
should
build
this
in
and
then
you
know,
move
the
cheese
later
and
then
when
they
say.
Why
did
you
do
that?
You
told
me
to
do
this
and
you
said
it
would
be
fine
and
it's
like
well,
it
was
unstable
yeah
there
yeah.
D
E
I
Hi
hi
antuva
from
mobile
technology.
We
build
at
least
my
division.
We
build
data
processing
units
and
we're
launching
the
open
programmable
infrastructure.
We
linux
foundation
tomorrow
and
within
that
group
we
have
been
mostly
official,
not
announced
yet
adopting
open
telemetry
for
the
chips.
So
thank
you.
I
I'm
just
a
member,
but
anyway
the
question
is
we're
gonna
implement,
at
least
for
us
marvel
we're
gonna,
implement
hotel,
collector
agents
on
our
chips
probably
dedicate
an
arm
core
to
it.
This
preliminary
design,
mostly
in
my
head
right
now.
My
question,
is
process,
pointers.
Thoughts
on
how
do
we
do
that?
You
know
piggyback
on
the
the
answer
just
now
about
you
know,
libraries
and
version
packaging
and
all
that,
among
other
things,.
C
C
Honestly,
my
suggestion
is
just
make
sure
that
it
has
a
processor,
a
linux
environment,
even
if
you're
running
a
container
a
from
scratch
container.
That
just
has
the
binary.
If
it
has
the
processor
and
the
memory,
it's
probably
going
to
be
a
good
experience,
but
that
also
just
means
you
also
have
to
be
able
to
integrate
it
with
the
rest
of
your
platform.
C
C
A
E
Yeah,
corporate
security
stuff,
we
would
love
to
talk
to
you
about
how
to
get
the
output
of
the
collector
builder
a
certified
thing
through
supply
chain
security
stuff,
because
I
don't
I'm
editorializing
sorry
one
challenge.
I've
noticed
in
especially
the
enterprise
is
that
they
will
approve
a
given
specific
version
of
a
collector
binary,
which
is
great
but
goes
completely
identical,
antithetical
to
what
you
just
said
about
the
collector
being
a
framework
for
building
collectors.
So
there's
some
work
that
needs
to
be
done.
E
E
Yeah,
I
know
I'm
just
going
to
go
outside
and
I'm
going
to
I'm
going
to
walk
in
the
hall
and
scream
supply
charge
security
where's
my
supply
chain
security
fanatics
at
all
right.
I
got
another
question
from
the
chat:
what
have
been
the
biggest
challenges
with
implementing
the
api
and
sdk
across
the
supportive
languages
in
a
standardized
way?
How
much
does
the
sdk
configuration
feel
native
to
your
language.
A
A
You
know
method
name
with
these
arguments
and
all
of
that
and
it's
the
same
in
every
language.
But
then
a
ruby
developer
looks
at
it
and
says:
well,
this
isn't
how
we
typically
name
things.
It
feels
weird
to
me
or
a
go
developer,
looks
at
it
and
says
this
isn't
how
we
normally
name
things.
It
feels
weird
to
me
or
how
I
normally
structure
my
project
or
anything
like
that.
So
I,
if
you
read
the
specification,
which
I'm
sure
a
lot
of
people
here,
are
familiar
with
the
specification,
you'll
notice.
A
It
leaves
a
lot
of
leeway.
It
defines
the
way
that
features
should
work
and
feel
and
the
value
that
they
should
provide
and
how
they
should
do
that.
But
it
does
also
leave
a
lot
of
leeway
for
individual
implementations
to
make
it
feel
native
for
their
users,
which
I
has
been
extremely
helpful
for
me.
As
you
know,
a
maintainer
to
say,
I'm
looking
for
people
who
know
javascript,
not
necessarily
people
who
are
super
intimately
familiar
with
the
way
that
other
hotel
sdks
or
the
specification
work.
B
Although
I
would
say
that
they
don't
feel
entirely
similar,
there's
the
ergonomics
from
language
to
language
yeah,
it's
not
entirely
intuitive.
So
I
I
think
of
the
specification
as
more
of
a
specification
of
functionality
rather
than
like
ergonomics,
and
so
you
know
you'll
be
able
to
find
the
same
features
in
each
each
of
the
language,
but
yeah
we
had
some
maintainers
in
java
that
you
know
just
recently
used
the
go
sdk
and
api
and
they
were
kind
of
they
were
kind
of
surprised
at
how
different
it
felt
so
trade-offs.
D
Hello:
everyone,
my
name
is
shubanshu,
I'm
part
of
adobe
and
I'm
part
of
the
observability
team
at
adobe,
and
we
are
trying
to
increase
the
adoption
of
open
telemetry
at
adobe.
So
we
interact
with
a
lot
of
engineering
teams
and
so,
first
of
all,
I
would
like
to
thank
the
java
community
for
building
the
auto
instrumentation
teams
and
adobe
loves
that
that
makes
their
tracing
and
instrumentation
easy
and
onboard
to
them.
B
Well
I'll
just
say
before
we
get
too
far,
is
that
so
we
were
supposed
to
have
trask
here.
He
couldn't
make
it
and
he's
he's
one
of
the
maintainers
for
the
open,
telemetry
java
instrumentation
project,
which
is
where
the
auto
instrumentation
comes
from,
and
so
I'm
kind
of
on
the
other
side
of
things
in
the
in
the
java
space.
I
work
a
little
bit
with
those
folks,
but
I
work
primarily
on
the
api
and
sdk,
so
big
shout
out
to
the
instrumentation
folks
on
your
behalf.
A
Yeah,
so
for
for
the
javascript
sake,
I
would
say
our
primary
focus
has
been
on
getting
the
you
know.
The
signals
to
a
stable
level
within
the
sdk,
because,
when
they're
not
stable,
maintaining
very
advanced
instrumentation
can
be
difficult.
If
the
api
changes,
you
then
have
to
go
change,
50
60
packages,
which
can
be
a
challenge.
Obviously
we
also
have
a
lot
of
issues
with
different
versions
of
node,
supporting
different
things
and
and
maintaining
backwards
compatibility
because
the
node,
the
node
community
is
not
always
on
the
latest
versions.
A
I
guess
I
would
say
yeah
I
mean
yeah
it.
Every
every
community
has
those
problems,
but
a
lot
of
our.
So
we
don't
have
the
auto
instrumentation
the
way
that
java
does
where
you
can
just
run
a
single
command
and
it
works.
But
I
know
we
actually
have
been
working
on
that
and
I
would
say
hopefully
coming
soon,
but
until
then,
if
you
can
modify
just
the
startup
of
your
of
your
process,
you
can
actually
get
quite
a
bit.
A
If
you,
you
know,
we
have
like,
if
you're
familiar
with
node,
there's
like
a
dash
r
flag,
that's
short
for
register,
which
will
load
or
short
for
require
which
will
load
a
file
before
your
application
loads,
and
it
only
takes
like
10
lines
in
like
a
tracing
js
file.
To
do
the
setup
work
required
in
order
to
then,
when
your
application
loads,
everything
is
automatically
instrumented.
C
D
C
That
being
said,
I
know
there
are
some
people
that
are
just
getting
off
the
ground
trying
to
work
that
in
go
and
it's
it's
monumental
tasks
for
them.
I
also
wonder
if
for
go
just
the
way
we've
built
the
way
the
language
is
built,
if
maybe
just
having
easy
ways
to
wrap,
is
enough,
because
it's
very
common
for
go
programs
to
start
off
with
setting
up
a
number
of
your
dependencies
right
off
the
bat
so.
C
F
I
think
auto
instrumentation
is
super
important,
like
we're
all
very
involved
in
open
telemetry.
We
know
all
the
details
and
how
to
set
up
an
sdk
and
configure
it
and
register
everything
and
how
it
all
works,
but
the
people
that
want
to
use
open
telemetry
they
usually
it's
just
one
task
of
other
things
they
have
to
do.
They
want
to
get
started
as
quickly
as
possible
as
easily
as
possible.
They
don't
want
to
spend
few
days
learning
all
the
details
they
just.
Let
us
give
you
something.
F
A
I
would
also
quickly
mention
I'm
not
super
familiar
with
this,
so
I
won't
speak
about
it
for
a
long
time,
but
I
know
that
the
the
operator
project
does
do
some
like
auto
injection,
even
in
languages
like
javascript,
like
where
I
said,
we
don't
necessarily
have
the
no
code
modification
set
up,
but
where
the
initial
setup
is
easy
to
do.
If
you're
running
in
a
kubernetes
environment
the
the
operator
can
do
some
of
that
injection.
For
you
and
again,
I'm
not
super
familiar
with
it,
but.
E
J
Hello
as
far
as
infrastructure
metrics
are
concerned,
and
the
the
kind
of
recommended
way
to
play
within
the
infrastructure
metrics
ecosystem.
Now
that
prometheus
and
the
pole-based
system
is
kind
of
one.
The
the
dominant
structure
there.
What's
the
recommendation
as
far
as
open
telemetry,
metrics
emission
and
collection
from
host
base
and
points
within
the
infrastructure,
is
it
to
recommend
it
to
always
have
the
pole
base
method
and
then
also
how
do
metrics
worth
work
within
the
sdks?
J
C
So,
just
a
heads
up,
your
story
is
going
to
be
very
different
from
everybody
else's
your
infrastructure,
your
application
and
everything
are
very
personalized
to
your
business
model.
So
this
is
not
blanket
recommendation
for
everybody
everywhere,
but
my
general
thoughts
are,
if
you
have
something
that's
working,
keep
using
that
unless
it's
not
working
right.
Unless
you
have
some
extra
feature.
C
That
being
said,
there
is
definitely
an
overlap
between
the
push-based
metrics
and
the
pull-based
metrics
in
what
they
are
good
at
serving,
and
you
can
actually
do
both
you're
supposed
to
be
able
to
do
both
with
open
telemetry.
It's
it
can
be
difficult
to
set
up,
but
you
can
get
it
going
at
least
in
go.
It
can
be
this.
It
can
start
off
difficult
to
set
up
we're
still
we're
still
working
in
that
space,
but.
C
A
Yeah,
I
completely
agree
with
that.
I
would,
I
guess,
challenge
the
assertion
that
poll
based
metrics
has
won,
not
because
I
think
push
base
metrics
won,
but
because
I
don't
think
it's
a
a
question
of
of
winning
and
losing
they
did
they.
They
both
make
sense
in
different
use
cases
and
they
can
be
used
side
by
side.
A
One
example
I
would
give
is
a
common
deployment
pattern.
We
see
is
a
an
application
running
on
a
host
that
has
open
telemetry
built
in
that
exports
to
a
collector,
that's
running
on
the
same
host
that
may
be
gathering
host,
metrics
and
exporting
those
using
you
know
whatever
format
otlp
prometheus
anything
like
that,
and
that
collector
may
also
be
scraping
prometheus
endpoints
from
different
processes
on
the
host,
which
were
already
instrumented
using
prometheus.
A
Like
you
said,
if
it's
not
broken,
there's
no
re,
I'm
not
I'm
not
here
to
tell
you
that
you
should
switch
just
because
open
telemetry
is
new
and
shiny,
like
if
you
have
something
that's
working
then
great,
but
on
the
other
hand,
if
you
have
a
problem
or
if
you
see
a
feature
of
open,
telemetry
you're
like
wow,
I
really
wish
that
I
could
use
that.
It's
not
like.
You
have
to
switch
all
of
your
infrastructure.
It's
it's
it's.
B
B
It's
it
provides
receivers
that
speak
all
the
different
protocols
you
you
might
be
using
in
standardizes
to
an
internal
representation
and
provides
tools
to
export,
to
enrich
the
data
and
export
it
to
wherever
you
want,
and
so
putting
that
in
your
environment,
really
in
a
lot
of
ways,
allows
you
to
regain
control
in
in
situations
where
you
might.
You
know
you
you're,
using
open
source
projects
that
are
emitting
in
a
variety
of
protocols
and
have
limited
configuration
options
around
that.
So.
A
Yeah
and
a
lot
of
work
has
been
done
around
and
we're
we're
very
proud
of
sort
of
the
interoperability
work
that
we've
done
with
prometheus.
I
I
think
maybe
I
saw
richie
hartman
here.
Maybe
I
was
hallucinating
from
the
heat.
He's
been
extremely
helpful
from
that
perspective,
as
well
from
the
prometheus
side.
So
it's
very
much
like
a
a
community
project.
E
We're
gonna
we
have
time
for
maybe
two
more
questions,
maybe
just
this
one,
so
we're
gonna
end
at
the
beginning.
With
a
question
from
the
chat,
I
missed
the
intros
and
some
of
the
start
so
ignore.
If
this
is
duplicative,
it's
actually
not,
but
I'd
be
curious
as
the
panelists
back
stories
around
getting
into
open
telemetry,
but
not
their
whole
backstories.
E
F
Yeah
I
didn't
plan
to,
I
started
walking
at
the
spectre
and
then
we
will
originally.
We
didn't
use
open,
telemetry
and
then
one
day
we
said,
okay,
open
telemetry
is
here
it's
supposed
to
be
great:
let's
give
it
a
shot
and
yeah
that
just
stalled
from
there.
It
wasn't
planned.
I
just
it
just
happened.
A
A
So
again
I
would
say
I
I
never
really
planned
it.
It
did
just
happen.
I
that
said,
if
you
know
if
somebody
said
oh,
I
have
this
this
great
opportunity
over
here,
and
I
would
first
question
I
would
ask
is:
can
I
continue
my
work
on
open
telemetry
because
I
probably
wouldn't
consider
anything
that
would
say
no
to
that.
You
know
for
me,
it's
table
stakes
now
for
anything
that
I'm
going
to
do
in
the
future.
B
Let's
see
so,
I
worked
in
web
services
for
a
while.
You
know,
building
out
services
in
a
service,
oriented
architecture,
always
kind
of
had
a
knack
for
observability
and
was
interested
in
monitoring
the
systems
that
me
and
my
team
wrote
and
that
brought
me
into
new
relic
so
took
a
hobby
and
kind
of
went
pro
at
it
and
then
so
new
relic.
I
was
kind
of
on
the
side
always
interested
in
open
source
projects.
I
tried
to
open
source
one
of
the
main
projects
I
worked
on.
That
was
a
proprietary
project.
C
So
mine's
a
little
bit
different.
I
found
open
telemetry
because
it
solved
about
90
of
a
problem
that
I
had.
That
was
fairly
unique.
So
that's
where
I
started
contributing,
but
when
my
previous
job
was,
you
know
getting
towards
the
end
of
a
big
project,
I'm
like
I'm
looking
for
something
new,
I
was.
I
asked
some
of
the
maintainers
at
the
time
like
hey.
Is
there
any
jobs
that
I
could
do
open,
telemetry
work,
full-time
and
they're
like
hold
on
a
second?
C
E
H
E
E
I
guess
some
of
this
is
a
scaling
question
right
like
if
we
suddenly
like,
if
everyone
goes
and
tells
10
of
their
friends,
and
we
get
a
thousand
new
contributors
tomorrow,
like
what
is
the
best
use
of
that
time
going
to
be.
Where
should
people
be
focusing
their
efforts?
You
know,
let's
wrap
it
up
with
this
one,
so
down
the
line
I'll.
C
Start
reviews
like
that's
where
we're
lacking
the
most
having
good
actual
pr
reviews
both
of
documentation
of
what
the
code
is
doing
prs
are
great
issues
are
great.
I
love
them.
They
save
me
time,
effort
energy,
but
I
know
I
spend
most
of
my
time
doing,
reviews
and
if
there
was
somebody
who
could
if
there
was
a
team
of
people
that
could
help
speed
that
process
along
that
could
free
myself
up
to
to
be
doing
more.
You
know
to
be
enabling
more
cool
things
going
forward.
A
A
If
you're
an
expert
in
rpc
there's
a
semantic
convention
area
for
that,
if
you're
an
expert
in
host
metrics,
there's
a
semantic
convention
area
for
that,
and
all
of
these
problems
will
need
to
be
solved
and
if
we're
only
working
with
the
limited
pool
of
people
who
is
regular
specification
contributors,
they
can
only
be
deep
experts
in
so
many
things.
So
looking
for
outside
contributors
that
bring
expertise
that
we
don't
have
into
the
project
is
huge.
F
I
think
there's
a
lot
of
creativity
and
good
ideas
out
there
and
when
someone
is
working
on
something
that
he
believes
in
and
wants
to
work
on
it
and
wants
to
see
that
it's
implemented
at
the
best
and
like
big
something
great,
then
this
is,
in
my
opinion.
This
is
like
the
best
option.
So
if
a
thousand
people
come
so
I
just
tell
them
pick
the
thing
that
you
believe
that
you
want
to
to
see
that
is
implemented
as
best
as
possible
and
work
on
it
and
do
what
you
do
best.