►
From YouTube: Grafana Community Call 2021-10-21
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Right,
I
guess
that's
my
cues
to
start
speaking
okay,
so
we
have
more
people
coming
and
joining
they're.
Just
we
just
had
in
all
hands,
so
some
people
are
struggling
or
whatever
so
but
hi.
My
name
is
jessica.
I
am
the
engineering
manager
for
the
team
that
will
be
doing
the
community
call
today.
It's
quite
a
massive
team
at
this
point,
so
we
do
quite
a
lot
of
things
mostly
within
the
back
end
realm.
A
So
we
have
engineers
working
on
everything
from
the
api
obstructing
things
with
the
schema,
all
sorts
of
things,
all
the
way
over
to
release
engineering
to
yeah.
We
tried
to
narrow
it
down
a
little
bit
because
I'm
and
removed
plugins,
because
I
think
they
just
had
a
community
call
over
the
summer,
so
yeah
that's
just
a
little
bit
about
what
we're
doing
and
that's
a
little
introduction
from
me.
B
So
so
just
curious:
what
in
in
general,
what
are
you?
What
kind
of
stuff
are
you
working
on
in
general?
You
know
back
and
stuff
of
course,
but
what
does
that
mean
in
the.
A
C
You
I
could
give
a
very
simple
top
level
answer
to
that,
so
I'm
malcolm
so
I
I
joined
jessica's
team
in
august,
although
I've
been
with
the
company
for
a
number
of
years,
so.
D
C
What
I
think
the
way
to
see
it
is
that
for
a
long
time,
the
role
of
the
the
back
end
is
sort
of
to
serve
the
front
end,
so
it's
almost
playing
somewhat
second
fiddle.
Whatever
the
front
end
needs
will
do
it.
What
that,
what
that
ends
up
with
is
is
something
that's
that's
powerful,
but
not
necessarily
as
well
organized
as
it
could
be.
C
So
what
we're
looking
at
is.
Actually,
I
guess
you
could
sort
of
say
if
we
were
to
build
this,
how
would
we
architect
it?
How
what's
the
right
way
for
this
to
be?
You
know
what
how
do
we
want
it
to
to
have
in
terms
of
the
objects
that
it
manages?
Obviously,
it's
the
thing
grafana
gives
you
this
wonderful
user
interface
that
allows
you
to
edit
things,
but
they
need
to
be
persistent
and
it's
the
back
end's
job
to
persist
them.
So
how
do
they
get
persisted
in
the
most
efficient
way?
C
B
So
what
is
you
know
the
team
working
on
right
now?
I
imagine
that
there's
tons
of
feature,
requests
and
and
tons
of
stuff
and
stuff
that
we
want
to
be
doing.
Is
there
anything
that
you're
excited
about
right
now?
What
is
on
the
on
the?
What
are
you
working
on
right
now
and
what
is
kind
of
in
the
in
the
near-term
road
map.
C
C
We
spend
time
going
through
the
steps
to
make
the
release
so
we're
going
to
be
looking
at
those
two.
We
are
already
looking
at
those
two
things
and
looking
for
ways
we
can
make
developers
lives
easier
so
that
they
can
spend
more
time
adding
cool
features
to
grafana
and
less
time
waiting
for
builds.
C
That's
one,
that's
one
thing
yeah,
the
the
other
thing
is
is
sort
of.
I
I
think,
there's
a
lot.
There's
lots
of
things
we
could
say,
but
there's
also
looking
at
in
terms
of
adding
schema
to
to
grafana,
so
that
the
objects
that
we
store
can
be
validated
and
we
can
know
what
their
correct
form
is,
and
I
suspect
sam
might
feel
like
saying
something
more
about
that.
F
Been
I
apologize,
my
voice,
I
am
sick.
My
whole
house
is
sick.
We
have
been
working
on
schematization
of
pravana
for
months
now
and
we've
you
know
developed
our
own
schema
system,
for
it.
F
And
make
conceptual
progress?
It's
a
complex
topic,
because
grafana
dashboards
are
complex
objects
that
are
constituted
by
you
know
a
lot
of
plugins,
which
means
you
can't
just
write
a
single
schema.
You
have
to
have
a
composite
schema
in
order
to
be
able
to
actually
adequately
cover
them.
So
there's
been
a
lot
of
pieces
happening
kind
of
in
the
background.
Certainly
we
talked
about
at
grafanacon
in
june,
what
we're
aiming
for
with
eight
three
there's
a
road
map
issue
out
there.
F
I
can
provide
a
link,
if
need
be,
there's
a
road
map
that
describes
what
we're
aiming
for
in
a3,
which
is
essentially
sort
of
more
documentation
and
more
clearer
public-facing
communication,
as
well
as
progress
in
a
number
of
areas.
I
feel
like
it's
out
of
scope
to
go
too
much
into
the
details
of
what
those
areas
are,
but
essentially,
where
the
project
is
at
is
we
have
functioning
schema?
F
We
they're
sloppy
in
a
number
of
ways:
they're
not
where
we
want
them
to
eventually
be,
but
the
foundations
of
the
system
are
in
place
so,
like
an
adventurous,
third-party
user
could
start
actually
doing
things
with
our
could
realistically
start
doing
things
with
our
schema
com,
a3
and
there
will
be
at
least
sort
of
some
guarantees
in
place,
but
we're
looking
more
at
grafana
9
for
sort
of
really
really
hitting
the
scheme
of
goals
like
getting
to
the
point
where
I
mean
we'll
really
know
that
we've
arrived
when
the
front
end
app
is
no
longer
responsible
for
like
taking
a
grafana
dashboard
and
translating
it
into
like
what
a
new
organic
version
expects.
F
F
So,
like
those
really
firm,
clear
guarantees
are
not
gonna
be
around
until
nine,
but
the
the
basics
of
the
system
and
folks
who
are
adventurous
and
already
doing
things
like
you
know,
using
grafana
will
probably
be
able
to
start
using
pieces
of
the
new
system
around
h3
and
perhaps
most
importantly,
we're
going
to
be.
You
know,
have
clear
sort
of
points
for
for
receiving
feedback
and
and
doing
back
and
forth
communication
around
what
people's
needs
are
with
us.
C
F
Yeah
yeah
I
mean
there
are
what
is
the
point
of
schematization?
We
wanna?
We
wanna
make
a
strong
foundation
to
build
on
right,
like
at
the
end
of
the
day.
Anyone
who
has
worked
with
any
one
of
the
grifano
libraries
that
or
one
of
the
like
the
third
party
levers
or
the
ones
that
we
support
for
generating
dashboards
from
code
working
with
grafana
from
code
knows
that
it
is
a
process
that
mostly
works
asterisk
asterisk
fuzz
fuzz
all
over
the
place,
and
we
would
like
to
not
be
in
that
world.
F
We
would
like
to
build
reliable
tools.
We
think
that
is
a
very
important
part
of
any
cloud
native
ecosystem
and,
and
you
know,
most
sort
of
observability
ecosystems
going
forward,
but
we
fall
down
when
it
comes
to
being
able
to
really
hook
in
to
the
get
ups
as
code
type
workflows
that
are
essential
to
doing
you
know
modern
software
development,
so
the
schematization
work
we
think,
will
not
just
provide
a
good
foundation
but
provide
a
provided
foundation
that
that
is
of
such
quality.
It
has
not
been
seen
before.
F
Dare
I
say
you
know
we
like,
I
said
we
have
created
the
new
schema
system,
it's
it's
written
in
queue
and
we
have
we
have.
We
have
a
bunch
of
things
spinning
here,
because
we
think
there's
a
lot
more,
that
we
could
do
with
as
code,
but
you
need
to
be
more
rigorous
and
clear
about
housekeeping
get
defined
for
it
to
work.
Well,
so
we're
doing
the
light
work.
B
B
Is
it
you
know
like
a
type
language,
for
example,
rather
than
say
something
like
python,
where
you
can
get
really
anything,
and
this
is
being
able
to
make
assertions
and
once
we
were
able
to
do
that
like
what
is
something
that
you'd
be
excited
to
see
the
community
doing
with
this
rather
than
you
know,
I
understand
that
you
know
with
dashboard,
says
code
being
able
to,
you
know,
do
githubs,
but
are
there
any
like
tools
and-
and
you
know
things
that
you
think
that
might
come
out
of
this-
that
is
not
necessarily
just
purely
grafana
centric.
F
Oh
yeah,
I
mean
already,
there
are
like
I,
I
gave
the
schema
framework
that
that
we
created
for
this
is
called
schemata.
I
literally
just
made
a
repository
for
it
like
two
hours
ago.
It's
been
inside
of
grafana,
but
it's
gonna
be
its
own
public
project.
Hopefully
that
will
gain
wider
adoption
to
be
clear.
F
It's
a
shell
repository
because
I
haven't
put
the
files
in
it
yet
because
I
needed
to
basically
I
opened
it
because
right
now,
there's
also
a
cue
town
hall
happening
and
I
needed
to
put
up
like
a
road
map
alignment
thing
with
them,
but
there's
that
we
also
have
the
the
poly
package
project
out
there,
which
is
supposed
to
be
a
successor
to
mix-ins
a
way
of
packaging
together
your
durability,
resources
that
is
much
more
tight
and
convenient
and
clear,
then
exists
today
and
crucially,
one
that
you
know
we
hope
to
be
able
to
actually
drive
from
the
ui
instead
of
having
a
lot
of
awkward
like
export
this
from
from
from
grafana
and
then
write
it
back
to
disk
and
then
like
have
a
pull
request
around
it.
F
One
of
the
things
that
we
get
with
this
cubase
system
is,
since
we
can
actually
like
validate
the
correctness
of
the
stuff.
That's
on
disk,
instead
of
just
you
know,
run
on
hopium
like
we
do
with
jsonna
we're
able
to
make
much
more
reliable,
automated
systems
out
of
it
at
sort
of
every
stage,
a
thing
that
I
think
will
be
able
to
start.
F
You
know,
probably
will
roll
in
prometheus
alerts
and
rules
so
like
expressing
policy
over
the
way
that,
like
properties,
that
dashboards
are
supposed
to
have
relatively,
but
all
things
like
coloration,
although
those
still
matter,
but
also
doing
things
like
linting
over
your
queries
and
making
sure
that
certain
properties
are
present
and
ensuring
uniformity
over
the
way
that,
like
certain
dashboards,
are
supposed
to
look
so
that
you
know
your
entire
organization
knows
that,
like
this
dashboard
looks
the
way
that
it's-
or
this
is
a
certain
class
of
dashboards.
F
Like
an
slo
dashboard
or
something-
and
this
is
the
way
that
they're
supposed
to
be
laid
out-
you
can
express
that
as
a
policy.
These
are
the
kinds
of
things
that
become
possible
when
we
have
a
effectively
a
type
language
for
for
talking
about
what
what
dashboards
are,
and
it's
it's
not
really
feasible
today
and
to
be
clear
part
of
the
reason
that
this
takes
a
while
now
this
is
difficult.
F
Is
that
the
only
way
to
really
make
this
work
is
if
the
system
that
we
use
to
schematize
grafana,
the
these
objects
is
the
same
one
that
the
grafana
front
end
uses.
It
is
about
joining
the
ends
like
you
can't
have
a
secondary
system
over
here,
that's
sort
of
trying
to
hope
and
and
reverse
engineer,
the
way,
the
dashboards
work
and
actually
have
a
reliable
system.
There
has
to
be
one
canonical
statement
of
what
the
form
of
a
persistent
dashboard
is
supposed
to
look.
D
F
In
order
to
have
both
all
of
our
supporting
systems,
our
policy
expressions
our
get
up
stuff
like
all
fold
together
nicely
and
have
it
all
cooperate
nicely
with
the
grafana
front
end
where
all
this
stuff,
actually,
you
know,
does
things
so.
G
C
So
to
answer
the
the
question
of
what
can
the
community
do
as
as
the
as
more
and
more
of
this,
this
is
gets
into
place
as
these
abstractions
get
into
place.
We
can
you
can
as
it
were,
so
we
can
start
to
move
up
the
abstraction
tree.
C
We
can
make
thing
more
substantial
things
with
less
effort
and
what
would
be
great
is
to
see
more
and
more
people
using
these
tools
to
to
you
know,
when
I
write
a
piece
of
software,
I
publish
a
zip
file
that
contains
the
binary
of
that
software
or,
if
I
published
a
package
that
says
this
is
how
you
observe
this
software,
and
that
happens,
and
as
a
standard
piece
of
more
and
more
of
that,
those
are
made.
The
better.
F
Yeah
that
right,
there
is
basically
the
goal
of
poly
packages
that
the
malcolm
just
described
is
the
idea
that,
when
you
ship
software,
you
should
ship
the
tools
to
observe
it
along
with,
and
if
you
start
with
that,
as
an
assertion
about
the
way
that
the
world
should
be
and
you
work
backwards
to
like
what
are
the
necessary
conditions
in
order
to
make
that
a
reasonable
ask
for
people
who
are
actually
writing
software
and
not
like
observe
the
juniors
to
do
that.
That's
sort
of
how
we've
gotten
back
to
this
point.
F
If,
if
I'm,
not
somebody
who
you
know,
thinks
about
observability
for
my
day
job,
I'm
not
going
to
be
spending
time,
fighting
json
up
and
down
to
like
force
it
into
the
right
shape.
I
need
a
really
reliable
underlying
foundation
that
I'm
expressing
the
dashboard
objects,
the
the
alerts,
the
rules
that
I'm
packaging
them
up
into.
That's
validatable
that
I
can
not
think
about
because
it's
so
reliable.
We
built
automation
on
top
of
it.
F
That's
like
the
world
that
we're
going
towards
and
that
all
seems
totally
prerequisite
to
being
able
to
make
participation
in
the
collective
effort
of
trying
to
observe
your
entire
system.
It's
it's
necessary
because.
F
Yeah
10-15
years
ago,
like
testing
wasn't
really
a
thing
yet,
and
it
really
has
become
this
standard
part
of
the
software
developers
toolkit.
You
know
it
you're,
not
you're,
not
shipping
serious
offer
if
you're
not
writing
tests
for
it,
and
I
think
that
it's
feasible
to
get
to
a
world
where
people
have
the
same
sort
of
organic
expectations
of
doing
observability
work.
F
But
we
have
to
have
the
tools
in
place
to
remove
the
friction
so
that
they
can
spend
their
time.
Thinking
about
the
thing
they're
trying
to
observe
and
exactly
what
matters
about
it
and
absolutely
nothing
else
in
between
like
you've
got
your
application.
You've
got
your
observability
bits
and
you
are
not
thinking
about
all
the
garbage.
That's
in
between
that
you
have
to
do
in
order
to
like
package
up
and
distribute
that
to
all
the
people
who
might
be
consuming
it.
B
So
I'm
curious,
then,
because
we
we
have
the
the
dashboards
page
on
graffana.com
right
where
you
can
today
you
can
you
know
it's
or
you
can
you
can
go
there,
you
can
search
for
a
promethean,
I
wanna,
I
wanna,
monitor
prometheus
or
itself
or
I
want
to.
You
know,
monitor
something
and
I
just
go
there.
I
search
for
it.
I
found
I
find
you
know
a
really
nice
dashboard
and
I
install
it
and
it
seems
to
work
so
this
sounds
like
it
could
use
some
improvements
on
this.
B
How
would
that
you
know?
Would
you
instead
of
dashboards?
Would
you
would
you
see
like
a
app
store
for
these
observability
packages
instead
of
the
dashboards
that
we
have
today.
F
Are
they
going
to
be
amazing?
Yes,
and
you
know,
we've
talked
about
things
like
that
internally,
I
would
say
we
don't
even
really
need
to
limit
it
to
observability
per
se,
because
there's
lots
of
kinds
of
data
that
you
can
consume
through.
The
final
there's
no
reason
to
say
that
such
a
data
product
needs
to
be
just
an
observability
product,
but
yes
like,
I
think
that
that
there's
a
totally
valuable
future
data,
apps
yeah,
there's
a
totally
foreseeable
future
in
which
you
ship
up
a
package
of
different
bits
configuration
that
are
essentially.
F
This
is
how
you
know
you.
You
do
a
certain
data
task
and
there's
a
bunch
of
things
between
here
and
there
to
be
able
to
make
that
work.
Well,
but
you
know
we're
taking
the
long
view
on
this
one
and
saying
that
we
think
that
it
is.
It
is
fundamentally
valuable
to
be
able
to
do
something
like
that,
and
but
to
do
it
we
need
those
sufficiently
reliable
foundations
that
that
you
can
do.
F
F
Here's
the
dashboard
stage
alerts,
here's
the
the
rules,
here's
the
the
giant
piles
of
other
config
that
I
can
imagine
being
relevant
bundle
them
together,
and
then
you
know,
given
that
you
have
equipped
your
grafana
instance
with
the
appropriate
credentials
to
talk
to
the
grafana
marketplace,
hit
a
button
that
that
publishes
your
you
know
the
latest
data
package-
and
you
know
this
is
I
I
don't
know
how
feasible
that
is,
I'm
not
like
promising
or
putting
a
timeline
on
it
or
anything
like
that,
but
north
star
wise.
F
I
think
that
is
a
absolutely
is
absolutely
the
right
goal
to
be
to
be
focused
on
realistically
there's
little
difference
between
doing
that
for
like
oss
publishing,
and
there
is
for
doing
that
for
like
publishing
a
data
app
inside
your
company.
That's
going
to
be,
you
know,
consumed
in
a
similar
kind
of
way,
we're
just
we're
doing
packaging
again
there
at
that
point.
So
you
know
you've
got
private
private,
repels
and
public
repos
and
we
can
run
a
public
one
and
you
can
run
a
private
one
internally
at
your
capital.
C
But
just
just
to
play
slight
div
devil's
advocate
marx
is
already
saying
that
we
have
a
place
where
you
can
go
download
dashboards.
Isn't
that
enough.
F
C
F
I
mean
dashboards
are
I'd,
say
this
right
like?
Can
you
tell
me
what
the
the
what
the
criteria
are
that
establish
a
dashboard
as
well?
I
won't
even
say
ideal
I'll,
just
say
good.
F
F
So
if
we
want
to
really
do
this
well,
then
part
of
it
is.
We
need
supplementary
pieces
in
order
to
actually
make
like
what
you're
consuming
understandable.
F
Another
part
of
it
is
indeed
dashboards
are
not
sufficient
for
doing
all
of
the
things
like
you
also
need
to
in
the
observability
case,
do
things
like
rules
and
alerts,
yeah.
F
B
Yeah,
I
I
think
you
know
that
when
talking
about
criteria
I
mean
I
I'm
very
personally
very
excited
about
what
kind
of
criteria
that
will
evolve
once
we
make
this
available,
you
know,
can
we
can
we
provide,
like
you,
know,
good
color
schemes
for
it
that
are
accessible?
That
are,
you
know,
use
these
color
schemes
to
get.
B
You
know,
create
a
great
dashboard,
make
sure
that
you're
consistent
throughout
your
whole
or
microphone
installation,
no
matter
if
you
have
500
dashboards
in
it,
you
you're
using
colors
you're
using
graphs
and
everything
in
a
consistent
way.
I
think
that's
personally
what
I'm
super
excited
about.
Just
that
consistency
and
letting
good
practices
evolve
and
be.
You
know,
codified.
B
I
think
it's
personally
something
that
I'm
very
excited
to
see
what
the
community
might
come
up
with.
B
Except
you
know,
get
offs
and,
and
schemas
malcolm
you
mentioned
a
new
release.
Engineering
team.
Is
there
anything
else
you
can
share
with
the
audience.
G
So
I
think
I
could
give
a
brief
follow-up
on
the
schematization
and
code
generation
that
you
can
derive
from
there.
So,
by
the
way,
I'm
search,
I'm
part
of
the
backend
team
and
primarily
focused
on
the
api
part
of
it,
and
when
we
speak
about
api,
the
first
reaction
of
the
users
is:
don't
you
dare
to
change
it?
Don't
you
dare
retouching,
because
my
property
bash
scripts
depend
on
it
and
you'd
rather
not
break
it.
G
G
The
short
answer
is
to
boost
the
reliability
of
the
grafana
back
end
to
remove
all
the
dark
magic
that
has
been
there
for
some
years
to
boost
to
their
performance.
So
we
are
trying
to
optimize
your
cloud
bills
and
yeah
to
leverage
everything
that
schematization
code
generation
static
code.
Analysis
lending
would
would
give
us.
D
G
Grafana
has
been
based
on
the
macron
framework,
which
is
a
really
good
solution.
If
you
want
to
kick
off
something
quickly,
if
you
want
to
bootstrap
quickly,
because
it
does
not
force
you
to
think
about
the
type
safety
or
write
lots
of
code,
you
can
connect
together
the
basic
parts
and
it
will
do
the
rest.
But
as
your
code
base
grows,
it
becomes
harder
and
harder
to
actually
detect
errors,
find
bugs,
and
it
might
cause
even
certain
vulnerable
therapies
related
to
that.
G
G
Of
course,
to
the
the
foundation
of
the
griffin
api
is
now
the
go
standard
library
and
not
a
third-party
framework.
Additionally,
we
also
want
to
move
towards
these
standardization
as
much
as
possible.
We
are
removing
the
remains
of
the
custom
testing
framework
and
rely
on
the
standard
library,
testing
and
standardization
does
not
mean
that
we
use
go
standard
library
everywhere.
We
use
the
best
practices
everywhere.
G
Specifically,
if
we
talk
about
the
instrumentation
of
the
apis
that
we
have,
we
have
been
using
logger
the
third
party
logger
for
a
while,
which
again
turned
out
to
be
a
rather
slow-ish
and,
and
it
has
been
used
in
reflect
and
to
dynamic
interfaces
everywhere.
We
are
switching
that
to
gokit
logger,
which
is
proven
to
be
quite
fast
according
to
our
benchmarks
and
proven
to
be
more
type
safe.
Comparing
to
what
we
have
now
and
last
but
not
least,
we
are
switching
our
tracing
tooling.
G
We
have
been
using
opentracing
before
we
now
use
open
telemetry,
which
is
a
more
up-to-date
api
that
is
used
in
that
is
supposed
to
be
the
future
replacement
of
the
open
tracing.
So
all
these
larger
factories
are
ongoing
right
now,
please
keep
your
eye
on.
What's
going
on
and
yeah,
I'm
looking
for
the
feedback
on
that.
B
C
C
B
So
I'm
curious
about
you
mentioned
open
telemetry
right
how
you
know
what
will
the
end
user?
How
will
the
end
user
be
able
to
utilize?
You
know
the
fact
that
you
know
you
have
open
telemetry
throughout
the
graph
on
a
code
base.
You
know
if
I
want
to
start
using
that
for
myself
and
and
just
figure
out
how
the
fireworks
can
I
do
that.
G
So
if
you
want
to
monitor
profound,
if
you
haven't
instanced
running
you
most
likely
collect
logs
from
it,
collect
metrics
from
it
and
probably
collect
traces
from
it
to
yeah,
to
actually
observe
your
final
instance.
Currently
we
do
support
only
open
tracing
and
we
from
my
awareness
only
support
the
jaeger
backhand,
which
means,
if
you
are
using
some
other
tracing
backend,
so
some
other
tracing
tooling
in
your
company.
G
It
may
just
not
be
compatible
with
how
grafana
exposes
its
spans
and
its
phrasing
information.
Open.
Telemetry
is
more
advanced
api
that
allows
you
to
plug
in
the
implementations
differently,
and
that
is
how,
for
example,
we
can
propagate
spans
and
transit
information
in
two
different
formats.
One
is
jager
compatible,
which
is
kinda
considered
legacy
these
days.
The
other
is
w3c
conformant
way
of
sending
expanses
headers
and
that
probably
will
get
adopted
by
more
and
more
tools
in
the
future.
G
Similarly,
you
can
plug
in
different
tracing
backends
and
not
just
jager,
but
other
implementations
of
that.
So,
basically,
we
are
switching
from
the
oldish
tracing
api
that
was
fit
to
a
certain
tracing
solution
into
something
that
is
more
flexible
and
more
adopted.
D
So
hello,
everyone,
maybe
so
I
see
the
agenda
and
it
doesn't
include
plugins.
But
I
guess,
malcolm
you
mentioned
plugins
a
bit.
D
But
but
yeah,
I'm
basically
a
part
of
the
grafana
tracking
platform
team,
but
I've
recently
switched
focus
a
bit
towards
plugins
and
we
sort
of
have
a
team
focusing
on
the
plugins
platform
of
things.
That
is
both
back-end
and
front-end.
D
D
So
yeah
not
sure
if,
if
there's
anything
more
to
discuss
around
the
the
catalog,
maybe
just
interesting
to
say
that
it's
out
there
and
if
you
have
any
feedback
on
it,
would
appreciate.
You
have
to
feed
that
back
to
us
either
here
or
on
github
or
whatever.
I
guess.
B
B
Yes,
should
is
it
even
enabled
by
default.
D
Yeah,
I
think
it
is
so
earlier.
It
was
like
it
wasn't,
embedded
into
to
graph
on
a
core,
but
it
was
yeah.
It
was
a
plug-in,
but
now
it
is
in
core
grafana
and
but
yeah.
I
shouldn't
guarantee
that
it
is
enabled
by
default,
because
I
got
I'm
certain
now,
but
at
least
for
me
locally,
it
is
enabled.
B
So
yeah,
I
I
believe
it
is
on
by
default,
via
from
the
last
version
as
well
looks,
looks
great.
G
B
So
what
what
are
you
responsible
for,
then?
I
mean
more
on
the
back
inside
what
what's
the
tricky
part
of
the
plug-in
catalog
from
a
vacuum
perspective.
D
So
the
catalog
is
maybe
not
that
tricky,
but
it's
more
the
whole
infrastructure
of
like
providing
support
for
back-end
plugins,
as
we
call
it
like
you
can
have
like
from
the
beginning.
There
was
like
panel
plugins
data
source,
plugins
and
app
plugins,
but
they
were
only
client-side,
but
with
grafana
7.
We
added
official
support
for
back-end
clients.
D
So
it's
more
like
trying
to
figure
out
the
the
whole
infrastructure
behind
this
and
sort
of
a
bit
related
to
what
sergey
talked
about
earlier,
like
what
we're
trying
to
do
with,
like
the
the
back-end
as
a
whole,
also
trying
to
make
like
everything
that
powers
plugins,
more
powerful
and
and
potentially
allow
it
to
extend
it
to
potentially
new
and
interesting
things
that
that
we
can
make
plugable
such
as
such
as,
yes,
I
guess,
one
that
has
been
discussed
and
potentially
promised
for
quite
some
time
is
alert
notifiers.
D
That
has
been
kind
of
a
tricky
thing
historically
like
with,
like
initially
with
with
the
first
grafana
alerting.
When
was
that
released.
Grafana
four
point
something
I
think,
maybe
group
one
of
four
and
we're
quite
open
to
accept
like
contributions
of
of
new
note
fires.
But
I
guess
it
came
to
a
point
where
we
sort
of
realized
that
we
are
not
sure
as
maintainers
that
we
can
actually
like
take
responsibility
of
all
these
notifiers
like
we
don't
know
how
to
test
them
and
like
stuff
like
that.
D
So
at
a
point
it
was
sort
of
we
got
very
restrictive
and
started
to
talk
about.
This
would
be
a
great
thing
to
to
enable
through
plugins
so
that
anyone
could
could
like
implement
whatever
notifier
they
wanted
in
a
sense
but
yeah.
I
guess
the
discussion
has
been
ongoing
for
years
and
we
haven't
really
come
there
yet
and
then
I
guess,
like
new
alerting
happened
with
graphon.
Eight
well
like
currently
we're
we're
in
this
world,
where
we
have
like
two
alerting
systems.
D
Maybe
right
now,
it's
not
the
right.
It's
not
the
right
time
to
to
actually
do
that,
but
when
we
have
like
one
alerting
system,
maybe
that
would
be
a
good
a
good
time.
But
with
that,
I
would
say,
like
we
have
the
web
hook,
notifier,
which
is
like
very
general
which
allow
anyone
to
basically
implement
their
own
webhook
receiver
and
with
that
they
should
be
able
to
like
implement
their
own
note
fire
in
a
sense.
D
Some
other
interesting
aspects
in
regards
to
plugins
have
come
up
is
authentication,
maybe
like
authentication
providers
like
we
have
this
generic
oauth
solution,
which
is
like
we've
tried.
We've
we've
tried
throughout
the
years
to
to
keep
it
as
lean
as
possible,
but
like
the
number
of
configuration
parameters
for
it's
just
growing
and
growing,
and
that
is
sort
of
yeah.
It
makes
the
life
for
us
as
maintainers
hard
to
to
actually
maintain
all
of
that.
D
So
there
is
also
where,
like
a
pluggable
authentication
provider,
could
make
sense
for
users
that
have
special
needs
in
regards
to
authentication.
B
So
so,
basically
you
know
what
I'm
hearing
is
that
we're
looking
to
create
like
a
really
stable
backbone
of
the
grafana
backend
and
then
splitting
out
a
lot
of
functionality
into
separate
modules
that
could
potentially
enable
more
plugin
types
in
the
future.
Yeah,
for
example,.
B
So
or
things
like
you
know
the
the
alert,
notify
and
notifiers
would
that
be,
you
know,
are
we
looking
to
add
more
plug-in
types,
or
do
you
think
something
like
that
would
be
like
included
in
a
back-end
plug-in
say,
or
are
we
looking
to
expand
the
number
of
types
of
plug-ins
or
do
we
think
that
it
could
be
included
in
the
existing
types.
D
Yeah,
that's
a
really
good
question.
It's
I
think
it's
also
part
what
we
sort
of
need
to
wrap
our
head
around
moving
forward.
Like
I
told
you
about
what
we
historically
had
in
regards
to
plugin
types
like
panel
data
source
and
app,
and
then
we
sort
of
introduced
back
end
into
the
mix
of
this,
but
like
every
time
like
even
in
our
documentation
and
try
to
explain
it
like
it's
a
data
source
with
a
back
end,
but
it's
like
the
since
it's
hard
to
actually
explain
what
it
is
and
for
like
developers.
D
What
is
it
that
you
actually
can
implement?
What
are
the
possibilities
like?
D
Maybe
how
can
we
find
a
way
to
make
it
easier
to
reason
about
plugins
in
a
sense
like
both
from
the
user
perspective,
but
also
from
the
developer
perspective,
and
that
is
related?
I
would
say
to
this
idea
of
plugin
types
because
like
right
now,
plugin
types
are
basically
client-side
things
like
panel
data
source
app,
but
the
back
end
it
I
mean
it
could
be
seen
as
plug-in
type,
but
it
isn't
really
right
now.
B
B
You,
you
know,
wouldn't
you
be
able
to
build
a
back-end
back-end
component
and
then
like
expose
like
http,
like
a
rest
api
that
the
panel
could
use
as
like
a
support?
If
you
want
to
offload
things
to
the
server,
for
example,
sure
I
haven't
actually
tried
it
out,
but.
B
E
B
D
D
G
D
B
Right
because
I
think
you
know
back
in
in
3.0,
I
think
plugins
were
kind
of
introduced
as
a
way
to
expand
on
you
know
you
could
extend
your
own
refund
experience
that
and
it
wasn't
so
much
made
for
you
know
you
know.
Today
we
have
like
the
the
plugin
directory,
where
you
can
get
a
wholesale
grafana
instance,
and
you
can
start
installing
plug-ins
from
the
community
and
much
like
you
know,
an
app
store
and
other
on
other
platforms
and-
and
I
I
don't
think
anyone
at
grafana
3.0.
B
Could
you
imagine
that
you
know
fully
happening
today.
So
I
think
just
moving
that
into
that
kind
of
perspective
and,
like
you
say,
like
rethinking
what
plug-in
means
today.
D
D
Absolutely
and
yeah
what
are
some
potential
other
crazy
ideas
with
plugins,
like
it's
like
interesting
to
think
about
like
app
plugins,
for
example,
which
has
there's
probably
a
lot
of
room
for
improvement
there,
but
like
in
general,
what
it's
interesting
to
think?
What?
If,
if
you
would
be
able
to
store
data
using
a
an
app
plugin?
D
What
what
kind
of
crazy
plugins
would
you
be
able
to
build
with
that
inside
perfoma,
like.
B
Right
because
one
of
the
one
of
the
current
challenges
I
know
is
that
if
you
want
to
build
a
panel
plug-in
that
you
know
authenticates
toward
into
an
api
or
something
like
that,
you
can't
really
because
there's
no
way
to
securely
store
credentials
in
a
panel
plug-in,
for
example,
but
sometimes
you
you
just
want
to
you
know
you
don't
want
to
a
full-size
data
source,
but
you
still
want
to
make.
You
know
authenticated
requests
from
a
panel
plug-in.
B
So
I
think
there
are
some
hybrids
that
could
be
interesting
to
explore.
To
be
honest,.
D
Yeah
I
mean
since
yeah
like
given
we
yeah
panel.
Plugin
is
obviously
client
side,
but
we
have
this
plugin
proxy,
which
that
was
the
way
to
integrate
with
data
sources
and
other
systems,
like
I
guess,
starting
from
grafana
3
something.
D
But
then
with
grafana
version
4
when
alerting
came,
there
was
a
need
for
grafana
to
actually
like
he
had
to
have
a
back-end
for
data
source
for
grafana
to
be
able
to
to
use
it
in.
In
the
alerting
scenario,.
D
But
given
this
plug-in
proxy,
it's
it's
still
very
useful.
Today,
like
you,
can
build
a
client-side
plug-in
that
doesn't
have
a
back-end,
but
you
can
still
use
this
plug-in
route
functionality
right,
but
it
it
is.
It
is
a
bit
limited.
You
cannot
do
everything
with
that
so
like
if
you
find
that
what
do
you
want
to
do
with
it?
D
Yeah
but
as
you
say
you
you
cannot,
you
cannot
really
store
configuration
for
a
panel,
so
yeah
it's
hard
to
make
it
like
dynamically
configured
in
a
sense.
B
Yeah
yeah,
I
guess
you
would
have
to
have
a
sort
of
a
way
of
storing
credentials
that
you
any
panel
could,
I
know,
access
somehow
without
necessarily.
D
Yes,
yeah
absolutely,
but
that
is
also
like
an
interesting
aspect
like
yeah.
As
we
said,
you
cannot
configure
anything
with
with
panel
plugins
today
with
data
source
data
source
plugins
you
create
like
instances
and
configure
them
and
with
apps
you
can
create.
B
D
Let's
yeah,
let's
take
the
prometheus
data
source,
for
example
like,
like.
Historically
it
had
some
setting
to
say
what
http
method
method
to
use
for
connecting
to
to
promote
your
service.
I
think
it
was
get
in
the
beginning,
because
prometheus
didn't
support.
D
Post
at
first,
but
then
they
added
that
but
get
was
still
there.
The
default,
because
earlier
versions
of
like
people
were
probably
still
using
older
versions
of
prometheus,
but
like
as
an
example,
maybe
a
global
configuration
can
be
just
a
switch
to
default
to
use
post,
for
example,.
D
C
D
I'm
just
talking
widely
here:
I'm
not
yeah
yeah,
it's
just
short.
B
B
It's
like
a
global
key
value
store.
Basically,
that's
what
can
you
say:
yeah,
maybe
cool,
I.
I
guess
this
is
a
a
shout
out
to
or
the
question
to
the
broader
community.
B
If
this
is
something
that
you'd
want
to
see,
you
know
reach
out
to
us
or
or
post
in
the
forums
or
on
github,
and
let
us
know
that
this
is
something
that
you'd
be
interested
in
using,
and
you
know,
what's
your
use
case,
what
would
you
like
to
be
able
to
do,
and
and
so
on,
so
we're
very
curious
to
hear
more
about
how
your,
how
what
kind
of
plugins
that
you
would
want
to
develop
that
you
can't
develop
today?
B
So
please,
let
us
know
we're
coming
up
on
the
hour
here.
So
I
would
just
like
to
thank
everyone
from
the
grafana
team
that
has
joined
and
shared
about
what's
happening
in
the
in
the
in
the
back
end
squad
and
all
the
community
members
that
have
dropped
in
during
the
call
and
as
usual,
this
will
be
available
on
youtube
in
the
next
couple
of
days,
so
feel
free
to
share
it.