►
From YouTube: Loki Community Call 2021-05-06
A
B
C
Sure
so
today
I
would
like
to
show
you
two
new
improvements
that
we've
been
working
on,
and
I
hope
that
these
features
are
going
to
improve
your
vlogging
experience
in
grafana
and
the
sec.
The
first
feature,
which
is
download
logs,
is
implemented,
but
the
second
one
which
is
logs
navigation
is
still
work
in
progress.
So
all
the
feedback
is
welcome
and
I'm
going
to
start
and
show
you
the
download
logs.
So
that
was
one
of
the
more
requested
features
that
we've
had.
C
D
C
A
C
So
we've
been
considering
couple
of
options
regarding
copying
everything
we
didn't
consider
it,
because
we
had
already
inspected
the
place
where
you
could
download
csv
and
we
wanted
to
keep
it
kind
of
all
together
and
not
have
it
spread
all
over
the
explore.
However,
there
is
jess
has
worked
on
when
she
was
working
on
vlogs
navigation
design.
She
was
exploring
the
idea
of
having
like
ad-hoc
interactions
with
individual
log
lines.
So
if
you
would
hover
over
the
log
line,
you
would
have
kind
of
like
options
to
interact
with
it.
B
I
I
have
a
question
more
relating
to
because
I
know
that
you're
gonna
talk
about
pagination
too
today
and
are
you
able
to?
Is
it
like
the
current
page
right
or
the
current
set
of
data
that
you're
viewing,
or
is
it
like
all
of
the
logs
that
match
that
query
in
that
time
period?
So,
as
opposed
to
you
know
the
first
1000?
Would
it
be
the
all
of
them
within
the
one
hour.
C
Yes,
so
how
we
decided
to
do
it
is
that
we
run
query
if
you
like,
when
you
hit
the
limit.
Let's
say
you
hit
the
limit
in
your
first
four
seconds
and
your
range
was
one
hour
you
are
able
to
go
to
older,
like
click
on
the
button
and
request
all
their
logs,
so
the
logs
that
start
with
the
time
step
that
previous
ended
and
continue
with
the
next
one.
So
that's
how
how
we
did
it,
because
otherwise
we
were
hitting
the
max
line,
limit
cool.
C
E
A
C
C
C
So
when
you,
when
we
are
running
lock
queries
quite
often,
our
users
hit
the
line
limit,
and
I
have
seen
couple
of
questions,
even
on
our
slack
or
on
community
sites,
that
users
weren't
aware
that
you
can
set
the
line
limit
and
they
are
just
like
confused
why
they
see
just
like
10
seconds.
What
is
it
19
seconds
of
vlog
if
they
request,
we
did
one
hour
range,
so
we
have
decided
to
or
we
are
trying
to
improve
it
in
couple
of
ways.
C
First
way
is
improving
the
messaging
or
adding
more
info
and
more
context
about
the
fact
that
you
are
hitting
line
limit,
how
much
time
is
covered
and
we
used
to
have
a
different
name
here,
so
we
have
renamed
it
in
the
same
way
as
you
can
see
here.
So
it's
kind
of
more
closer
for
you
to
to
see
that
you
probably
can
increase
the
limit
that
have
has
been
reached.
C
C
So
that's
one
thing:
let
me
open
the
inspector,
and
so
we
expect
our
users
to
probably
be
searching
for
some
lock
so
interact
with
this
navigation
and
maybe
go
like
into
the
older
older
pages.
So
we
have
decided
to
cache
previous
results.
Currently
we
are
caching,
as
you
can
see,
there
is
no
request
here.
That's
what
I
was
trying
to
show
with
opening
the
inspector.
We
are
caching
last
five
requests
that
you
have
run
and
therefore
you
are
not
re-requesting
the
same
logs
over
and
over
again.
C
So
that's
the
second
thing,
and
the
last
thing
is
that
when
you
have
a
lot
of
logs
in
the
in
the
past
you
had
to
when
you
were
on
the
bottom,
you
had
to
scroll
to
the
top.
By
the
way
everything
is
slow
because
I'm
running
docker
and
screen
sharing.
So
everything
takes
much
longer
that,
instead
of
scrolling
up,
you
can
use
this
new
button.
C
B
C
B
A
C
F
Thank
you.
This
is
cool,
but
I
have
one
like
usually
when
I
use
the
explorer
section
like
it
defaults
to
like
show
me
that,
like
the
time
range
is
like
the
last
hour
and
then
if
I
search
for
something
and
I
want
to,
and
I
can
run
into
the
line
limit
and
I
want
to
see
logs
from
like
the
start
of
that
hour,
it
was
very
useful
before
how
it
worked
before,
where
you
could
just
zoom
in
in
the
actual
graph
to
select
the
the
narrower
time
range.
F
C
So
jessica,
I
understand
you
are
referring
to
when
we
had
the
instagram
that
you
would
have
like
full
one
hour
there
yeah
yeah,
yeah,
yes,
so
histogram
was
not
part
of
this
code.
What
we
know
about
it,
we
are
still
trying
to
figure
out
what
would
be
the
best
way
how
to
solve
it.
It's
also
related
to
the
fact
that
a
running,
if
I,
if
I
recall
correctly,
a
running
locky
query
that
would
show
you
full
histogram
could
be
expensive
and
users
should
be
notified
about
it
if
we
are
doing
it.
A
So
the
I'll
recap
it
just
a
little
bit,
because
I
was
a
little
more
animated
last
time,
it's
probably
more
entertaining
to
watch
last
month's
video,
but
the
histogram
is
is
a
unique
challenge
for
loki
and
in
a
couple
ways,
one
because
I
think
every
other
logging
system
most
that
I'm
familiar
with
have
this
as,
like.
You
know,
an
expectation
right.
It
just
works.
You
get
this
full-time
window
histogram,
it
also
exploits.
A
You
know
one
of
the
trade-offs
that
loki
makes
in
how
we
do
indexing,
because
that
query
can
be
very
expensive
to
calculate
so
like
filling
the
full
histogram,
especially
when
you're
running
like
filter
expressions,
and
things
is
hard
for
loki
to
do
so.
So
we've
not
wanted
to
do
it
for
that
reason
by
default,
because
it
would
be
kind
of
a
burden
on
on
the
back
end,
but
I
think
the
compromise
that
came
out
last
time
that
I
wanted
to
chat
with
you
about.
It
was
basically
you
know,
adding
a
button.
A
A
link
in
the
histogram
for
people
to
on
demand
just
be
able
to
run
it.
What
it
equates
to
is
a
metric
query
of
basically
count
over
time
or
rate
one
or
the
other,
for
whatever
your
query
is
so
that
I
think
we
kind
of
all
agreed
would
be
really
kind
of
a
nice
compromise,
because
if
you
want
to
see
the
full
histogram
right,
if
that's
going
to
be
helpful
in
your
query
path,
you're
either
going
to
just
write
the
query
yourself
and
do
it
manually.
You
know.
A
C
C
That's
actually
a
very
good
point
as
well,
because
we
we
are
basically
calculating
what
is
the
range
and
showing
it
off
instead
of
taking
the
range
that
you
have
requested.
So
I
think
that
it
would
be
quite
easy
fix
for
this,
so
yeah
I
I
will
try
to
find
an
issue
and
post
it
here.
I
feel
like
there's
a
discussion
on
the
feature:
requests
related
to
histograms.
F
A
All
right
some
notes
down
here,
thanks
roger
that's,
but
that's
great
feedback.
That
was
similar
feedback
that
we
had
last
month
too.
If
I
go
back
and
rewatch
myself,
I'm
gonna
have
to
eat
some
of
my
words
because
I
was
sort
of
talking
about
like
how
I
I
don't
find.
I
don't
use
the
histogram
right
like
I
didn't
see,
so
I
apologize
because
the
histogram
many
people
have
pointed
out
lots
of
value
in
it
specifically
around
exactly
that
right,
like
it's
a
modified
and
improved.
A
D
A
Yeah,
what's
what's
funny
about
this
is
the
technical
problems
that
lead
into
this
right,
which
is
my
perspective,
but
also
the
challenges
around
how
we've
been
represented
in
the
ui
like
at
right.
Now,
I'm
pretty
sure
that
on
community.grafano.com
there's
an
open
issue,
that's
it's
worded!
Like
somebody's
saying
you
know,
I
can't
see
logs
after
an
hour.
I
I
would
bet
like
a
buck
on
that
that
it's
probably
the
thousand
log
line
limit,
and
so
it's
still
an
unsolved
problem
for
us.
A
So
I'm
really
happy
to
see
the
ui
improvements
like
just
the
words
there
that
talk
about
having
you
know.
Some
percentage
of
your
logs
returned,
I
think,
is
a
huge.
You
know
step
in
helping
with
that.
Then
I
think
the
next
steps
are,
you
know,
making
the
histogram
useful
for
showing
actual
log
volume.
I
think
the
on
demand
for
that,
but
to
your
point,
roger
like
even
without
that
just
having
a
a
mouse
based
time.
Selector
is
a
very
useful
feature.
A
So
some
somehow,
I
think,
I'd
like
to
enable
both
of
those
the
truncating.
The
histogram
window
was
an
effort
to
help
people
understand
that
it
was
sort
of
more
confusing
when
they
saw
just
a
little
bit
of
logs
at
the
one
side,
and
then
most
of
it
was
blank
in
the
histogram
where
they're
like,
where
are
my
logs,
so
this
helped
in
that
direction,
but
then
removed
the
functionality
that
that
you
were
using.
A
D
A
Thank
you.
Ivana
awesome
really
excited
to
see
paging
support
for
sure.
Like
I
you
know
I
I
have
found
myself
able
to
you
know
we
use
loki
right
like
yeah.
That's
good
good,
good
intro
there,
but
you
know
I've
basically
learned
how
to
use
loki
within
the
constraints
of
a
thousand
log
line
limit,
and
that
usually
looks
a
lot
like
removing
log
lines
that
I
don't
care
about.
So
a
lot
of
filter
expressions
of
not
equals
this
not
equals
that
and
that
works
well
for
me,
but
there
are
still
you
know.
A
G
Ed
on
that
on
that
comment,
a
problem
that
I've
noticed
recently
that
maybe
a
similar
thing
with
the
fetch
holder,
logs
kind
of
comes
into,
is
it
if
you
do
have
a
lot
of
filtering
and
you
get
down
to
a
very
specific
query
and
you
go
there
there's
the
problem.
I
was
looking
for
what
preceded
that
is
difficult
to
find.
G
G
G
I
do
but
there's-
and
I
haven't
quite
figured
out
what
the
pattern
is:
it's
not
always
available
and
it
seems
to
be
depending
on
how
I
structure
the
filter,
so
maybe
it's
when
it
when
it
starts
applying
to
multiple
label
streams
or
something
but
there's
time
periods
where,
where
I
can't
get
the
show
context
to
appear
and
that's
where
I'm
suddenly
like
crap,
how
do
I?
How
do
I
get
the
two
lines
around
this
now.
E
A
A
What
I
was
wondering
what
that
would
look
like,
because
I
believe
that
the
span
knows
it
started
end
time
in
absolute
terms,
could
the
traces
to
logs
button
actually
run
a
log
query
with
extremely
precise
start
and
end
times
of
the
span
itself?
That
seemed
interesting
to
me.
I
wonder
herb
if
that
would
help
you.
A
E
C
I'm
also
wondering
because
david
demotes
today,
this
new
integration
between
so
when
you
are
running
queries
for
tempo.
Currently,
you
can
only
search
for
trace
id,
but
what
we
did
is
that
in
the
tempo
data
source
settings
you
can
link
the
locky
data
source
and
then,
if
you
go
to
the
explorer-
and
you
want
to
run
tempo
query,
you
can
actually
run
loki
query.
C
You
have
to
specify
the
regex
on
how
to
like
what
is
the
trace.
What
is
the
pattern
that
it
then
gives
you
the
the
list
of
all
traces
basically
and
you
in
the
table
with
the
log
message-
and
I
am
looking
for
that
and
maybe
I
can
so
yeah.
I
can
show
you
the
or
I
can
send
here
a
poll
request
and
there
is
actually
a
video
or
like
a
gif.
E
G
Yeah
sorry,
since
everybody's
talking,
I
was
to
the
to
the
point
about
seeing
just
the
the
logs
that
you're
interested
in
the
time
range
is
one
thing,
but
the
other
piece
of
that
might
be
that
and
granted
you
have
to
log
enough
trace
id
in
your
log
statements
for
that
to
work.
But
if
the
trace
id
regex
automatically
got
copied
into
the
the
loki
query,
that'd
be
a
nice
time.
Saver.
A
A
B
A
This
is
yeah
the
traces
to
vlogs.
I
don't
think
we
have
a
ton
of
feedback
on.
I
know
that
ourselves,
we've
not
you,
know,
spent
a
ton
of
time
yet
to
sort
of
dig
in
so
would
love
to
hear
more
use
cases.
I'm
not
sure
what
issue
did
you
link
here
about
it?
This
is
a
good
one
for
a
okay.
No,
that's
the!
I
wonder
what
the
best
place
to
categorize
or
to
capture
since
the
log
feedback
is.
We
need
another
issue
for.
A
D
B
And
that's
fun
for
us
too,
because
we
don't
have
to
like
figure
out.
You
know,
oh,
what
have
we
been
working
on?
What
do
we
want
to
demo?
Our
show
it's
like
we,
it's
really
fun
for
us
to
like
see
how
other
people
are
using
loki,
because
a
lot
of
time
we
realize
that
people
use
loki
a
little
bit
differently
than
we
do
internally,
and
it
helps
us
discover.
Things
like
you
know
like
not
to
you
know,
beat
that
dead
horse
ed,
but
like
the
histograms
right
or
like.
A
B
A
I
mean
the
use
cases
for
loki,
which
is
why
we,
you
know
it's
going
to
take
over
the
world.
Right
is
they're
unlimited,
but
it
really
helps
us
to
get
feedback
from
people
and
like
what
works
well
for
them
and
really
that
what
works
well,
feedback
is
my
favorite,
but
also
the
what
doesn't
work
well
feedback
is
is
welcome
to.
D
A
All
right
so
cyril
couldn't
make
it
he's
been
working
on
custom
retention.
The
pr
is
merged.
We
are
in
the
process
of
basically
testing
it
through
our
environments.
I
think
we've
made
it
as
far
as
dev
and
looking
into
our
operations
environment.
So
this
is
the
ability
to
define
stream,
matchers
and
set
retention,
and
it
will
change
the
behavior.
A
This
would
change
that
to
make
retention,
loki's
responsibility,
fully
you'd,
remove
your
ttls
and
you'd
be
able
to
set
retention
per
stream,
and
it
is
working.
So
I
would
say,
there's
a
good
chance,
not
sure
when
2.3
will
be
released,
but
there's
a
good
chance
that
it
will
have
it.
I
mean
it
will
be
in
2.3
the
question
about
whether
we
what
sort
of
level
of
maturity
we
assign
to
it,
I'm
not
quite
sure
yet,
but
that's
my
update
on
retention,
but
it
is
in
it
is
merged
into
main
now.
A
G
C
Yes,
so
that's
a
good
feedback,
it's
and
so
on.
My
branch
is
already
fixed.
It
was
kind
of
working
progress.
I
have
decided
to
like
split
it
into
different
pr's
and
we
are
going
to
have
actually
like
a
sticky
navigation.
So
it's
going
to
have
size
of
one
window
approximately,
but
it's
going
to
be
like
sticky,
so
you
won't
have
to
scroll
to
the
bottom.
That
will
be
very
user
friendly.
C
D
G
D
G
Okay,
cool-
I
I
would
want
to
if
it's
possible-
and
I
assume
loki
can
do
this
and
the
query
is
the
labels,
since
you
can
select
any
of
them,
they
don't
all
make
sense
as
a
stream,
though
so
it
you
know
if
you,
if
you
select
one
particular
application,
but
it
doesn't
have
another
label.
That
label
is
still
in
the
picker
and
you
can
you
know
you
can
choose
instance,
ids
and
all
sorts
of
labels
that
will
give
you
zero
results
right,
because
there
is
no
stream
with
that
combination.
B
A
D
A
Long
story
short
is
that
the
series
api
is
is
is
rough
like
it.
The
indexing
in
loki
isn't
quite
enough
to
know
values
easily.
So
what
happens
when
the
series
api
is
called?
It
will
download
a
chunk
for
each
series
to
be
able
to
see
what
values
existed
for
the
label
name,
so
the
label
names
are
in
the
index.
What
that
means
is
that
call
happens
asynchronously
within
the
browsers
when
you
type
in
a
label,
so
this
hurts
more
on.
You
know
certain
deployments
than
others.
A
So,
like
the
number
of
labels,
you
have
the
number
of
streams
you
have
and
the
time
window
of
your
range
selector
when
you
do
this.
So
if
it's
not
filtering
for
you,
it's
possible
and
you
could
check
this
by
opening
up
the
you
know.
If
you
open
up
the
developer
tools
in
the
console,
you'll
see
it
send
to
the
series
api
query:
it's
possible
that
query
is
just
not
coming
back
fast
enough
with
the
results
to
do
that.
Filtering.
A
There
is
actually
I
mean,
there's
a
lot
we
can
do
here.
It's
just
been
not
a
high
priority,
it's
kind
of
worked
well
enough,
but
that's
not
a
great
experience
right
for
it
to
sort
of
inconsistently
apply,
but
I
think
that,
depending
on
like
one
sort
of
pro
tip
here
would
be
always
start
with
the
most
restrictive
label.
You
can
think
of
right,
like
always
start
with
a
label
that
you
think
will
return
the
fewest
number
of
matching
streams
and
that
sort
of
lowers
the
workload.
But
so
I'm.
B
There's
a
seri,
you
know
we're
hitting
the
series
api.
Maybe
we're
not.
I
said
that
we're
definitely
hitting
it,
but
it
looks
like
we're
not
excuse
me.
We
like
I,
it
could
be
tied
into
the
ui
a
little
bit
better,
but
the
calls
are
going
through
ed's,
totally
right,
yeah.
Also
there's
like
the
fun
tidbit
of
like
how
did
what
did
owen?
Do
you
remember
that
ed?
It
was
like
a
year
and
a
half
ago
I
this
is
like.
B
What
we
want
to
do
is
like
make
this
knowable
at
the
index
layer,
which
means
this
would
be
way
way
more
efficient,
but
for
now
we
basically
need
to
take
the
these
labels,
which
speaks
to
ed's
point
of
use,
the
most
restrictive
labels
you
can
first,
and
so
it
would
grab
all
of
the
like
one
chunk
for
every
stream.
Basically,
I'm
gonna
have
to
download
that
and
then
check
the
labels,
and
I
think
the
first
time
we
did
this
and
we
like
really
opened
this
up.
B
I
had
a
bug
in
my
code
which
made
it
iterate
through
every
like
every
single
log
in
every
chunk
that
we
pulled
and
then
needlessly
you
know.
Needless
to
say,
once
we
rolled
it
out
to
one
of
our
larger
internal
environments
like
everything
started
falling
over,
and
I
like
that
scene
from
tommy
boy
where
chris
farley
is
like,
what
did
you
do.
B
A
A
G
A
C
B
G
A
H
No,
no
tempo
and
loki
essentially
because
we
are
trying
to
switch
from
jager
to
temple
and
in
jaeger
we
can
filter
out
traces
that
are
taking
more
than
this
amount
of
time,
for
example,
and
we'll
see
that
20
of
our
calls
are
taking
too
long.
What
I
was
wondering
if
now
that
we
are
switching
to
tempo,
there
is
any
way
for
this
whole
integration
to
work
on
our
benefit,
and
we
say
give
us
the
logs
for
those
traces
that
took
more
than
this
amount
of
time.
Because
then
we
have
an
integration.
H
We
are
logging,
the
trace
ids
as
part
of
our
logs,
and
we
have
connection
between
loki
data
source
and
temporal
data
source
using
that
drive
field.
So
it
has
all
those
connectivity
and
data
around.
I
know
it
spans
both
of
those
systems
and
not
a
single
one
of
them
has
all
the
information.
But
that
was
just
a
question
since
that
would
ease
the
whole
and
debugging.
A
A
B
So
the
interesting
question
here,
though,
is
like:
can
you
bootstrap
that
in
a
more
automatic
fashion-
and
it's
can
I
because,
in
things
like
jaeger
right,
where
you
can
search
on
on
the
other
dimensions?
Right,
yes
like?
Can
we
automatically
like?
Can
we
integrate
the
opposite
way
and
basically
use
loki
somehow,
for
instance,
to
be
able
to
query
properties
of
tempo,
and
I
knew
that
joe?
J
So
we're
gonna
start
exploring
that,
I
would
say,
probably
in
the
second
half
of
this
quarter,
we're
gonna
send
one
of
our
developers
off
to
take
some
of
our
designs
and
some
of
the
work
we've
done
towards
that
direction
already
and
really
work
on
making
a
mature
something
else.
That's
upcoming,
that's
already
in
the
agent
to
kind
of
maybe
help
with
this
need
before
we
could
create
native
search
is,
let
me
see
if
I
can
find
the
pr
it's
not
been
released
yet,
but
automatic
logging.
D
J
E
D
D
J
A
J
A
D
C
B
F
B
B
F
A
I
mean
it
sounds
like
you've
already
built
something
that
you
yeah
yeah
yeah.
I
think
the
the
question
one
thing
that's
interesting
about
that
is
loki-
has
the
potential
to
lose
track
of
the
actual
source
file.
So
I
think
a
feature
like
this
would
require
you
to
sort
of
pick
what
label
you'd
want
to
split
the
result
by,
but
that
that
use
case
like
what
you
described,
of
of
being
able
to
extract
data
like
especially
for
ticketing
systems
and
purposes,
I
think,
is
a
lot
of
what
people
want.
A
It's
usually
how
I'm
wanting
to
pull
logs
out
of
loki
from
the
ui
is
that
I'm
trying
to
facilitate
a
postmortem
dock
or
you
know
a
ticket
or
some
communicate
something
to
someone
so
yeah.
I
could
see
you
know
the
idea
of
like
pic
pick,
one
or
two
labels
or
something
to
split
the
stream.
So
when
you
click
download,
you
could
get
separate
files.