Juniper hardware recommendation

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.

Jean

-----Original Message-----
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.

--
  ++ytti