►
From YouTube: Metrics and Logs Are Out, Distributed Tracing Is In With Chinmay Gaikwad | Kongcast Episode 5
Description
In this Kongcast Episode, Chinmay Gaikwad, tech evangelist at Epsagon, explains why metrics and logs aren’t sufficient for companies with a microservices architecture. Instead, Chinmay recommends leveraging distributed tracing for optimal observability.
Try Epsagon in a demo environment: https://demo.epsagon.com
Sign up for Epsagon: https://app.epsagon.com/signup
Subscribe to get email alerts for the latest new episodes and see which guests are coming on the show next: https://bit.ly/3zQV71e
▬▬▬▬▬▬ TIMECODES ▬▬▬▬▬▬
0:00 Kongcast Show Intro
0:28 Welcome, Chinmay!
1:56 How Observability Has Changed Over the Years
3:52 How Does Epsagon Help With Observability Challenges?
5:43 What’s the Value of Distributed Tracing?
6:59 Important Metrics to Track With Distributed Tracing
9:47 Epsagon Use Case
12:00 How to Instrument Epsagon
16:10 Monitoring Workloads in the Clouds
17:16 Demo: Epsagon in Action
23:47 Book Recommendations from Chinmay
24:33 Thanks for Joining, Chinmay!
25:07 Kongcast Show Outro
▬▬▬▬▬▬ ABOUT KONGCAST ▬▬▬▬▬▬
Hosted by @ViktorGamov and Kaitlyn Barnard, we interview software developers and technology leaders at the top of their game every other week. We’ll also give you the tools, tactics and strategies you need to take your distributed architectures to the next level. Kongcast goes beyond the buzzwords and dissects real-life applications and success stories so that you can tackle your biggest connectivity challenges.
▬▬▬▬▬▬ KONG COMMUNITY ▬▬▬▬▬▬
⭐ https://github.com/Kong/kong
🐦 https://twitter.com/thekonginc
🌎 https://konghq.com/community/
🍻 https://www.meetup.com/pro/kong
❓ ️https://discuss.konghq.com/
💯 https://konghq.com/kong-champions/
#microservices #observability #serverless #lambda #kubernetes #Kongcast
B
B
C
Sure
so
I
basically
come
from
a
software
development
background.
I
started
off
my
career
at
intel
as
a
software
developer.
I
was
there
for
a
few
years,
then
moved
around
roles.
I
jumped
from
software
engineering
to
application
platform
engineering
to
technical
marketing
engineering,
and
then
I
also
did
a
bit
of
product
marketing
and
now
I'm
a
technical
evangelist
here
at
epsilon,
I'm
based
out
of
new
york,
love
the
city.
I
think
it's
one
of
the
best
cities
in
the
world.
I.
B
C
New
york,
yeah
yeah,
so
essentially
epsilon
is
an
observability
platform
and
we
help
monitor
applications
running
in
kubernetes
and
serverless
environments
and
epsilon
started
as
a
distributed
tracing
based
obsolete
platform,
and
we
can
talk
more
about
that
as
we
go
further
along.
But
that's
what
I'm
saying
on
earth
essentially.
B
That's
that's,
that's
actually
pretty
cool,
and
I
think
these
days,
the
observability
and
the
health
of
production
systems
is
becoming
more
important
when
we're
talking
with
engineers
we're
talking
with
the
builders.
People
who
build
the
systems-
and
you
know
want
to
make
sure
that
the
system
stays
up
24
by
seven
and
no
one
gets
paged
in
the
middle
of
the
night
and
things
like
that.
B
Let's,
let's
talk
about
these
challenges
so
see
I
already
you
know,
call
out
some
of
the
things
that
I
remember
from
my
years
when
I
was
a
consultant
when
I
work
with
some
of
the
teams
where
we
provided
some
production
support
and
that
time
was
just
something
different.
You
know
they
only
called
me
as
a
developer
when
something
was
really
bad
because
there
was
a
development
team.
B
We
developed
the
code,
we
throw
this
over
the
fence
and
the
people
need
to
support
this
and
we
didn't
care
much
about
what
they're
gonna
be
using
for
monitoring
how
they're
gonna
be
alerted,
then,
who
will
be
on
call
and
all
these
kind
of
things
and
over
the
last
you
know
couple
years,
maybe
like
the
last
10
years
or
so.
This
situation
has
changed.
How
you
see
this
over
the
years
in
your
career.
That's
a
great.
C
C
So
that's
a
huge
shift
that
I've
seen
over
the
last
10
years
and
the
other
shift
that
I've
seen
is
developers
versus
a
devops
culture
and,
as
you
mentioned
just
developing
the
code
and
throwing
it
over
was
kind
of
a
thing
back
then,
but
these
days
you
are
responsible
for
your
own
code,
you're
responsible
for
monitoring
the
health
of
your
own
code,
so
the
devops
culture
has
clearly
integrated
in
most
of
the
companies
these
days.
So
those,
I
think,
are
the
two
major
shifts
that
I've
seen
over
the
last
10
years
as.
B
Many
listeners
know
that
clone
is
a
cloud
connectivity
company
and
we
really
truly
care
about
the
the
connecting
the
applications
through
apis.
Through
all
you
know,
sorts
of
things
how
distributed
systems
are
connected.
So
that's
why,
for
us,
it's
also
important
topic.
How
we
can
you
know,
provide
this
like
connectivity,
like
electricity
or
water,
or
even
air,
for
modern
digital
enterprises
and
the
part
of
observability
and
monitoring
to
make
sure
that,
like
things
are
going
smoothly,
it's
also
important
for
for
us
yeah.
C
What
I
mean
by
that
is
the
logic
of
the
code
was
within
an
application
itself,
so
it
was
kind
of
easier
to
moderate
or
monitor
the
applications
itself,
and
they
were
also
focused
on
infrastructure,
because
back
then
infrastructure
was
very
varied,
so
we
had
of
virtual
machines.
We
had
dedicated
servers,
we
had
on-premises,
we
had
in
the
cloud,
so
infrastructure
was
kind
of
valid,
but
these
days
essentially
it
applications
have
gained
more
importance
with
the
essence
of
microservices
coming
into
picture
and
infrastructure
is
kind
of
becoming
standardized.
C
So
you
generally
use
a
particular
cloud
provider
or
you
generally
use
kubernetes
based
infrastructure,
so
epsilon
essentially
came
into
picture
when
microservices
revolution
was
kind
of
complete
and
then
we
realized
that
hey
there
is
metrics
and
there
is
logs,
but
those
two
are
not
really
effective
to
troubleshoot
applications
in
a
microservices
world.
So
what
do.
B
We
need
usually
we
use
logs
only
as
a
you
know,
like
a
last
resort.
Okay,
so
let's
check
the
logs
and
see
what's
going
on
there
and
we
do
have
metrics,
but
those
metrics
might
show
some
current
state.
For
example,
if
we
see
something
is
happening
in
production,
but
if
we
cannot
reproduce
this
because
it
was
a
spike
how
we
can
use
this
data
like
how
they
use
this
metrics
to
to
investigate,
like
we
probably
need
to
do
something
better
right.
B
C
C
So
a
trace
essentially
tells
you
the
story
behind
a
particular
user
action
or
a
request,
and
that's
where
the
problem
might
lie
in
so,
for
example,
if
a
user
is
not
able
to,
let's
say
put
an
item
into
the
cart
and
you
have
an
error
there
so
distributed
tracing,
helps
you
to
pinpoint
where
exactly
the
problem
is
occurring,
which
microservices
are
responsible
for
that,
and
essentially
it
helps
to
connect
metrics
and
logs.
In
that
way,.
C
B
That
show
some
immediate
data
and
traces
that
shows
things
how
they
happened
in
progression
in
in
time.
So
I
have
a.
I
have
a
question
then,
usually,
when
we
talk
about
metrics,
we
talk
about
things
that
important
how
we
can
choose
or
like
how
people
should
think
about
which
metrics
are
or
the
traces
or
all
all
this
information
is
actionable.
B
Some
of
the
information
this
actionable,
because
there
are
some
cases
where
you
see
high
spikes
with
cpu,
but
like
okay,
do
I
need
to
call
my
people
who's
on
call
right
now,
or
I
see
you
know
the
something
where
my
kubernetes
can
handle.
For
example,
auto
scaling
just
spin
up
another
instance
of
the
application,
so
in
this
case
the
load
will
be
gradually
distributed
across
things.
So
can
you
talk
about
this
like
it's
not
like
a
technical
question,
it's
more
like
architectural
and
more.
B
Like
the
cultural
question
like
what
the
how
you
would
approach
or
like
what
kind
of
advice
you
provide
to
people
about
which
metrics
are
actionable
impactful
for
business
and
all
what
we
do
is
is
essentially
serving
the
business,
and
we
need
to
make
sure
that
the
business
continues
to
run.
How
you
think
about
this
and
how
the
apps
are
going,
help
to
think
about
those
things
like
like
business,
related,
metrics
and
actionable
alerts
or
actionable
items
that
happened
in
the
system.
C
B
C
Yeah
exactly
so,
we
get
to
work
with
a
lot
of
cool
customers.
That's
why
but
yeah
so
essentially,
at
a
business
level.
You
have
a
particular
list
of
kpis
defined
based
on
your
service
level
agreements.
So
sls
are
important
and
then
you
define
your
kpis
and
the
kpis
might
be
as
as
simple
as
how
much
of
the
time
the
website
is
up.
So
that's
a
very
simple
kpi
and
then
you
need
to
kind
of
figure
out
the
engineering
team
or
the
cto
needs
to
figure
out.
What
does
it
take
to
keep
the
website
up?
C
So
what
are
the
components
required
in
that
and
then
you
can
actually
define
which
metrics
are
important.
So,
for
example,
if
you're
using
aws
dynamodb
as
your
backend
database,
then
you
need
to
figure
out
how
much
requests
request
time
is
being
taken
to
fetch
data
from
dynamodb.
So
that
might
be
one
of
your
important
metrics.
So
it
depends
on
case
by
case
basis,
but
like
business
level,
metrics
definitely
define
engineering
metrics
and
then
the
flow
goes
on
at
the
end.
Can.
B
You
talk
a
little
bit
about
some
of
the
most
exciting
use
cases
that
you
work
in
in
your
work
when
you're
meeting
the
customers-
or
you
know
your
your
colleagues
and
meeting
your
customers-
and
you
know
it's
great
things
that
you
can
talk
about.
Can
you
talk
a
little
bit
about
some
of
the
like
cool
use
cases
that
you've
seen?
Maybe
you
know
collection
or
some
like
weird
the
languages
and
that
application
is
written?
C
So
we
had
so
like
one
of
the
one
of
the
cool
things
again
as
we
discussed
was
different
industries
and
they
have
like
so
varied
use
cases
and
most
of
them
were
doing
the
transition
from
being
monolithic
to
being
micro
services
in
the
recent
years.
So
for
them
monoliths
were
so
it's
a
huge
mindset,
shift
right
moving
from
one
list
to
microservices
and
generally
people
don't
really
jump
directly
to
serverless
functions.
They
generally
take
an
intermediate
step,
maybe
move
to
containers
and
run
monolithic
applications
in
containers.
C
It
kind
of
becomes
hard
to
monitor
monolithic
applications
within
containers
that
we
can
definitely
do
that,
but
the
ideal
case
would
be
running
microservices
within
containers.
So
one
of
our
customers,
for
example,
did
this
huge
transition
and
it
required
a
lot
of
engineering
resources
and
they
were
not
seeing
the
results.
So
they
did
not
see
the
transition
from
monolithic
to
microservices
to
their
benefit.
They
were
seeing
a
lot
of
website
downtime.
C
They
were
seeing
a
lot
of
database
downtime
and
they
did
not
know
what
what
was
happening
essentially
and
they
were
also
using
ruby,
which
is
not
the
most
commonly
used
language
in
cloud
these
days.
So
it
was
essentially
for
us.
It
was
essentially
a
challenge
to
figure
out
what
exactly
is
going
on.
It
was
basically
trying
to
figure
out
two
things:
the
technical
challenge
of
monitoring
ruby
applications,
as
well
as
helping
the
customer
understand
that
they
are
transitioning
from
bonus
to
microservices,
is
an
effective
one
and
they
should
go
that
route.
C
B
So
since
we
on
this
subject,
so,
can
you
talk
a
little
bit
about
what
it
takes
to
say?
We
have
a
two
services,
one
written
in
ruby,
another
php
and
maybe
third
one
written
in
java.
What
it
takes
to
install
integration
with
pepsico
like
is
it
requires
some
sort
of
agent
or
those
agents
needs
to
be
aware
about
the
language
that
they're
running
or
it's
like
some
sort
of
like
genetic
agent
that
monitors
traffic
and
applies
some
of
the
heuristics
to
extract
like
information
from
the
things.
So
can
you
talk
a
little
bit
about?
C
Yeah
sure
so
that's
the
part
that
you're
talking
about
is
basically
instrumentation
and
it
is
language
specific,
so
epsilon
supports
a
bunch
of
languages
such
as
node,
gold,
java,
python,
etc.
So,
right
now
we
have
seen
a
wave
of
no
code,
low
code,
applications
or
architecture
coming
up
and
epsilon
definitely
supports
that
kind
of
motion.
So
we
essentially
believe
in
low
code
implementation
so
far
for
you
to
instrument
your
application.
It
just
requires
like
four
or
five
lines
of
code
and
then
you're
good
to
go
so.
B
They
need
to
use
a
library,
and
recently
I
started
watching
some
of
the
the
videos
about
like
a
popular
physics
with
my
son,
he's
only
six
but
he's
quite
interested
in
quantum
physics,
for
some
reasons
he's
like
when
we're
driving
somewhere
or
like
we're
seeing
washington,
let's
watch.
This
is
the
video
about
quantum
physics
and
in
quantum
physics,
there
is
a
paradox
of
the
observer.
So
when
there's
some
experiment
is
happening,
usually
with
even
observer,
you
know
watching
something.
B
It's
actually
my
defect,
because
the
the
experiment-
usually
it
happens
on
the
it-
doesn't
happen
on
the
macro
level,
it
happens
on
on
the
micro
level
or
nano
level
right.
You
know
when
they
we're
talking
about
particles
and
there's
the
famous
experiment
when
we
shooting
electrons
through
the
through
the
grid
and
if
we're
putting
some
detector
that
detects
the
fly
of
the
electron
through
the
through
this
grid.
This
actually
affects
the
experiment.
The
same
thing
is
also
people
talking
about
the
the
shirting
experiment.
B
B
C
Yeah,
that's
a
great
question
so
again
earlier
generally,
people
did
not
care
about
the
agent's
cpu
or
memory
consumption
because
they
were
using
on-premises
data,
centers
and
stuff
like
that,
so
the
cost
was
not
much.
But
now
since
you're
running
almost
everything
in
the
cloud,
the
cost
of
cpu
and
memory
is
definitely
high
and
epsilon
is
kind
of
cognizant
of
that.
So
once
we
instrument
our
the
application,
the
cost
of
cpu
or
memory
usage
is
just
about
one
to
two
percent.
So
it's
not
much
even
with
the
fact
that
we
don't
do.
C
B
What
about
like
a
network
because
you
either
need
to
like
submit
all
requests
or
like
come
with
some
like
smart
matching
strategies,
so
the
yeah
information
about
the
so
and
also
you
you
don't
want
to
bash
too
long.
So
in
this
case,
information
would
be
not
super
real
time
and
things
like
that.
It's
a
trade-off!
I
understand
but
like
what
what's?
What's
your
feel,
what
the
what
how
the
users
feel
about
this
in
the
in
general?
What's
your
recommendation,
yeah.
C
So
we
actually
did
a
very
basic
cost
analysis
for
the
network
data
that
you
sent.
For
example,
you
need
to
send
metrics
data
to
epsilon,
or
you
need
to
send
a
certain
trace
data
to
epsilon
and
the
cost
essentially
is
in
tense
or
at
the
most
lower
hundreds.
So
it's
not
it's
not
very
significant.
It's
minimal
to
the
customer
as
compared
to
what
observability
brings
to
their
entire
application.
Yeah.
B
Makes
sense
so
in
since
you
mentioned
the
cloud
and
the
things
that
people
moving
more
and
more
workloads
there
in
specifically
also
like
application
logic,
how
you
approach
the
the
question
of
monitoring
this
kind
of
like
a
serverless
like
a
function
as
a
service
type
of
applications,
lambda
google
cloud
functions
and
something
maybe
like
a
custom
implementation.
I
don't
know
like
how
someone
might
be
running
some
open,
whisk
or
something
like
that.
C
Yeah,
that's
a
great
question
again
so
epsilon
started
with
monitoring
lambda
applications,
so
our
complete
focus
when
we
started
back
in
2018
was
lambda
applications
and
all
you
need
to
do
is
essentially
just
integrate
your
aws
environment
and
that's
it.
You
don't
have
to
worry
about
anything
else,
because
we
specialize
in
monitoring
lambda
applications.
C
We
have
like
a
dashboard
and
we
have
a
function
screen
which
essentially
tells
you
if
there
are
exceptions,
what's
the
cost
associated
with
lambda
functions,
so
it's
very
serverless
focus
and
recently
we
also
started
supporting
a
lot
of
kubernetes
and
container
applications.
So
it's
a
combination
of
both
essentially.
B
C
Victor
so
victor
we
talked
about
how
what
does
it
take
to
instrument
epsilon
in
your
applications?
So
here
is
a
simple
code,
so
essentially
you
just
need
to
install
epsilon
and
then,
if
you
export
a
few
environment
variables,
that's
all
you
need
to
do
so.
Essentially
now
you
have
instrumented
epsilon
for
your
nodejs
applications.
We
also
support
other
languages,
such
as
python
java,
go
ruby.net,
etc.
So,
once
you've
done
that
you
can
start
playing
around
great
test
that
I
would
start
would
be
the
service
map.
C
This
essentially
gives
you
the
holistic
view
of
your
entire
architecture.
So
this
gives
you
how
micro
services
interact
with
each
other.
Here
you
can
essentially
see
whatever
you
have
designed
has
been
implemented
in
practice
or
not,
so
you
can
definitely
use
the
service
maps
in
your
design
phase
as
well
as
implementation
phase.
We
have
seen
customers
using
the
service
maps
in
their
implementation
phase
when
they
need
to
do
feature
development,
for
example,
so
how
new
micro
services
interact
with
the
older
micro
services,
for
example.
So
here
you
can
see
the
service
maps.
C
There
are
a
bunch
of
lambda
functions,
interacting
with
the
redis
database.
There's
also
a
dynamodb
table,
you
can
see
different
arrows
here
and
they
have
latencies
marked
on
them.
There
is
also
a
red
colored
arrow,
which
essentially
says
that
there
are
some
errors
going
on
here
so
once
we
click
on
a
particular
microservice,
a
sidebar
pops
up,
which
essentially
gives
you
a
picture
of
what
the
important
metrics
are
with
this
particular
microservice.
So
the
success
error
ratio,
for
example,
the
average
duration
and
also
the
api,
is
called
breakdown.
C
So
once
you
have
that
now
you
need
to
know
why
the
error
is
occurring,
so
you
can
directly
jump
to
the
traces
and
once
you're
in
traces,
epsilon
filters
out
the
trace
for
this
particular
lambda
function,
and
then
you
can
jump
to
any
trace
that
you
find
interesting.
You
can
compare
successful
traces
with
errored
out
traces
and
you
can
also
see
the
latencies
for
them.
C
So
let's
look
at
this
particular
error
once
you
click
on
this,
this
will
give
you
the
trace
view,
and
then
you
can
see
how
the
trace
is
interacting
and
what
errors
are
happening
in
this
particular
trace.
So
f
seconds,
one
of
the
a
great
differentiators
is
correlating
metrics
logs
and
traces,
and
in
this
complete
picture
you
can
see
that
a
trace
metrics
as
well
as
logs,
are
correlated
epsilon,
also
does
a
great
job
of
pointing
out
why
the
error
is
happening.
So
you
can
see
here
that
there
is
something
wrong
with
the
coupon
discount.
C
That's
going
on,
you
can
click
through
different
micro
services
and
see
what
information
it
gives
you
another
great
distinguishing
factor
for
epsilon
is
that
it
gives
you
the
payload
information,
so
you
get
whatever
payload
that
has
been
transferring
between
microservices.
You
can
get
access
to
it,
and
you
can
also
see
why
a
particular
error
is
happening.
You
can
also
see
the
timeline
view,
which
will
essentially
help
you
to
figure
out
performance
and
latency
issues,
and
then
you
can
also
see
the
sequence
diagram
associated
with
this
particular
trace.
C
Now,
once
this
is
done,
this
takes
care
of
your
application.
Troubleshooting
part,
the
other
other
important
environment
that
you
need
to
monitor,
might
be
the
kubernetes
environment
or
the
application
dashboard
environment.
So
epsilon
gives
you
a
lot
of
out-of-the-box
dashboards,
so,
for
example,
this
is
the
application
overview
dashboard.
You
can
see
the
top
five
applications
by
errors,
and
then
you
can
also
see
the
latency
and
throughput.
C
So
let's
look
at
the
kubernetes
overview
dashboard
here.
Essentially,
you
can
see
all
the
important
components
of
kubernetes
and
how
they
are.
How
are
they
reacting
to
your
applications
running
on
them?
You
can
see
the
cpu
usage.
The
memory
usage
as
well
as
the
nodes
can
obviously
correlate
them.
As
you
can
see
here,
the
cpu
usage,
the
memory
usage
for
nodes
containers
and
parts
running
you
can
also
use
different
resources,
as
I
had
mentioned
to
victor
before
we
started
off
as
a
serverless
monitoring
company,
and
then
we
move
to
kubernetes
and
containers
as
well.
C
So
you
can,
you
can
monitor
essentially
ecas
kubernetes
appsync
as
well
as
serverless
functions,
I'll
just
go
through
the
function
screen
for
this
particular
demo
in
the
function
screen.
You
can
see
the
top
functions
that
you're
using
when
was
it
last
modified
last
invocation,
the
number
of
errors,
the
average
duration
and
the
estimate
monthly
cost
as
well.
You
can
see
all
the
issues
at
one
place
in
the
issue
screen
and
that's
a
really
nice
thing
to
have
essentially
not
digging
through
different
issues.
So
everything
is
at
one
place
and.
B
C
C
Exactly
I
I
love
that
feature
too
and
then,
finally,
you
can
create
alerts
on
different
things,
such
as
lambda,
epsilon,
metrics
cloud
watch,
metrics
as
well
as
epsilon.
Traces
saigon
also
supports
metrics
data
through
prometheus
and
grafana,
so
you
can
also
create
alerts
based
on
those
metrics
as
well.
So
essentially,
that's
the
short
50
000
overview
demo
of
epsilon.
B
I
want
to
say
huge
thing
to
my
guest
today.
The
demo
was
super
exciting.
I
was
very
impressed
with
certain
features,
especially
like
I
said,
coastal
some
other
things.
We
discussed
this
in
my
some
of
the
some
of
the
other
podcasts
that
I
was
participating,
but
I
think
it's
one
of
the
metrics
that
modern
developers
also
need
to
take
an
account,
apart
from
understanding
the
how
much
it
takes
to
run
this
coast
from
perspective
of
cpu
cycles
and
proper
second
memory,
but
also
how
much
it
goes.
You
know
when
you
swiping
credit
card.
C
Yeah
one
of
the
books
that
I
am
reading
right
now
is
called
zero
to
one.
It
essentially
is
a
book
about
how
startups
work
and
it's
by
peter
thiel,
who
is
a
well-known
investor,
and
it's
about
how
do
you
take
a
startup
from
zero
to
one
so
essentially
how
you
scale
the
startup?
What
market
should
you
look
for?
So
it's
a
pretty
interesting
read
I
kind
of
agree
with
most
of
the
concepts
that
I
don't
agree
with
some
of
the
concepts,
but
that's
the
point
of
the
book.
B
C
I'm
excited
super
excited
about
where
the
industry
is
going
in
terms
of
microservices
and
observability,
so
I
really
wish
all
of
you
can,
if
you're
not
really
into
the
microservice
world,
please
hop
on
to
it
and
also,
please
feel
free
to
check
out
epsilon.
I
believe
that
observability
should
do
the
work
for
you
not
the
other
way
around,
and
with
that
I
would
like
to
say
thank
you
to
all
the
listeners.