Re: getting started with pfstat

2006-07-13 Thread Peter

--- Daniel Hartmeier <[EMAIL PROTECTED]> wrote:

> On Thu, Jul 13, 2006 at 11:07:46AM -0400, Peter wrote:
> 
> > I have installed the pfstat 1.7 package on my 3.8 system.  The
> trouble
> > is that I do not get any data being graphed.  Here is my test
> setup:
> > 
> > # cat /etc/pf.conf
> > pass log all
> 
> Add "set loginterface fxp0", which designates one interface to
> collect
> those counters for, which pfstat collects.
> 
> (newer versions of pfstat can query other interface counters, so the
> loginterface isn't needed anymore, and you can plot graphs for
> multiple
> interfaces)
> 
> > Bonus question: How does the program reconcile the data file being
> > updated at a different interval than the one the graph is being
> > generated with (i.e. every one minute as opposed to every five
> > minutes)?
> 
> Each line contains the timestamp (unix epoch time, seconds since
> 1970)
> of when the counters had those values of that line.
> 
> The rest is simple math done by pfstat. When it needs to find out
> which
> height to draw one specific pixel at, it calculates what timestamps
> the
> left and right edge of the pixel represent. For example, if you plot
> a
> whole year on 800 pixels width, one pixel represents about
> 365*24*60*60/800 == 39420 seconds. If this is left-most pixel, and
> you
> plot the year ending with timestamp 1152805255 (today, 17:40:55
> MEST),
> that pixel represents the time range 1152765835-1152805255.
> 
> For that pixel, pfstat will take all log entries that fall at least
> partly within that range, and calculates weighted average, minimum,
> and
> maximum of all matching log entries.
> 
> While it costs a little CPU time to do that, it allows to plot graphs
> with arbitrary widths over arbitray time ranges, no matter how often
> or
> regular the values are collected. In extreme cases (much more pixels
> than values), you'll see one value spread over many pixels,
> generating a
> "blocky" staircase or even a simple horizontal line. But the average
> should be mathematically correct, i.e. the area below the line (width
> times height) matches the amount of bytes transfered in that time
> period.
> 
> Daniel

Thank you Sir.
Peter 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


Re: getting started with pfstat

2006-07-13 Thread Daniel Hartmeier
On Thu, Jul 13, 2006 at 11:07:46AM -0400, Peter wrote:

> I have installed the pfstat 1.7 package on my 3.8 system.  The trouble
> is that I do not get any data being graphed.  Here is my test setup:
> 
> # cat /etc/pf.conf
> pass log all

Add "set loginterface fxp0", which designates one interface to collect
those counters for, which pfstat collects.

(newer versions of pfstat can query other interface counters, so the
loginterface isn't needed anymore, and you can plot graphs for multiple
interfaces)

> Bonus question: How does the program reconcile the data file being
> updated at a different interval than the one the graph is being
> generated with (i.e. every one minute as opposed to every five
> minutes)?

Each line contains the timestamp (unix epoch time, seconds since 1970)
of when the counters had those values of that line.

The rest is simple math done by pfstat. When it needs to find out which
height to draw one specific pixel at, it calculates what timestamps the
left and right edge of the pixel represent. For example, if you plot a
whole year on 800 pixels width, one pixel represents about
365*24*60*60/800 == 39420 seconds. If this is left-most pixel, and you
plot the year ending with timestamp 1152805255 (today, 17:40:55 MEST),
that pixel represents the time range 1152765835-1152805255.

For that pixel, pfstat will take all log entries that fall at least
partly within that range, and calculates weighted average, minimum, and
maximum of all matching log entries.

While it costs a little CPU time to do that, it allows to plot graphs
with arbitrary widths over arbitray time ranges, no matter how often or
regular the values are collected. In extreme cases (much more pixels
than values), you'll see one value spread over many pixels, generating a
"blocky" staircase or even a simple horizontal line. But the average
should be mathematically correct, i.e. the area below the line (width
times height) matches the amount of bytes transfered in that time
period.

Daniel