►
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Making Prometheus even more open - Richard Hartmann, Grafana Labs
We are actively working to make the Prometheus community even more open and even more welcoming. We want to give an overview of where we're at with this.
A
A
Yet,
just
as
a
reminder,
there's
more
and
more
players
entering
this
field
and
keep
in
mind
that
part
of
what
makes
prometheus
open
is
that
it
is
open
source
and
if
you
go
with
other
vendors,
who
might
not
be
open
source
at
least
consider
what
you're
doing
so
open
features
that
will
be
the
the
longest
part
of
this
talk.
A
A
We
lifted
our
services
covering
moratorium,
where
we
had
a
total
of
six
new
service
discoveries
added
recently
or
over
the
last
half
year,
or
so
we
added
tls
and
basic
off
to
all
the
things,
and
you
also
have
a
new
exporter
toolkit,
which
makes
it
a
lot
easier
to
create
and
synchronize
go
exporters.
What
do
I
mean
by
synchronize?
A
Well,
if
some
new
functionality
comes
in,
then
it's
a
lot
easier.
If
you
have
all
of
this-
and
you
just
render
it
in
as
opposed
to
having
to
do
this
yourself
or
someone
going
to
your
repo
following
an
issue
finding
a
pr
hey,
please
do
this
and
death
because
that's
the
new
thing,
if
you
base
your
stuff
or
migrate
your
stuff
on
the
exported
toolkit,
you
just
get
all
of
this.
For
free.
A
We
had
a
few
changes
in
prankyo.
We
have
things
like
last
overtime,
top
k
over
time
like
if
you're,
not
a
thing
where
you
say
top
k3
of
whatever.
Over
a
week,
you
might
get
10
20
100
different
values
which
are
at
some
point
in
time,
part
of
the
top
three
top
k3
over
time.
That's
what
it
means
or
if
it
does
what
it
says
on
the
lid
you
just
get
the
actual
top
three
over
that
time
range.
A
We
have
the
add
modifier,
where
you
can
determine
at
what
specific
time
and
what
alignment
you
would
like
to
have
your
queries
to
have
we
have
negative
offset
which
are
hidden
behind
the
feature
flag,
for
the
simple
reason
that
this
might
break
a
few
assumption
of
caching
front
ends,
and
we
obviously
don't
want
to
break
them.
So
it's
at
least
for
this
version
for
this
major
version
behind
the
feature
flag.
A
Yet
super
nice
super
useful,
try
it
out
and
also
we
have
human
durations
which
might
not
seem
like
a
huge
thing,
and
but
still
it's
it's
super
nice.
You
don't
have
to
write
this
90m
or
anything.
You
don't
have
to
write
90
times
60
or
do
the
math
in
your
head.
You
can
just
write
it
as
such
and
and
it
just
works.
A
This
is
not
meant
for,
like
super
high
volume,
production
or
anything,
but
still
it
enables
new
use
cases
like
prometheus
in
the
edge
or
something
I
forgot
to
write
that
in,
but
still
it
enables
new
use
cases
because
you
can
just
send
stuff
from
one
produces
to
another
without
having
to
go
to
any
long-term
storage
or
such
one
of
the
highlight
features
is
exemplars,
it
might
sound
small,
but
it
is
actually
quite
large
here.
At
the
end,
you
see
this
trace
id
blah
blah
blah
with
a
certain
value.
A
A
So
if
you
want
to
go
to
a
trace
for
low
latency
or
whatever,
you
can
jump
directly
to
a
trace
where
you
know
what
the
mental
context
is,
why
it
is
bad,
why
it
has
you
know
it
has
high
latency
or
it
had
this
and
that
amount
of
of
http
requests.
So
what
have
you
doesn't
matter,
but
you
can
jump
directly
to
this
to
this
trace,
and
you
know
precisely
that
this
is
interesting
for
a
reason.
A
You
have
the
complete
context
of
all
your
labels
and
everything,
and
you
can
just
move
seamlessly
between
between
metrics
and
traces
support,
for
this
is
already
in
prometheus,
cortex,
thanos
and
grafana,
so
you
can
just
use
it
and
it's
just
there
if
the
trace
id
is
somewhat
familiar
or
that
format.
That's
no
mistake,
of
course,
in
the
openmetrics
format
we
specified
or
we
used
the
w3
tracing
specs
as
an
example.
We
didn't
specify
them.
A
Of
course
we
didn't
want
to
tie
the
standard
down,
of
course,
that
space
is
relatively
new,
so
maybe
things
will
change.
Maybe
there
will
be
some
other
best
practices
or
something.
That
being
said,
it
is
a
good
standard.
What
what
w3
has
and
it's
it's
useful
and
that's
precisely
what
we
what
we
need,
so
obviously
we
we
use
it
as
as
the
example
in
in
the
specs
there's
also
support
for
spends,
but
that
fit
in
in
the
line
look
yeah,
you
can
have
spans
and
traces
kind
of
obvious.
A
We
have
a
new
ui
where
you
you
now
have
modern
react.
If
you
want
that,
there
is
a
super
nice
editor
which
has
auto
completion
and
snippets
and
all
bells
and
whistles,
and
it's
really
really
nice
and
you
really
should
check
it
and
it
has
a
dark
theme
for
vanity
reasons,
but
it
has
a
dark
theme.
So
try
it
out.
A
All
of
this
maybe
tells
you
a
little
bit
that
as
historically,
we
were
quite
conservative
with
with
things
we
are
deliberately
trying
to
change
this
and
that's
what
we
mean
by
by
this
aspect
of
open,
because
historically,
even
even
features
which
were
marked
as
experimental.
We
basically
treated
them
as
stable,
which
is,
on
the
one
hand,
quite
nice
for
for
someone
relying
on
this
behavior.
A
On
the
other
hand,
it
ties
us-
and
it
ties
the
community
down
and
that's
not
good
long
term.
So
we
are
actively
breaking
this
up.
A
lot
of
our
old
assumptions
have
been
revisited
and
we
are
enabling
more
use.
Cases
like
an
old
assumption
would
be.
We
had
that
moratorium
and
service
discovery
and
we
had
certain
certain
thoughts
around
what
we
would
need
to
to
see
or
want
to
see
before
we
take
more
service
recovery
integrations
in,
but
we
just
dropped
them
and
started
taking
those
use
cases
more
use
cases.
A
There
are
with
the
aging
thing,
for
example,
there
are
use
cases
which
are
not
recommended
by
permissions
clean
and
simple
like
for
me.
This
best
practice.
You
should
have
your
metrics
endpoint
on
a
distinct
port
per
service
that
doesn't
really
match
how
a
lot
of
enterprises
work
with
their
stuff.
Of
course,
their
security
teams
tend
to
not
like
a
team.
A
Coming
to
him
was
like
yeah,
okay,
we
might
have
30
different
ports,
maybe
100
different
ports,
they're
not
even
truly
continuous
and
they
might
be
open
or
they
might
not,
and
there's
no
way
for
you
to
tell
they
tend
not
to
like
this.
Having
everything
behind
one
single
port
makes
a
lot
easier
in
enterprise
scenarios
and
such,
but
this
is
an
anti-pattern
when
it
comes
to
pure
prometheus.
Yet
it
is
a
valid
use
case
for
for
certain
assumptions
for
certain
design
tradeoffs.
A
I
would
much
rather
talk
about
how
you
can
structure
this,
how
you
can
put
everything
behind
one
port,
and
then
you
have
your
your
sub
string
or
your
path.
There
you
say:
snmp
exporter,
slash
metrics,
or
what
have
you,
then
everyone
baking
their
own
and
and
people
basically
yeah,
not
knowing
what
what
they
should
be
doing
as
a
kind
of
standard,
so
opening
up
to
those
non-recommended
use
cases
is,
is
a
deliberate
goal.
A
Agents
are
another
great
example:
agents
themselves,
because
agents
are
an
anti-pattern
in
the
prometheus
word
like
again,
pure
prometheus,
yet
and
for
good
reason,
because
you
wouldn't
want
to
you-
wouldn't
want
to
tie
your
your
node
exporter
to
your
mysql
exporter
version.
Of
course
you
might
need
to
upgrade
one
or
the
other
independently
of
the
other,
yet
deploying
one
single
binary,
ideally
already
with
package
configuration.
Everything
is
a
plus
four
for
that
kind
of
model.
A
We
are
also
trying
to
make
our
code
more
modular
and
easy
to
reuse,
which
is
honestly
not
a
direct
benefit
to
us
like
not
for
prometheus
team.
Yet
there
are
projects
which
which
would
like
to
take
bits
and
pieces
and
just
reuse
them,
make
them
part
of
their
data
pipelines.
Or
what
have
you
so
we're
trying
to
make
this
easier
and
and
more
more
consistent?
A
Also,
that's
related
to
the
exporter,
toolkits
or
exported
toolkit
mixins
out
of
the
box,
ideally
where
we
want
to
have
the
whole
scaffold
and
everything
in
the
exporter
toolkit
to
just
entice
people
to
to
create
more
and
more
mixins
and
also
have
more
and
more
mixins
as
part
of
at
least
the
default
and
official
exporters,
and
and
encourage
others
to
also
put
this
in
their
exporters
and
their
integrations.
What
are
mixins
you
might
be
asking.
I
should
have
explained
this.
A
Mixins
are
basically
a
pack
a
way
to
package
configuration,
so
you
might
have
certain
dashboards,
you
might
have
alerts,
you
might
have
recording
rules
and
you
just
package
them
as
an
opinionated
thing
which
can
be
modified.
So
it's
it's
not
a
lock
in
into
one
specific
way
of
thinking.
A
You
can
actually
modify
this,
yet
you
get
a
saying
default,
something
which
should
work
and
which
you
can
base
upon,
which
hopefully
has
a
lot
of
synchronization
effort
effects
through
the
ecosystem,
where
people
start
thinking
with
the
same
terminology,
maybe
or
the
same
dashboards
or
they
have
similar
alerts.
A
They
have
thresholds
which
are
already
preset
by
the
domain
so
subject
matter,
expert
of
whatever
program,
you're
running
just
make
it
easier
to
to
to
push
this
kind
of
information
into
the
ecosystem
and
reuse.
This
another
interpretation
of
open
would
be
open
documents
and
we
have
all
our
design
documents
open.
A
That
is
kind
of
a
logical
evolution
of
the
mailing
list
discussions
and
by
and
large,
we
already
had
our
design,
docs
public.
Of
course,
why
not?
Now
we
are
deliberately
making
an
effort
to
to
make
all
of
them
public
and
actually
like
follow
up.
If
someone
forgets
to
do
it
and
such
that
it
is
not
by
accident
internally
prometheus
team
that
we
just
have
everything
out
in
the
open.
A
We
have
a
special
drive
on
google,
where
we
can
have
a
public
share
for
for
the
complete
folder
and
all
of
those
design
looks
live
in
there,
so
you
can
quite
easily
find
them
and
such
which
again
is
just
a
logical
evolution.
Yet
it
is
part
of
this
aggressively
becoming
more
open.
A
Another
interpretation
of
open
would
be
open
standards
and
there
are
a
few
we
have
openmetrics,
which
is
the
standard
of
how
to
how
to
export
or
expose
metrics
towards
an
ingester,
and
we
have
a
specification
for
remote
right,
which
is
how
you
push
the
data
from
your
permission,
server
to
something
else
or
from
your
agent
to
your
long
term
or
what
have
you?
Those
two
have
been
specified:
they're
finalized.
We
are
considering
doing
the
same
for
promptq
and
gtsdb.
A
We'll
see
next
aspect
is
open
testing,
of
course,
with.
I
think
it
was
oscar
wilde
who
said
that
imitation
is
the
sincerest
form
of
flattery,
and
this
is
quite
true.
If
you
look
at
the
cncf-endorser
survey
on
observability
prometheus
is
on
place.
A
One
open
matrix
is
someplace
five
five,
so
you
can
see
that
there
is
bound
to
be
a
lot
of
people
who
want
a
piece
of
the
cake
or
just
want
to
be
compatible
for
the
user's
sake
where
they
just
want
to
to
work
and
interact,
while
a
few
of
them
have
just
taken
reference
code
and
such
and
just
re-implemented
or
even
just
vendored
in
our
code.
That
is
not
the
case
for
everyone,
and
we
want
to
make
this
more
more
yeah
easier
for
people
to
actually
do.
A
We
already
have
three
test:
suites
or
compliance
suites
released,
one
for
prom
kill
one
for
road
right
and
one
for
openmetrics.
There
is
work
being
done
towards
maybe
it's
already
released
by
the
time.
This
video
is
out
a
remote
read
compliance,
and
we
are
also
considering
to
do
stuff
around
tsb
and
data
correctness,
and
maybe
we
also
have
some
baseline
performance
like
not
super
aggressive
performance,
but
just
some
same
baseline
to
to
give
you
some
reasonable
expectation
of
how
how
that
thing
will
perform.
A
Then
we
have
the
next
interpretation
of
open
that
would
be
open
ratings
and
that
is
kind
of
fuzzy.
That
term
I
I
know
that
it
fit
into
the
open
thing,
so
I
yeah
that's
a
big
one.
A
We
will
have
official
compatibility
testing
for
prometheus
and
this
will
be
backed
by
cncf,
legal
and
such
so
this
will
actually
be
watertight.
Hopefully
we
will
officially
bless
and
publish
those
results
on
promises.
Io,
we
will
most
likely
have
version
results
where
you
can
say
that
you're
complying
to
probably
l
as
of
april
2021
or
what
have
you.
A
We
might
also
have
an
umbrella
above
this
which,
which
states
that
you're
fully
prometheus
compatible
or
something
to
to
basically
discern
between
someone
who
or
a
project
which
wants
to
be
compliant
to
one
aspect
of
of
prometheus
and
something
which
can
be
in
its
entirety
in
its
how
it's
supposed
to
be
used
fully
compatible
with
with
a
prometheus
system
yeah,
but
that's
still
kind
of
tbd.
A
A
A
On
the
other
hand,
we
don't
want
someone
to
sit
on
this
for,
like
three
years
and
and
their
users
are
running
into
walls
left
and
right,
having
done
quite
a
bit
of
of
certification
work
and
such
in
my
past.
That
is
a
big
problem
where,
if
you
have,
if
you
have
certifications
or
stamps
of
approval
of
whatever
you
which
are
too
long
running
the
end,
users
might
actually
suffer
from
this.
A
A
Then
we
have
the
next
interpretation
open
meetings
and
basically,
all
our
things,
deaf
summits,
all
the
working
groups
and
such
is
all
out
in
the
open.
It's
all
public.
It's
recorded,
it's
free
to
join,
we
have
a
calendar
and
we'll
be
linking
those
slides
and
all
of
those
are
clickable.
So
you
can
just
you,
can
just
click
on
them
and
join.
A
We
publish
this
on
youtube.
We
kind
of
realized
with
with
the
whole
pandemic
thing
previously.
We
had
one
deaf
summit
per
year
and
that
was
physical
and
we
have
always
invited
people
and
such
to
to
not
be
just
amongst
ourselves,
but
obviously
it
doesn't
scale
to
have.
I
don't
know
how
many
people
and
how
dynamic
in
in
a
room
when,
when
you
need
to
actually
fly
to
a
place
and
such
we
started
having
virtual
dev
summits
for
pandemic
reasons,
and
then
we
kind
of
forgot.
A
I
guess
that
we
could
just
make
them
open,
so
we
realized
and
we
did
and
again
everything
is
just
open.
Of
course,
why?
Not?
It's
only
internet,
it's
trivial
to
do
this,
so
that's
it.
We
should
have
like
five
minutes
potentially
for
questions,
which
is
great,
and
I
hope
you
do
have
a
few
questions.
Thank
you
very
much.