►
From YouTube: 2022-09-22 meeting
Description
Open cncf-opentelemetry-meeting-3@cncf.io's Personal Meeting Room
A
B
B
Hey
everyone
and
we're
just
waiting
on
a
few
people
to
join
and
we'll
be
getting
started
soon.
C
D
B
B
E
Did
the
hotel
meetings
get
switched
around
I'm
trying
to
connect
to
the
Swift
Sig
and
it
keeps
coming
to
this.
A
Right,
you
know
I
wonder
if,
when
the
meeting
got
created
on
the
calendar,
we
ended
up
in
a
different
meeting.
Are
most
people
here
for
the
Swift
Zig
or
are
you
or
is
that
just
you.
A
E
E
I
think
you
guys
are
in
the
wrong
meeting,
because
I
clicked
the
other
one
and
it
says
waiting
for
hosts
to
start
meeting
open
until
in
practice
net.
E
E
A
Yeah
I
think
that's
the
problem.
This
is
the
link
in
meetup.com.
It
I
think
it
has
something
to
do
with
the
way
that
the
open
Telemetry
project,
like
the
calendar,
a
portion
zooms
no
okay,.
B
I
pray.
This
way
me
and
Rin
are
running
this
meeting.
So
if
we've
got
a
load
of
people
that
need
to
move,
then
we're
gonna
need
to
find
a
way
of
getting
everybody
over
there,
but
I
think
we've
got
the
majority
in
this
rumor
here
for
hotel.
E
Well,
so
the
the
meeting
that's
actually
assigned
to
the
Hotel
meeting
is
locked
on
the
precondition
that
the
host
starts.
It
so
I'd
be
happy
to
move
over
there
for
Swift,
but
I
don't
have
the
I,
don't
have
the
credentials
to
to
start
the
actual
meeting
here.
Let
me
post
a
link
in
the
chat
for
you
hold.
A
A
Let
me
oh.
E
A
E
Think
I'm,
the
only
one
that
has
showed
up
for
the
Swift
meeting
anyway,
all
right
well
at
least
make
sure
you
put
all
your
coffee
cups
away
once
you're
done
so.
B
Right
so
we
got
the
all
the
housekeeping
stuffer
in,
or
would
you
like
me
to
go
through
that.
A
Sure
welcome
to
the
open,
Telemetry
and
practice
series.
A
A
We
had
a
kubernetes
one
last
month
that
was
very
successful
and
this
month
we're
having
a
net
one
foreign
and,
if
you're
interested
in
following
these
I
believe
most
of
you
got
here
through
Meetup
we
have
captions,
the
link
has
been
posted
in
the
chat
and
I
am
working
on
getting
them
working
with
zing
and
that's
really
pretty
much
it.
Thank
you.
B
So,
let's
make
sure
sharing
works
and
you
can
all
see
because
it's
going
to
be
a
really
boring
meeting.
If
all
you
can
do
is
hear
me,
talk
which
I'm
perfectly
fine
to
do
by
the
way,
as
people
who
know
me
will
will
go
for
so
cool,
so
we're
here
to
talk
about
The,
Collector
and
more
specifically.net
and
The
Collector.
B
Obviously,
as
you
can
tell
by
my
name
on
zoom.net
is
is
part
of
me.
I
am
very
into
the.net
World,
so
this
is
very
in
my
wheelhouse,
so
who
am
I
so
my
name
is
Martin.
Thwaites
I
am
first
and
foremost
an
observability,
evangelist
and
I'm.
Also
a
developer
advocate
for
a
company
called
honeycomb.
You
can
follow
me
on
the
twitters
at
martin.net
and
for
a
mix
of
open
Telemetry
mixed
with
a
British
snark
aspect.
B
If
you
like
that
kind
of
thing
so
I
put
on
the
observability
Evangelist
purely
because
that
is
first
and
foremost
what
I
do.
I
am
trying
to
push
observability
into
the
community
around
everything
from
local
developments.
All
the
way,
through
into
running
these
things
in
production,
because
observability
in
general,
is
what
we're,
what
we're
aiming
for.
B
B
Thank
you
cool.
So,
first
of
all,
open,
Telemetry,
now
you're,
all
at
an
open,
Telemetry,
Meetup
I
would
imagine
that
a
lot
of
you
have
a
pretty
good
understanding
of
what
opensummer
tree
is
about,
but
there
are
possibly
some
people
who
are
still
new
to
what
open
Telemetry
is
so
I
thought
I'd.
B
Give
you
a
little
bit
of
an
idea
of
what
open
termometry
is
All,
About,
Now,
open
Telemetry
is
more
of
a
protocol
level
thing
than
it
is
a
thing
that
you
have
a
thing
that
you
deploy
and
there
are
certain
aspects
that
you
do,
but
it
is
a
language
agnostic
idea
around
how
we
do
things
like
distribute
tracing.
Now,
that's
the
origins
of
open
Telemetry.
B
There
are
more
and
more
signals
that
we're
working
on
as
part
of
the
community
right
now
but
tracing
is
the
origins
of
where
open
Telemetry
came
from
it's
protocol
focused.
So
the
idea
of
what
they
call
the
open
Telemetry
line
protocol
is
the
idea
of
how
we
transfer
that
data
between.
So
we
get
this
vendor
agnostic
idea
of
how
a
particular
bit
of
SDK
or
into
instrumentation
can
send
data
to
another
party,
it's
also
compliant
with
the
w3c
tracing
and
spec.
B
So
it's
using
the
idea,
w3c
tracing
headers
and
that
kind
of
thing
to
allow
it
to
interrupt
with
lots
of
different
systems.
Current
signals
signals
is
the
the
types
of
data
that
open,
Telemetry
support.
Tracing,
obviously,
is
the
where
things
come
from
logs
and
metrics
are
the
two
that
have
been
added
on
and
that
are
currently
going
through
the
different
sigs
and
at
different
levels
of
stability.
We're
going
to
be
talking
today,
specifically
about
tracing,
but
obviously
logs
and
metrics,
are
there
as
well
and
they
are
available
in
The
Collector.
B
Perhaps
we'll
do
a
different
talk
about
those
two
at
some
point
in
the
future.
The
other
thing
is
the
collector
Now
The
Collector
is
the
thing
that
the
open,
Telemetry
Community,
give
you
as
a
thing
to
deploy.
There
are
agents,
but
we
won't
go
into
those
at
the
moment.
Most
of
the
things
that
open,
Telemetry
provide
are
and
the
standards
the
protocols
of
how
things
work,
not
a
thing
for
you
to
use.
It's
not
a
thing
for
you
to
install
on
your
server.
B
The
Collector
is
the
kind
of
exception
to
that
I
suppose
now
it
can
be
a
thing
that
you
deploy,
but
it
can
also
be
a
sidecar,
so
people
familiar
with
things
like
kubernetes.
The
idea
of
sidecar
containers
as
a
service
that
you
run
alongside
collector,
can
also
work
in
those
kind
of
modes.
Today
we're
going
to
be
focusing
on
the
idea
of
running
it
as
a
service,
and
it
provides
a
few
extra
benefits
when
you're
running
it
as
a
service.
B
The
first
one
is
centralized
config.
So
the
idea
that
the
collector
is
the
thing
that
knows
where
to
send
things.
The
idea
that
the
collector
is
the
thing
that
has
things
like
API
keys
for
your
back
ends.
Remember
that
the
collector
itself
doesn't
allow
you
to
visualize
any
data.
The
Collector
itself
isn't
doesn't
provide
you
a
UI
that
you
can
go
and
view
your
spans
and
analyze
your
traces.
That's
not
what
the
collector
is
there
for.
B
So
what
this
does?
Is
it
actually
centralizes
all
of
that
config?
So
your
applications
don't
need
to
know
about
the
API
key
for
your
backend
provider.
It
doesn't
need
to
know
the
any
other
information
about
where
it's
going
to
be
doing
config
now
the
other
thing
is
centralized
egress.
B
B
When
you're
talking
about
hyper
secure
applications,
your
applications
wouldn't
be
able
to
just
arbitrarily
send
data
to
pastebin
what
they
would
have
is
very,
very
locked
down
ways
that
they
can
talk
if
you're
wanting
Telemetry
information
from
say,
100
different
applications,
configuring
every
one
of
those
100
applications
because
they
now
need
internet
access
is
probably
a
bad
thing
to
do
so
using
the
collector.
B
The
other
thing
is
around
filtering
and
reduction
now.
Tracing
data
could
actually
have
some
quite
sensitive
information
in
there
so
being
able
to
have
a
separate
service
to
your
applications.
That
then
filters
that
information
out,
so
it
might
be
that
actually
we
want
a
white
list
which
attributes
can
be
sent
over.
We
want
to.
B
We
want
to
filter
out
some
some
particular
attributes.
You
know
if
somebody
puts
a
first
dot
surname
attribute
in
there.
Maybe
we
don't
want
to
send
that
onto
our
third
parties.
That
might
not
be
the
right
idea,
but
he
can
also
do
redaction
and
redactions
are
quite
an
interesting
subset
of
filtering
because
it
can
find
particular
patterns
in
attributes
and
allow
you
to
say
well
still
send
it
but
redact
out
the
the
first
name,
not
surname
or
the
obvious
one
being.
B
If
you
find
16
numbers
in
a
sequence
together
in
a
field,
you
might
want
to
redact
that
out,
because
that's
probably
a
card
number,
and
that
might
not
be
something
you
want
to
send
and
those
are
quite
interesting
uses
for
filtering
a
reduction
but
doing
that
in
your
application.
Yes,
you
could
absolutely
do
that,
but
those
have
a
regular
Cadence
of
change.
What
you
would
potentially
want
is
to
be
able
to
do
that
centrally,
so
that
your
applications
don't
need
to
remember
to
implement
that
Library.
B
Things
like
what
region
was
that
thing
running
in
what
was
the
availability
Zone
that
that
was
running
in
what
was
the
network
segment
that
that
was
running
in
all
the
way
through,
so,
if
you're
using
something
like
kubernetes,
what
about
my
pod
deployment
replicas?
All
of
those
kind
of
things
would
be
really
interesting
to
throw
onto
it
the
spans
so
that
you
can
then
filter
by
that.
You
can
then
see
was
it
a
particular
pod
that
was
the
problem.
B
B
So
there's
quite
a
few
different
Avenues
I
used
to
be
a
big
skeptic
of
using
the
collector
and
I
used
to
always
just
drop
the
the
config
into
my
applications.
B
The
problem
is,
as
you
start,
to
get
bigger
and
bigger
those
become
lots
and
lots
of
configs,
and
you
then
end
up
sharing
sdks
between
lots
of
different
teams
and
then
you've
got
different
varying
things
of
the
sdks
and
It
all
becomes
a
bit
of
a
mess.
The
Collector
is
a
really
really
nice
way
for
you
to
be
able
to
centralize
a
lot
of
those
things,
while
still
allowing
teams
a
lot
for
ownership.
B
So
the
collector
itself,
how
is
that
collector
made
up?
So
if
we
start
on
this
diagram,
it's
a
basic
diagram.
All
of
this
is
I'll
put
some
links
at
the
end
to
some
of
these
diagrams.
All
of
this
is
available
on
the
internet
and
there'll
be
some
useful
links
at
the
end.
So,
on
the
left
hand,
side
of
this
diagram-
we've
got
receivers
and
receivers
are
how
we
get
information
into
the
collector.
B
There
are
lots
of
other
receivers
that
you
can
use
that
vary
from
different
ways
that
you
can
pull
in
data
and
that
you
can
make
data
be
able
to
be
sent
to
you
through
to
you
reaching
out
or
The
Collector,
reaching
out
to
get
that
data,
so
the
traditional
Prometheus
models,
but
also
the
models
around
Kafka.
For
instance,
if
you've
got
a
Kafka
stream,
that's
streaming
span
data.
You
can
use
the
collector
to
go
and
subscribe
to
that
Kafka
stream
and
pull
that
data
in
so
lots
of
different
Avenues.
B
Predominantly
though
otlp
is
the
way
to
go
on
the
right
hand
side,
however,
that's
where
we
send
the
data
to
different
third
parties,
so
we're
going
to
be
talking
today,
specifically
about
Jaeger
as
an
exporter,
but
you
can
send
it
to
many
many
different
locations
now
right
in
the
middle
is
how
we
process
that
data
they're
called
processes,
and
we
can
add
lots
of
processors.
We
can
add
no
processors.
The
general
idea,
though,
is
that
you
can
use
that
for
things
like
enrichment
for
things
like
filtering
and
you
add
those
into
a
config
file.
B
Unfortunately,
it's
in
yaml
I
apologize.
It
wasn't
my
decision,
but
you're
going
to
have
to
learn
yaml.
If
you
want
to
configure
it,
but
you
can
add
lots
of
different
things
and
create
something
called
Pipelines
which
allow
you
to
say
for
this
type
of
data
coming
in
on
this
particular
endpoint
I'd
like
to
do
this
particular
processing
and
send
it
onto
this
particular
third
party
that
might
sound
complicated
But.
Ultimately,
what
we're
doing
is
we're
offloading
all
of
our
configuration
from
all
of
our
applications.
So
we
do
it
once
so.
B
So
how
do
we
run
the
collector?
Always
in
a
container?
Yes,
you
can
run
it
up.
It
is
a
an
app
that
you
could
run
and
I
would
never
advise
that
we
have
enough
containerized
platforms
now,
especially
in
the
cloud
and,
if
you're
running
on
premise,
you're
likely
running
your
own
sort
of
kubernetes
or
some
kind
of
virtualization
layer
that
will
allow
you
to
run
some.
Some
containers
always
try
and
run
it
in
a
container
much
much
better
way
of
doing
it.
B
So
the
examples
that
we're
going
to
use
today
and
we've
got
a
DOT
application
called
the.net
Hotel
collector
is
the
name
of
the
application,
and
these
are
all
on
GitHub
you'll.
Be
able
to
take
this
away
after
the
after
the
presentation,
run
it
up
yourself
and
be
able
to
see
it
all
connected
together
and
that
dot
application
is
going
to
throw
through
the
open,
Telemetry
collector.
B
Now,
as
I
said,
it's
yaml,
which
I'm
not
a
yaml
hater
but
I,
don't
love
it.
But
it's
relatively
simple.
What
we
need
is
two
things
we
need
the
open,
Telemetry
collector
as
a
container,
and
we
also
need
Jaeger
as
a
container.
B
Now
on
this
particular
thing
here,
we've
got
a
config
file
that
we're
bringing
in,
as
you
can
see
there
and
we've
got
two
ports
that
we're
opening,
and
these
are
the
receiver
ports
that
we
were
talking
about.
There's
a
port
for
grpc
and
there's
a
port
for
http,
and
then
we've
got
Jaeger
and
Jaeger.
We're
going
to
tell
Jaeger
with
an
environment
variable
at
the
bottom
enable
the
otlp.
So
that's
enabling
the
hotel
collector
to
push
into
Jaeger
using
open
Telemetry
line
protocol,
and
then
we've
got
a
UI
opening
on
166x6.
B
B
B
We've
got
the
processors
and
this
one
we've
just
added
batch
so
to
batch
up
the
spans
together
and
send
them
on
to
the
exporter
in
a
batch
rather
than
just
sending
through
one
by
one
and
then
we've
got
our
exporter.
You'll
see
there
that
we've
got
otlp,
slash
Jaeger
the
otlp
at
the
start
tells
us
what
type
of
exporter
it
is
and
then
we
can
give
it
names.
So
we
can
add
multiple
otlp
exporters
on
there
we're
telling
it
to
go
to
Jaeger
on
4387
because
we're
using
the
networking
inside
of
docker.
B
So
it
knows
that,
because
the
container
is
called
Jaeger,
it's
going
to
use
Jaeger
we're
also
using
insecure,
don't
do
that
in
production,
Pro
tip,
but
for
what
we're
doing
here
at
the
moment
here
inside
of
those
two
containers,
because
we
don't
have
any
SSL
search,
we
don't
have
any
certificate
authorities
we're
just
using
the
insecure
one.
What
I
would
say
is
in
a
production
environment
under
any
kind
of
load,
do
consider
using
a
SAS
platform
instead
of
Jaeger
but
running
things
locally
for
trying
to
get
all
this
working
and
understanding
it.
B
Absolutely
Jaeger
is
an
amazing
option
and
for
small
scale
production
installations
as
well.
It
is
a
really
good
option.
So
how
do
we
add
it
to
not
net?
So
I'm,
well
known
for
saying
that
everything
is
10
lines
of
code
and
every
one
of
my
libraries
I
aim
for
implementation
being
10
lines
of
code.
It
is
exactly
10
lines
of
code.
B
I
made
sure
it
was
so
first
thing
we
need
to
do
is
we
need
to
add
some
libraries,
so
we've
got
on
here
the
open,
Telemetry
line
protocol
because,
as
we
looked
at
the
diagram,
Ro
r.net
application
is
going
to
Output
into
open
Telemetry
using
the
open
Telemetry
line
protocols.
So
we
need
to
import
the
library
for
that
we're
also
going
to
bring
in
the
hosting
Library.
B
The
hosting
Library
allows
us
to
tell
the
service
collection
to
add
a
tracer
Provider
from
open
telemetry
and
then
we're
also
going
to
add
something
called
instrumentation
for
asp.net
core
open
Telemetry
on
its
own
doesn't
really
do
anything.
It
acts
as
a
conduit
on
its
own.
Implementing
open
Telemetry
will
not
give
you
any
data.
B
You've
got
to
tell
it
to
produce
data,
and
that
is
where
instrumentation
is
coming.
There
are
a
lot
of
Auto
instrumentations
that
you
can
use
for
different
types
of
libraries
that
you
might
have
so
out
of
the
box.
You've
got
things
like
asp.net
core,
which
will
tell
you
four
requests,
and
it
will
do
some
some
stuff
around
requests
and
log
a
trace
and
a
roof
span
for
every
single
request
that
comes
into
your
application.
There's
also
things
like
HTTP
client,
which
will
Auto
instrument
any
calls
that
you
make
to
third
parties.
B
It'll
also
do
things
like
propagation,
so
it'll
allow
you
to
put
things
like
Trace
headers
between
all
of
your
different
applications.
This
isn't
a
talk
about
distributed
tracing
in
general
and
about
how
distribute
tracing
works
again,
possibly
something
we
can
do
a
talk
on
later.
This
is
specifically
just
about
how.net
and
The.
Collector
go
together.
You'll
also
notice
that
these
is
using
pre-release
packages.
B
Now
that
can
generally
scare
a
lot
of
people
I
can
give
you
a
lot
a
bit
of
context
there.
The
reason
why
we're
in
a
release,
a
pre-release
state
with
all
of
these
libraries
around
especially
around
the
auto
instrumentation
libraries,
is
because
the
semantic
conventions,
which
is
the
names
of
the
attributes
on
the
stands
haven't
been
signed
up.
B
They've
not
been
ratified
by
the
open,
Telemetry
Community
just
yet
what
that
means
is
the
attributes
could
change
in
the
next
six
months
now,
I,
don't
see
that
as
a
problem
personally,
what
we're
talking
about
with
tracing
is
production
debugging,
we're
not
talking
about
data
that
you're
going
to
keep
for
18
months
and
query
over
the
last
18
months.
We're
not
talking
about
data
that
you
will
look
at
today
and
compare
against
data
six
months
ago.
That's
not
really!
What
tracing
is
about
it's
about
production,
debugging,
so
you're,
looking
at
things
within
weeks.
B
So
we
add
open,
Telemetry
tracing.
We
tell
it.
We
want
to
use
the
asp.net
core
instrumentation
and
we
tell
it
we're
going
to
use
the
open
Telemetry
Explorer.
Now
this
tutor
on,
you
will
notice
that
there
is
no
config
there.
B
That
tells
it
where
to
send
where
the
open
Telemetry
endpoint
is
that
it's
going
to
send
it
to
and
that's
because
the
default
is
always
localhost
using
grpc
on
Port
4317,
so
I
don't
need
to
tell
it
that,
because
I've
configured,
my
architecture
to
know
that
I'm
going
to
use
localhost,
my
config
is
incredibly
small.
You
can
also
configure
that
using
environment
variables
as
well,
so
that,
even
if
you
want
to
move
that
to
another
location,
you
don't
need
to
do
anything
more
to
it.
B
Now,
if
you
then
run
up
that
application
start
whacking
some
of
the
the
pages
on
the
application,
we
can
start
to
see
a
basic
Trace
waterfall.
Now
I
said
before
that
we
have
to
add
an
auto
instrumentation
in
order
to
be
able
to
see
some
traces.
Now
we
added
into
there
the
asp.net
core
instrumentation.
B
You're
then
going
to
get
some
basic
attributes
that
are
automatically
populated
by
that
instrumentation
that
we
just
talked
about,
and
each
of
those
auto
insurance
stations
will
have
its
own
things,
that
it
adds
to
those
spans
that
are
useful
and
already
this
is
going
to
provide
you
with
some
really
useful
information.
Things
like
how
do
I
group
by
user
agents,
for
instance,
or
the
targets
to
see
individual
urls.
B
So
we've
talked
about
the
the
done
application.
We've
talked
about
how
we
get
a
little
bit
of
a
an
architecture
together,
but
I
said
that
the
collector
is
useful
for
some
reason.
So
how
would
we
add
some
basic
enhancements
to
the
open,
Telemetry
collector
that
are
going
to
provide
us
with
a
bit
more
use
for
The
Collector
being
there
other
than
just
centralizing
our
config?
B
B
That's
not
a
plug
for
my
blog
just
that
this
is
where
that
code
comes
from
now,
I
said
that
we
can
enhance
this
information.
The
span
information
with
things
that
are
useful
now,
for
the
purposes
of
that
article,
what
I
was
doing
was
adding,
on
the
name
of
the
container
app
the
particular
revision
of
that
container
app.
That
was
the
thing
that
sent
the
information
through
and
obviously
it
was
the
source
of
a
block.
So
I
put
the
the
block
thing
on
there.
So
we
can
inject
attributes.
B
You
can
delete
attributes,
you
can
replace
attributes,
you
can
redact
attributes.
All
of
that
is
possible
in
there.
This
specific
config
is
just
adding
to
every
single
span
that
comes
through
four
additional
attributes
that
give
us
some
context
of
which
collector
it
came
from
if
you're
using
kubernetes
there's
a
very
similar
one
to
this
for
kubernetes
as
well.
B
So
a
little
while
ago,
I
was
working
for
a
company
and
they
were
using
Azure
front
door
in
front
of
an
Azure
app
service.
B
B
B
Our
final
big
use
case
full
The
Collector,
sending
to
multiple
locations
so
from
my
single
one.net
application.
If
I
wanted
to
send
that
to
two
different
providers
now
different
providers
provide
different
benefits.
Some
are
good
at
one
thing.
Some
are
good
at
another.
You
might
want
to
always
send
to
two
providers.
You
might
want
to
try
one
provider
and
try
another
provider
to
see
which
ones
are
better.
B
If
I've
got
a
100
applications,
I'm
going
to
update
all
100
of
those
applications
to
Center
both
of
these
two
different
places
with
the
collector
my
applications
don't
need
to
know
they
don't
need
to
duplicate.
All
of
that
bandwidth.
I
can
just
send
it
through
the
collector
and
ask
the
collector
to
send
that
information
to
two
locations.
B
B
Now
all
of
that
is
from
a
config.
That
looks
like
that.
In
my
application,
I've
added
those
five
lines
of
code
and
those
libraries
and
I've
been
able
to
without
redeploying
my
application,
I've
been
able
to
augment
the
spam
data.
That's
gone
to
my
production,
debugging
systems,
so
particularly
it
and
of
what
we've.
What
we've
got
today.
I
hope.
B
That's
giving
you
a
little
bit
of
an
insight
as
to
how
you
can
run
the
collector
really
easily
how
you
can
then
how
you
can
then
Implement
that
in.net
in
a
very,
very
simple
way,
and
some
of
the
things
that
you
might
be
able
to
use
it
for
so
I
put
some
links
up
there
and
we'll
obviously
put
those
when
we
distribute
the
video
as
well.
You've
got
my
blog
on
there.
You've
got
the
repository
from
this
talk,
which
you
should
be
able
to
do.
B
B
But
after
that
I'm
open
to
some
questions
and
happy
to
answer
some.
A
B
B
So
the
the
login
stuff-
it's
not
fully
baked
I-
wouldn't
go
through
that
at
the
moment,
with
it
not
being
fully
baked
inside
of
the
sdks
just
yet
and
not
being
fully
stable.
B
That's
the
aim
for
that
I
believe
is
November
and
that's
when
it'd
be
nice
to
talk
about
that
and
how
we
get
that
logging
stuff
inside
of
the.net
framework
But.
Ultimately,
you've
got
the
same
sort
of
things
from
a
collector
perspective,
which
would
be
we've
got
an
end
point
that
you
can
send
otlp
formatted
log
data
to
you
can
use
processors
to
then
augment
that
data
and
then
export
us
to
send
that
onto
third
parties.
B
B
Cool,
so
what
would
I
recommend
for
production
is
a
yeah,
fairly
obvious
question.
Obviously,
working
for
honeycomb
I
would
recommend
honeycomb,
but
it
depends
on
your
use
case.
Different
providers
have
different
benefits.
B
Pearls
we
focus
on
rapid
ingest.
We
focus
on
debug
ability
of
production.
We
don't
focus
on
longevity
of
data.
We
don't
focus
on
things
like
seam
and
that
kind
of
stuff
it
depends
on.
What
your
use
case
is.
What
I
would
say
is
Jaeger
is
hard
to
scale
when
you're
talking
about
large
volumes
of
data.
If
you're
not
talking
about
large
volumes
of
data,
it's
probably
okay,
really
I
would
try
all
of
these
things
out
and
tailor
it
to
what
you
need
when
you
start
to
run
it
in
production.
B
Yeah,
don't
use
insecure
in
production,
even
if
you're
doing
it
between
two
services
that
don't
go
out
through
the
internet,
SSL
all
the
way
down.
B
B
There
are
open,
ID
connect,
so
you
can
use
oidc
as
a
mechanism
for
doing
authentication.
My
basic
recommendation
is:
do
not
make
the
hotel
collector
public
always
have
it
internal.
If
it's
always
internal,
then
you
don't
really
have
to
think
about
those
things.
You
can
use
network
security.
If
it's
a
trusted
service
internally,
then
you
won't.
You
don't
need
to
think
about
using
authentication,
headers.
B
So,
in
terms
of
how
to
compare
some
of
the
vendors
we've
got
a
load
of
things
on
our
website.
All
of
the
vendors
will
have
all
of
these
things
on
their
websites
and
direct
you
to
those
to
go
and
have
a
look
at
how
all
the
different
features
compare.
I,
don't
think
it's
something
that
we
should
go
through
on
this
call.
B
So
performance
info
when
we're
talking
about
metrics,
so
the
reason
why
metrics
are
used
is
because
they
compress
and
they
lose
context.
Trace
data
is
high,
carnality
high
dimensionality
and
storing
the
raw
data,
which
is
a
very
different
use
case
because
we're
talking
about
production
debugging.
If
you're
talking
about
longevity
of
performance
data
I,
think
you're
really
talking
about
metrics
than
traces.
B
But
for
tracing
data,
don't
try
and
keep
it
for
10
years.
It's
not
that
useful.
When
you
start
talking
about
10
year
old
data,
especially
because
nowadays
the
the
compute
capacity
changes,
the
the
Frameworks
that
you're
using
get
faster
that
comparison
between
two
different
time
periods
between
two
different
releases
of
your
data
is
becoming
less
and
less
of
a
thing
to
think
about.
Nowadays,.
B
So
yeah
I'm,
looking
specifically
at.net
from
a.
How
do
we
Implement
all
the
signals?
Absolutely
I
shall
get
Rin
on
sorting
out
another
meet
up
at
some
point
soon,
I'm
sure
they
will
be
awesome
at
setting
up
a
a.net
all
the
signals.
B
Any
more
questions
it
doesn't
just
have
to
be
in
the
chat
by
the
way
you
can
turn
your
camera
on
turn
your
mic
on.
B
The
other
thing,
I
would
say
as
well
is:
there
is
a
a
demo
application
that
open
Telemetry
have
created,
which
does
do
all
of
these
things
that
you
can
run
up.
It's
a
micro,
Services
solution
with
all
of
the
different
languages
and
all
of
the
different
sdks
working
in
a
kubernetes
environment
that
you
can
have
a
look
at
it.
Who
does
have
all
of
those
signals
in.
E
So
I'm
curious
about
what
kind
of
over
overhead
does
it
have
when
you're
tracing
so
I
have
some
experience
with
doing
some
open
tracing
in
an
embedded
environment
and
what
we're
finding
is
that
when
I
try
to
do
automated
open
tracing
it
just
seem
to
like
slow
down
things
help
a
lot
and
I
was
forced
to,
like
you
know,
back
off
from
that,
so
I
was
wondering
how
good
or
bad
is
it.
In.Net,
environments.
B
It
had
some
some
memory
leaks,
I've,
noticed,
I
noticed
them
in
the.net
World
around
there
with.net
all
of
open,
Telemetry
for.net
is
based
on
something
called
activity
which
is
baked
into
donut.
It's
not
an
additional
thing
that
they
built.
They
observe
the
activity,
sources
and
the
activities
that
are
created
and
then
use
those
to
generate
spans.
B
So
this
is
something
that's
always
been
in
the.net
framework
and
is
part
of
what
Microsoft
say
is
the
way
to
observe
your
applications
is
to
use
activity
and
activity
sources
to
then
use
activity.
Listeners
off
the
back
of
those
it's
a
whole
activity,
thing
I,
haven't
noticed
it
in
a
performance
overhead
way
at
all.
B
I
have
done
in
Blazer,
but
that's
because
it's
single
threaded,
the
compute
capacity
of
the
things
that
I
generally
work
on
I,
don't
work
on
small
embedded
devices
with
you
know.
Megabytes
of
members
would
I
use
it
in
those
worlds.
There's
a
lot
of
people
using
it
in
iot
and
looking
at
how
we
send
tracing
data
over
mqtt,
which
is
a
very
different
use
case
right
than
what
we're
talking
about
today.
B
All
right,
but
yeah
I,
think
that's
probably
closer
to
what
you're
thinking
about
is
tracing
in
an
iot
type
environment.
Where
we're
talking
about
small
embedded
devices.
E
Yeah,
well,
that
was
a
context
in
which
I
observed
it.
But
of
course,
now
it
changed
jobs
on
a
different
situation
where
it's
not
an
embedded
environment
anymore,
but
I
was
still
curious,
like
how
bad
is
the
overhead
in
terms
of
compute
but
as
you're
saying,
Microsoft
is
already
creating
these
activities
even
before
open
tracing
came
into
the
picture
and
you're
sort
of
leveraging
it.
So
maybe
the
overhead
is
not
quite
as
much.
B
Yeah,
so
it's
all
done
asynchronous
anyway,
so
the
the
generation
of
these
activities
doesn't
impact
your
request
response
times,
for
instance.
Obviously
there
is
a
mechanism
where
those
things
are
generated
added
to
an
internal
queue
and
that
queue
then
batched
and
sent
up
so
depending
on
how
big
that
batch
gets
you've
got
memory,
things
that
happen.
What
I
would
say
is
in
Cloud
environments,
these
days
that
isn't
really
a
problem.
We're
not
talking
about
gigabytes
of
data.
In
these
things,
we're
talking
about
megabytes
and
kilobytes
of
data,
and
then
it's
gone.
D
Probably
drilling
into
certain
very
small
use
cases,
but
one
thing
that
just
came
to
mind:
is
there
any
guaranteed
delivery
feature
with
the
hotel
collectors?
That's
something
about
Bob
Greener,
it's
more
on
your
implementation!
How
you're
hosting
yourself
to
handle.
B
If
we
get
a
response
that
says
success,
then
it
doesn't
get
sent
again.
So
there
is
a
as
part
of
the
otlp
that
the
whole
protocol
itself.
There
is
a
when
you
receive
something
you
send
an
act
back
to
say:
yes,
we
got
it.
The
Collector
will
retry
how
long
all
configurable.
B
So
Christoph
has
posted
the
link
to
the
the
open
tracing
shim
I,
have
wrote
a
blog
post
on
activity
and
when
to
use
activity
versus
when
to
use
the
shim.
B
My
general
advice
is:
if
you
are
polyglot
and
moving
across
different
languages,
the
shim
is
probably
an
idea
because
it
means
that
you're
using
the
same
Concepts
concepts
of
span
and
span
attributes
versus
activity
and
tags.
If
you
are
purely
in
the.net
world,
don't
worry
about
it.
Just
use
activities
directly.
D
We're
looking
at
deploying
and
managing
a
fleet
of
them
across
different
types
of
machines
and
I
know
that
the
op
amp
project
has
aspirations
that
help
a
lot
with
this
I
don't
know
if
that
would
be
a
separate
session,
that
the
management
of
the
collectors
and
different
flavors
of
the
configuration,
because
we're
trying
to
figure
out
do
we
deploy
in
a
sense,
dumb
collectors
that
are
good
at
just
collecting
from
their
single
endpoint
and
forwarding
on
to
a
centralized
Gateway
model
and
how
to
manage
all
those
over
time.
B
Multitade
collectors
is
definitely
a
big
thing.
There
is
an
entire,
probably
topic
series,
not
just
the
topic
on
its
own,
so
we
have
got
a
special
guest
Grace.
B
Who
is
here
to
talk
about
some
specific
implementation,
stuff
that
that
she's
done
on
um.net
and
Azure
and
all
that
kind
of
stuff,
so
I
think
it's
a
good
time
to
to
bring
Grace
into
the
conversation
and
I
will
stop
sharing,
because
I
didn't
realize.
I
was
continued
to
share.
C
C
I
don't
know
if
you
want
to
just
kind
of
like
ask
questions
and
we
kind
of
go
from
there.
I
don't
have
like
a
structure
for
what
we
should
talk.
C
B
Well,
you
know
obviously
I
have
some
pre-cammed
questions,
but
you
know
it's
basically
just
about
having
a
conversation
about
the
the
stuff
that
we've
been
talking
about.
So
me
and
Grace
have
been
talking
about
stuff
offline
on
this
sort
of
stuff
anyway,
and
we
thought
it'd
be
really
interesting
for
you
guys
to
hear
a
lot
of
stuff.
C
And
I,
yeah
and
I
can
also
actually
give
a
little
bit
of
background
of
where
I
sit
in
this
too.
It's
like
so
I
started
at
iqmetrics
about
a
year
and
a
half
ago,
and
so
I
am
I,
come
from
like
a
more
Linux
background.
C
I
come
from
like
a
non-windows
background,
not
Azure,
I
I,
know
AWS,
and
these
things
so
I
still
consider
myself
to
be
a
net
Noob,
and
so
then
I'm
coming
into
this,
but
but
I
had
already
worked
with
open
Telemetry
before
and
I
knew
that
it
was,
and
traces
I
knew
that
traces
were
something
that
my
company
needed
to
do
and
so
I
wouldn't
shut
up
about
it
and
they're
like
fine,
we'll
do
it,
and
then
we
did
it
for
kind
of
a
Greenfield
project
and
it
worked
out
great
and
so
now
they're
like
okay,
please
go
around
and
tell
other
teams
to
do
this
too,
and
so
that's
the
job
that
they
gave
me
is
to
basically
go
around
and
observability
all
the
people
and
all
the
things,
but
I
still
consider
myself
to
be
kind
of
a.net
new,
because
I
can
get
tripped
up
of
like.net
framework
versus
dot
net
core
and
then
open
Telemetry
in
particular,
is
unique
amongst
open
Telemetry
implementations
because
it
has
dot
it
has
activity
already
and
so
for
people
who
might
be
familiar
with
that.
C
There's
that
piece
too
so
so
I'm
coming
into
this
as
like,
like
I,
would
say.
My
experience
is,
like
you
know,
intermediate-ish
seniors
developer,
like
some
were
kind
of
in
between
there,
but
a
noobin.net
but
I
know
just
enough
to
know
like
how
to
help
people
like
here's.
How
instrumentation
should
work?
Here's
how
you
should
instrument
your
code,
in
particular
here's
how
to
think
about
instrumentation.
C
But
then,
when
you
get
into
the
actual,
like
implementation
and
Architectural
details
of
like
I
kind
of
laughed,
when
when
Martin
said
something
about
the
collector
like
that,
might
sound
complicated
when
he
was
showing
a
diet.
I'm
like
I'm
like
yeah,
it
does
sound
a
bit
complicated
right
and
so
there's
a
I've.
C
And
I
think
I
can
simplify
it
more
now,
but
like
I
because
of
my
position,
I'm
kind
of
I'm
sort
of
like
an
internal
evangelist
and
like
an
implementary
and
helpers.
And
so
my
big
thing
is
about
helping
people
reduce
their
cognitive
load
in
debugging
and
being
able
to
understand
their
applications.
And
so
I
have
found
that
there
are
some
cognitive
load
issues
in
just
getting
set
up
in
like
the
correct
way
with
open
Telemetry.
And
so
that's
where
my
position
comes
from.
B
So
you
know
before
you
were
using
vendored
agent
libraries
and
decided
that
open
Telemetry
is
the
one
true
way.
What
what
do
you
think
was
one
of
the
reasons
why
that
was
a
that
was
a
move
that
you
wanted
to
make.
C
I
need
for
me
because
I'm
in
this,
like
weird
sort
of
like
somebody
recently
called
me,
observability
Grace,
like
as
if
that's
my
first
name
in
the
company
and
so
because
I
have
like
this
kind
of
like
Narrative
of
like
open,
Telemetry
and
observability.
Like
oh,
go
talk
to
Grace
about
it
like
vendor,
like
I.
For
me,
it
was
kind
of
about
the
narrative
and
the
cognitive
load
of
it.
C
You're
gonna
hear
me,
say:
cognitive
load
a
whole
lot
today,
but
just
like,
because
we've
already
come
from
a
situation
of
this
vendor
lock-in
of
like
this
specific
APM
agent,
where
we
have
no
control
over
it
and
it's
kind
of
overdoing
it
a
little
bit,
and
so
it's
making
things
kind
of
complicated,
like
I,
wanted
us
to
have
to
change
the
The
Narrative
entirely
of
like
no
vendor
lock-in.
C
Let's
like
let's
just
go
with
the
straight
otel
libraries
as
they
are,
and
then
vendors
will
ingest
them
as
as
they
are,
and
then
I
I
don't
know,
maybe
in
the
future.
We'd
consider
like
something
with
that's
specific
for
vendors
if
they've
got
specific
features
they
implemented,
but
for
just
like
actually
having
the
disc
session
like
I.
Don't
want
to
I,
don't
want
to
be
the
next
person
who
says
hey
what
about
this
new
tool.
After
all,
of
the
other
new
tools
that
people
have
previously
been
sold
so
yeah.
B
I
I
turn
this
as
purposeful
observability.
It's
the
idea
that
we've
added
this
for
a
reason.
This
is
the
the
thing
that
we
say
we
use
these
these
libraries
and
we're
going
to
use
these
things
so
that
instruments
these
things
for
us,
not
I've,
just
added
this
agent
and
this
agent
does
all
of
this
auto
magic
stuff
and
is
really
opinionated.
It's
okay
for
libraries
to
be
opinionated,
because
the
person
who
wrote
that
Library
also
wrote
the
instrumentation.
B
So
it's
okay
for
those
to
be
opinionated,
but
for
an
external
company
to
be
opinionated
about
the
the
attributes.
The
way
that
spans
are
created
becomes
a
well
this
one
vendor.
Does
it
this
way
and
this
vendor?
Does
it
this
way
and
you
can't
switch
between
them?
That's
standardization
becomes
this
well
I'm,
purposefully
deciding
that
I
want
to
instrument
this
thing,
or
this
is
something
that
I
believe
is
an
interesting
part
of
my
application,
which
you
don't
get
when
you
start
to
use
the
pre-duill
agents.
B
It's
one
of
the
reasons
why
I'm
not
a
huge
fan
of
the
new
agents
that
are
coming
in
to
open
Telemetry,
because
they
now
are
the
open,
Telemetry
agents
for
the
different
languages.
Python,
Java
and
net
have
Auto
instrumentation
agents,
which
you
can
add
without
adding
any
code
to
your
application
and
it
will
just
Auto
instrument
your
application
application,
but
it's
again
really
opinionated
they're
doing
a
lot
better
job,
because
they're
doing
a
lot
of
Discovery
and
they're
still
using
the
the
SQL
Auto
instrumentation,
the
asp.net
core,
also
instrumentation
stuff.
B
D
Martin
and
Grace
just
a
question
on
that.
Maybe
you
have
a
unique
setup
in
some
regards,
but
the
organization
I'm
with
we
have
dozens
of
customers.
We
have
28
plus
products,
various
versions
for
each
customer,
so
we
have
an
extreme
Challenge
at
times
introducing
code
changes,
Library
changes,
instrumentation
changes
that
get
out
to
all
customers
in
any
reasonable
amount
of
time.
Of
course,
we're
on
a
cloud
Journey
trying
to
unify
code
bases
and
get
to
single
releases
and
so
on.
But
on
the
flip
side
we
have
an
operations
group
that
is
outsourced.
D
So
it's
a
separate
company
that
actually
operates
everything
for
us.
So
historically,
we've
had
an
APM
agent
with
very
opinionated
instrumentation,
because
that
Ops
group
is
responsible
for
uptime
and
ensuring
everything's
running
well
for
our
dozens
of
clients,
so
I'm
innocent,
similar
stance
trying
to
Champion
this
open,
Telemetry
and
I
have
the
developers
who
don't
have
opinions
on
how
to
instrument
because
they
never
needed
to
the
Ops
group
just
took
care
of
deploying
this
extra
smart
agent.
Nobody
needed
to
worry
about
it
because
it
wasn't
their
responsibility.
D
So
this
interesting
Dynamic,
where
the
Ops
group
says
sure
that's
that's
a
great
idea.
So
that's
if
you
can
produce
quality
Telemetry
for
us
that
this
agent
is
currently
getting
like.
Well,
we
could
produce
better
if
we
could
get
the
devs
to
do
it.
So
it's
kind
of
this
Middle
Ground,
where
I'm
wondering
I
guess
getting
the
point.
What
kind
of
audience
do
you
see
gravitating
towards
an
open
Telemetry
and
these
Solutions?
Is
it
Ops?
Is
it
Dev?
Is
it
both
someone
else.
B
It's
definitely
an
interesting
question.
I
I
think
this
is
all
about
culture
change.
This
comes
down
to
a
lot
about
the
the
whole
devops
movement
of
don't
throw
things
over
the
wall
and
hope
that
somebody
else
will
monitoring
somebody
else's
concerned.
B
C
We
have,
we
do
have
like
it's
all
internal,
it's
not
a
separate
company,
but
we
do
have
a
bit
of
cultural
separation.
At
the
moment,
I
would
say
between
developers,
I
wouldn't
say,
developers
have
a
strong
relationship
with
production,
and
that
is
not
something
that
I
think
will
be
sustainable.
Long-Term
term
I.
C
Don't
think
that
I
I
don't
think
that
it's
sustainable
as
we
grow
as
we
expand
as
the
complexities
of
distributed
systems
make
themselves
known
over
and
over
and
over
again
I
think
that
I
think
it's
going
to
end
up
being
the
case
that
developers
are
going
to
be
the
ones
that
are
going
to
need
to
be
more
responsible
for
production.
Be
looking
at
production
on
a
daily
basis.
C
Would
just
be
a
dream
at
this
point
and
just
being
able
to
be
interested
in
production,
because
that's
what
I
really
love
about
open,
Telemetry
and
like
having
a
tool.
That's
like
explorable,
too,
is
that
you
can
actually
I
care
about
how
people
feel
about
coding
I
care
about
how
people
feel
about
production
and
I
care
about
how
people
feel
about
actually
being
able
to
ask
questions
and
answer
them
quickly.
C
So
if
there's
a
separation
between
the
developers
who
write
the
code
and
then
the
actual
people
who
are
responsible
for
like
the
uptime
I,
think
it's
difficult
to
actually
have
a
relationship
with
production
like
if,
if
a
developer
is
only
asked
about
production,
when
somebody
who's
responsible
for
uptime
asks
them
hey
what
happened
recently
like
I,
don't
think
the
answer
is
as
strong
as
if
developers
going
and
looking
at
production
every
morning
and
being
like
what
does
it
look
like
today?
Why
does
that
thing?
B
And
I
think
it's
there's
three
different
things
that
happen
in
that
scenario.
What
you've
got
is
the
developer
understands
their
code.
They
understand
what
they
write.
You've
got
the
the
customer
who
uses
that
code
and
gets
an
error,
so
they
will
say
this
thing
happened.
The
Ops
Team
then
go
here's
some
data
that
you
don't
know
about
as
a
developer,
to
tell
you
that
the
customers
just
told
me
that
there's
an
error
that
happened
and
I've
got
some
information
here.
You've
got
three
different
things:
three
different
people
in
that
conversation.
B
Realistically,
if
you
can
do
a
scenario
where
the
developer
is
able
to
ask
the
questions
of
production
and
have
that
first
party
conversation
with
production
that
says:
okay
tell
me
where
it
hurts.
You
know
that
the
idea
of
which
which
thing
went
wrong:
okay,
but
then
well
what
else
went
wrong
at
that
time
and
who
else
was
affected?
Or
was
it
just?
This
particular
end
point?
B
Was
it
just
for
this
particular
user
asking
those
questions
of
production
now
if
you've
got
Ops
in
the
way
and
not
in
the
way,
in
the
the
bad
sense,
but
I
mean
as
being
that
intermediary?
In
that
conversation,
every
question
that
you
ask
they've
got
to
ask
the
system
and
then
they've
got
to
respond
with
that,
and
it's
that
democratization
of
access
to
that
production
data
that
really
pushes
the
developers
to
go.
B
Oh,
no,
I,
I,
don't
want
somebody
to
send
me
some
abstract
information
about
production
and
I
want
that
to
actually
be
I
want
to
be
able
to
really
get
to
the
core
of
what
that
user's
problem
was
and
not
be
getting
this
third-party
information
about
it,
yeah,
which
you
know
we're
getting
into
more
just
general
observability
and
that
kind
of
stuff.
At
that
point,
rather
than
specific
to.net.
B
What
I
would
say,
though,
is
I
I,
think
in
the.net
community
we've
perpetuated
the
idea
of
that
Ops
APM
all
of
that
kind
of
stuff
for
a
lot
longer
than
a
lot
of
languages
have
because
we're
we're
very
comfortable
with
the
handoff
into
the
Ops
people.
They
know
how
to
run
is
I,
don't
know
what
err
is
it's
fine.
They
run
that
web
Farms
Oh,
no
I
got
one
application,
I
hit
play
and
I
I,
don't
like
to
generalize
I,
don't
but
I
think
that
I
was
in
that
world
six
years
ago.
B
B
The
you
know
there
was
the
thing
that
you
did
in
production
was
very
different
to
what
you
did
locally
well,
I
run
it
on
an
is
web
farm
with
a
network
load
balancer,
that's
baked
into
windows
that
does
round
robin
and
unicat
I'm,
like
what
I
I
I
I
write,
C
sharp
that
isn't
me
and
I
think
we're
getting
to
a
point.
Now
where
we
run
in
containers,
we
run
things
locally,
we
we're
net
and
we
run
things
in
containers.
Now
it's
what
we
do.
It's
not
an
obscure
thing
anymore.
B
We
we
do
write
them
in
that
way.
So
I
think
we're
getting
to
a
point
now
where
people
are
not
as
scared
of
production.
Just
one
of
our
developer
Advocates
likes
to
say
that
production
is
part
of
the
team.
Now
the
production
is
just
another
member
of
the
team,
because,
in
order
for
things
to
work,
we
need
to
work
as
a
team.
B
Well,
production
is
a
member
of
the
team,
then,
and
I
love
that
analogy
that
now
all
of
a
sudden,
especially
in
the.net
World,
we're
like
no
no
production,
is
a
thing
that
you
need
to
know
about.
You
might
not
need
to
get
up
and
at
2AM
and
fix
it.
You
definitely
need
to
know
how
it
runs,
because
it's
running
in
containers-
and
you
can
do
that
locally.
B
So,
let's
talk
a
little
bit
about.
There
was
a
question
in
the
chat
about
full
framework.net
versus
dot,
net
core
and
I
believe
you've
had
some
experience
of
working
with
full
framework.net
with
Nancy
I
believe
yeah.
C
C
So
we
still
have,
because
our
company
has
gosh
I'm,
gonna,
I'm
gonna,
say
about
100
Services.
It
might
even
be
more
than
like
200.
C
and
then
many
of
those
are
like
between,
like
the
teams
like
some
of
those
projects
will
be
inherited
from
another
team,
and
so
the
people
who
are
currently
responsible
for
that
for
that
service
are
not
like
the
original
implementer.
So
there's
like
a
little
bit
of
a
knowledge
transfer
there,
but
also
like
a
lot
of
these
services
are
just
running
and
they've
been
built.
In.Net
framework
and
Nancy,
and
and
some
of
the
newer
ones
are
either
getting
like
migrated,
to.net6
and
net
core
and
all
those
things.
C
I
would
say,
with
implementing
instrumentation
with
open
Telemetry
in.net
core,
especially
the
auto
instrumentation
they're
like
I've
just
recently,
was
working
with
a
couple
services
that
were.net
core
and
then
a
service
that
was.net
framework,
also
in
Nancy
and
like
the.net,
core
ones.
When
you
set
up
like
the
SQL
Auto
instrumentation,
you
can
do
so
much
with
it
and
it'll
automatic
and
it'll
like
add,
like
the
DB
statements
and
whatnot,
not
true
for
Net,
Framework
and
so
I
get
like.
You
know.
C
The
actual
calls
to
the
database
and
everything
and
I
get
a
little
bit
of
information.
But
it's
like
I
want
the
statement
and
I
want
to
be
able,
to
like
add
any
sort
of
like
extra
enrichment
like
if,
because
within,
like
the
all
of
the
enrichment
that
you
can
do
with
auto
instrumentation,
like
maybe
I,
could
get
some
parameters,
sometimes
as
long
as
it's
safe
and
all
of
those
things
right.
But
it
also
was
a
and
I
haven't
actually
worked
with,
like
the
specific,
like
Hotel
Auto,
instrumentation
Library.
C
We
also
have
some
situations
where
it's
like.
We
have
common
libraries
within
the
ecosystem
with
internally
that,
like
hey,
if
you
want
to
talk
to
this
particular
service,
a
here's,
a
library
that'll,
do
it
for
you.
But
that
means
that
sometimes
the
configuration
to
talk
to
that
service
type
of
like
redis
or
like
Monger,
whatever
it's
hidden
in
that
Library,
so
I
can't
actually
like
get
to
the
connection
strings
of
like
or
anything
and
I'm
like
okay.
C
C
Overall,
the
the
main
thing
is
like
because
I'm
trying
to
convince
people
hey,
we
can
move
Beyond
logs
and
metrics
in
general
and
I
move
into
tracing
like
I
I
need
to
kind
of
make
these
strong
cases
for
why
this
is
important,
but
then
by
not
having
like
the
ease
of
like
by
having
Auto
instrumentation.
That
gets
you
like
a
certain
degree,
but
you
know
if
I'm,
if
I'm
talking
to
a
team,
that's
got
like
their
main
services
like
an
older
service,
that's
not
upgraded
to.net,
core
and
Dot
net
six
or
anything.
C
Then
it's
like
okay,
so
like
if
they're
talking
to
SQL
and
you're,
not
going
to
get
the
DB
statements,
it's
like
okay,
so
I!
Now
you
have
a
choice.
It's
like!
If
you
need
the
DB
statements,
then
you
probably
do
like
okay
am
I.
Is
my
recommendation
going
to
be
to
tell
you
to
wrap
everything
with
like
some
like
custom
middleware
that
we
make,
or
is
it
like
wait
for
hotel
like
open
source
to
kind
of
catch
up
for
it
right
so
I.
B
C
Of
times
exactly
so
like
I,
I
would
say
that
you
know
like
some
of
the
struggles
I
have
is
like
you
know
the.
What,
if
for
people
who
are
you
know,
they've
got
these
like
long-lived
Enterprise
services
and
everything
like
if
we're
not
in
a
situation
where
you
can
convince
management
to
actually
like
pay
upgrade
today?
That
is
that,
okay.
So
what
are
strategies
to
like
bridge
the
gap?
Basically.
B
Yeah
I
think
there
is
a.
There
is
a
big
gap
with
the
the
full
framework
stuff
I
know:
there's
a
movement
in
the
hotel.net
to
potentially
try
and
drop
some
of
those
and
drop
some
of
the
things
to
dotnet
standard
and
that
kind
of
stuff
which
will
probably
be
met
with
some
resistance
from
people
like
yourself,
but
I
think
we
need
to
wrap
up.
There.
We've
run
over
a
little
bit,
I'd
like
to
thank
absolutely
everybody
for
for
coming
by
I
hope.
B
You
learned
some
things
and
at
least
walked
away
with
some
ideas
on
what
you
can
potentially
have
a
look
at
tomorrow
and
waste
your
time
we're
not
looking
at
for
myself,
you
can
reach
out
to
me
on
Twitter.
We
I
also
do
some
office
hours.
You
can
check
out
the
honeycomb
website
if
you'd
like
to
have
some
chats
about
me
and
about
observability
and
um.net,
and
all
that
kind
of
stuff
I
will
talk
your
air
off
for
a
full
half
an
hour.
B
If
you
want
to
do
that,
and
just
one
quick
thing,
observability
Grace
is
available
on
Twitter
as
a
handle,
so
I
think
you
need
to
pick
that
one
up
pretty
quick,
so
I
think
Rin
has
some
closing
remarks.
But
from
me.
Thank
you.
So
much
for
listening
to
me
rant
for
a
little
bit.
A
Absolutely
I'm
not
sure
if
you
can
hear
me
because
my
situation
is
frozen,
but
thank
you
to
everyone
for
coming
by
and
we
I'm
I'm
gonna
put
this
in
the
chat
as
well,
because
I'm
not
sure
if.
A
You
here
that's
fine,
oh
wonderful,
okay,
my
connection
is
going
wobbly,
yeah,
so
two
ways
to
keep
up
with
this
project.
There
is
a
meetup.com
group,
open
Telemetry
in
practice.
That's
a
great
way.
If
you
just
want
to
get
notified
of
the
next
Meetup,
we
have
one
on
kubernetes
for
October
and
we
are
planning
an
in-person
day
for
all
languages,
co-located
with
kubecon
on
October
25th.
A
That
will
be
announced
super
soon,
and
you
know,
we've
had
a
great
conversation
here
today
and
gotten
several
topics
for
meetups,
so
looking
at
doing
another.net
one
in
November
and
you
can
also
join
the
cncf
slack
and
look
for
the
otel.net
channel,
and
you
can
message
me
Rin.
A
My
name
is
Rin
Mancuso
in
the
cncf
slack
or
reefley,
who
is
also
here
and
asked
to
be
added
to
the
private
Hotel
end
users
Channel,
where
you
can
discuss
with
other
folks
who
you
know
are
not
vendors
hope
you
all
have
a
lovely
day
and
thanks
for
coming
to
our
first.net
Meetup.