Dpinger multiple targets - aka gwmond $2,500
-
Lets see if we can get the author of dpinger on this:
https://github.com/dennypage/dpinger/issues/24
-
First version of gwmond available here: www.miscstuff.org/pfSense-pkg-Gwmond-0.2.4.txz No graphing capability at present due to the version of rrdtool supplied with pfSense being compiled without graphing support.
-
hmm,
I did not get a notification. I am going to check it out.
Do you have a github setup?
-
no github yet, I'm still working on graphing also.
-
It is a shame we do not have more people jumping on this.
What you are coming up with is a standard feature in pfsense's competitors devices now and also forms that basis of the buzzword 'sd-wan'.
It is going to come of great benefit to pfsense and if you get a github up where I can see the code differences I wanted to contribute. I do not want any of the bounty.
-
I have never installed an alternative package. What is the best way to install this?
-
Graphing has arrived! caveat: the x axis labels are weird because D3 insists on doing it by itself and makes a horrible mess of it. Any attempts I've made to impose order have either broken it completely or been ignored.
Also there might not be any Y axis labels on the packet loss graphs when there's no packet loss, I assume that's because it can't work out a scale from a bunch of 0s.
download here: http://www.miscstuff.org/pfSense-pkg-Gwmond-0.2.4.1.txz
git hopefully coming soon
to install dump the file in /tmp and in console run pkg install /tmp/pfSense-pkg-Gwmond-0.2.4.1.txz
-
Thanks for working on this - this feature will go a long way to improve the reliability of pfsense.
-
Guys,
I admin a pretty decent size network and I have yet to test this plugin. Does this replace what is installed? Is it additional functionality? Can I roll back? I have a box I would like to try it on.
It also seems that luckman212 has not replied. I am going to try and secure some funds from my company to donate to this, how do I donate?
The big question I have now is: Is this compatible w/ 2.4.3_1 or the latest and greatest, and how do we get this rolled into official pfSense packages?
-
@webdawg said in Dpinger multiple targets - aka gwmond $2,500:
Guys,
I admin a pretty decent size network and I have yet to test this plugin. Does this replace what is installed? Is it additional functionality? Can I roll back? I have a box I would like to try it on.
It also seems that luckman212 has not replied. I am going to try and secure some funds from my company to donate to this, how do I donate?
The big question I have now is: Is this compatible w/ 2.4.3_1 or the latest and greatest, and how do we get this rolled into official pfSense packages?
Guys,
Does this replace what is installed, is it easy to remove?
-
@webdawg I was ready to test this, but no one replied. Hello?
-
@webdawg Guys:
https://redmine.pfsense.org/issues/7671
edit: https://redmine.pfsense.org/issues/4354
Also got a message back from pfSense:
Ultimately it's not seeing any traction because the suggested solution isn't right. Essentially dpinger is only a daemon that pings and reports responses. It doesn't make decisions about what is good or bad for a pfSense gateway as a whole only its specific single target. It isn't up to dpinger to handle multiple targets or different protocols.
What is needed is more like some middleware-ish daemon to sit between pfSense and other gateway monitoring daemons like dpinger (See #7671 for some other suggestions) that would be capable of coordinating multiple monitoring techniques for each gateway and making more informed decisions about their status.pfSense
|
+--- [gateway monitoring daemon]
|
+ --- [dpinger <1...n>, <something that checks http>, <something that checks tcp>, etc]There isn't currently a feature request for that, however, but feel free to open one and start a bounty on the forum to see if you get any takers. Given the responses on the dpinger github it appears its author agrees that it's out of scope for dpinger itself.
Can someone create a new bounty?
-
Yes, in my original post/redmine ticket I did suggest that what's really needed is a new gw monitoring daemon to make intelligent decisions and take actions based on the current state of dpinger (or other monitoring processes).
I should have stayed in school and learned enough C so I could create this myself, but, too late for that. We need someone more capable to step up to the plate here.
Maybe $2500 wasn't enough- not sure if it's even possible to raise that much (or more) without some marketing/campaigning from Netgate themselves. Maybe a monthly "Top Bounties" section of the Newsletter could help fund this type of 3rd party development?
In the meantime, I really feel like the saying "Perfect is the enemy of good" (aka Pareto principle) applies here. With the existing tools (dpinger/base pfsense) we already have what's needed with some small code changes to define additional gateway monitoring targets (albeit, ICMP only) and not trigger a gw failover event unless ALL targets are down.
Until & unless we can figure out how to fund or create enough demand for a better solution, maybe we should just implement 3 targets for now which will probably help 80% of the users who need multitarget monitoring.
-
@luckman212 Can you pile in on the new issue? Lets see if we can make it happen?
-
Well I don't know about piling in, but I would go in for $500 or so
My financial position has changed since the original bounty- I can't afford to put $2500 in anymore. Hopefully we can get some others to contribute.
-
I think I might try, and do this. I sent Jim an email, and I will post anything I do here soon.
-
What is the status of this?
I proposed https://redmine.pfsense.org/issues/14177 to try and solve this issue, but having multiple ICMP monitors for a single GW would be a great improvement.
More broadly, how do features like this gain the necessary attention to get implemented sooner than 6+ years?
-
I didn't really care about latency, but I had a need to know if a handful of internal systems are up or down by glancing at the dashboard.
I've tried the same with "monitoring other external systems" (by DNSName or IP) and it works for that as well, but it is a moot point if the WAN is down.
Take one system down to show
-
@jrey said in Dpinger multiple targets - aka gwmond $2,500:
I didn't really care about latency, but I had a need to know if a handful of internal systems are up or down by glancing at the dashboard.
Librenms?
-
@dennypage said in Dpinger multiple targets - aka gwmond $2,500:
Librenms?
No - why?
Everyone always wants to suggest more packages, or external systems. All of which are great if that is the requirement.The requirement for me was simply -
show the up/down status of a handful of internal system on the pfSense Dashboard.In my case there was no need for any third party system.
- No more systems to run/manage/maintain
- No need to record when they are down, just need the NOC/Ops to see they are.
- No need to monitor external systems (although it can), because currently outside the wall is not my problem ;-) someone with a remote location might certainly want this, and perhaps latency shown at that point. But honestly the tunnel would likely go away.
- No need to display or record latency history (although the data is right there and easy enough to display. These are internal systems so response is typically <1ms - dashboard real estate is more valuable than seeing latency)
Why do I do this? because in my case, for my requirement these internal systems are all virtual and have automatic strategies for shutdown / backup / restart and other scheduled maintenance functions. On rare occasions they go down for said automated maintenance and then don't restart cleanly. So instead of having to investigate each of them manually, or waiting for the masses to start complaining, there is an immediate visual clue in plain sight that something is wrong.
The less work that has to be done to maintain/discover and solve the better. Now instead of potentially hours before a "down" gets noticed, by some user, or having to check everything. The issue is identified, systems back up in minutes, to the point those users, likely never even notice. And there in lies the illusion 99.99% uptime.
Auto maintenance by night, smooth operation by day. Sit back and watch the blinky lights.Tools need to save time, not create more work.
PS: one of those systems I monitor, actually has a network monitoring tool running on it, in a docker, with a bunch of other dockers as well. However, it has been my experience that Network monitoring is not very functional if the system goes off the network. Could just be a weird observation, that needs more coffee. ;-)
