11–20 of 25 posts
Edit: I should clarify, I really liked the article and I like the unix philosophy but I'm truly interested to know what type of networks can be monitored with this approach. I work in the enterprise monitoring space and a lot of the solutions are truly horrible, but on the other hand, I'm not sure this approach would work either when you have 500K managed nodes and dealing with multiple campuses across 3 continents...
I swear I've seen HP OpenView processes using more CPU than Oracle. I have no idea why companies throw away so much money on such terrible software.
To some degree, the best "monitoring software" doesn't even monitor at all - it simply provides a framework for people to add their monitors to. To take one example I'm familiar with (though I'm sure this could be applied to the rest of the great monitoring systems) - Nagios is, at it's heart, a State-Tracking/Notification/Scheduling Engine. The fact that you can add commands like "ping" or "http test" or "Database S…
1) High-availability with minimal downtime (seconds)
2) I18N readiness & L10n language packs
3) Scale on the order of 10000 or 100K
4) Guaranteed delivery of Alerts and Metrics
5) Easy Deployment and configuration - where the first step is NOT download and deploy Redis and configure it.
Make no mistake I love open source offerings but having worked in this domain for a while, Enterprise software becomes complicated to solve complicated problems with minimal intervention by users - not every IT shop has super-duper DevOps ninjas who Crunch Machine Learning Pardigms for breakfast.
I swear I've seen HP OpenView processes using more CPU than Oracle. I have no idea why companies throw away so much money on such terrible software.
Monitoring systems that have to execute thousands of active checks every polling interval consume a bit of CPU. I've certainly seen high CPU usage and run queue depth on a busy Nagios server.
It is easy to beat up on big complicated monitoring software - call it Enterprise Level and then proceed to find flaws. There is a reason it is complicated - because it tries to solve Tough problems: Can these other offerings give me: 1) High-availability with minimal downtime (seconds) 2) I18N readiness & L10n language packs 3) Scale on the order of 10000 or 100K 4) Guaranteed delivery of Alerts and Metrics 5) Easy…
2) WTF ARE YOU INSANE ? monitoring isn't about displaying foreign characters, it's done in integers and english strings, like all programming. You will use user-related mess only in the user-related part
3) Every database does that with ease, if you talk about scaling from 100k monitored nodes, that only requires an aggregation layer, and that's still easy
4) That's a commercial "guaranteed", noone can do that with standard networks and machines
5) Indeed, but you'll need consultants anyway so shifting part of the costs to man days instead of licensing is more or less equal.
Now in reality, most products that are known actually suck (like how mysql is a "standard" although it's a total fail) and enterprisy solutions only have a little software packaging to make them look smooth - and in the case of monitoring, I haven't seen a sensible solution yet, with a complete round robin system, logical rather than string events, distributed 1st level pre-processing, etc.
I'll build one if I need one - right now I'm busy on something else.
It is easy to beat up on big complicated monitoring software - call it Enterprise Level and then proceed to find flaws. There is a reason it is complicated - because it tries to solve Tough problems: Can these other offerings give me: 1) High-availability with minimal downtime (seconds) 2) I18N readiness & L10n language packs 3) Scale on the order of 10000 or 100K 4) Guaranteed delivery of Alerts and Metrics 5) Easy…
1) Realistic scaling. Just about every piece of enterprise grade software I've seen falls off a cliff when it hits a certain load point. This is ALWAYS enough to sell it to you. When it goes wrong...
2) When it goes wrong, it's a nightmare of maintenance contracts, verification, finger pointing and telephone calls that last hours.
3) It rarely works as advertised. I mean literally 1% works as advertised.
4) Trials and realistic evaluations without crazy constraints are not usually possible (this is changing slowly).
5) Installation is a breeze but when it comes to backup/restore and upgrade, it's a pain in the butt.
Time is money. The difference between "enterprise level software" and "OSS" platforms are the following:
* OSS time is spent up front.
* Enterprise time is spent later on and costs more up front.
I'd rather have one Ninja on the team and lose the enterprise software. Ninjas scale better as well.
Nice article, whose central message ("don't bundle your tools") is widely applicable to domains other than monitoring. Small, specialized tools that can be combined together is the very essence of the Unix philosophy.
It is easy to beat up on big complicated monitoring software - call it Enterprise Level and then proceed to find flaws. There is a reason it is complicated - because it tries to solve Tough problems: Can these other offerings give me: 1) High-availability with minimal downtime (seconds) 2) I18N readiness & L10n language packs 3) Scale on the order of 10000 or 100K 4) Guaranteed delivery of Alerts and Metrics 5) Easy…
Excuse the cynical POV here, but it's from a number of years of dealing with such things. The problems I find with enterprise software as a rule are it solves the above but fails at: 1) Realistic scaling. Just about every piece of enterprise grade software I've seen falls off a cliff when it hits a certain load point. This is ALWAYS enough to sell it to you. When it goes wrong... 2) When it goes wrong, it's a nightma…
I do a lot of work in Enterprise CMS land and Open Source land and you've essentially described my experiences working with ALL Enterprise CMS's I've used since the early 00's. I'm pretty convinced that within about 18 months Open Source CMS's will have negated any residual technical benefits that Enterprise platforms offer.
At this point the only competitive advantage Enterprise CMS vendors will have is their reputation and the "nobody ever got fired for buying IBM" attitude and commercial support.
With many other businesses sprouting up to provide commercial support for open source platforms I can see many Enterprise vendors having to pull up their socks and shaking up how they sell and manage their platforms in the very near future.