►
From YouTube: Grafana UX Community Call 2020-08-03
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).
B
B
It
should
be
publicly
editable
for
you,
so
if
you
have
anything
specific
that
you
would
like
to
address
in
the
progress
of
this
call
feel
free
to
throw
it
in
around
the
agenda
for
the
current
date
and
yeah.
While
you
look
at
that,
I
will
start
my
presentation
so
that
we
can
do
this
properly.
Let
me
share
my
screen.
C
B
Yeah
we're
going
to
get
to
that.
I
hope
a
slide
for
that
in
the
presentation.
If
not,
I
will
do
it
anyway,
yeah.
So
I've
already
mentioned
the
topic
of
the
call
and
at
first
welcome
everyone
happy
to
see
you
guys
so
about
these
calls.
In
general,
we
meet
on
the
first
monday
of
every
month
for
everyone
who
didn't
know
yet
so
the
next
one
will
be
on
the
7th
of
september,
if
you're
interested
in
joining
more
regularly
feel
free
to
put
it
in
your
calendar.
So
you
don't
forget
always
same
time
same
place.
B
Each
meeting
will
have
a
different
theme
or
feature,
and
we
announce
that
in
the
document
and
on
social
media
and
in
our
public
slack.
So
hopefully
you
will
be
up
to
date
and
also
we
want
you
to
suggest
topics
or
drive
the
discussions
as
well.
That's
why
we
have
this
public
document.
B
B
The
ux
team
is
not
having
any
job
offers
out
at
the
moment,
but
feel
free
to
check
our
job
page
on
the
gridfinder.com
website
for
other
job
opportunities,
with
good,
finalists
and
yeah
anything
ux
related.
You
can
drop
in
the
grafana
public
slack.
We
have
a
slack
channel
called
grafana
fails,
which
is
about
all
the
things
that
grafana
is
failing
at.
Not
you
failing,
but
graffana
failing.
B
So
please
tell
us
when
that
happens,
so
we
can
fix
it
and
then
the
ux
team
also
has
an
email
address,
ux
griffina.com,
so
you
know
where
to
find
us
now
the
agenda,
as
diana
already
asked.
So
first,
we
want
to
take
just
a
tiny,
quick
look
at
what
happened
to
your
feedback
from
the
last
session.
Then
we
have
some
announcements.
B
Talking
about
the
query
history,
there
I
have
a
short
presentation
about
how
we
actually
came
up
with
the
feature
that
you
know
and
hopefully
like,
and
we
also
have
plans
to
make
it
even
better
and
ivana
who
is
also
here
in
this
call
and
working
on
this
feature
with
me,
is
going
to
demo
the
status
quo
and
then
we
can
collect
your
feedback
and
opinions
and
have
a
little
discussion
about
that.
And,
of
course
we
will
answer
any
questions
you
might
have,
and
it
doesn't
have
to
be
about
the
query.
History.
B
You
can
talk
about
anything
and
everything
that
you're
interested
in
maybe
explore
related,
but
we
will
also
appreciate
any
other
questions
and
feedback
and
then,
in
the
end
we
will
announce
the
next
ux
community
call
and
then
that's
it.
So
unless
anyone
has
any
questions
or
remarks,
I
would
jump
right
into
it,
but
feedback
anything.
B
E
Yeah,
it's
it's
teddy,
who
started
today
at
grafana,
labs.
B
B
Cool
yeah
happy
to
have
you
alright,
so
let's
get
to
it.
Your
feedback
from
the
last
call.
The
main
topic
that
you
asked
us
about
in
the
last
call
was
regarding
transformations
and,
as
you
can
maybe
see
in
the
dock,
in
the
meeting
notes,
the
main
question
was:
how
do
they
even
work,
because
at
some
point
they
were
a
bit
broken,
so
we
have
now
a
blog
post
that
explains
how
they
work.
I
will
also
throw
the
blog
post
in
the
doc
later
and
then
we
are
continuously
improving
the
feature.
B
So
after
a
brief
period
where
they
were
broken,
they
are
working
again
7.0.2.
So
for
a
while.
Yes,
that's
great,
and
in
the
last
release
7.1,
we
added
a
merge
tables
functionality
and
yeah
if
you're
interested
in
that
maybe
check
out
the
release,
notes
and
that
blog
post
and
if
you
have
any
more
questions,
I'm
not
sure
whether
anyone
who
is
super
savvy
with
the
transformations
feature
is
in
this
call,
but
if
not
put
it
on
the
agenda
for
next
time
and
now
some
announcements
we're
currently
researching
different
projects.
B
One
topic
is
the
onboarding
experience
with
grafana
in
general
and,
more
specifically
with
grifana
cloud,
and
then
we're
also
looking
to
work
on
the
search
and
navigation.
So
we
would
love
some
feedback
on
that
and,
like
very
concretely
related
to
today's
topic,
we
are
looking
for
people
who
are
willing
to
test
the
query.
History
usability
wise.
So
if
any
of
you
in
the
call
would
like
that,
please
just
contact
us
at
the
email
address
displayed
or
on
public
slack.
That
would
be
great.
Thank
you
and
then
one
more
thing
in
case
you
didn't
know.
B
Yet
we
have
a
grafina
ui
library,
which
is
a
component
library
where
you
can
read
documentation
about
how
to
use
and
implement
code
components
that
we
also
use
in
grafana.
So
if
you're
a
plugin
developer
or
know
someone
who
is
a
plugin
developer
or
you've
always
wanted
to
contribute
some
front
end
stuff
to
grafana
check
that
out,
we
would
love
some
feedback
to
improve
that
as
well,
and
it
still
needs
a
lot
of
documentation.
So
anyone
who
is
interested
in
writing
documentation
for
that
would
also
be
very
welcome
all
right
and
that's
all
for
announcements.
B
B
B
So
at
first
we
thought
this
could
be
a
great
tool
to
educate
new
users
about
explore,
so
they
look
at
already
pre-existing
queries
and
understand
better
how
to
query
stuff
and
then,
of
course,
you
could
also
look
at
how
you
solve
past
problems
and
maybe
remember
how
that
worked
and
do
the
same
stuff
again
and
of
course
you
can
also
eliminate
the
need
to
remember
what
queries
you
entered.
So
if
you
have
some
favorite
queries
so
to
say
that
you
use
a
lot,
then
the
history
could
help
you
rerun
them
without
all
the
typing.
B
So
with
these
theses
that
we
had
of
why
the
history
would
be
a
good
idea,
we
went
to
do
some
user
research
because
we
had
not
that
much
time
at
first,
we
ran
exploratory
research
only
within
the
final
labs.
The
good
thing
about
that,
though,
is
we
have
a
lot
of
new
joiners,
so
there's
always
fresh
meat
to
ask
we're
not
super
biased.
B
Yet,
but
of
course
it's
the
best
case
scenario
when
we
can
also
ask
external
users,
so
we
did
that
later,
but
for
even
the
internal
research,
we
got
23
pages
of
observations,
so
there
was
already
a
lot
of
material
to
work
with
and
helped
us
make
what
you
already
know
and
with
the
research
findings
yeah.
I
have
a
quick
summary
of
the
most
important
stuff
there.
So
one
thing
we
notice
is
that
there
are
two
patterns.
B
There
are
people
who
query
case
by
case
and
don't
really
have
favorite
queries,
and
then
there
are
people
who
always
run
the
same
stuff.
So
one
user
said
that
I
don't
think
it's
efficient.
If
I
type
out
my
regular
queries
that
I've
used
before
and
another
user
said
that
saved
queries
could
be
useful,
but
I
use
usually
use
dashboards
or
panels
as
soon
as
I
need
to
save
a
query.
B
So
I
don't
need
it
in
a
history,
so
there
you
could
see,
like
some
users,
think
it's
super
valuable
to
have
these
three
runnable
queries
and
then
others
they
don't
care,
and
if
users
wanted
to
reuse
queries,
it
was
mostly
recent
queries.
B
B
So
one
more
finding
was
that
a
lot
of
people
mentioned
that
they
would
like
to
see
a
team
history
to
see
what
others
query
and
how
they
could
make
their
own
querying
behavior
more
efficient,
so
yeah
that
we
really
pretty
much
got
that
from
everyone.
Finally,
though,
most
people
said
I
would
love
to
see
other
people's
queries,
but
I
don't
want
other
people
to
see
my
queries
because
there
are
so
many
errors
and
like
every
time
I
have
an
unsuccessful
query.
It
would
be
embarrassing
to
show
that
off.
B
So
that's
a
problem
that
we
still
haven't
solved.
Yet
that's
something
for
the
discussion
later,
maybe
yeah,
but
with
all
that
input
we
went
on
to
ideate
and
design.
You
can
see
here
that
we
started
with
some
scribbles
in
the
top,
and
then
we
moved
from
the
scribbles
and
like
merged
them
into
first
wireframes
and
the
wireframes
evolved
into
the
current
design
that
you
might
know
from
using
grafana.
B
So
we
prototyped
that
more
advanced
design.
As
you
can
see,
there's
a
lot
of
clicks
and
options
there
and
then,
with
that
prototype
we
went
to
run
usability
testing
with
community
members
and
we
recruited
community
members
through
the
grafana
public
slack.
So
in
case
you
aren't
in
there.
That
might
be
interesting.
B
If
you
like
to
be
involved
in
feature
development
and
yeah,
we
regularly
ask
for
people
who
want
to
test
stuff
or
have
opinions,
so
that
could
be
a
good
way
for
you
to
get
involved
and
in
this
three
test
sessions
we
got
78
observations
and
managed
to
improve
the
feature
even
before
release.
B
Here
is
a
rough
timeline
of
our
development
process.
So
last
december
we
started
a
kickoff
meeting
and
planning
and
did
first
user
research.
That's
the
extent
exploratory
research
that
I
already
mentioned
here,
the
blue
bar.
Then
we
started
I
ideating
designing,
presented
the
first
stage
design
within
rafana
labs
got
some
feedback
then
started
coding
in
february.
B
Then
we
had
the
usability
testing
iterated
improved
the
code.
Then
we
had
a
beta
release
in
grafina,
6.7
and
implemented.
The
usability
testing
results
did
last
quality
assurance
and
then
the
query
history
was
released
in
grafana
7
and
that's
probably,
where
most
of
you
who
already
know
the
feature
started
using
it
properly
and
while
you've
been
doing
that,
we
are
in
the
process
of
planning,
query
history
2.0
as
we
call
it.
B
So
we
have
first
design
ideas
now
and
some
scribbles
and
the
next
step
for
us
will
be
to
transfer
those
into
more
prototypes
and
starting
from
now
you
can
kind
of
see
it
here.
It's
slightly
cut
off,
but
we
would
like
to
run
more
usability
testing
on
the
current
state
of
the
query
history
and
then
also.
B
We
would
like
to
show
off
our
new
design
ideas.
So
if
any
of
you
are
interested
tell
us
later,
we
would
love
to
have
some
testers
from
the
community,
and
now
I'm
done
with
all
the
talking,
and
I
would
like
to
head
over
to
ivana
who
has
working
code
for
us,
I'm
not
sure
ivana.
What
would
you
like
to
show
us
today?
Do
you
already
have
some
some
new
improvements
to
show
or
just
the
status
quo.
G
G
Can
everyone
see
my
graph
on
the
screen
yeah?
I
can
see
it
yes,
okay,
just
making
sure,
because
the
other
time
I
was
presenting
with
the
wrong
screen
so
just
making
sure
it's
gross
under
there
so
yeah.
I
would
like
to
give
you
a
quick
demo
of
how
the
query
history
looks
like
right
now,
so
we
are
in
the
explore
view.
So
this
is
explorer
and
to
open
the
query
history.
We
have
added
a
button
which
opens
the
drawer
which
can
be
expanded
or
can
be
made
very
small,
even
kind
of
hidden.
G
Okay
and
in
the
query,
history.
We
have
currently
three
types.
We
have
query
history,
which
basically
has
all
of
your
queries
that
you
have
run.
G
We
have
a
tab
with
start
queries,
so
the
queries
that
you
have
start
and
we
have
a
settings
with
which
you
can
customize
your
query
history
to
kind
of
work
for
you,
the
in
the
in
the
best
possible
way.
So
in
the
settings
you
can
select
the
period
of
time
for
which
graphene
I
will
save
your
query.
History
and
the
maximum
is
currently
two
weeks.
G
The
other
customization
is
your
default
active
tag.
So
as
you
could,
I'm
not
sure
if
you
noticed
that
when
I
open
the
query
history,
it
opens
with
the
the
query
history
tab
that
if
we
switch
it-
and
this
is-
I
would
say
mostly
for
power
users
who
already
have
their
favorite
queries.
When
you
open
the
query
history,
it
will
directly
open
with
the
start
queries.
G
So
that's
one
customization
and
the
another
customization
is
to
only
show
queries
for
data
source
currently
active
in.
So
we
have
prometheus
data
source
currently
active
in
the
explorer
and
therefore
we
see
only
prometheus
queries.
But
if
we
decide
to
switch
this
off,
we
can
now
see
all
all
queries
for
all
data
sources,
but
I
will
switch
to
the
custom
custom
settings
and
we
can
talk
a
little
bit
more
about
what
query
history
does
or
or
how
it
can
help
you
with
your
query.
G
So
if
you,
for
example,
run
your
queries-
and
you
know
that
you
ran
some
query,
that
was
very
important
for
you
a
couple
days
ago,
you
can
filter
your
history
based
on
the
time
line.
Oh,
I
don't
have
that
all
history,
so,
for
example,
these
were
four
days
ago
and
another
thing
that
you
can
do
is
you
can
search
the
queries,
so
you
can
search
or
filter
based
on
query
text
and
based
on
the
comments.
G
G
You
can
easily
add
comments
to
kind
of
remind
you
or
or
make
it
easier
for
you
to
remember
what
you
use
query
for.
Another
thing
is
that
you
can
copy
the
query
to
the
clipboard
and
then
just
paste
it
anywhere.
You
want
that's
very
useful
if
you,
for
example,
want
to
share
the
query
to
your
colleagues
or
or
just
open
a
new
tab
and
edit
there.
But
another
thing
that
is
very
useful.
G
Is
you
can
copy
link
to
that
query
to
the
clipboard,
and
this
way
you
can
basically
send
the
whole
query
link
and
it
will
open
the
query
result
for
you
and
the
last
thing
is
deleting
of
the
query.
So
if,
for
example,
you
don't
like
the
query,
you
don't
want
to
see
it
in
your
query,
history,
you
can,
you
can
delete
query
for
all
the
start.
Queries
we
have
kind
of.
You
have
to
confirm
that
you
really
want
to
delete
that
query
and
it
will
be
deleted
permanently.
G
For
the
query
history,
we
decided
to
not
add
it
there
and
you
are
able
to
delete
your
history
with
one
click
and
basically
the
biggest
button
on
the
query.
History
is
run
query,
so
you
are
able
to
to
run
the
query
right
from
your
query
history.
So,
for
example,
we
can
run
this
query
and
the
query
is
already
run
for
you,
so
I
guess
that's
most
of
it.
I'm
not
sure
if
anyone
has
any
questions
or
would
like
to
see
something
more.
Just
let
me
know
yeah,
I
already.
B
Have
two
questions
in
the
chat,
so
the
first
one
was:
would
it
work
to
have
a
full
history
of
the
queries
which
you
could
search
by
fields
and
present
them
in
recent
order?
So
my
question
there
is,
what
does
would
it
work
mean
like
if,
if
we
could
make
it
technically
work,
or
is
it
a
good
idea,
you
xyz
or
both?
Could
you
maybe
elaborate
on
that.
B
And
while
yeah.
B
B
G
Not
saving
the
queries
that
didn't
reason
that
resulted
in
the
error.
That
is
a
maybe
a
good
question
for
the
future
to
to
talk
about
if
we
would
like
to
save
also
the
queries
that
were
wrong
or
didn't
result
in
in
the
response.
Correct
response,
but
currently
all
of
these
queries
are
queries
that
didn't
have
error.
C
I
have
a
follow-up
question
from
that.
Thanks
for
answering
that
question.
So
can
I
search
based
off
of
user
or
is
there
any
way,
because
I
know
that
you
guys
just
integrated
with
like
you
can
see
what
users
are
looking
at
dashboards?
Let's
say
like
I
want
to
collaborate
with
someone
and
like
I
know
that
they
have
been
doing
a
specific
query.
Can
I
like
type
their
name
in
here
and
find
them.
G
I
think
I
I
I
can
answer
that
so
currently,
we
are,
users
are
only
able
to
see
their
query
history,
so
we
are
in
a
process
of,
as
just
mentioned,
researching
the
team
history
and
how
would
that
work
and
and
how
would
we
create
that?
But
currently
it's
only
your
queries,
so
no,
you
are
not
able
to
see
any
other
queries
of
other
people.
Okay,
thank
you.
G
And
yeah
richie
had
also
a
good
comment
about
saving
answers
unsuccessful
one.
Maybe
we
could
even
store
some
basic
metadata
metadata
like
how
many
results
we
had,
how
long
the
query
ran,
etc.
That
was
actually
a
thing
that
we
discussed
during
our
brainstorm
and
during
our
workshop,
so
just
still
processing
the
the
results
of
our
brainstorm,
but
that
was
definite.
Those
were
definitely
questions
and
points
that
we
also
raised
and
were
interested.
G
Future
I
used
to
have
a
comment
with
the
blue
heart,
so
I
was
just
checking
if
I,
if
I,
if
it
was
the
for
prometheus
but
no.
E
So
I
have
a
question
for
adele
regarding
tagging.
People
like
what's
what's
behind
this:
is
this
sort
of
people
in
your
team
that
you
want
to
kind
of
investigate
the
same
query
or
what's
what's
what's
behind
this
feature,
request.
C
I
was
thinking
of
like
if
my
teammates
were
working
on
a
dashboard
that
maybe
I
haven't
worked
on
yet
like
with
a
certain
data
source
like
maybe
I
could
maybe
not
just
clone
their
dashboard
but
understand
like
what
their
queries
are
without
having
to
go
in
and
like
pretend
to
edit
them,
which
is.
It
always
feels
a
little
awkward
to
me,
because
I
don't
like
touching
other
people's
dashboards.
So
I
always
copy
it.
C
If
I
could
just
like
look
at
their
like
data
source
of
type
and
like
you
know,
I
mean
I
wouldn't
have
to
go
to
their
dashboard
like
every
single
time
to
see
it,
I
can
see
all
of
their
work
from
the
past
like
two
weeks
or
whatever,
so
that
makes
sense
like
I'm
not.
I
think
that
is
a
good
solution
to
like,
like
if
I
wanted
to
look
at
each
one
individually,
but
this
allows
me
to
look
at
it
in
a
more
aggregated,
like
full
listing
way.
E
Yeah
well,
no,
it
actually
makes
a
lot
of
sense
because
the
the
same
people
will
probably
have
similar
workflows
or
similar
troubleshooting
approaches
and
if
you're
on
call
then-
and
you
have
a
similar
problem-
that
you
probably
want
to
go
through
the
same
things,
and
maybe
it's
not-
you
don't
have
a
runbook,
that's
written
well
and
then
you
sort
of
just
trying
to
follow
what
they've
been
doing
so
a
sort
of
like
tracking
on
what
which
users
are
using,
which
dashboards.
Maybe
it
could
be
something
useful.
E
I
think
we,
I
think
we're
trying
something
similar
for
in
the
enterprise
solution
that
we
have,
but
it's,
but
it's
not
so
workflow
oriented
in
in
kind
of
helping
you
figure
out
or
helping
you
retrace
steps
of
other
people
yeah.
Maybe
that's
a
good.
It's
good
input
thanks.
A
C
I
know
it's
like
a
little
awkward,
a
little
cringy
because,
like
I've,
done
plenty
of
unsuccessful
queries
where
they
air
out,
but
I
think
it's
like
a
really
good
learning
opportunity,
especially
like
with
new
users
like
we
had
someone
that
ran
a
postgresql
query,
but
it
like
was
like
a
select
star
and
it
completely
took
down
our
grafana
instance,
and
if
someone
else
was
like
man,
I
want
to
put
a
query
into
grafana
like
let's
say:
there's
a
new
user
like
they
can
see
like
that
was
unsuccessful.
They
shouldn't
be
doing
a
select
star.
A
C
Yeah-
and
I
think,
like
one
sorry
to
completely
take
over
this,
but
I
think
one
thing
that's
like
good
on
that
is,
if
you're
allowed
to
keep
it
anonymous,
that's
great,
but
at
some
point
you
may
want
admins
to
be
able
to
see
like
if
they're
running,
like
50
bad
queries
every
week
or
something
like.
A
C
Yeah
and
I
think
like
with
the
ability
to
filter,
I
think
it
will
kind
of
allow
you
to
like
bring
it
in
if
you
really
want
to
like
add,
failed
queries
from
last
week
or
something,
but
I
get
where
you're
saying
like
every
single
failed
query
listed.
That's
like
a
lot
of
resources
of
like
people
can't
actually
use
it.
It's
not
like
replica
like
you,
can't
replicate
it.
E
Yeah,
I
think
I
think
we're
starting
to
track
like
broken
dashboards
in
that
sense
and
then
so
so
that
that
sort
of
thing
an
administrator
could
figure
out
which
of
the
dashboards
in
your
in
whatever
you're
monitoring
could
already
be
troublesome
and
kind
of
in
a
preventive
measure.
You
could
look
at
them
and
figure
out
before
anything
was
wrong
on
how
the
queries
are
broken,
but
yeah.
That's
that's,
usually
not
kind
of
supporting
the
learning
experience
for
the
learning
experience.
E
E
B
Absolutely
I
mean
starting
from
now,
there's
not
much
of
a
presentation
left
because
we're
already
kind
of
in
the
middle
of
the
discussion,
and
if
you
don't
have
anything
regarding
the
query
history
itself
to
discuss,
then
of
course
we
could
also
talk
about
exploring
and
logs
in
general.
If
there's
anything
else
in
the
explore
area
that
you
would
like
to
talk
about,
feel
free
to
throw
it
in
the
chat
we've
had
some
more
people
join.
If
I
saw
that
correctly,
so
any
questions
or
opinions
on
explore
in
general.
A
Maybe
just
one
high-level
comment,
because
there
was
comment
about
being
sorry
for
taking
over
the
call
and
that's
precisely
wrong,
because
this
is
very
much
about
open
discussion
about
actually
getting
feedback
like
anything
you
want
to
talk
about
is
on
topic
by
definition.
Of
course,
the
top
like
the
topic
of
this
call
is
just
more
and
more
free
from
discussion
of
whatever
users
care
about
so
feel,
free
and
bold
and
speak
up.
B
B
We
would
take
that
into
very
good
consideration,
so
I
wouldn't
say
we
have
decided
anything
right
now.
It
is
an
interesting
point,
but
I
think
the
way
grafana
usually
operates.
We
are
all
about
protecting
privacy
and
being
transparent
about
what
we
track.
So
my
gut
feeling
would
be
that
we
would
probably
make
it
an
opt-in
or
optional
thing
where
users
could
decide
themselves
in
their
installations
how
they
handle
this.
B
But
I
don't
know
I
mean
this
point
was
just
raised
and
I
don't
have
an
opinion
about
that,
and
I
know
that
we
do
implement
some
analytics
in
some
parts
of
grafana,
for
example
the
enterprise
part.
So
maybe
in
the
future
we
would
allow
some
more
tracking
options
there,
but
especially
in
the
open
source
version.
I
don't
think
we
would
make
a
mandatory
decision
like
that.
Any
other
opinions
on
that
from
the
grafana
side.
H
Yeah
we
we,
it
would
be
almost.
It
would
be
quite
critical
for
us
to
be
able
to
audit
the
sort
of
queries
that
being
generated.
So
at
the
moment,
what
we
have
is
we
have
a
number
of
different
teams
to
which
we'll
have
an
administrator
which
will
build
dashboards
and
and
whatnot,
and
they
will
and
they're
visible.
And
then
we
have
a
read-only
user
that
people
have
created
for
each
other
to
be
able
to
read
and
read
through
those
sort
of
those
the
data
within
grafana,
but
the
the.
H
E
Sense
yeah,
so
any
sort
of
audit
logging
feature
is
still
under
is
still
under
it's
in,
like
a
pre
product
phase,
so
to
say
we're
still
trying
to
figure
out
how
to
do
this
properly.
E
It's
not
implemented
in
grafana
yet,
and-
and
I
think
I
think
it
will
also
be
there'll-
be
a
big
switch
in
the
configuration
to
to
kind
of
turn
this
on
or
off,
obviously,
and
kind
of
in
a
similar
manner.
Also
for
for
kind
of
the
visibility
of
the
query
history
itself
right,
because
that,
because
these
are
two
different
things,
one
sort
of
the
sort
of
user
facing
and
the
other
thing
the
order,
logging.
E
That
is
just
for
the
for
the
admins
and
that's
another
project
that
we're
doing
internally
to
figure
out
what
would
be
a
good
addition
there
for
kind
of
to
balance.
What
kind
of
what
other
requirements
in
some
at
some
companies,
but
also,
how
can
we
protect
the
privacy
of
of
the
employees.
H
That's
it.
I
think,
I
think,
that's
the
difficulty
right
you're
trying
to
strike
a
balance
between
the
two
you're
trying
to
remain
completely
private,
protecting
users,
but
then
for
for
I'll
work
for
quite
a
large
enterprise
company
and
the
the
difficulty
we
would
have
is
not
being
able
to
see
those
sort
of
requests
that
are
being
made.
So
we
could
implement
restrictions
on
what
can
be
queried,
of
course,
but
but
it's
still
having
some
sort
of
visibility
of
the
things
that
are
being
queried
and
would
would
be
good
yeah.
A
H
In
the
data
source,
oh
okay,
I
see
what
you
mean
so
like
on
a
elastic
search,
something
like
that,
squaring
it
from
there
or
okay
yeah.
That
makes
sense.
Then
how
would
the.
A
I
mean
with
my
prometheus
head
on
and
such
I
can
absolutely
see
this
as
a
feature,
for
example
cortex,
but
I'm
not
convinced
that
at
least
with
the
open
source
version.
You
actually
gain
much,
because
you
don't
have
that
forced
proxy.
H
Thing
unless
I'm
very
mistaken,
so
so
so
with
something
like
prometheus,
I
usually
use
telegraph
and
influx
db.
So
with
with
the
query,
though,
you're
setting
up
as
a
data
source,
you
would
have
a
particular
user
associated
with
that
data
source.
So
how
would
you
be
therefore
be
able
to
identify
which
users
making
that
query
through
grafana.
A
Primitive
itself,
not
at
all
cortex,
you
have
already
a
concept
of
of
canons,
you
don't
have
a
per
user
concept,
but
that's
at
least
easier
to
get
into
cortex
than
entrepreneurship.
On
the
other
hand,
I
think
we're
outside
of
the
scope
of
the
ux
call,
but
you
can
simply
send
email
if
you
want
which
age.
E
Because
I
think
I
think
this
question
was
also
around
influx
and
there
there
you
would
essentially
have
one
user,
one
api
user
or
something
for
the
data
source
and
then
yeah.
It's
difficult
for
the
data
source
to
track.
Who
who,
who
made
the
request
right.
H
E
So
fajar
had
a
question
because
you
you
were
saying
yeah.
I
Regarding
the
sql
query,
is
it
possible
to
limit
the
query?
Is
I
saw
in
the
in
the
forum
that
if
we
use
the
sql
query,
we
must
be
careful
about
the
the
query
itself,
something
like
if
you
running
some
update
or
delete
it
can
be
done,
but
I
think
you
need
to
do
some
limitation.
Let's
say
about
the
read-only
query
that
allowed
when
we
used
the
sql
query.
Is
it
possible
to
do
that.
E
So
I
think
this
has
to
be
so.
I
think
this
this
can't
really
be
done
on
the
grafana
side.
This
needs
to
be
done
on
on
the
sql
or
on
the
data
source
level
so
or
like
on
the
like.
Let's
say
the
mysql
itself,
where
you
would
create
users
or
like
a
user
login
with
a
username
and
password
that
only
has
like,
let's
say,
read
access
or
it
can
only
access
views
or
something
right,
and
that
is
not
allowed
to
modify
the
data.
E
And
then
you
would
use
the
credentials
for
that
user
in
as
the
data
source
credentials
in
grafana.
I
Yeah
yeah,
sometimes
sometimes
the
administrators
doing
something
not
like
that
yeah.
If
in
the
grafana
can
have
some
limitation
about
the
red.
Only
query
like
like
a
load
only
select
has
been
better
because
in
the
data
source,
sometimes
we
can
do
something
like
delete
or
some
update.
So
I
think
in
the
data
source
level
of
the
mysql
or
repository
or
mssql,
something
like
that
just
to
only
the
selling
query,
not
the
other
things
like
update,
insert
and
it
it.
It
could
be
more.
E
Yeah,
so
we
can't
really
restrict
queries
on
the
grafana
side
right
like
if
it's,
if
it's
not
limited
by
the
user
like
on
on
the
user
rights
on
the
on
the
sql
side,
there's
not
much
that
grafana
can
do,
because
that
would
mean
we
would
need
to
interpret
like
queries
that
modify
something
and
then
have
that
as
a
separate
permission
or
so
yeah.
That's
that's
not
something
that
grafana
can
do.
Sadly,.
I
No,
no,
no
just
just
select
query,
not
not
modified.
So
that's
in
the
in
the
data
source
level
of
the
gravana,
so
only
select
query
a
lot
rather
than
insert
delete
and
update.
H
So
so,
if
you
create,
if
you,
if,
when
you're
setting
up
the
data
source
within
grafana,
you
use
the
mysql
user
to
which
only
had
read
access
I'll
select,
you
can
only
do
select
statements
that
would
resolve
the
issue
there,
because
then
the
mysql
user,
which
you're
using
in
grafana,
will
only
have
access
to
be
able
to
do
a
select
statement.
So
it's
my
mysql
access
control
level,
as
opposed
to
rafana.
I
E
Okay,
yeah,
that's
probably
good
practice,
if
you
like,
if
you're,
if
you
have
a
grafana,
that's
accessible
widely
and
you
have
an
sql
data
source,
then
then
you
definitely
shouldn't
have
explore
open
or
anything
like
that.
E
B
So
far
I
don't
think
there's
anything
else
in
the
dock
or
in
the
chat.
So
if
there
is
nothing
more
that
you
would
like
to
talk
about
dear
users,
then
we
can
use
the
last
bit
of
the
call
to
talk
about
the
next
ux
community
code.
Any
more
last
questions,
ideas,
feedback.
B
I
guess
that's
a
no,
so
basically
we
do
have
some
things
that
we
could
demo
and
we
can
prepare
a
topic
if
you
don't
have
any
ideas,
but
of
course
we
want
to
make
this
call
so
helpful
for
you
that
as
helpful
for
you
as
possible.
So
please,
if
you
have
any
ideas,
what
we
should
do
in
the
future,
any
topics
that
you're
interested
in
making
of
stories
feature
ideas,
anything
that
you
would
like
to
address
us
as
ux
team
in
the
future.
In
these
calls,
please
tell
us
now.
D
Yeah
there
or,
if
you
think
of
it,
two
minutes
after
we
close
the
call
there's
also
the
public
slack
grafana
fails
channel
that
is
monitored
by
ux
or
the
ux,
I
believe,
posted
their
email
earlier.
And
then
there
is
the
google
doc
that
just
posted
a
link
to
earlier
which
will
be
monitored
and
checked
before
the
next
community
call.
So
absolutely.
B
B
Right
so
hopefully
you
all
know
that
ux
stands
for
user
experience,
so
what
our
grafana
user
experience
team
deals
with
is
anything
relating
to
how
using
grafana
makes
you
feel
and
whether
you
have
a
smooth
frictionless
way
of
using
this
tool
or
whether
there's
anything
where
you
think,
oh
damn
it
griffana,
that's
really
annoying.
Why
are
you
doing
that
or
oh
grafana?
I
don't
understand
why
you
are
doing
this
in
an
ideal
world.
The
user
experience
that
you
have
would
be
everything
is
so
clear
and
easy.
B
I
know
exactly
where
to
click
and
what
to
do
next,
and
I
also
know
what's
going
to
happen
if
I
click
here
but
oftentimes,
especially
with
tools
as
complex
as
grafana,
is
that
doesn't
work
for
every
place
in
the
tool.
So
if
there
are
questions
you've
had
like,
why
does
this
work
like
that
and
not
in
a
better
way?
Or
how
did
you
come
up
with
this
ingeniously
great
feature,
then?
Please
ask
us
and
we
can
make
it
a
topic
in
a
future
call.
H
B
A
But
there's
a
lot
of
homework,
think
of
more
people
who
would
be
interested
in
joining
those
calls,
and
also,
if
you,
if
you
like
one
thing
which
which
that
was
one
of
the
earliest
things
which
I
did
when
when
I
learned
about
grafana
pulling
in
people
in
use
cases
of
hey,
this
isn't
covered
yet.
But
it
would
be
super
nice
to
have
covered.
So
you
can
also
feel
free
to,
for
example,
suggest
a
certain
thing
or
something
like.
We
can't
promise
that
we'll
implement
it.
H
I
mean
the
only
thing
I
could
think
of
like
whenever
people
see
that
we're
using
grafana
in
the
way
that
we
do
they're
always
like
blown
away,
and
they
want
more
of
it,
having
something
which
was
just
easily,
for
I
don't
know
for
people
just
to
be
able
to
set
up
a
simple
sort
of
monitoring
platform
for
a
few
of
their
servers
without
having
to
go
into
extremely.
H
You
know,
you
can
download
custom
dashboards
online
through
the
community
through
the
community
site,
but
just
having
something
where
they
can
have
a
simple
monitor
system
monitor.
You
can
run
an
agent
client-side,
this
little
configuration
and
they
can
chuck
up,
would
be
nice
for
people.
H
E
Yeah
so
there's
an
internal
project
around
this
to
kind
of
curate
dashboards
a
bit
better,
so,
for
example,
that
there
could
just
be
one
dashboard
on
how
to
monitor
a
linux
host,
for
example,
or
one
dashboard
on
how
we
recommend
you
monitor
a
mysql
database
yep
and
unfortunately,
that
is
for
the
hosted
service
for
now,
but
we're
still
trying
to
figure
out
how
to
build
a
community
around
these.
So
there
is
something
happening
also
in
the
open
source
space.
All
right.
H
C
H
But
but
yeah
yeah.
D
I
would
strongly
recommend
showing
up
to
the
next
community
call
they
can.
We
have
a
community
team
that
does
calls,
and
the
people
on
that
team
are
the
ones
who
are
looking
at
the
dashboards
section
on
and
also
taking
close
look
at
plugins,
which
are
closely
related
to
dashboards
and
trying
to
make
that
whole
experience
a
lot
more
user-friendly.
B
Yeah,
I
guess
we're
through
with
our
program
for
today,
and
you
all
gave
great
feedback
and
had
great
questions.
So
if
people
are
already
starting
to
leave,
we
can
all
start
into
our
rest
of
the
day.
But
I
was
very
happy
to
see
so
many
involved
people
here
and
have
a
proper
discussion
so
hopefully
see
you
all
again
on
the
next
community.
Call,
don't
forget
it's
september
7th
for
the
ux
community
called
and
maybe
for
the
people
who
are
still
here
diana.
E
A
Basically
or
just
doesn't
exist
in
sweden
at
least
not
for
work,
sweden,
so
maybe
it's
even
in
september.
I
I
don't
know.