Your opinion about adding Smokeping for monitoring WAN and LAN links state as standard pfSense feature

[Sergei_Shablovsky]

Your opinion about adding Smokeping for monitoring WAN and LAN links state as standard pfSense feature?

For networks admins and engineers trace route and pings are still one of base&useful measurement tool within decades.

Mainly as networks admins and engineers we not need something more that understanding two main things if thinking about the source of problem that need to resolve:
a) what happened on our hardware (physical state, loading of software components, network loading on separate components (i.e. LAN, WAN, ...)
b) what happened outside (uplinks state, lathency, speed, ...)

And due COVID-19 when many business come to online - the importance of right measurement tools growing fast:

Distinct Sites per Year
Year Sites
2020 14544
2019 7045

The main advantages of Smokeping:

• very flexible system of a measurements (due a lot of probes
• trusty software, stable quality code;
• already tested on a millions of installations;

The Multihost Graph

The Overall Graph

Feature request

[q54e3w]

@sergei_shablovsky
I like smokeping, I've run it for many years on a host behind pfSense and it was a critical component in me resolving some ISP issues last year.
That said, I'm not personally in favor of adding more stuff into pfSense. I say let pfSense route the ICMP packets that originate elsewhere on your LAN.
Interesting question though and I'm curious what others think.

[Sergei_Shablovsky]

@q54e3w said in Your opinion about adding Smokeping for monitoring WAN and LAN links state as standard pfSense feature:

@sergei_shablovsky
I like smokeping, I've run it for many years on a host behind pfSense and it was a critical component in me resolving some ISP issues last year.

Glad to read this.

But let me to note, that in your case there are some disadvantages:
a) another one point of failure (cables connecting, server fault;
b) needs of separate UPS, separate display and spare parts for this monitoring server;
c) needs to create (and maintain) special set of rules on pfSense to allow your separate monitoring machine be effective in measurement;
d) increased bills of electricity cost (the server + ups + monitor + extra cooling spending on whole server room);

If Smokeping exist in pfSense, it eating only a small fraction of resources of whole device. But adding a great valuable feature to whole feature list of pfSense as product.

That said, I'm not personally in favor of adding more stuff into pfSense. I say let pfSense route the ICMP packets that originate elsewhere on your LAN.

In each product community (no matter what), the are a lot of people’s who have personal preferrables and each of them try to push “another one big feature” into product. As a result, sometime project become to stay with a lot of “bells&wishes”, where each of certain feature used only by few “tech nerds”.
So, very important to say “NO” to most of this “wishes” in case we need to se stable and useful product.

But in this case pfSense during a years
a) have no any ping / traceroute interactive screen;
b) have no any useful dashboard on VGA console about main state of device;

External 17-23 monitor now are frankly cheap, and using it as VGA Console screen for constant monitoring by ping (like dashboard for for BandwithD in browser pfSense view) are VERY REASONABLE.

Other detailed monitoring of traffic for future analysis better to doing on remote admin machine in browser window, of course.
And of course, in cases when some automatic alerts UP that indicate anomaly in traffic.

Generally speaking, as a network/system administrators we need to care not only about "how we looks from outside" but also "how outside world looks like".
The third-party professional services like Alertra, Uptime.com, Pingdom, Site24x7, Cula.io, UptimeRobot, CloudFlare, - for the first, and Smokeping - for the second.

[verizu]

You can already achieve this with telegraf which has a ping feature

[Sergei_Shablovsky]

@verizu said in Your opinion about adding Smokeping for monitoring WAN and LAN links state as standard pfSense feature:

You can already achieve this with telegraf which has a ping feature

Please give me link to some example?
(In case I need the result as described in first post of this topic). Thank You!

[johnpoz]

@sergei_shablovsky said in Your opinion about adding Smokeping for monitoring WAN and LAN links state as standard pfSense feature:

b) needs of separate UPS, separate display and spare parts for this monitoring server;
c) needs to create (and maintain) special set of rules on pfSense to allow your separate monitoring machine be effective in measurement;
d) increased bills of electricity cost (the server + ups + monitor + extra cooling spending on whole server room);

None of those make any sense to me.. smokeping can run on some VM or docker on your already installed infrastructure or just native on some box you have running anyway. Why would it need its own ups? This could be the same ups your pfsense is on. Why would it need a display? Or just run it on a pi for example..

Rules - so you don't allow ping anyway? Why would you block outbound ping? Even if you blocked it for your network, it would be 1 rule..

If its running as vm or docker on something you have running anyway.. The added cost of running a few extra cpu cycles to run the vm/docker would be really nonexistent. Who doesn't have say their nas up 24/7? Or lets say ran it on a pi - the cost there is pennies.. Lets say the pi draws 3w - which is prob on the high end to be sure.. At like 12 cent per kwh your talking like 3 bucks for the whole year.. You don't have a pi to play with, I have a couple on the network ntp server, pihole.. And then a couple older ones on the shelf - you could run this on a pi zero with nic adapter for like 20$ ;)

I don't see how any of your disadvantage should come into play to be honest.

But nothing stopping anyone from creating a smokeping package for pfsense..

