►
From YouTube: Episode 23: Antrea Network Flow Visibility
Description
Come and join Anlan and Yongming to explore antrea flow visibility using Grafana. It's a new feature added to antrea 1.6!
A
B
C
Everyone,
my
name
is
yumi.
I
work
for
andrea
team
at
1.5
year
and
mostly
focus
on
the
flow
availability
stuff.
Currently,
we
are
building
the
solutions
to
for
the
monetary
and
gives
the
visibility
to
the
user
with
the
poor
traffic
and
extra
I'm
online,
and
I
and
also
us
also,
we
have
other
team
members
are
working
on
these
features
to
maintain
this
and
create
new
features.
A
Okay,
thanks
for
like
telling
us
a
little
bit
about
yourself
and
also
we
have
zach
and
scott
here
with
us,
hi,
jack
and
scott,
and
for
all
the
audience.
If
you
want
to
interact
with
us,
please
log
in
to
your
youtube
account.
So
you
can
leave
your
comments
in
in
you
know,
so
you
can
post
your
comments
and
we
can
show
them
in
our
screen
in
our
live.
Show,
okay,
so
alan,
would
you
like
to
go
ahead
and
share
your
screen
to
tell
tell
us
a
little
bit
about
this
network
visibility.
B
I
think
I'll
start
with
a
very
helpful
architecture
diagram
here.
So
in
our
project
we
have
two
main
building
blocks.
The
first
one
is
called
flow
exporter,
so
for
exporter
is
running
as
part
of
our
entry
agent
and
the
main
functionality
of
our
flow
exporter
is
to
periodically
pulling
from
contract.
B
I
think
here
maybe
we
can
like
stop
and
look
what
kind
of
fields
are
included
in
those
flow
flow
records,
so
that
so
that
we
can
have
a
bet,
a
better
idea
like
knowing
what
the
metadata
in
the
flow
records.
So
we
have
those
kind
of
fields.
For
example,
we
have
time
stamped
those
four
star
seconds
which
represents
when
the
flow
start
and
also
we
have
flow
n
seconds,
which
is
the
most
up
to
date.
B
Seconds
of
our
current
flow
connection,
and
also
we
have
the
v4
addresses
and
v6
addresses
in
separate
fields,
and
we
have
port
and
also
the
packet
account
and
by
count
of
the
current
connection,
which
will
record
like
how
many
five,
how
many
dice
and
packets
are
currently
flowing
in
this
connection,
and
we
also
have
the
reverse
count.
So
the
pack
account
and
icon
here
means
the
packing
accounts
going
from
source
to
destination,
but
the
reverse
packet
and
bytes
means
the
the
packet
invites
going
from
destination
to
source.
B
So
that's
why
it's
called
a
reverse
count
and
we
also
added
some
kubernetes
resources:
specific
metadata,
for
example,
pod
namespace,
pawn
name
also
destination,
pawn
m
and
no
name
in
the
cluster
ip
service
port,
and
also
we
have
a
bunch
of
network
policy
related
metadata
here,
postman
space
type
role,
name,
etc,
and
we
also
have
photo
photo.
Basically,
you
represent
a
weather
connection
is
a
internal
connection
or
it
is
a
internode
or
it
stands
for
from
front
clustered
to
external
network.
B
Currently
we
have
three
three
kinds
of
different
flow
collectors
there,
the
first
one
is
ipfix
for
flagship
with
with
this
with
ibfx
flow
collector,
we
can
kind
of
print
out
the
flow
records
in
our
terminal,
but
but
but
we
can
imagine
that
is
not
not
so
much
helpful
compared
to
ui.
So
so
that's
why
we
also
have
two
different
to
other
kind
of
flow
collector.
The
first
one
is
eok
for
collector.
This
is
the
one
which
we
previously
supported,
but
now,
due
to
some
license
dependency
issue.
A
A
A
A
A
A
A
B
B
A
B
A
A
A
B
B
A
A
A
C
Yeah,
I
think
we
don't
do
the
aggregation
inside
the
database.
Actually,
we
have
a.
We
have
a
component
called
flow
aggregator
which
will
get
the
flow
data
from
to
exporter
and
we
will
do
correlation
and
aggregation
as
this
as
this
service
and
then
the
flow
aggregator
will
export
will
send
out
the
the
flow
records
after
aggregation
to
the
database.
So
on
the
database
that
we
don't
have
any
aggregation
process
there.
B
C
D
A
B
D
A
B
Yeah,
that's
nice,
okay,
yeah
so
like,
since
you
just
said
for
full
aggregator.
We
have
three
main
functionalities,
storage,
correlation
and
aggregation
which,
like
I
think,
can
answer
one
of
the
questions
that
we
just
encounter
and
if
we
have
time
at
the
end,
you
mean
we'll
go
more
in
detail
into
those
three
functionalities.
B
B
B
B
B
B
B
B
So
here
we
can
see
we
have
in
total
six
dashboards.
The
first
one
is
flow
records
dashboard.
This
is
functioning
like
the
the
base
dashboard
which
which
contains
the
total
count
of
flow
records
we
currently
have
in
our
database
and
also
the
time
series
data
and
also
we
have
pod
to
pause,
dashboard,
positive
service
dashboard
part
external
dashboard.
There
are,
they
are
very
similar.
B
The
difference
is
just
the
destination
pod
type
or
whether
it's
a
pod
or
it's
a
service
or
the
or
the
destination,
is
an
external
ip,
and
also
we
have
no
to
no
dashboard
and
also
a
network
policy.
Dashboard,
let's
see
currently
is
zero
because
it
takes
some
time
for
for
the
flow
records
to
be
exported
from
full
exporter
and
then
to
aggregator
and
then
to
graph.
B
So
currently,
the
flow
aggregator
is
is
an
arrow
because
flow
aggregator
is,
is
previously
deployed
and-
and
it
is
awaiting
to
be
connected
to
the
click
house
server,
but
we
we
first
start
the
flow
irrigator
and
then
we
start
the
clear
house
server.
So
the
aggregator
will
well
well
hit
arrow
when,
when
it
is
trying
to
get
connected
to
the
server
normally
it
will
just
recover
in
a
few
minutes.
C
B
B
B
B
We
have
two
sankey
diagram
at
the
top,
so
the
second
diagram
will
show
the
source
path.
Information
on
the
left
hand,
side
and
shows
the
destination
proclamation
on
the
right
hand,
side.
If
we
just
hover
on
our
mouse
onto
the
link,
it
will
show
the
source
pawn
land
going
to
the
destination
pawn
m
and
how
many
bytes
are
are
going
through
this
connection
and
on
the
left
hand
side
is
the
is
the
bias
going
from
source
to
destination
and,
on
the
right
hand,
side
it's
it's
recording
the
reverse,
bytes
going
from
destination
to
source.
B
C
A
B
Documents-
yes,
yes,
yes,
that's
right!
So
so
currently
I
I
I
didn't
generate
any
deny
narrow
policy.
So
if
we
have
that
we
can
like
filtering
on
this
real
action
field
and
trying
to
find
those
connections
that
have
to
deny
narrow
powers
enforced
to
it,
but
but
for
for
for
the
next
release.
We'll
also
add
this
part
into
our
network
policy
dashboard.
B
So
currently,
our
now
our
narrow
policy
dashboard
only
visualize
the
allow
traffic,
but
for
our
next
release
we
will
also
add
a
support
for
the
denied
traffic,
so
those
denied
traffic
will
be
represent
in
different
colors
to
to
to
to
distinguish
those
from
the
allow
traffic.
So
that
is
a
future
feature
that
we
can
inspect.
B
See
joey
is
asking:
why
did
we
move
from
elk
to
grafana?
So
the
reason
is
elk
is
previously
open
source,
but
then
they
were
too
licensed
based.
So
that
means
we
cannot
just
depend
on
them
anymore.
So
that's
why
we're
moving
away
from
elk
to
graffana
and
another
reason
is.
We
have
found
some
performance
issue
with
with
logstash.
B
B
Okay,
I
I
think
we
can.
I
can
move
on
to
another
topic
that
is
doing
some
customization
on
our
dashboard.
For
example,
if
we,
if
we
want
to
add
a
new
panel
on
our
previous
dashboard,
how
can
we
do
that?
We
can
just
click
on
the
add
panel
button
here
and
add
a
new
panel
and
we
can
select
the
visualization
we
want,
for
example,
if
we
just
want
to
do
the
statistic
one,
and
then
we
select
our
data
source,
which
is
click
house,
and
let's,
let's
write
some
queries
here.
A
B
B
A
B
And
we
can
just
quickly
save
that
for
here,
but
if
we,
if
you
want
to
do
something
like
more
more
advanced,
for
example,
we
want
to
create
a
dashboard
from
scratch.
We
don't
we
don't
want
just
to
customize
our
preview
dashboard.
We
can
just
create
a
brand
new
one.
So
in
this
new
dashboard
we're
just
doing
the
same
thing,
we
we
add
panels
and
we
can
do
multiple
of
them.
B
And
we
save
this
dashboard,
so
it
will
be
available
here,
new
dashboard,
but
one
thing
to
be
mentioned
is:
if
we
just
click
on
save
dashboard.
These
changes
will
only
be
saved
for
this
runtime,
which
means
if
we
just
stop
our
graffana
pod
and
redeploy
the
pod.
Those
changes
will
not
still
be
there
for
the
restart.
B
So
if
we
want
to
have
if
we
want
to
have
these
changes
saved
for
the
restart,
there
are
two
ways
to
do
that.
The
first
way
is
we
just
export
it
and
save
save
the
json
file
somewhere
and
the
next
time
we
can
just
import
the
json
file
so
that
we
can
bring
the
dashboard
back
to
our
graphing
ui.
So
that's
the
first
way,
let's
say
manually,
export
and
import.
B
A
B
A
B
A
B
A
B
A
C
A
C
Yes,
thanks
ella,
so
actual
flow
aggregator
is
behaves
like
a
lack
of
three
parts.
The
first
one
is
called
a
collecting
process,
since
there
are
multiple
kinds
coming
from
the
flow
exporter
are
sending
flow
records
to
the
flow
aggregator.
So
the
first
step
of
the
flow
regulator
will
collecting
these
flow
records
and
the
second
part
is
called
the
aggregation
process.
C
With
this
524
we
could
identify
identify
a
single
network
connections
and
all
the
flow
records
coming
from
flow
exporter
have
the
same
vector.
We
will
do
the
correlation
and
aggregation
here.
The
interesting
part
here
is
that,
if,
if
there
is
the
flow
record,
which
is
correlating
to
internal
flows
such
as
the
source,
the
source
port
and
destination
port
are
located
in
different
nodes,
so
in
that
case,
after
the
correlating
the
source,
the
flow
records
coming
from
the
source
node
flow
exporter
will
have
the
information
of
the
source
port,
so
flow.
C
Rockers
coming
from
the
destination
node
flow
exporter
will
have
the
information
of
the
destination
port.
In
this
case,
we
could
do
the
correlation
here,
and
the
flow
records
sent
by
the
flow
aggregator
will
have
the
port.
We
have
the
pawn
name
for
both
the
software
and
destination
part.
We
could
do
more
beyond
the
correlation
here,
since
we
have
some
more
information
here
and,
for
example,
the
the
full
records
sent
by
the
flow
aggregator.
We
also
have
the
throughput
information
based
on
the
flow
records.
C
D
A
D
C
If,
if,
if
the
flow
character
is
our
new
graphana
flow
flow
character,
we
will
use
the
clean
house
client
to
send
all
the
full
records
directly
into
the
database
yeah.
Basically,
that's
that's.
What
does
this
was
also
actually
do,
and
if
we,
if
you
are
interesting,
we
could
also
we
are
all.
We
also
have
the
uncutter
support
for
the
full
record.
If
you
do
not
want
to
set
up
a
grafana
flow
character
or
elk
flow
catcher,
you
could
simply
log
into
the
flow
aggregator
port
and
run
some
uncutter
commands.
A
Okay,
so,
basically,
what
you
are
saying
is
that
from
this
graph
we
can
see
that
each
for
each
flow
exporter
only
runs
each
node
right,
so
it
I
can
only
see
the
information
within
this
node,
but
the
flow
aggregator
here
collects
all
the
data
from
each
node.
So
the
flow
aggregator
has
the
information
in
the
cluster
scope
not
within
like
each
specific,
specific
node.
So
it
can.
D
C
B
Cinchy,
could
you
just
let
me
to
share
with
you?
Yes,
so
we
have.
We
have.
We
have
added
two
two
data
retention
methods
to
prevent
this
kind
of
data
restart.
So
for
for
these
two
methods,
the
first
one
is
ttl
mechanism,
so
basically
ttl
will
periodically
delete
the
expired
flow
records
in
our
database.
B
A
Yeah,
I
think
this
is
a
great
answer
to
this
question
and
is
there
any
other
questions
by
the
way?
If
I
remember
this
correctly,
it's
the
first
time
in
our
intro
like
show
that
we
cover
the
flow
of
visibility,
part
and
it's
like
really
really
sensu,
and
you
mean
to
tell
us
a
little
bit
about
this
aggregator.
I
don't
know
about
this
like
the
dashboard,
and
we
can,
of
course
like
use
that
to
on
troubleshooting
the
cluster
or
like
do
some
statistics
based
on
the
beautiful
dashboard
review.