►
From YouTube: EOS Node Operator Round Table - Nov 30th 2022
Description
This week the EOS Node Operator Roundtable updates the community on software development and has an in-depth technical discussion on the Prometheus node exporter and how best to relay information to the network.
00:00:00 Start
00:00:03 Recap and this week's topics
00:01:05 Software development
00:10:42 Prometheus technical discussion
00:54:45 End
EOS Node Operator Roundtable Github
https://github.com/EOS-Nation/leap/issues/109
The EOS Network Foundation coordinates financial and non-financial support to encourage the growth and development of the EOS Network. We’re harnessing the power of decentralization to chart a coordinated future for the EOS Network as a force for positive global change.
// EOS Network Foundation //
https://www.eosnetwork.com
https://twitter.com/EosNFoundation
https://www.linkedin.com/company/eos-network-foundation
https://t.me/EOSNetworkFoundation
https://discord.gg/eos-network
info@eosnetwork.com
#EOS #Web3 #antelope
A
A
It's
a
technical
discussion
on
state
database.
Trimming
left
some
notes
Here
for
those
who
want
to
catch
up.
Also
the
recordings
available
and
I
believe
there
are
some
issues
we
already
saw
being
opened
up
coming
out
of
that
conversation
in
the
in
the
enf
repo.
So
that's
awesome
to
see
this
week
on
the
agenda
suggested
by
Matthew
is
a
discussion
on
what
statistics
should
be
added
to
the
Prometheus
exporter
in
leap,
4.0
kind
of
the
problem
there
is
that
no
deal
with
is
a
black
box.
A
We
have
no
idea
what's
happening,
let's
provide
some
statistics
and
the
ask
was
to
bring
a
list
of
what
you'd
like
to
have
in
Prometheus
for
this
call,
so
we
can
talk
about
that
before
we
get
into
that
as
we
normally
do,
I
don't
know
if
there's
any
relevant
updates
on
software
development.
Progress
from
the
enf
side.
B
Yeah
I'll
chime
in
right,
quick
and
say
that
there's
really
no
material
updates
for
this
week.
Of
course,
leap
3.2
is
and
has
been
out.
I
believe
I'll
have
a
more
material
update
around
the
CDT
release
timeline
in
next
week's
meeting.
I
may
also
have
some
updates
for
system
contracts
in
Dune
we're
definitely
shifting
our
Focus
back
that
direction
so
again,
I
think
next
week,
we'll
have
just
more
to
say
about
those.
C
Let
me,
let
me
put
Kevin
on
the
spot
and
I
hope
you
had
a
wonderful
Thanksgiving,
Kevin
and
so
I'm
hoping
you
actually
didn't
get
this
done,
because
you
had
a
wonderful
Thanksgiving
but
I
know.
You've
been
looking
at
running
the
new
Benchmark
code,
with
3.2
against
3.1
to
just
talk
in
terms
of
on
the
same
node
set
up
like
a
relative
percent
increase
or
decrease.
Did
you
have
a
chance
to
run
that
through
yet
or
or
maybe
in
a
week
or
so.
D
Yeah
I
I've
run
it
a
few
times
operator
error
last
night.
Didn't
give
me
good
results.
Issues
with
our
our
actual
performance,
harness
didn't
get
new
results
before
that
that
we've
been
fixing
so
I've
been
debugging,
our
performance
harness
and
then
last
night,
I
I,
just
screwed
up
I
I
copied
a
3-1
into
place
to
to
use,
but
I
didn't
actually
copy
it
in
the
place
to
use.
So
I
got
results
from
4.0
last
night
again,
which
I
verified
that
I'm
getting
stable
results
from
my
4.0
test.
So.
C
D
C
D
What
interesting
thing
that
has
already
come
out
of
that
a
performance
evaluations
that
we're
that
we're
doing
is
at
least
on
our
initial
testing.
The
increasing
the
producer
thread
count
seems
to
have
a
significant
impact
and
performance,
which
is
something
that
we
were
never
able
to
measure
before.
I
know
any
time
that
we
tried
to
measure
that
before
we
weren't,
we
didn't
actually
difference
between
increasing
those
back
in
the
back
in
the
day
back
in
that
other
company.
So.
E
D
E
D
D
I
mean
the
numbers,
I
probably
shouldn't,
say
the
numbers
I'm,
seeing
on
my
machine
they're
quite
remarkable.
Now
it
is
single
producer
and
yada
yada
yada,
but
I
mean
you
have
to
remember
and
I,
don't
know
how
much
we
want
to
go
to
in
this
call,
but
on
the
public
networks
they're
artificially
constrained
to
just
under
under
4
000
TPS,
and
that's
simply
just
settings
that
we
could
change
at
some
point.
A
Some
other
leap
news
not
EOS
related
yesterday,
the
Telos
public
blockchain
upgraded
to
the
successfully
as
far
as
I
can
tell
so
good
news
for
leap.
Adoption
on
public
networks.
I'm,
not
sure,
is
it
now,
just
those
two
EOS
and
Telos
are
the
only
two
public
chains
that
have
leap
activated
as
far
as
I'm
know,.
D
Matthew's
here
you
can
talk
to
that
more
than
I
can
probably
I
mean
they
they
upgraded,
but
no
they're
and
they're.
They
still
haven't
activated
any
of
the
protocol
features
so
they're
still
effectively
on
on
the
old
esio
protocol,
but
some
of
them
are
running
at
Matthew.
Speaking
for
you
here,
but
he's
actually
running
3.2
on
some
of
his
nodes.
Others
are
running
3.1,
others
I
think
are
still
running.
E
Eos
was
a
little
further
ahead
so
anyway,
but
node
operators-
and
you
know-
I
mean
the
layer
twos
and
all
of
that.
For
the
most
part,
a
lot
of
us
are
already
yeah
running
3.1
or
3
dot
somethings
for
a
flavor
of
it
like
it
does
on
wax.
But
no
the
protocols
haven't
been
because
the
system
contracts
on
wax,
which
is
what
tilos
actually
just
finished,
completing
and
then
running
through
test
Nets
and
testing.
F
E
Which
led
to
a
lot
of
yeah
some
of
the
you
know
cleanup
of
the
repos
because
of
the
MC
versions
and
stuff
like
that
right
I
mean
it
was
great
in
blazing
some
reblazing,
some
Trails
on
the
back
side
of
it,
which
is
going
to
you
know,
make
it
easier
for
a
lot
of
the
other
chains
to
kind
of
catch
up
and
Lessons
Learned
going
forward.
So
but
yeah
they've
been
working
on
it,
you
know
because
they
got
a
heavy
set
of
customized
contracts.
E
A
G
E
Network
man,
that's
a
privilege,
not
a
burden,
come
on
man.
Well,
all
of
you
all
are
sleeping
right.
No
I
was
putting
princess
to
bed,
though
at
the
time
I
think
it
got
executed.
I
was
like
you
know,
but
then
I
I
was
sitting
beside
the
computer.
I
was
watching
everything's
going
good.
The
only
node
that
stopped
was
our
2.0
snapshot.
E
C
On
a
a
private
chain,
note
I've
heard
from
Rick
Whitner
that
voice
did
upgrade
to
LEAP
3.1.
Obviously,
it's
a
single
node
setup
and
there
are
no
protocol
features
to
enable
because
it's
not
really
docking
a
protocol,
but
at
least
they've
successfully
update,
upgraded
their
side
chain
that
they
use
to
leap,
cool.
A
E
A
C
D
Is
yeah
he's
working
on
it,
I've
been
reviewing
it
and
doing
some
insight
there,
but
the
so.
The
Prometheus
is,
you
know,
and
I
wasn't
really
prepared
for
this
discussion,
but
Prometheus
is
and
I
don't
know
if
it's
a
standard
so
much
as
just
an
a
particular
implementation,
but
it's
a
it's
a
tool
for
Gathering
statistics
from
a
node.
It's
it's
very
popular
apparently,
and
so
you
know
it
it's
it's.
D
Basically
just
an
HTTP
endpoint
that
you
can
hit
repeatedly
and
pull
information,
there's
also
a
a
push
mechanism,
but
we're
not
we're
not
doing
that
part
we're
just
doing
the
pull,
because
you
can
actually
it
provides
a
a
push
alternative,
even
if
you
only
implement
the
pool.
So
that's
that's
really
all
we
need
to
do
on
our
side
and
the
rest
can
be
tooling
in
in
the
ecosystem,
but
so
it
just
provides
an
endpoint
for
Gathering
statistics.
D
E
D
E
D
E
A
very
standard
product
that
you
know
is
is
open,
source
and
and
free
that,
basically,
you
know
very
regularly
provides
endpoint
with
all
the
metrics
of
that
machine.
You
know
CPU
time
use
memory,
disk
access,
whatever
you
configure
it
to
do,
but
it's
really
kind
of
the
base.
You
know
task
manager,
type
of
Statistics,
but
it's
a
great
tool.
That's
all
a
lot
of
us
admins
kind
of
Bolt
in
additional
info
in
so
oh
I
want
to
monitor
the
nvme
life
cycle
of
my
you
know
dries.
E
So
it's
added
into
the
logic
and
gets
published
via
this
Prometheus.
You
know
node,
exporter,
plug-in
and,
of
course,
I
on
all
the
servers,
and
then
it
just
gets
collected
into
a
master
database
on
the
back
end
and
graphed
and
pretty
and
tracked
or
whatever.
But
node
exporter
is
kind
of
one
of
the
standards.
You
know
it's
like
a
lamp
stack
for
for
sentences,
Linux
admins
for
really
easily
collecting
all
the
node
information
on
the
machine
and
then
publishing
it
in
a
you
can
its
own
Json
version,
but.
D
E
E
And
then
that's
the
framework
to
use
it,
you
know
what
I
mean,
but
the
problem
is:
where
do
you
go
and
get
that
it
knows
what
the
CPU
is
out
of
the
box
and
the
memory
and
the
network
and
all
that
and
you
can
bolt
it
to
do
whatever
the
hell
you
want.
But
you
know
where
is
that?
Is
it
a
local
API
that
gets
queried?
Is
it
big
foul
of
node
OS?
That
may
be
the
only
place?
That's
really
there.
E
It
may
only
have
been
something
displayed
in
the
startup
of
the
node
a
month
ago
whenever
it
fired
up,
you
know,
and
so
that
a
lot
of
the
info
health
feature
and
monitoring
is
really
just
scattered,
and
if
there
were
ways
that
you
could
just
really
just
kind
of
dump
that
info
out
in
that
standard,
Prometheus
format
and
idea,
you
could
very
quickly
bolt
into
a
whole
feature
set
of
now.
I
can
see
what's
going
on,
that
makes
sense,
yeah.
A
G
E
This
is
the
one
that
so
this
is
Live.
Well
I
hit
refresh
live,
so
this
is
the
one
for
Eos
our
current
active
block
producer
and
for
those
of
you,
who've
been
familiar
with,
blockchain.stats.usnation.io
I
know,
Michael
doesn't
use
it,
but
many
of
you
others
of
you
do
so
that
data
comes
from
this.
For
me
this
exporter,
so
you
know
like
this
first
group
of
things
here.
E
Strings
in,
but
you
have
to
do
it
in
this
creative
way
of
making
it
in
there
tweak
the
system
I
think
so
there
we
go.
We
all
built
a
system
that
calculates
all
that
and
then
basically
it's
throwing
that
info
and
then
yeah.
So
exactly
so.
This
is
there's
a
whole
separate
process
that
collects
all
the
data
and
then
makes
it
available.
So
it's
reading
it
from
the
node
us
ini
files
or
apis
or
log
files,
as
Michael
mentioned,
so
it's
getting
it
from
wherever
and
then
making
it
available.
Do.
E
E
F
E
C
C
E
C
C
But
rafana
is
a
is
it
all
of
this
is
open
source
grafana
is
open,
source
Prometheus
is
open.
Source
Brian,
you
in
particular,
should
be
trailing
along
here
and
getting
that
note
and
doing
that
stuff,
I
love
these
Open
Source
Products
I've
used
zabix
and
Prometheus
and
grafana
and
stuff
for
years.
So
this
is.
This
is
just
amazing
that
it's
there
and
this
just
what's
gonna
happen.
When
we
really
expand
this
plug-in,
will
there
there
hopefully
will
be
more
stats
available,
and
you
know
people
that
are
grafana.
C
E
Unless
you
I
can't
expose
my
private
that's
to
fast
forward,
but
I
can
maybe
shoot
it
over
to
Daniel
or
something
he
can
post
it,
but
you
can
monitor
all
you'll
see
we
monitor
all
of
our
proxy.
You
know
information,
the
lack
of
all
the
servers,
you
know,
I
mean
all
sorts
of
different
things
you
can
do
with
it,
but.
C
C
E
F
E
Right
now
we
roll
it
all
together
and
whatever,
but
like
a
lot
of
what
you're
seeing
there
and
a
lot
of
the
magic
that
they
built
and
hard
work
that
doesn't
sound
like
now,
three
that
you
made
it
easy,
but
it's
more
trying
to
get
kind
of
the
help
of
the
chain
how
all
the
BPS
are
looking.
You
know
I
mean
holistically,
but
just
looking
at
it
from
the
log-
and
you
know
a
contextual
View
versus
exposing
things
about
the
node
itself
features
you
know
it
now.
E
It
now
does
at
least
get
info
exposes
earliest
block
log
available.
Things
like
that.
You
know
in
the
log
file,
but
there's
a
difference
and
Masons
is
about
the
only
one
that
tackled
that
holistic.
Looking
View
and
they're
just
straight
or
word
just
scraping
the
logs
and
then
figuring
things
out
well,
the
Aloha
monitor
that's
how
it
kind
of
does
it
latches
on
the
state,
history
and
just
kind
of
listens
and
when
it
attacks
anomalies,
fire
stuff
out.
So
so.
G
Messy,
how
would
you
explain
the
Prometheus
plug-in
in
node?
Yes
like
what
is
the?
What
is
the
wish?
What
does
it
do
so
at
the
moment,
you're
scraping
the
logs
right
and
you
you
go
to
collating
everything
that
you
are
able
to
pull
into
grafana.
What
is
it
if,
if
we,
if
we
enabled
the
plug-in
at
node?
Yes,
what
you
know
what's
its
what's,
this
function.
G
C
G
My
question
is
that
nodius
does
not
know
when
or
track
when
somebody
has
dropped
a
block
per
se.
It's
like
it's
like
a
yeah
in
the
log.
Something
happened,
it
didn't
actually
go
and
say
hey.
This
is:
what's
happened.
Somebody's
got
low,
latency
the
highlight
and
see
that
it
doesn't
say
anything
like
that.
Right,
right.
C
C
There's
some
smarts
in
it,
you
pull
it,
it
doesn't
push.
There
is
a
push
mechanism
as
well.
I
I
believe
that
you
could
set
up,
you
know
a
receiver
site
and
it
and
you
could
make
it
I'm,
not
100
ensure
on
that
Kevin
you'd
have
to.
Let
me
know
if
you
guys
set
it
up
where
it
can
periodically
post
the
stats
to
a
receiver
site.
I.
Think
that's
another
thing
that
can
be
done
in
okay,
Prometheus
as
well.
C
E
C
Network
system
management
tool-
you
can
use
it
to
look
at
your
entire
now,
it's
not
just
for
Block
producers,
I
get
that
I.
Look
at
it
for
just
your
ec2
nodes,
your
local
nodes
and
your
rack
inside
your
data
center.
It
looks
at
any
type
of
statistics
of
your
Linux
of
your
database
of
you
know
you
name
it
your
eight,
your
HTTP.
E
G
C
G
E
F
C
C
G
C
That
says,
when
you
measure
something
you
actually
distort
its
result
and
I
mean.
Obviously
that's
that's
the
age-old
issue
of
of
systems,
monitoring
and
systems
management
like
if
my
processes
that
tell
me
how
well
the
system
is
doing,
make
the
system
run
worse.
Is
it
worth
running
them
or
not?
You
know,
and.
E
The
big
thing
to
me,
like
as
an
example,
is
and
y'all
just
added
it
to
like
get
info,
is
exposing
some
more
of
that
local
node
info.
That's
the
main
thing
it's
doing
right
now
is:
oh,
you
want
to
know
the
earliest
block
blocking
the
log
here.
It
is
in
a
Json
response.
Now
it's
going
to
be
coming
out
in
raw
Prometheus
and
you
don't
have
to
go
through
that
manual
process
of
injecting
it.
E
You
know
maybe
like
State
history,
log
status
and
things
like
that,
but
this
is
more
like
what
nations
does
and
builds
is
or
an
Aloha
is
a
little
bit
more
intelligence,
and
almost
you
know
like,
like
stateful
tracking
of
the
chain
itself,
I
think
it
knows
current
Net
usage
and
you
snapshot
it
and
print
it
over
time.
But,
like
you
know,
missed
blocks
I
guess,
as
an
example,
is
that
that's
what
you
were
talking
about?
E
Ross
right
I
mean
yeah,
because
there's
there's
two
sets
of
stuff:
there's
monitoring
the
node
itself
and
there's
monitoring
the
chain,
and
maybe
one
of
the
requirements
is
oh
I'm
really
concerned
about
my
you
know,
usage
of
my
infrastructure,
so
I
don't
want
to
monitor
the
chain.
I
just
want
to
monitor
my
network
right,
so
I
don't
want
to
enable
all
those
other
stats.
So
that
would
be
you.
G
E
A
E
Mean
like
I,
don't
even
know
if
the
team
is
actually
even
working
on
those
chain
monitoring
things.
Are
they
just
working
on
basic
things
to
just
monitor
the
note,
like
the
current
note,
I
envisioned
it
because
phase
one
and
phase
two
one
is
the
node
info
and
y'all
did
a
great
job
on
get
info
and
getting
some
extra
stats
out
there.
C
Let's
see
Kevin,
can
you
show
what
currently
is
is
planned
in
this
first
release
of
the
Prometheus
plug-in
as
to
what
things
are
being
going
to
be
pulled
back?
Is
it
going
to
be
just
node-based
data,
or
will
there
also
be
some
chain-based
data
and
will
it
be
configurable
I
only
want
these
parameters
versus
those?
Obviously
you
can
throw
ones.
You
don't
want
to
weigh
on
the
floor,
but
you're,
possibly
causing
more
work
on
the
on
the
Node
or
at
least
on
The
Wire.
D
D
That's
kind
of
what
hoping
we're
getting
from
this
meeting
is
what
we're
kind
of
interested
in
seeing
well
we've
been
focused
on
so
far
is
some
of
what's
been
alluded
to
the
fact
that
how
do
we
gather
statistics
without
impacting
the
node
or
at
least
minimizing
the
impact
of
that
node?
And
so
you
know
we
want
the
that
endpoint
to
be
on
a
different
thread.
D
So
the
the
approach
is
effectively
that
the
main
thread
and
other
other
plugins,
the
various
components
of
node,
is
Will
Will
effectively
push
into
the
Prometheus
plug-in
the
information
that
that
they
that
they're
providing
and
then
the
Prometheus
plugin
will
gather
that
up
and
answer
requests
on
a
separate
thread.
So
the
the
the
the
impact
there
should
be
minimum
in
terms
of
like
threat
contention,
it's
still
going
to
be
there.
I
mean
there's
absolutely
no
way
to
get
around
that
ultimately,
but
it
should
be
at
least
that's
the
theory.
D
D
You
know
we're
producing
a
new
block,
every
half
a
second,
so
you
know
even
every
100
milliseconds
is
probably
not
unreasonable
to
to
query
something
like
this
and
it
not
really
have
a
a
huge
effect
because
again
we're
doing
most
of
the
most
of
the
lift
on
a
separate
thread.
So
what
you
want
to
what
you
want
to
gather?
D
I
think
it's
basically
all
we're
currently
tracking,
but
obviously
we
want
to
expand
that,
and
once
we
have
the
framework
expanding,
it
should
be
easy
right.
It's
just
a
matter
of!
Oh
you
want
this.
Okay,
we'll
add
it.
You
know,
and
you
know
that
part
gets,
that
part
gets
easier.
It's
getting
the
the
all
the
the
plumbing
and
everything
in
place
to
make
that
then
easier.
E
My
thought
was:
I've
got,
you
know,
I
mean
I,
went
down
this
path
of
what
you're
building
your
own
check.
This
data
and
oh
crap
I
gotta
check
this
because
I
forgot
about
it
refer
me:
I
can
kind
of
rattle
off
as
an
operator
what
some
of
the
things
I
was
looking
and
checking
and
displaying
as
well
as
you
know,
where
I
had
to
go
and
get
it
you
know
or
where
I,
where
I
ended
up
finding
it.
If
that's
helpful
I
mean
I
know
we
only
have
limited
time
but
yeah.
E
E
So,
and
some
of
it
is
you
know
in
the
get
info,
so
you
know
we
we
track
the
the
version
of
the
server
we
track.
You
know
head
block
lib
difference
between
the
two.
You
know,
if
it's
out
of
sync
things
like
that,
but
I
mean
that's
all.
You
know
generic
info,
that's
kind
of
out
there
that
didn't
get
info
right
now.
What
is
some
additional?
E
That
you
know
you
couldn't
get
from
the
get
info
was
we
ended
up
going
to
the
configs
of
the
nodes
to
try
to
see
what
run
time
it
was
running,
because
that
was
a
big
thing
dear
in
Watson
and
jit,
and
all
that
shift
over
is
OC
enabled
on
the
Node
and
then
potentially
threads
all
that
kind
of
stuff,
yeah.
Okay,
the
is
console
logging
on
you
know
for
State,
history
and
or
API.
E
The
features
and
I
ran
into
this
because
it
does
have
available
features
or
whatever,
but
when
you
have
8
000
servers,
I
mean
I.
Can't
even
my
public
endpoint
doesn't
show
everything,
because
it's
going
through
eight
different
servers
providing
all
the
different
services,
so
I
would
go
to
the
config
and
look
and
see
you
know.
What
does
it
have
account?
Db
enabled.
Does
you
know?
What's
the
maximum
API
timeouts?
What's
the
AP
HTTP
Max
I,
don't
remember
which
one
exactly
that
is,
but
all
the
things
that
over
the
years,
all
the
switches
yeah?
E
Last
offset
as
a
block
producer,
damn
I
didn't
realize.
That
was
a
40.
You
know
that
needs
to
be
three
percent
on
this
node.
You
know
so
things
like
that,
where
we
really
kind
of
had
to
parse
through
the
config
file
of
every
single
node
and
then
expose
it
as
as
local
configuration
options,
so
even
account
DB,
because
it
wouldn't
show
up
right.
Sorry.
G
E
G
H
E
The
first
one
you
talked
about
really
it's
it's
about
the
machine
itself
right.
So
if
you
look
at
Network,
you
know
you
could
do
that
from
the
C
advisor
Prometheus
exporter,
which
gives
you
all
the
or
the
the
node
exporter,
depending
on,
if
you're,
in
a
container
or
the
note
right.
So
the
default
Prometheus
thing
is
that
so
it
provides
all
the
operating
statistics
and
all
that
stuff
right
for
the
node
for
the
whole
machine
or
container
right
and
then
there's
the
node
node
us
version
of
that
versus
the
machine.
E
E
E
E
E
You
run
like
you
know,
or
EOS
right
I
mean
we
trim
it
down
to
like
five
percent
on
some
of
these
things
right,
so
it's
just
being
able
to
see
that
without
having
to
go
and
pull
it
out
of
the
damn
config
file.
Additionally,
we
also
and
I
think
it's
better
is
the
the
block
logs.
You
know
I
mean.
Is
that
a
full
node
or
is
it
not
a
node
or
you
know
a
trim,
light
node
as
well
as
way
more
exposure
to
even
a
tool?
What's
in
the
State
history,
because.
D
G
H
E
G
E
Files
have
two
through
whatever
and
then
obviously
you
assumed
it's
more
March
forward.
If
it's
not
screaming
at
you
about
missing
a
block
in
State
history
yeah.
But
again
that
is
even
way
more
obscure.
Great
news
is
it's
a
much
more
resilient
process,
so
it
makes
itself
much
better,
but
that
was
something
I
couldn't
even
use
a
smoke
test
of
the
eosyl
block
log,
which
is
how
I
used
to
get
that
info
now
get
info
does
provide
that,
but
that
for
State
history
would
also
be
nice
as
well.
E
I,
don't
even
think
it's
anywhere
in
memory,
probably,
but
those
are
a
lot
of
the
big
pieces
I
have,
but
you
know,
parameters
in
your
your
config
file,
as
well
as
like
Matthew,
even
noticed
and
sounds
like
log
number
of
peers
connected
I'll
also
say
you
know,
maybe
even
at
a
granular
level,
there's
a
difference
between
external
peers
coming
in
and
internal
peers
going
out.
Obviously,
node
OS
knows
that,
but
there
is
actually
a
difference
fundamentally
any
other
ideas.
Now
that
I
mean
I
know
we're
running
out
of
time.
F
I
have
a
question
actually
about.
Some
of
the
things
that
you
mentioned
like
is,
is
Prometheus
the
right
place
for
those
things,
because
we
at
the
beginning
of
this
call
we
said
Prometheus
is
a
Time
series
database
and
many
of
the
things
that
you
mentioned.
Are
they
I?
Have
the
question
of?
Are
they
helpful
to
track
on
in
a
Time
series
you
know,
I
was
I
was
sort
of
imagining
more
things.
G
E
E
G
C
I
mean
you
can
make
a
different
plug-in
for
different
data.
The
reason
it's
called
Prometheus
is
the
server
that's
actually
calling
from
for
the
data
at
the
endpoint
is
an
actual
Prometheus
server,
that's
running
either
at
EOS,
Nation
or
somewhere
else.
You
can
run
it
in
your
house
and
you
know,
hit
the
node.
C
It's
an
open
source
server.
You
can
download
it
and
run
it,
and
so
you
can
have
like
on
off
State
information
and
like
did
every
time
it
pulls
it.
It
says
on
on
on
on,
and
you
see
this
one
zero
line
that
just
goes
one
and
then
someday.
Someone
turns
that
feature
off
and
it
switches
to
off
and
what
you
would
do
with
that
is
you'd.
Look
back
at
the
last
24
days,
365
days
and
you'd
say:
oh,
this
feature
got
turned
off
on
April,
14th
or
whatever,
because.
E
H
H
G
Ted,
what
what
the
reason
why
I
kind
of
came
in
at
that
angle
is:
we've
actually
started
building
our
own
platform,
that's
going
to
be
public
or
it
is
already
publicly
available
for
people
to
just
spin
up
their
own
Docker
instance
of
a
monitoring
solution
and
that
that
will
definitely
use
this
interface,
but
it
won't
be
Prometheus.
That's
get
that
squaring
it
right
so
and
that's
why
I'm
saying
that
you
know
if
you,
you
could
say
it's
hey.
It's
suitable
for
Prometheus
woman!
Well,.
C
Here's
why
here's
here's?
Why
I
would
say
you
should
call
it
Prometheus,
because
anyone
in
their
right
mind
would
have
done
this
in
Json
and
in
Json
you'd,
be
like
oh
awesome.
Here's
a
Json
payload
of
all
this
data
that
I
may
be
even
did
a
graphql
input
to
say
which
Fields
I
wanted
back
well
wow
this
thing's,
so
amazing.
E
E
C
To
still
create
the
so
you
know,
I
get
what
you're
saying
we're
not
saying
that
nothing
will
ever
change
in
the
future
and
you
can't
have
the
requirements.
That's
why
we're
talking
to
you?
The
the
thing
is
the
first
request
that
came
in
that
were
fulfilling
was
make
it
where
it's
Prometheus
compatible
all
because
the
majority
of
people
running
these
systems
management
nodes
are
running
Prometheus.
So
we.
C
E
C
Trying
to
say
is
the
people
that
made
the
request.
First
were
running
Prometheus.
We
were
shocked
too
at
how
backwards
the
Prometheus
interface
is.
So
that's
what
got
built
first,
I
agree
with
you.
The
marshalling
of
the
data
on
the
outbound
response
to
the
get
request
is
relatively
straightforward
as
a
follow-on,
and
we
could
put
it
in
some
Json
format,
but
the
Json
format
it
comes
back
in
will
likely
be
compatible
with
nothing
other
than
custom
parsers
that
are
written
on
the
other
end.
This
is
at
least
compatible
out
of
the
box.
G
C
E
F
E
G
G
A
F
E
C
B
C
G
C
F
That
matter,
like
I
I,
will
you
know
I
invite
you
to
proactively.
Send
me
stuff
this.
This
goes
out
to
everybody
on
the
call
and
anybody
who's
who's
watching
or
checking
the
notes
afterwards.
Yeah
you
can.
You
can
message
me
directly
for
those
of
you
that
I
already
know
and
speak
to
I'll
reach
out
to
you
as
well
and
and
try
to
pull
it
out
of
you
so
and.