a) doesn't really come into play either if running it on something already running as vm/docker/native - if nas fails that pretty significant issue for me, so not really adding any point of failure in anything if already running on something that is important to be running. If a docker shuts down for whatever reason - I get an email to check it, etc.

[PPCM]

Hello there,

The question from @Sergei_Shablovsky is really interresting

@johnpoz To resolve issue with ISP (I add to make that and it is not easy), you have to prove that the problem doesn't come from your own network, for that Smokeping need to be as close to WAN as possible, otherwise, the ISP will blame the routeur or your switch...
In my case, I use a Rpi on which Smokeping is istalled because I have the chance to have multiple IP addresses in my WAN network, so I use one of them for the pfSense and one other for the Rpi
But for those who have only one ip address, the problem is more complicated

So I am agree with Sergei, it will be great and more ease to use if Smokeping is integreted in pfSense...

[Sergei_Shablovsky]

@johnpoz said in Your opinion about adding Smokeping for monitoring WAN and LAN links state as standard pfSense feature:

But nothing stopping anyone from creating a smokeping package for pfsense..

Where am I able to read how to write packages EXACTLY for pfSense ?

(Please, do not point me on classic packages for BSD writing docs, or suggesting to reverse engineering one of already existed in pfSense packages...;)

[johnpoz]

@sergei_shablovsky

https://docs.netgate.com/pfsense/en/latest/development/develop-packages.html

[Sergei_Shablovsky]

@johnpoz said in Your opinion about adding Smokeping for monitoring WAN and LAN links state as standard pfSense feature:

@sergei_shablovsky

https://docs.netgate.com/pfsense/en/latest/development/develop-packages.html

Thank You!

I read this around a year ago, but cannot find something like templates, controls example, etc... May be more detailed description of pfSense package making exist somewhere?

[Sergei_Shablovsky]

@johnpoz said in Your opinion about adding Smokeping for monitoring WAN and LAN links state as standard pfSense feature:

@sergei_shablovsky said in Your opinion about adding Smokeping for monitoring WAN and LAN links state as standard pfSense feature:

b) needs of separate UPS, separate display and spare parts for this monitoring server;
c) needs to create (and maintain) special set of rules on pfSense to allow your separate monitoring machine be effective in measurement;
d) increased bills of electricity cost (the server + ups + monitor + extra cooling spending on whole server room);

None of those make any sense to me.. smokeping can run on some VM or docker on your already installed infrastructure or just native on some box you have running anyway. Why would it need its own ups? This could be the same ups your pfsense is on. Why would it need a display? Or just run it on a pi for example..

Ok, I agree with You about monitor and UPS. But anyway a You need separate server with 2 PSU, etc...
Because based on data of Smokeping - Prometheus&Grafana&AlertManager come in action.
Let say, when one uplink degradate on 20-30%, remote admin immediately receive mobile notifications and also some changes (changing software settings, fire up and kill some services and servers, etc) within infrastructure started.

Rules - so you don't allow ping anyway? Why would you block outbound ping? Even if you blocked it for your network, it would be 1 rule..

I mean that measuring the uplinks and measuring the inside infrastructure - are very different tasks by goals: if something happened with ISP uplinks - we doing one bunch of actions, when something happened with inside servers or active network equipment- we doing totally another bunch of actions.
And also after some time, may be this monitoring would be divided on 2 separate servers. (We not talk here about tiny micro servers like Raspberry or nettops).

If its running as vm or docker on something you have running anyway.. The added cost of running a few extra cpu cycles to run the vm/docker would be really nonexistent. Who doesn't have say their nas up 24/7? Or lets say ran it on a pi - the cost there is pennies.. Lets say the pi draws 3w - which is prob on the high end to be sure.. At like 12 cent per kwh your talking like 3 bucks for the whole year.. You don't have a pi to play with, I have a couple on the network ntp server, pihole.. And then a couple older ones on the shelf - you could run this on a pi zero with nic adapter for like 20$ ;)

I don't see how any of your disadvantage should come into play to be honest.

a) doesn't really come into play either if running it on something already running as vm/docker/native - if nas fails that pretty significant issue for me, so not really adding any point of failure in anything if already running on something that is important to be running. If a docker shuts down for whatever reason - I get an email to check it, etc.

As I wrote before: the docked server not good for precisely monitoring, and the tiny server not able to keep monitoring + set of mgmt software (Prometheus, Grafana, AlertManager, etc... well known stack).

But nothing stopping anyone from creating a smokeping package for pfsense..

Where reading with GREAT samples about creating packages for ofSense ? ;)

[heper]

@sergei_shablovsky
https://github.com/pfsense/FreeBSD-ports
has the sourcecode for the packages.

https://docs.netgate.com/pfsense/en/latest/development/develop-packages.html
https://docs.netgate.com/pfsense/en/latest/development/package-directories.html

[Sergei_Shablovsky]

@heper said in Your opinion about adding Smokeping for monitoring WAN and LAN links state as standard pfSense feature:

@sergei_shablovsky
https://github.com/pfsense/FreeBSD-ports
has the sourcecode for the packages.

https://docs.netgate.com/pfsense/en/latest/development/develop-packages.html
https://docs.netgate.com/pfsense/en/latest/development/package-directories.html

Thanks You. I able to read official web. ;)

I just asking for OTHER great sources with examples :)