On Tue, Jul 29, 2014 at 10:43 AM, Alan McKinnon <alan.mckin...@gmail.com> wrote:
> That matches what I see out in the general world at large. > The majority find that nagios does not suit their needs - mostly due to > limitations in nagios - and when upgrade time comes along they switch to > a nagios fork (or something else). > Why not teach general SNMP, WBEM/CIM and other aspects instead? I think we're getting to the point that if we go down specific implementations, we're going to limit ourselves. Nagios considers itself the centre of the universe, which I suppose is > fine if your network consists of one subnet in-house. Very few real-life > scenarios match that simplistic model. Hence why people migrate away to > something that maps better to real life. > So ... again ... why not teach the underlying agent, MIB, etc... basics? We're really talking about accumulators v. concentrators, and arguing over the concentrators. To me, I want someone who at least understands the concepts of WBEM/CIM, agents, remote polling, etc... and, optionally (more legacy), SNMP. It's that question we might want to visit more, and what is most relevant, than the Nagios v. Zabbix question. SIDE NOTE: There is even OpenLMI that Red Hat is pushing for Upstream adoption with newer Fedora releases and, now, with RHEL7's release, to fill in system management areas where typical WBEM/CIM agents are not addressing. This is largely to please the "new generation" of Windows admins who area actually learning PowerShell (a way to do shell calls into .NET, kinda like using Java or Python for similar automation using similar functions), and heavily around scripting for WBEM/CIM agents as well as key NT system functions. However, nagios is still mostly representative of monitoring at large > and especially of it's forks. Knowledge of nagios still maps well to > what LPI does and how it does it - anyone who can demonstrate working > knowledge of nagios can be assumed to be able to drive other similar > products in short order. As such, it still fits the purpose. > I don't see anything much to be gained from changing that objective. We > aren't in the game of showing that the candidate can take a known > product in a known environment, and apply specific steps to achieve a > defined result. That's practical testing, Red Hat pays there. > Just to be impartial, at this time, Red Hat supports neither Nagios nor Zabbix as part of its RHEL product line. Both are in the Fedora Extra Packages for Enterprise Linux (EPEL), and I know Red Hat associates who use either or both. At most there is some Nagios integration in a few add-ons, like oVirt-based solutions (e.g., used by Enterprise Virtualization Manager, RHEV-M, and Storage Console, RHS-C), largely for partner considerations. I.e., many partners are asking Red Hat for a built-in monitoring solution as a "fallback," so working with partners who provide their SNMP and/or CIM agents, plus some developed software SNMP or CIM agents, combine to provide the accumulators so they can feed something like Nagios that can be bundled. But in the end, we can really get really deep on this stuff. I wouldn't like to make it a Nagios v. Zabbix consideration, but more of a CIM base-level knowledge and related considerations. Heck, even Microsoft ships The OpenGroup's OpenPegasus set of CIM agents for select UNIX/Linux as part of SCCM Server -- although it's deployment is manual, and updating is a PITA (also largely manual). -- bjs
_______________________________________________ lpi-examdev mailing list lpi-examdev@lpi.org http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
