faucet
faucet copied to clipboard
gauge does not expire entries when flow rules expire
The host learning table gauge results will linger after the rules themselves are gone so it's hard (impossible?) for monitoring to check the host learned state.
FAUCET tracks learning state at a port, host and VLAN level. Scraping Gauge is not a good solution because Gauge doesn't know anything about learning - it's scrapes flow tables.
What we wanted was visibility in to the actual flow tables... we're trying to track down a bug somewhere and trying to get more eyes on the system -- remoting into all the switches is problematic. Shouldn't gauge be able to (indirectly) tell us about the learning state since it should be reflected in the flow tables? The question here is, very specifically, about monitoring the state of OF tables on the switch.
On Mon, Sep 30, 2019 at 6:12 PM Josh Bailey [email protected] wrote:
FAUCET tracks learning state at a port, host and VLAN level. Scraping Gauge is not a good solution because Gauge doesn't know anything about learning - it's scrapes flow tables.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/faucetsdn/faucet/issues/3264?email_source=notifications&email_token=AAIEPD3VG5R4NIVCVGOF7CLQMKPV7A5CNFSM4I4CQVF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD77SNIY#issuecomment-536815267, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIEPD66N2IMXMNMWEHJM43QMKPV7ANCNFSM4I4CQVFQ .
Sure, it should stay synchronized with the flow table. That's a bug.
However inferring the learning state from the flow table as a general rule is going to be hard on a big system. It's probably the wrong tool for the job. More tests that test what you want and more Prometheus variables etc are going to be better.