Good monitoring softwares allow to do "preprocessing" before storing the monitored data in database.
Saku's formula should work well in this case. I use Zabbix for monitoring big infrastructure. It has many advantages like: - Push or pull metrics (dmz friendly) - Can use many proxies (scale well) - preprocessing of data (fix vendors mess) - alert based on business logic through templates ( proactive instead of reactive) - open source and have enterprise support (always nice to be able to call 1800 zabbix in case of emergency) - agent, agentless, discovery, snmp, java/jmx, telnet, ipmi, web scenarios, etc (never face a coirner-case that can't be monitored so far) Really awesome at infrastructure level. Jean -----Original Message----- From: NANOG <[email protected]> On Behalf Of Saku Ytti Sent: May 17, 2021 3:34 AM To: Sander Steffann <[email protected]> Cc: Michael Fiumano <[email protected]>; nanog list <[email protected]> Subject: Re: Juniper hardware recommendation On Mon, 17 May 2021 at 00:22, Sander Steffann <[email protected]> wrote: > How do you normalise? Use L2 or L3 octets stats, and use the number of > packets to calculate the L2 and/or L1 overhead the stats are missing? > Or do you have a better way? That's the way one of my employers did it, and I can't think of a better way. bytes += PPS*overhead Overhead is likely 20bytes (preamble, SFD, ifg). But it could also be 24B (FCS/CRC might be missing in what otherwise is claimed to be L2). You may need a lab to confirm what exactly is being counted. This adjustment could be in DB or it could be render-time, both have pro and con. -- ++ytti
