Assuming that by "monitoring" you mean "receive an email when something breaks" then the note you cited will not be much of a help, as it is focused on Root Cause Analysis which is oriented more towards finding the source of a problem once you already know about it.
Unfortunately as you are discovering SAP has really gone off the rails in the complete disarray of its toolset; one look at note 1357901 shows what a study in complexity this is (and that note doesn't mention BPMon, EEM, and throws up its hands at MySQL and Sybase, grin). Theoretically there should be a bit of a reunification of all these monitoring pieces in SolMan 7.1 but it's going to be a long journey before things really get sane again.
Focusing on the "monitoring" side, Sean's suggestion of GRMGLITE for URL monitoring is the right way to go for availability monitoring (GRMGLITE is handy for monitoring any non-SAP web server such as Apache, IIS, etc). GRMGLITE is relatively easy to configure as no agent is required on the satellite system, so this is a quick win for the REALLY important thing ("is my application up or down?") at least from a web perspective. For a starting point see: http://help.sap.com/saphelp_nw70/helpdata/en/6d/6fe040852f712ae10000000a155106/frameset.htm
For OS metrics, such as disk space, CPU utilization and RAM, the shortest path from here to there is to install SAPOSCOL + SAPCCMSR on the satellite system. This combination will give you monitoring in RZ20 (with the ability to generate email notifications) plus you will get to use familiar transactions like ST06 to dig into the OS metrics a little more. Buried deep in note 1357901 is actually a little help in section 6.2, for setting up monitoring of relevant processes although you can make that config yourself too. There is no single document that explains everything required for the SAPOSCOL+SAPCCMSR combination but a couple starting points would be notes 371023 and 451166.
Regarding the idea of using Nagios or another tool... this will depend on your organization. If you are mostly an SAP shop then I'd vote to stick with SAP's tools, which, for all their flaws, will be familiar and supportable by a Basis team (e.g., everyone on the Basis team knows how to apply a kernel patch and therefore knows how to patch SAPOSCOL and SAPCCMSR). On the other hand, if you have a heterogeneous environment of SAP, Siebel, PeopleSoft, etc, then there is less incentive to stick with an SAP-oriented strategy. This is especially true if you happen to have a small team of perl programmers (in which case a perl-based tool like Nagios would be a great fit) or java programmers (in which case a Java-based tool would make sense).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.