Index | Thread | Search

From:
Stuart Henderson <stu@spacehopper.org>
Subject:
Re: [new] pf_exporter
To:
Nick Owens <mischief@offblast.org>
Cc:
Abel Abraham Camarillo Ojeda <acamari@verlet.org>, ports@openbsd.org
Date:
Tue, 8 Oct 2024 15:18:40 +0100

Download raw body.

Thread
On 2024/10/05 22:46, Nick Owens wrote:
> On Sat, Oct 5, 2024 at 7:41 PM Abel Abraham Camarillo Ojeda
> <acamari@verlet.org> wrote:
> >
> >
> >
> > On Sat, Oct 5, 2024 at 1:15 PM Nick Owens <mischief@offblast.org> wrote:
> >>
> >> On Sat, Sep 28, 2024 at 11:40 PM Nick Owens <mischief@offblast.org> wrote:
> >> >
> >> > hi,
> >> >
> >> > i spent today doing a little work on my prometheus (sysutils/prometheus)
> >> > exporter for pf. this program exports some metrics for pf. it can
> >> > export the top level pf stats (states, searches, etc), the loginterface
> >> > stats, and the drop/transmit counts for each queue.
> >> >
> >> > my personal usage of pf is pretty limited to my own home firewall, so i
> >> > can't really say this is battle tested, but i thought since i updated
> >> > it, i'd try my hand at my first ever openbsd port, so here it is :-)
> >> >
> >> > there are certainly warts, like the questionable file descriptor passing
> >> > and use of the 'nobody' user in the rc.d script, but feedback is
> >> > welcome.
> >> >
> >> > cheers,
> >> > nick
> >> >
> >>
> >> ping
> >
> >
> > Are there info you get with this that you can't get with, for example, snmpd + snmp_exporter ?
> 
> i admit i've never used or been interested in SNMP, though, it's hard
> to tell to the untrained eye if snmpd can read statistics for pf
> queues. that was my main interest when writing pf_exporter.

I think not at the moment, but it could be added.

More importantly, that is in base, so will get fixed if the PF API/ABI
changes.

The state of some pf-related things in ports isn't great - IIRC some of
those haven't really coped properly after queue changes many releases
ago.

I didn't check - how does pf_exporter retrieve stats? If it's via
parsing pfctl output then it's going to be reasonably resilient - but
if it's via /dev/pf then I'm not too excited about adding something
else relying on kernel ABI (especially something not in C so it can't
directly use system headers).