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 <nanog-bounces+jean=ddostest.me@nanog.org> On Behalf Of Saku Ytti Sent: May 17, 2021 3:34 AM To: Sander Steffann <sander@steffann.nl> Cc: Michael Fiumano <mfiumano2@gmail.com>; nanog list <nanog@nanog.org> Subject: Re: Juniper hardware recommendation On Mon, 17 May 2021 at 00:22, Sander Steffann <sander@steffann.nl> 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