On Monday, October 07, 2013 10:27:56 AM, Adam Armstrong wrote:
On 2013-10-07 15:02, Eric Stewart wrote:
Being an administrator for a cheap-ass educational institution, I really don't have issues with the Edition Split. We're unlikely to contribute money, but I understand the need for a solid revenue stream.
Except, as I am an administrator for a cheap-ass educational institution, I have a tendency to tinker, and I even have a student assistant whose job is to aid with project implementation, including development support (he's been quite active with NetDB in the past). Our existing MRTG implementation is customized with a lot of shoe-horned in graphs that I don't ever expect to see in Observium (so, there will always be MRTG for some things here), but Observium does do a lot of things our homegrown system doesn't do, and has a much more appetizing interface. However, there are things that Observium is doing that could be better, and I was thinking of putting in the time (or my student's time) to contribute changes that implement these features. For example:
* I've added an APC UPS but have noted that battery percentageremaining/runtime remaining don't exist at this time (I can understand how much of a headache this is, especially with the APC's using "timeticks" instead of a raw number of minutes or seconds). I've seen comments that this needs to be addressed, and I'd be willing to put the time in to address it.
* We have additional UPS models (e.g. Leibert) that may or maynot be properly supported yet. * I was happy to see Cisco SLA stuff implemented, but it's not implemented to the depth that we'd like it to be (e.g., jitter's great, but we'd also like to see packet loss stats, latency, better support for video stats, etc). * Since we do our stats collection at the distribution layer (8-9 servers across campus, remote sites/campuses, and a remote data center), I'm still trying to think of a good way to search/navigate between them (particularly since it's not always clear which building is out of which node) without adding too much complexity.
Would it be useful to the community for me to work on the community tar.gz version and submit them? Or would trying to add new code that was developed against potentially dated code be too much of a headache for the main developers?
This is one of the things that kept us from splitting the project for so long.
We're probably not going to accept patches generated from the community edition because it's quite painful to merge things with such a large disconnect in time.
I would ask, however, why a cheap-ass educational establishment has so many expensive UPSes, but can't pay for their monitoring software. ;)
adam.
The short answer? It's easier to get money for equipment, particularly since we're a state university.
The slightly longer answer? Observium is a great product, but it doesn't yet do exactly what we need it to do, and while we have something in place that doesn't look pretty or provide us with little tidbits of functionality (e.g. sometimes we miss the ability to look at snippets of time in our graphs that can get lost if there's a spike outside of the time frame), it does a lot more for us right now than Observium could. If we were starting from scratch, we might start with Observium, but I couldn't justify paying for something that's missing key things that the current system does well enough.
-- Eric Stewart - Network Administrator - eric@usf.edu University of South Florida, Information Technology