►
From YouTube: Grafana Agent Community Call 2023-03-22
Description
All about Agent Flow! For more details about our community calls https://docs.google.com/document/d/1TqaZD1JPfNadZ4V81OCBPCG_TksDYGlNlGdMnTWUSpo/edit
A
B
Hey
my
name
is
Craig
I'm,
a
developer
on
the
agent
and
I've
been
working
for
a
while
on
the
operator,
specifically
on
handling
pod,
monitor
service
monitors
and
probes
in
the
agent
for
anyone
not
familiar
with
that,
a
pod
monitor
is
or
kubernetes
it's
a
custom
resource
that
you
can
drop
into
your
cluster.
That
says
essentially,
I
want
to
scrape
pods
that
match
this
spec.
B
B
Currently
we
can
consume
those
with
the
agent.
Only
through
the
grafana
agent
operator,
we
have
an
operator
which
is
running
in
your
cluster
and
you
create
custom
resources
for
pod
monitors,
but
also
for
configuring.
Your
agent,
the
problem
with
this
model
is
it
forces
people
who
want
to
use
pod
monitors
to
use
the
operator
to
deploy
their
grafana
agents
and
there's
some
rough
edges
there.
B
B
It
could
be
any
Prometheus
anywhere
and
that's
all
it
is
so
when
I
run
the
agent
it
will
find
all
of
my
pod
monitors.
It
will
discover
pods
that
match
those
it
will
scrape
them.
It
will
forward
them
all
in
one
go
so
here,
I'm
just
running
this
against
my
local
a3s
cluster
I
have
exactly
one
pod
monitor
here
for
core
DNS.
It's
trying
to
match
pods
here.
This
have
k8s
app
is
Cube
DNS.
B
Where
is
this
thing?
One
pod
in
my
cluster
that
matches
it
8s,
app
and
Cube
DNS,
so
I
would
expect
this
pod
monitors
running
in
my
cluster
I
would
expect
it
to
find
so
here
it
found
that
pod,
Monitor
and
I
expected
to
find
that
pod
and
scrape
it.
If
we
look
at
the
grafana
agent
UI,
this
is
a
new
feature
in
flow
2,
mad
props,
to
the
team
that
made
this
yeah.
B
B
A
Thanks
Craig
I
think
I
think
that's
super
cool,
like
one
of
the
things
that
I
think
is
really
interesting
about
bringing
pod
monitors
in
to
flow.
Is
you
could
hypothetically,
like
use
upon,
monitor
component,
convert
that
to
otlp
data
and
then
send
it
to
like
some
other
company
which
is
really
cool
like
you
can't
do
that
with
Prometheus
operator?
You
can't
do
that
with
the
agent
today.
So
I'm
really
excited
to
see
like
all
these
new
capabilities,
with
putting
operator
support
directly
into
flow.
B
Yeah
I
really
like
that
we're
handling
the
metrics
directly.
Instead
of
like
all
the
operator
you
Prometheus,
operating
on
grafana
agent
operator,
they
find
the
Pod
monitors.
They
then
generate
a
config
with
all
that
data
in
it
statically
and
give
it
to
the
agent
that's
running
so
there's
kind
of
this
intermediate
step
of
like
okay.
Let's
read
the
big
old
blob
of
config
that
it
generated,
whereas
with
this
model
we
just
scrape
it
directly,
you
can
see
the
state
of
you
know
what
pod
monitors.
Have
you
found?
B
A
B
So
the
big
three
are
pod
monitors,
service,
monitors
and
probes.
Those
are
the
the
kind
of
dynamic
monitoring
ones
from
Prometheus
operator.
There's
also
some
things
like
pod
logs,
there's
Prometheus
rules,
there's
a
variety
of
of
kubernetes
custom
resources.
The
agent
can
handle
I.
Think
kubernetes
events
are
one.
B
A
A
A
A
D
Perfect,
okay,
all
right,
so
we're
gonna
talk
about
modules,
so
kind
of
before
we
get
into
modules.
I
just
want
to
show
what
you
know.
Current
state
looks
like
and
then
we're
going
to
get
into
an
example,
eventually
with
modules
showing
what
it
would
look
like
in
that
format.
So,
today
what
we
have
with
flow
is
you
kind
of
need
to
stack
all
of
your
configuration
into
a
single
file?
D
So
we've
got
this
single
dot
River
file
here
and
inside
of
it
I've
got
some
metrics
I've
got
some
logs
and
I've
got
some
traces.
So
what
happens
is
this
is
a
fairly
simple
example
that
we're
going
to
go
through
of
getting
some
basic
metrics
clogs
and
traces
out
there.
However,
if
you
can
imagine
for
more
complex
configurations,
it'll
be
a
little
difficult
to
manage
as
it
gets
bigger
as
well
as
if
you
have
reusable
configurations
that
you
want
to
be
able
to
mix
and
match
this.
D
D
So
the
way
we
got
to
where
we
are
now
is
we
start
out
with
this
with
this
RFC,
so
I
want
to
kind
of
just
call
this
out
as
as
something
that
the
the
team
has
gone
through
and
it's
been
available.
You
know
public
for
comment
and
input,
and
it
you
know
it's
it's
quite
detailed
about
what
we're
trying
to
do
and
why
and
to
follow
that
up.
D
Here's,
here's
the
pull
request
for
it
and
you
can
see
we've
got
67
comments,
so
there's
been
quite
a
bit
of
healthy
discussion
on
it,
which
is
been
fantastic
and
I.
Think
you
know
by
the
time
we
release
this
this,
this
RFC
will
will
be
merged
and
finalized.
So
it'll
be
part
of
the
the
agent
repo
going
forward
so
that
people
can
look
back
on
the
history
of
this,
which
is
fantastic
one.
D
Once
we
kind
of
have
the
the
RFC
laid
out
to
where
we're
comfortable,
we,
we
did
a
prototyping
phase,
so
I
I
think
there
was
at
least
three
prototypes
that
were
built
to
to
approach
this
from
some
different
angles
within
the
code
base
and
I'll
kind
of
show
you
so
so.
This
is
a
very
simplified
diagram
of
the
before
so
kind
of
like
that
single
River
file
that
I
showed
we've
got
this
flow
controller,
which
manages
a
set
of
components
so
that
would
all
go.
D
What
we're
calling
a
module,
loader
and
and
that's
a
component
that
starts
another
flow
controller,
and
then
inside
of
that
we
can
have
that
managing
different
components
and
I
wanted
to
show
here
we've
also,
you
know
you
can
have
a
module
flow
controller
inside
of
a
module
flow
controller
and
that
that'll
be
an
example.
So
you
can,
you
can
keep
going.
We
we've
talked
about.
You
know
putting
a
limit
on
how
deep
you
can
go,
but
I
don't
think
we've
finalized
what
that
would
be
or
what
that
would
look
like.
D
Yet,
okay
sure
I
got
all
okay.
So
what
do
we?
What
do
we
actually
have
so
far?
What
have
we
built?
What?
Where
are
we
at
this
moment
in
time,
so
concept
docs?
So
here
we've
added-
and
this
will
be
in
the
next
release-
a
concept
doc
that
talks
about
modules-
oh
and
I,
gotta
blow
this
up.
I'm
sure
maybe
like
that-
and
this
also
includes
down
at
the
bottom
and
I'm
not
going
to
go
through
this
in
detail,
but
I
just
want
to
bring
it
up
for
awareness.
D
We've
got
examples
of
what
a
module
would
look
like
and
how
it
would
be
referenced
from
another
River
config,
so
right
here,
We've
also
got
documentation
on
the
module
string
component
itself,
so
it's
similar
to
other
grafana
agent
components.
So
it's
right
in
the
list,
but
it
starts
with
a
module
Dot.
D
So
that's
what
we've
got
over
here
and
that's
at
least
well
documented.
For
now,
so
that's
the
documentation
side.
What
is
this
stuff
actually
look
like
in
practice
and
we're
going
to
do
a
a
little
demo,
so
we
started
with
this
concept
of
module.string
as
the
first
module
loader
just
make
sure
any
questions,
okay,
good.
D
So
this
is
an
example
of
what
it
would
look
like.
So
here
we've
got
this
module
string
component
and
we
can
see
that
it's
loading
content
from
another
local
file
component
so
for
module.string,
it
kind
of
requires
two
components
to
make
it
work
there
and
you'll
see
Works
we're
prototyping
and
I'm
going
to
demo
what
a
module.file
would
look
like.
So
we
don't
need
multiple
components,
but
here's
an
example
of
that
first
config
that
I
showed
you,
but
we've
broken
it
up
with
modules
into
three
distinct
areas:
metrics
logs
and
traces.
D
So,
instead
of
having
all
the
config
in
one
place,
we've
got
additional
config
files
that
we're
pointing
to
one
one
for
each.
So
that's
how
a
module.string
started,
and
then
we
got
into
the
idea
of
K.
Well,
it's
kind
of
a
bummer
to
have
to
do
both
of
these.
So
what
if
we
try
to
do?
I'll
bring
it
up
here.
D
What,
if
we
just
do
it
as
module
file
and
just
bring
the
file
stuff
inside
so
this
this
module
loader
will
work
with
files.
We've
we're
also
exploring
things
like
module.
Git,
conceptually
that's
been
considered
and
you
know
other
module
ideas.
Let
us
know
we're
definitely
trying
to
brainstorm.
What
ones
would
be
useful.
D
A
F
D
A
Think
the
general
angle
to
think
about
it
is
like
a
module.
Is
the
idea
that
you
can
take
a
set
of
components
and
encapsulate
them
as
one
thing,
so
you
can
have
like
a
pipeline
where
you
discover
things
on
kubernetes
and
scrape
metrics
from
those
things
you
discovered
and
then
filter
some
things
out.
You
can
kind
of
combine
those
three
different
or
those
set
of
components
into
one
module
that
have
other
people
just
import
that
that
module
as
a
single
unit,
I
think
kind
of
like,
like
almost
kind
of
like
a
Helm
chart.
D
Yeah
and
and
to
to
look
at
kind
of
like
a
precise
example
here
or
a
specific
examples,
so
in
this
case
we're
we're
using
a
module
export
to
access
a
component
from
within
the
module.
The
fact
that
this
is
the
hotel
processor
batch
component
is
not
really
important
in
the
sense
that
this
could
have
been
any
flow
component
that
we're
that
we're
exporting.
D
So,
if
I
go
here,
we
can
see
that
this
module
is
exporting.
This
oldtel
processor
batch
default
input,
which
is
which
is
defined
down
here.
So
that's
where
I
say
any
any
flow
component
would
be
compatible
with
doing
this.
You
can
also-
or
you
know,
do
the
same
thing
with
arguments,
so
that's
the
to
go
the
other
direction
to
go
to
push
data
down
into
a
module.
We've
got
this
for
the
metrics.
We've
got
this
Prometheus
exporter
Unix
and
we're
passing
the
targets
of
that
into
a
module.
D
D
D
D
Too,
oh
yeah,
you
get
it
you
you
got
it
so
this
is
just
showing
that
the
the
modules
are
pushing
data
up
to
up
to
the
graphonic
cloud.
I
can
see
if
we
can't
get
the
logs
to
go
up,
but
either
way
so
we've
got,
we've
got
the
metrics,
definitely
the
traces
and
hopefully
get
some
logs
popped
up
here,
but
so
this
gets
running
and
I'll
show
you
the
graph
as
well.
So
the
graph
looks
a
little
different.
We're
still
doing
some
work
on
it.
Let's
refresh
now
that
it's
running.
D
Should
be
running
there,
we
go
so
now
we
can
see
that
this
module
file,
let's
look
at
the
traces
one.
So
here
are
the
the
components
within
the
module.
So,
instead
of
having
all
the
the
components
at
the
top
level
of
our
graph
they're
they're
kind
of
pushed
down
to
within
the
module-
and
then
you
can,
you
can
click
through
those
there's
some
work.
D
We
need
to
do
for
nested
modules
to
make
that
work
nicely,
but
this
is
kind
of
the
gist
of
of
what
it
looks
like
that's
different
than
if
it
was
not
a
module.
So
I
think
that
covers
it.
So
yeah
we've
got
some
finishing
touches
to
do
and
building
more
module.
Loaders
is
is
kind
of
where
we're
at
in
the
development
cycle
here
for
this.
For
this
feature
so.
A
D
D
A
D
Yeah,
it's
hard
to
say,
I
I
kind
of
like,
like
you
saw
kind
of
breaking
up,
my
metrics
logs
and
traces
into
different
pieces
for
reusability.
I
I
could
see
having
modules
for
each
of
the
different
components.
That
kind
of
have
a
working
example,
four
different
components,
but
yeah
I'm
not
totally
sure
on
that.
What
do
you
think
Robert
I?
Guess
you
have
some
thoughts.
A
I'm,
pretending
I,
don't
know
anything
on
modules:
okay,
fine
I'll,
I'll
drop,
the
ACT
I
mean
I
I.
Think
end-to-end
pipelines
are
probably
not
the
best
use
case
of
modules
unless
it's
just
for,
like
you
using
it
locally
to
split
things
up,
I
think
the
more
common
thing,
because
the
intent
modules
are
reusable
right,
I
think
it's
going
to
be
more
common,
that
they
handle
some
subset
of
the
pipeline,
probably
at
least
like
retrieval
and
and
processing,
but
not
delivery.
A
E
D
It
is
running
independent
flow
controllers,
but
right
now
a
failed
module
load
will
stop
the
agent
from
from
starting
up
just
similar
I
guess
to.
If
you
had
a
bad
portion
of
config
in
your
River
file
today
it
wouldn't
start
up
so
I.
Think
I
think
it
kind
of
mirrors
that
for
the
moment,
but
there's
definitely
been
some
conversations
about
that.
D
A
Yeah,
this
is
a
flow
mode
exclusive
feature
we're
putting
most
of
our
efforts
into
flow
mode
right
now.
We
think
it's
the
future
of
the
agent
where
we
can
unlock
all
these.
You
know
new
use
cases.
I
I
want
to
go
back
to
Warrior's
question
real
quick
that
is
so
on
the
initial
load
of
of
the
agent
a
flow.
A
All
components
must
be
healthy,
but
after
that
initial
load,
or
they
must
succeed
to
unloading,
but
after
the
initial
load,
things
can
fail.
So
if
you
start
out
with
a
healthy
agent,
but
then
your
module
has
a
bug
in
it.
The
module
loader
will
will
continue
like
any
other
component
in
its
last
valid
state.
So
you
don't
get
like
a
a
propagating
failure.
In
that
specific
case,
you
just
have
to
make
sure
that
the
the
initial
load
is
air
free.
A
C
C
And,
of
course
much
of
this
is
based
on
previous
work.
There
were
proposals
of
implementing
this
behavior
in
static
mode
early
on,
but
we
never
got
through
to
it,
and
the
contact
is
that
we
routinely
run
the
agents
with
tens
of
millions
in
active
metric
cities
without
hiccups,
and
our
usual
recommendation
is
that
we
start
thinking
about
original
scaling
around
the
2
million
reactive
series
Mark
to
avoid
any
surprises,
if
cardinality,
if
the
cardinality
explodes,
but
the
current
implementations
are
not
really
applicable
to
flow,
they
have
various
drawbacks
like
Hazmat.
C
So
our
goal
is
to
build
the
flow
native
cluster
anymore,
that
can
elastically
scale
the
agent
by
making
use
of
a
single
configuration
file
and
to
do
that
we'll
make
use
of
the
gossip
protocol
it's
what
also
Mimi
and
Locker
using
for
the
distributed
deployment.
So
you
have
some
operational
experience
around
it
and
we
think
it
can
be
a
good
fit
for
anybody
not
familiar
with
what
the
gossip
protocol
is
and
how
it
works.
You
can
see
it
in
action
here.
C
Imagine
you
have
this
20
cluster
node
with
a
fun
node
factor
of
two.
That
means
that
each
node
can
send
a
message
to
two
of
its
neighbors
and
if
we
start
with
the
stop
node
that
receives
one
new
piece
of
information,
we
can
see
where
it
might
send
this
information
to
its
neighbors
and
by
sending
the
message
this
information
is
propagated
in
the
next
in
the
next
cycle.
Each
of
the
nodes
that
has
information
propagates
it
to
more
of
its
neighbors
and
so
on,
and
so
on.
C
C
But
the
magic
Source
here,
The
crucial
part,
is
that
in
the
eventually
consistent
State,
each
node
can
perform
the
Sardine
and
independently
arrive
at
the
same
result.
So,
for
a
specific
has
value
of
x,
all
nodes
will
agree
which
certain
period
is
responsible
for
it
and
in
case
of
cluster
changes,
only
one
over
n
of
these
tokens
will
be
to
be
redistributed.
C
So
for
starters,
we
have
identified
the
two
use
cases
that
we
would
like
to
start
working
towards,
in
sequence:
first
off
Target
distribution.
So
if
all
the
agents
in
the
cluster
have
the
same
configuration
file
and
can
discover
the
same
set
of
targets,
then
we
can
use
this
distributed
sardine
to
make
its
node
only
scrape
the
targets
which
is
under
their
own
ownership.
C
The
Second
Use
case
that
we
would
like
to
enable
later
on
is
to
have
fine
grain
scheduling
so
for
components
that
don't
make
sense
to
run
in
all
the
nodes.
For
example,
you
have
a
10
node
cluster.
We
don't
want
to
run
10
instances
of
a
MySQL
exporter.
For
example,
you
can
only
have
one
or
two
for
high
availability.
C
Then
we
can
make
this
distributed.
The
system
decide
which
node
should
have
ownership
of
that
component,
so
it
gets
good
for
scheduling,
so
here's
how
it
works
right
now,
for
example,
we
can
have
a
prometheus.scrap
component
that
has
to
scrape
these
four
targets,
and
it
also
has
an
argument
that
says:
nodes
update
equals
true.
So
every
time
the
cluster
State
changes
either
a
new
member
joins
the
cluster
or
a
member
leaves
the
cluster
because
it
was
unhealthy
or
whatever.
It
will
call
an
update
method
on
this.
C
The
update
method
of
this
component,
so
it
will
redistribute
the
targets.
I'm.
Sorry
I
can't
make
the
phone
size
any
larger
than
that
right
now,
I
hope
it's
readable.
So
initially
we
can
see
that
the
node
is
responsible
for
five
targets
here,
because
it's
a
a
one
node
cluster,
but
when
a
new
peer
joins
in,
we
can
see
that
it's
only
responsible
for
four
of
them,
since
the
new
node
is
responsible,
takes
ownership
of
one
of
those
same
happens
for
a
winning
new,
and
you
know
the
joins
I.
C
Don't
know
that
we're
tracking
here
has
a
responsibility
for
even
less
of
the
targets,
but
when
it
leaves
it
takes
a
responsibility
of
one
more
and
when
another
joints
it
may
have
a
responsibility
of
more
as
it's
not
like
a
an
exact
match.
But
it's
based
on
the
hash
values
which
will
balance
out
in
the
long
term
and
not
just
for
small
numbers,
go
ahead.
Robert.
C
C
A
C
So
this
means
that
we
lose
efficiency
as
a
you
may
have
to
have
cast
things
that
will
no
longer
be
present
on
this
machine
and
you're
at
headlock
may
become
slower
and
that
kind
of
thing.
Whereas
in
this
approach
you
typically
only
need
to
distribute
1
over
n
of
your
targets
and
you
don't
have
to
recalculate
everything
for
all
so
for
a
10,
node
site
cluster,
you
would
have
to
roughly
redistribute
10
of
the
targets.
I'm,
not
sure
if
it
was
the
best
explanation
here.
If
you
can
chime
in.
A
C
C
C
We
still
have
to
make
sure
that
the
the
loading
of
all
the
flow
components
also
happens
in
a
similar,
smaller
time
frame
than
the
metric
collection
interval,
and
the
roadmap
is
to
make
this
work
as
an
horizontal
political,
scalar,
a
local
government
environment,
to
see
it
in
action.
These
kind
of
systems
are
hard
debug
typically,
so
we
want
to
make
it
some
first
class
debugging
so
that
people
can
actually
understand.
C
What's
going
on
in
the
agents
and
debug
issues,
we
hope
the
flow
UI
can
be
of
help
here
and
also
offers
on
opinion,
United
ways
to
Monitor
and
alert
from
these
clusters.
There's
already
some
metrics
like
to
have
the
conflict
houses
and
see
which
config
files
would
load
and
how
much
time
it
took,
but
there's
still
work
to
do
and
the
plan
is
to
have
something
usable.
This
quarter
so
stay
tuned
for
news,
and
hopefully
we'll
have
something
good
for
you
to
use
yeah.
G
A
All
right
so
last
up,
actually
sorry
so
on
our
agenda.
We
had
like
a
plan
to
talk
about
proposals,
but
before
we
do
that,
is
there
any
questions
that
anyone
has
like
in
general
that
they
want.
They
want
us
to
talk
about
before
we
move
on
I
give
about
30
seconds
for
someone
to
say
yes
or
no
less
than
30
seconds.
A
A
A
good
idea
is
explore
a
new
thing
where,
at
the
end
of
the
community
call
we
all
together
kind
of
look
through
some
of
the
proposals
that
we
have
for
flow
and
figure
out.
Do
they
still
make
sense?
Do
we
want
to
do
this?
We
want
to
close
it
I,
hand-picked
some,
which
will
probably
be
interesting
to
talk
about
and
we'll
see
how
this
goes.
A
We
might
not
do
this
again
if
it's
just
boring,
but
let
me
share
my
screen
and
show
the
first
one
I
have
selected
up
I'm
going
from
oldest
to
newest
here,
so
back
in
September.
This
is
like
right
after
flow
is
like
the
initially
released.
Probably
I
suggested
hey
what
about
a
component
which
can
run
a
binary
on
your
system
and
return
the
output
to
other
flow
components?
A
There's
the
initial
there's
the
obvious
like.
Oh,
no,
that
sounds
insecure
right,
like
there's
that
concern,
but
I
kind
of
just
want
to.
You
know
start
with
that
context,
open
up
the
floor
and
see
what
people
think
if
they
think
this
is
useful
if
they
think
this
is
a
horrible
idea
right
now
it's
in
the
unplanned
Milestone,
so
it's
kind
of
at
risk
I
think
of
just
being
closed
as
like
a
yeah,
we're
not
feeling
cool
with
this
one.
A
G
Matt
yeah
I
mean
there's,
obviously
the
scary
part,
but
I
think
you
know
long
term
with
module.
If
we
have
the
plan
to
introduce
like
for
lack
of
a
better
term
security
levels,
you
know
like
network
access
or
file
system
access.
So
if
we
plug
those
to
the
main
module
and
have
that
has
like
maybe
the
default
off
I
think
this
becomes
a
lot
more
reasonable.
A
G
A
A
So
I
will
say,
like
the
the
initial
use
case
that
I
had
identified
for
this
was
I
wanted
to
run
like
some
components,
to
talk
to
kubernetes,
but
I
needed
to
use
like
a
kubernetes
authentication
helper.
To
even
do
that.
So
here
I'm
showing
like
like
digitalocean
CTL,
to
get
the
credentials
for
kubernetes
cluster
in
like
an
expose
that
as
a
secret
to
components
but
I'm
wondering
if
like
if
anyone's
looking
at
this,
and
they
can
think
to
themselves.
A
A
Any
other
ideas,
any
other
concerns
or
questions.
Do
we
want
to
vote
to
see
what
we
do
with
this
just
figuring
this
as
I
go
I,
I.
Think,
okay,
here,
here's
the
vote.
Here's
the
thing
to
vote
on.
Should
we
do
anything
about
this
right
now
or
should
we
leave
it
and
revisit
later
and
by
do
anything,
I
mean
close
or
you
know
you
know
something.
D
I,
don't
know
where
that
is
closing
now
but
I,
but
I
wonder
if
this
specific
use
case
is
like
the
one
matches
laid
out
if
solving
them
using
something
this
generic
may
not
be
the
answer
ever
you
know
what
I
mean
like
you,
you
would
you
know
it's
a
great
suggestion,
but
would
you
solve
it?
You
know
a
different
a
different
way,
so
you
weren't
opening
yourself
up
too
much.
That's
all.
A
D
A
E
I'm
thinking
this
makes
many
things
that
are
not
possible
today,
like
you,
can
at
least
hack
around
it
right,
I'm
thinking,
you
have
a
very
custom
way
of
decrypting
a
secret
in
your
file
system,
or
you
know,
I
mean
you
can
do
plenty
of
things
with
this.
It's
mostly
around
you
know,
thinking
about
the
security
model,
as
you
know,
I
like
the
idea
of
having
like
this
different
levels
of
security
and
maybe
off
by
default,
but
I
like
that
they
are
having
you
know.
E
A
I
think
one
of
the
things
that
I'm
kind
of
curious
about
is
the
security
model
here
right
because
technically,
there's
already
a
component
to
read
files
from
the
local
file
system
and
you
could
use
Prometheus
remote
right
with
a
like
malicious
server,
not
not
to
give
the
people
attack.
Vector
ideas
on
our
YouTube
recording,
but,
like
you,
could
you
could
technically
use
local
file
and
Prometheus
remote
right
to
send
any
file.
You
want
to
any
server
and
you
have
to
make
sure
when
you're
running
flow.
A
C
A
E
E
A
A
A
A
D
C
A
A
C
A
A
Yeah
I
mean
this
is
I
would
like
this,
because
I
mean
this
is
something
that
comes
up
a
lot.
Loki
prompt
tell
us
something
for
this.
I
mean
sorry
looking
components
too
too,
where
you
can
use
a
label
to
inject
the
the
header
to
write
to,
but
Prometheus
can't
do
that.
So
I
think
I
think
this
really
comes
to
like
a
contribute
to
Prometheus
Upstream
kind
of
thing.
A
A
C
C
Okay,
yeah
I,
see
so
like
for
this
specific
proposal.
I
would
like
I
will
just
post
a
comment
later
on.
I
would
like
to
see
us
have
a
new
component
with
a
disclaimer
that,
like
having
n
different
tenants,
will
make
the
right
head
log
be
n
times
as
large,
and
people
can
see
whether
they
want
the
soccer
head
under
systems
or
not.
People
do
use
code
external,
even
though
it
has
the
same
pixels,
but
it's
it
works
for
them
in
terms
of
the
use
case.
A
All
right
well
with
four
minutes
left
for
the
call
I,
don't
think
it
makes
sense
to
to
do
another.
One
of
these
thanks.
Everyone
for
joining
I
think
this
is
where
I
would
normally
Pander
to
the
to
the
YouTube
audience
like
like
comment
subscribe
all
those
things
it
probably
helps
out.
I,
don't
know
it's
I
don't
run
on
the
Pravana
Channel,
but
we
do
these
monthly
they're
posted
to
YouTube.
We
do
them
live
too.
A
H
H
So
today,
I
tried
to
install
your
funnel
agent
via
VIA
Helm,
chart
and
operator,
and
I
see
that
in
case,
when
I
use,
Operator
Operator
allowed
to
use
service
managers,
but
can't
use
prameters
rules
am
I,
correct
yeah.
Do
you
have
any
plans
to
implement
to
a
greater
using
like
you
using
no
promises
rules
or
any
plans
to
add
possibility
to
grafana
agent
in
flow
mode
to
use
service
mentors
yeah.
A
I
can't
say
a
long,
but
I
can
answer
this
question
at
least
I
think
so
right
now
the
strategy
is:
we've
recognized
that
a
lot
of
people
are
struggling
with
the
operator,
and
so
we
think
that
it
generally
makes
more
sense
and
it's
easier
for
people
to
understand
and
for
us
to
document
and
help
people
be
successful
with.
If
we
took
what
the
operator
does
today
and
moved
it
all
into
flow.