I won't weigh in on this thread other than to say I also, previously took the view to look for commonality, and this is not only a great set of examples, but just re-enforces my prior view that I feel could be put to objectives.
E.g., from experience, most of the operational focus (which should be included, not just installation focus) for DevOps administrators involves writing tests and checking results. That and several are based on the same codebase (e.g., Incinga is essentially based on Nagios). There are just a lot of other things to cover, and I think just these basic, common objectives, instead of installing and configuring a specific monitoring solution, isn't a bad approach. - bjs On Tue, Aug 22, 2017 at 6:27 AM, Jeroen Baten <[email protected]> wrote: > Hi, > > In case you mist my earlier reply (lost at the bottom of an old thread > in your email client :-) ) I repost it like this. > > Having thought about devops and monitoring I must admit that I am not > happy about where it was heading. > > I love LPI's generic and practical approach so I spend some time about > that regarding devops and monitoring > > Yes, a devops guy needs to know about monitoring. > Yes, he should know that there are a few popular open source projects > that do monitoring: Nagios, Icinga, Zabbix, Prometheus (if you must > insist allthough I think it is not nearly mature enough). > > No, he should not become an expert in one of these packages. > (well, I could say it must be Zabbix but 10 to 1 somebody will see that > completely differently) > > But we can tell students about things like: > -Be aware of sizing. The amount of monitorin information is the number > of items times the number of servers. > -Know the difference between storing in a rrd database or a sql database > or elastic database and the difference in housekeeping. > -The sort-of standard way how return/errorlevels are organised: > > Nagios/Icinga: > Plugin Return Code Service State Host State > 0 OK UP > 1 WARNING UP or DOWN/UNREACHABLE* > 2 CRITICAL DOWN/UNREACHABLE > 3 UNKNOWN DOWN/UNREACHABLE > > Zabbix: Any exit code that is different from 0 is considered as > execution failure. > > Prometheus:? (couldn't find it, pointers welcome) > > so, there you have it. I hope this is of use to people. > > Warm regards, > Jeroen Baten > > > > > Op 17-08-17 om 15:55 schreef Jeroen Baten: >> >> I thought I'd give Prometheus a try. >> I really don't understand the enthusiasm. >> All I can see is that the agent sends data to the server and I can get a >> graph for the data. >> >> Maybe I am mistaken but I can't see things like templates >> (pre-configured lists of triggers and data) like in Zabbix, or how to >> configure alerts. >> >> And if I want a prometheus dashboard I have to install Rails and install >> PromDash. But even than I have to add all the metrics that I need to >> monitor. >> >> I want to be able to daily add servers from a cmdb to my monitoring >> solution and attach some templates. >> I want to not be bothered by metrics unless something goes wrong. >> >> AFAICT Prometheus is nice for small scale projects but that's it. >> >> Am I maybe missing something? >> >> regards, >> Jeroen >> > > -- > Jeroen Baten | EMAIL : [email protected] > ____ _ __ | web : www.i2rs.nl > | )|_)(_ | tel : +31 (0)345 - 75 26 28 > _|_/_| \__) | Molenwindsingel 46, 4105 HK, Culemborg, the > Netherlands > _______________________________________________ > lpi-examdev mailing list > [email protected] > http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev -- -- Bryan J Smith - http://www.linkedin.com/in/bjsmith E-mail: b.j.smith at ieee.org or me at bjsmith.me _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
