Database Reference
In-Depth Information
Chapter 8
Monitoring the Hosting Platform
Another very important aspect in the management of the consolidated platform solutions is monitoring. For this
purpose many companies have developed their own home-grown monitoring solutions, partly based on existing
frameworks, partially written on their own. Very often these solutions have been maintained over a long period of
time and have constantly evolved. Although such solutions may work very well for the specific systems for which
they were written, there are many potential problems associated with an in-house developed monitoring solution.
Consider for example that the main server platform was AIX, with a little Solaris in the mix as it was common for many
enterprises. In such environments korn-shell scripts often bore the brunt of the work. The question to ask is: how
flexible are your scripts when you change your hardware platform? Has everything been coded so that it is operating
system independent? If your new platform is Linux, then there might not be a huge need to rewrite, but if your
monitoring solution has to support an altogether different platform—Windows, for example—then you cannot readily
make use of any shell scripting. Something more flexible is needed.
Another item to consider is support: who is going to support your home-grown scripts if there is a problem with
monitoring? In today's environments, where every DBA looks after a huge number of databases, you cannot readily
assume that the primary DBA has intimate knowledge of the system he works on! Being notified by the business users
about a problem that the monitoring software has failed to recognize is a major embarrassment at best. But if this
happens you need the right people to look into the problem.
Other challenges with home-grown solutions are notification, escalation, and message flood control. Not
all systems are equally important, and as an IT department you will have different service-level agreements for
development systems compared to live production environments. Nevertheless, if a development system reports
a severe problem it still needs fixing. Gentle escalation is important. Flood control is equally important: your
monitoring solution should not page you every 5 minutes with the same error. After the page has gone out, there
should be an easy way to acknowledge that you have received the alert but have not resolved it yet. One system that is
comparatively easy to deploy is Oracle Enterprise Manager 12c Cloud Control, which is the subject of this chapter.
There is a lot more to Enterprise Manager 12c than it is possible to cover here. Where applicable in this chapter,
you will find references to the Oracle documentation set that lead you to even more detail on key topics.
Note
Oracle Enterprise Manager
Oracle Enterprise Manager is designed as a multi-tier application, consisting of agents actively monitoring targets
on hosts, a Management Service (OMS) to receive that information and a repository database to persist data. The
Enterprise Manager is written entirely using Oracle products. The user interface uses the Java-based Application
Development Framework (ADF), which you also know from the My Oracle Support website. The runtime environment
is provided by Oracle's WebLogic application server. The management agent is also from Oracle. An advanced
deployment of Enterprise Manager is shown in Figure 8-1 .
 
 
Search WWH ::




Custom Search