►
From YouTube: Monitor Strategy Discussion
Description
A quick discussion on the Monitor stage strategy
A
But
what's
clearer
and
clearer
to
me
or
what
I
suspect
more
and
more
is
that
the
usability
the
out-of-the-box
usability
of
datadog
is
really
really
great
like
it
just
has
default
connectors
for
everything.
Now
they
even
build
a
connector
for
like
we
will
not
take
that
as
an
insult,
but
it's
like
we're
trying
to
disrupt
them.
They're
adding
supports
for
like
getting
the
metrics
in
from
gitlab
yeah,
so
they've
they've
built
all
of
these
connectors.
So
that's
great
one
thing
that.
A
B
So
here's
another
thing
that
is
happening
in
the
industry,
so
datadog
donated
their
agents
to
open
telemetry,
so
the
open,
telemetry
agents
are
actually
based
at
least
partially
on
the
existing
data
dog
agents.
So
I
would
say
like,
as
far
as
like
having
access
to
a
large
library
of
agents
or
tracers
or
exporters.
B
B
B
They
made
us
several
acquisitions
there,
because
at
the
end
of
the
day,
it's
like
data
is
there's
a
lot
of
data,
it's
what
you
make
of
that
data
and
how
you
make
that
experience
as
out
of
the
box
and
automatic
and
less
manual.
That
makes
the
platform
particularly
useful.
I
was
just
reading
an
article
on.
A
The
vendors
are
all
making
investments
there.
I
think,
if
I
look
at
the
success
of
datadog,
it's
not
because
they
have
better
ai
or
ml,
it
is
because
it
was
easier
to
set
up
like
it
was
this
quicker
like
they
have
like,
I
don't
know
templates
or
they
they
automatically
recognize
hundreds
of
applications
and
setups,
and
it
was
easy
to
go
from
a
graph
select
a
time
frame
there
and
go
to
the
logs
and
traces
that
are
part
of
that.
B
That
could
be
so
datadog
also
had
a
has
an
inherent
advantage
on
where
they
started.
This
is
strictly
my
opinion
here,
so
they
started
with
infrastructure
monitoring,
so
they
have.
They
have
like
several
different
classes
of
agents.
So
to
monitor
your
infrastructure,
you,
actually
you
need
something
like
pretty
close
to
the
machines.
That's
running
so
they
had.
I
forget,
all
the
names,
but
they
have
a
datadog
agent.
B
That's
a
that's
written
in
go
that
runs
on
all
the
hosts
for
their
customer
and
for
application,
monitoring
and
they're,
adding
things
like
network
monitoring
and
all
other
kinds
of
things.
These
are
additional
software
that
sits
on
top
and
they
talk
to
the
foundational
data
dog
agent,
so
that
data
datadog
agent
is
something
that
other
vendors
don't
necessarily
have,
because
at
the
core
datadog
is
starting.
B
Most
people
buy
them
to
start
to
monitor
their
infrastructure.
So,
like
application
network,
everything
else
is
kind
of
a
bonus
and
they
they
use
that
same
architecture
where
the
application
tracers.
I
think
they
call
talks
to
the
datadog
agent
and
the
datadog
agent
is
then
the
thing
that's
responsible
for
talking
to
the
ultimate
cloud,
storage
and
everything
else.
A
And
I
think
I
think
we
always
underestimate
how
fast
things
move,
because
we
live
on
the
forefront.
We
see
a
lot
of
prometheus
and
everything
else.
Today.
The
datadog
agents
are
by
far
the
best
ones
and
the
whole
rest
of
the
industry.
Everyone
sees
where
this
is
going,
so
all
the
other
companies
are
like.
Oh
we're
going
to
build
like
prometheus
clients
and
hotel
collectors
and
stuff
like
that.
A
A
A
And
then
another
problem
was
like
it
didn't
90
of
our
usage
isn't
self-managed
and
it
didn't
work
out
of
the
box.
Like
people
didn't
install
the
things
datadog
people
seem
comfortable
with,
like
having
a
third
party,
run
it
great
we'll
do
the
same
thing.
We'll
only
also
only
offer
this
as
a
surface
that
we
managed,
because
it
would
be
a
way
for
us
to
get
a
connection
with
all
those
self-managed
instances
as
they
start
using
monitoring.
B
Yeah,
I
totally
agree
with
that
approach
because
I
think
so.
Actually
I
scheduled
a
meeting
with
you
two
weeks
or
friday
next
week
and
there's
a
deck
which
I'll
link
here,
I
wrote
a
lot
of
these
ideas
down
which
I'll
share
with
you.
When
you
get
a
time,
please
take
a
read.
I
totally
agree
that
people
at
the
end
of
the
day
don't
want
to
manage
prometheus.
B
B
What
I
think
gitlab
is
particularly
well
suited
for
is,
since
we
are
the
own
plan,
we
already
own
your
code
in
scm.
We
have
ci
like
giving
early
signal
on
how
well
your
things
are
working
for
the
developer.
I
think
it's
an
area
that
we
can
really
hone
in
on
and
the
pattern
that
I
like
is
you
have
you
you
get
a
snapshot
of
what
your
production
environment
looks
like,
and
then
you
run
your
same
agents
same
tracers
when
you're
testing.
B
This
presents
a
view
of
how
development
environments
look
like
relative
to
what
production
environment
looks
like
you
mean
it's
almost
like
testing,
it's
like
testing
by
using
monitoring
techniques.
I
think
that
that
plays
really
well
with
gitlab,
and
the
advantage
of
that
is.
We
don't
need
to
have
massive
amounts
of
storage
and
processing
to
to
facilitate
this
earlier
use
case.
So
I
think
it's
more
iterative,
it's
like,
if
we're
actually
successful
at
being
a
monitoring
vendor
like
a
scale.
We
need
to
operate
our
infrastructure
at
it's
like.
A
We
can
we
can
solve
that
because
it
will
people
will
pay
for
it
and
we
it's
a
great
market
to
be
in.
So
don't
be
afraid
of
that,
like
it's,
it's
a
positive
problem
to
have
that
the
growth
will
solve
all
problems.
We
can
just
hire
more
people
to
fix
it.
I
think
the
problem
is
if
nobody
uses
it,
because
that's
what
we've
had
so
far
so
don't
be
afraid
of
people
actually
using
your
stuff.
A
I
love
your
idea
of
monitoring
in
ci
and
then
cd
like
we
can
start
early
yeah,
so
auto
devops
should
instrument
every.
If
you
push
code,
it
should
instrument
it
and
it
should
measure
that
code
and
because
it's
it's
not
a
production.
App
people
will
not,
hopefully
freak
out
if
we
send
those
metrics
off
to
a
third
party,
namely
us
calm,
and
I
think
we,
the
argument
that
this
presentation,
I
love
a
lot
about
the
presentation-
that's
not
useful
to
you!
So
I'll.
Tell
you
what
I
disagree
with.
A
I
disagree
that
we
cannot
just
charge
directly
at
a
goal.
I
know
in
most
cases,
if
you
are
a
business,
you
want
to
kind
of
get
to
a
niche
or
something
like
that.
You
don't
need
to
do
that.
We
went
from.
We
went
into
version
control
when
it
was
like
when
github
was
dominant.
We
went
into
ci
when
jenkins
was
dominant.
It
is
not
a
problem.
We
can
just
do
that.
We
just
offer
more
convenience
and
a
lower
price.
A
That's
open
source,
that's
disruption,
so
we
can.
We
can
just
as
long
as
the
incumbent
is,
is
either
proprietary
or
outdated.
Like
jenkins,
we
have
an
advantage
and
we
can
use
that.
So
I
don't
want
to
distract
the
current
team.
I
love
the
focus
on
health
and
incident
management,
but
I
think
we
can
have
a
parallel
stream
where
we
just
go
for
the
monitoring
market
directly.
I
I
would.
A
B
B
B
A
A
No
workflow
will
have
the
same
work
workflow
as
datadog
go
from
metrics
to
logs,
and
I
know
that's
not
really
what
you're
saying
here
you're
saying
people
didn't
even
get
in
the
monitoring
workflow,
but
I
don't
know
I
have
some
points.
I
just
want
to
make
the
wrong
market
yeah,
so
no
kubernetes
needed.
A
B
Sorry
to
muddy
the
water
slightly
point
number
one.
The
other
thing
that's
happening
in
the
industry
is
now
everyone's
like
all
right,
instrumentation
doesn't
matter.
Everything
should
be
open,
so
new
relic.
Who
has
been
a
long
success
story
here
in
terms
of
agents.
They
also
open
source,
their
agents
so
like
there's
like
everything's
out
there
for
us
for
a
company
like
us
yeah,
and
what.
A
A
A
Far
yeah
we
aimed
too
far
we
weren't
practical
enough.
We
weren't
thinking
customer
centric
and
I
was
there
and
I
made
those
decisions.
So
I'm
not
operating
anybody,
but
we
we
shouldn't.
We
shouldn't
do
that
again.
We
should
do
stuff
that
works
today
and
I
think
the
other
insight
and
that's
a
good
insight
from
you.
A
B
B
A
I
think
the
only
thing
I'm
wondering
about
is
like
it
was
a
lot
of
work
for
us
to
make
the
graphs
and
things
like
that
in
the
gitlab
interface
and
there's
a
project
that
does
that
already
really
well
graphic
yeah,
but,
on
the
other
hand
like
we
do
need
it
in
the
gitlab
interface.
Our
premise
is
a
single
application,
and
that
includes
like
that
means
a
single
interface.
So
we
can't
do
that
is.
Is
there
like
an
ugly
way
to
kind
of
just
embed,
grafana
graphs
and
get
live.
B
Yeah,
I
was
thinking
about
it
because,
like
grifana
strategies,
they
start
at
the
they
they
want
to
control
the
users,
and
then
now
you
see
them
they're,
like
hey,
whatever
thing
you're
using
use
the
grafana
version
of
tracing
use,
the
grafina
version
of
metrics
they're,
swapping
their
the
business
model.
I
think,
is
to
swap
out
something
so
that
they
can
make
money.
They
can
start
to
monetize.
B
B
A
I
think
I
think,
like
grafana,
has
like
an
engine
to
make
graphs
and
stuff
like
that.
Can
we
just
like
copy
paste
that
code
and
have
it
run
manually
inside
gitlab?
Don't
even
embed
it,
but
like
do
something
ugly
there.
It
feels
like
we're
we're
on
the
like.
It
takes
five
years
before
you
have
all
the
options.
B
A
A
B
A
But
I
think
we've
gone
for
the
for
the
nice
solution.
Let's
use
the
really
nice
open
source
standards,
let's
make
our
own
graphs.
Instead,
we
should
go
for
the
ugly
hacky
thing,
let's
copy
datadogs
thing
and
change
some
code,
so
it
sends
graphs
to
us.
Let's
take
the
graphana
code
and
make
some
changes
so
that
it
renders
and
github.