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