►
From YouTube: Node.js Diagnostic Best Practices - Gireesh Punathil, IBM India & Mary Marchini, Netflix
Description
The session will cover the philosophy of Diagnostics Best Practices deriving from identified user journeys, current state of and development efforts on Best Practices content. It will also provide highlights on the key best practices around major diagnostic use cases. We provide guidance on tool selection based on the associated user journey, deployment models and the tooling capability and maturity. The objective of the session is to spread the awareness and adoption of the user journey based diagnostic best practices for problem determination of Node.js deployments, leading to improved Node.js user experience.
A
Hello,
everybody
welcome
and
thank
you
for
joining
this
presentation
on
the
node.js
diagnostics
best
practice
documentation
before
we
talk
about
what
this
session
is
all
about
and
what
is
the
stated
purpose,
what
are
the
expect
outcomes,
etc?
Let's
provide
a
brief
introduction
about
these
speakers,
myself,
girish
pinata.
I
work
for
ibm,
I'm
an
architect
with
one
of
the
team
called
ibm
runtimes,
that's
responsible
for
developing
and
supporting
language
runtimes
such
as
java
and
node.js.
B
A
A
A
How
the
user
journey
is
driving
into
the
best
practice
documentation
effort,
then
we
also
provide
a
introduction
to
the
tool
tails
and
how
that
is
going
to
drive
into
the
user
experience
around
the
node.js
diagnostics.
And
finally,
we
look
at.
Where
do
we
stand
in
terms
of
the
current
status
on
the
best
practice
documentation
effort?
A
A
Node.Js
is
a
open
source,
cross-platform
javascript
runtime,
but
then
what
is
v8
v8
is
also
an
open
source,
cross-platform
javascript
runtime.
What's
the
difference,
node.js
is
customized
for
optimally
running
in
the
back
end
as
opposed
to
running
in
the
browser
and
that
specificity,
or
that
key
differentiation
makes
it
one
of
the
very
favorite
runtime
for
hosting
most
of
the
modern
workload
that
runs
in
the
back
end,
including
the
cloud
the
analytics,
the
ai,
the
mobile
and
the
iot
etc.
A
A
Originally,
we
started
as
two
different
working
groups
where
back
in
2015
one
is
the
post-modern
working
group
that
largely
concerned
around
the
dumb
debugging
and
the
second
one
being
the
tracing
working
group,
which
was
mostly
focusing
on
the
runtime
pricing,
eventually
around
2017,
or
so
we
felt
the
need
for
merging
both
the
working
groups,
because
we
found
that
there
is
a
high
degree
of
overlap
in
the
objective
as
well
as
the
way
we
work
in
both
the
working
groups.
So
that's
how
diagnostic
working
group
was
born?
A
What
we
do
in
the
working
group,
we
make
sure
that
there
is
a
great
user
experience
derived
out
of
the
node.js
diagnostics,
so
we
are
active
in
developing,
as
well
as
attaining
maturity
to
most
of
the
healthiest
grade.
Diagnostic
tools,
such
as
asynchronous
profiling,
tracing
dump,
debugging
tools
such
as
ll
node,
ffdc
tools
such
as
diagnostic
report.
A
B
We
soon
realized
that
thinking
in
terms
of
two
stability
would
be
challenging,
because
several
diagnostic
tools
node
rely
on
come
from
dependencies
such
as
v8.
With
that
in
mind,
the
working
group
decided
to
shift
focus
from
twos
two
user
journeys,
with
the
goal
of
allowing
the
project
to
guarantee
coverage
of
diagnostic
use
cases
across
not
measures,
even
if
that
meant
changes
to
the
tooling
every
once
in
a
while.
B
B
Those
guides
will
also
provide
instructions
and
pre-requirements
to
use
diagnostic
tools
in
production
environments,
since
some
tools
require
note
process
to
be
preemptively
configured
in
a
certain
way
and
because
of
the
range
of
tools
coherently
available
to
users.
Those
guides
are
also
loaded
with
case
studies
on
different
tools
applied
to
similar
issues
with
observations
on
when
each
two
is
preferred
over
the
other.
A
A
What
are
those
value
parameters
such
as
how
efficient
the
tool
is
in
terms
of
debugging
a
specific
use
case,
and
how
much
is
the
maturity
level
of
the
tool
in
terms
of
say,
for
example,
the
stability
index
and
what
is
the
overall
adoption
story
of
the
tool
in
the
user
ecosystem
and
how
well
the
tool
is
maintained
by
the
tooling
owners,
etc.
So
these
are
some
of
the
value
parameters
that
decide
what
is
the
current
tier
of
the
tool
now?
A
Where
do
each
of
this
tool
reside
in
terms
of
the
stability
index
and
various
parameters
that
I
mentioned
and
take
calculated
decisions
around
inclusion
in
certain
releases
based
on
the
long-term
support
strategy?
Number
one
number
two
is:
it
helps
the
contributors
to
the
tooling
to
understand
which
tool
reside
in
which
state
in
terms
of
various
value
parameters
and
where
to
actually
apply
the
focus
where
they
get
maximum
value.
A
A
So,
as
I
said
previously
for
each
of
the
use
case,
we
could
have
as
many
tools
as
relevant
and
from
those
perspective,
we
can
bring
in
more
real
world
stories
here,
as
well
as
the
demonstration
of
different
tools
that
solves
the
same
problem
in
different
ways.
So
that
way
that
would
enrich,
as
well
as
improve
the
consumability
of
the
documentation.
If
we
have
different
tools
telling
the
same
story
in
slightly
different
manner,.
A
A
As
we
can
see,
we
have
a
top
level
folder
for
each
of
the
identified
symptom
or
the
use
case,
whatever
we
want
to
call
it
and
under
each
such
top
level
folder,
we
will
have
a
readme
file
that
explains
the
specific
use
case
and
a
setup
instruction
that
explains
any
special
setting.
That's
required
for
your
production
box,
in
preparation
of
your
system
towards
containing
that
specific
use
case
or
the
production
anomaly,
an
investigation
flow
that
shows
how
the
case
study
will
be
carried
out
and
the
case
study
documentation
itself.
A
And
finally,
we
can
have
as
many
steps
duplicated
wherein
each
of
the
step
will
take
the
specific
use
case
through
different
tools.
So
this
will
be
on
a
best
deferred
basis.
We
can
have
a
specific
use
case
with
a
single
tool
versus
another
use
case
with
you
know:
five
or
six
different
tools
attacking
the
same
use
case
through
different
angles,
etc.
B
B
B
B
The
user
journeys
document,
as
well
as
the
best
practices
guides
and
more
reviewers,
and
since
not
everything
covered
in
user
journeys
became
best
practice
guides.
Yet
helping
with
writing
new
guides
based
on
the
user
journey
documents
is
also
a
great
place
to
start
and
if
you
operate
node.js
in
production
or
if
you
face
some
nasty
bugs
in
the
past
and
believe
there
are
gaps
in
tooling,
bring
us
real
world
stories,
so
we
can
incorporate
more
workloads
and
types
of
issues
in
user
journey
documents.