Target modeling
Any enterprise IT infrastructure contains numerous disparate components that are geographically distributed across various data centers. These components include both hardware components such as servers hosting different applications, network switches, routers, storage devices, and so on, as well as software components such as operating systems, database servers, application servers, middleware components, packaged applications, distributed applications, and so on. Although these components exhibit various management traits and expose multiple management operations, they also have certain common attributes that need to be monitored by the IT administrators. For instance, the performance characteristics of an Oracle database instance are completely different from those of an Oracle WebLogic managed server. However, both these components still exhibit a common trait of indicating their health or current state. This indicates if the corresponding component functions are available or not. The components themselves and the management of both their common and dissimilar traits form the building blocks of the IT infrastructure management. Each of these components is a monitor-able entity and is represented as a target in OEM. A target represents any component that is managed by OEM. Targets are the fundamental building blocks, on which the different systems management capabilities of OEM are built upon.
Continuing with our travel portal example, each of the components within the travel portal is represented as targets within OEM. These include the Oracle database targets, Oracle WebLogic server targets, the host targets on which these run, and so on. Other than the physical hosts, OEM 11g does not support the management of physical hardware such as network routers, switches, and so on. Hence, a discussion on the management support for those components is beyond the scope of this book.
OEM categorizes targets primarily based on the type of the component that they represent. This classification based on the type of the component is known as a Target Type. The targets are first classified based on the component type and subsequently based on the vendor type. The kind of target types depends on the flavor of OEM that is used to manage the target, while target specific flavors such as OEM Database Control and OEM Fusion Middleware Control support only database and middleware components to be modeled within their respective consoles. OEM Grid Control provides a wider canvas to support multiple target types within the same console. OEM Grid Control supports all manageable products from the Oracle product family as well as certain popular products within each target type from other vendors. The different kinds of target types supported by OEM Grid Control include:
- Host targets: These represent the physical boxes of hosts that run different products such as databases, application servers, and so on.
- Database targets: These represent the various database server instances that run within the enterprise such as Oracle database instance targets, Oracle Real Application Clusters (RAC) targets, and so on.
- Middleware targets: These represent the various middleware components such as Oracle WebLogic servers, domains, clusters, Oracle application servers (OC4J), service oriented architecture (SOA) components and composites, Oracle coherence server, and Oracle Identity Management (IDM) components. Middleware servers from other vendors such as IBM Websphere Application Server (WAS) and, JBoss Application Server are also supported.
- Application targets: These model various applications such as custom J2EE applications deployed on various application servers, packaged applications such as Siebel, Peoplesoft, Oracle E-biz Suite, other functional applications such as Oracle Business Intelligence products like OBIEE, Oracle Beehive, and so on.
- Composite targets: These include logical target types that provide business abstraction such as systems, groups, and service targets.
- OMS targets: These model the OEM itself as a target. OEM provides Monitor-the-Monitor (MTM) capability and is represented as OMS and repository targets within.
The following image is a screenshot of OEM Grid Control and displays a small subset of the large number of target types supported by OEM Grid Control. This page is referred to as the All Targets page within OEM Grid Control.
The user can navigate to this page by first clicking on the Targets link in the global tab and then subsequently clicking on the All Targets link within the subtab. This page displays all the targets configured within an enterprise. It also displays the current status of the target as well as the corresponding target type.
Tip
In any enterprise, there are numerous IT components deployed to support various business functions. The All Targets page has a search feature that helps to filter the targets displayed based on either the target type or target name. In addition, the OEM Grid Control also provides quick filters based on key target types such as databases, middleware components, services, and so on. These quick filters can be viewed by clicking on the Targets link in the main tab and then clicking on the respective filter links within the subtab.
Target discovery
For a component to be modeled within the OEM as a target, certain parameters may need to be provided to monitor the component. The process of modeling a component in OEM as a target by specifying these monitoring properties is known as target discovery. The discovery is a process through which the OEM instance learns about the target, its type, configuration, and so on. It starts periodically monitoring the various performance characteristics. This discovery process helps in representing any physical manageable entity such as a host or an application as a target within OEM. The steps to discover any component as a target within OEM may vary based on the target type. OEM provides the administrator with a wizard or a guided flow. This is a series of steps that ask the administrator to provide the relevant parameters so as to discover a specific component based on the target type. During the discovery of the target, the OEM requires the user to specify the name for the target. The combination of the target name and the target type must be unique. OEM Grid Control supports multiple targets having the same name as long as their target types are different.
The process of discovery can be manual or automated based on the target type. Host targets are automatically discovered by OEM whenever there is an agent deployed on the physical host machine. However, an Oracle Siebel Server instance needs to be manually discovered by the OEM Grid Control before it can be monitored and managed.
Tip
The discovery process varies based on the target type to be modeled. The target discovery for a specific component can be initiated from the All Targets page within OEM Grid Control by choosing the appropriate target type in the drop down next to Add label in the All Targets page and then clicking on the Go button.
Agent-monitored and repository targets
In order to model a component OEM must support the type of the component and its attributes. In most cases, OEM uses an Oracle Management Agent to monitor these components as targets. Such targets that are modeled and monitored by an Oracle Management Agent are called agent-monitored targets. Prominent agent-monitored targets include databases, application servers, applications, and so on. For instance, if a database component that stores the inventory information within the travel portal example is to be modeled as a target, the database will need to be monitored by an Oracle Management Agent instance.
The targets to be monitored expose different attributes that can be determined using various protocols such as Simple Network Management Protocol (SNMP), Java Management Extension (JMX), and so on or just by running some shell or batch scripts. An Oracle Management Agent may use one or more of the above techniques to determine the monitor-able aspects of each component by running some executable modules. Such modules within the agent that are executed to monitor the performance characteristics of a target are known as fetchlets. Examples of fetchlets include JMX fetchlets, SNMP fetchlets, OS Line Token fetchlets, and so on. An Oracle Management Agent may use different fetchlets to monitor the various performance aspects of a single target. Also, a single agent instance can monitor multiple targets within a host. For instance, if an agent is deployed on a host comprising an application server and a database, the agent instance is capable of monitoring the corresponding host, application server, and the deployed applications, as well as database targets.
As discussed previously, the Oracle Management Server (OMS) of an OEM instance supports multiple agents monitoring multiple targets. The agents support both local and remote monitoring. During local monitoring, the agent needs to be in the same machine as that of the target. For example, the host targets are always locally monitored and require the agent instance to be deployed in the same host. However, some targets can be monitored remotely by having an agent in a separate machine from that of the target itself. So, remote monitoring does not require the agent and the target to be within the same host boundary. Remote monitoring is very useful in reducing the management overhead on the target server. However, the ability to perform remote monitoring depends on the target type as well as the performance attributes that are to be monitored. Targets such as Oracle WebLogic managed server targets can be monitored remotely using JMX fetchlets.
Certain targets represent logical or functional entities. Composite targets such as groups, system and service targets represent various traits of a business function. As these business functions are not readily available to be monitored as a physical entity, such targets cannot be monitored using Oracle Management Agents. These targets need to be defined within the Oracle Management Server (OMS) and do not require any agents to be assigned for monitoring. Such targets that are defined in the OMS repository and are not monitored directly using an agent are called repository targets. Composite targets within OEM Grid Control are defined as repository targets and do not require any agent for directly monitoring them. However, composite targets comprise other targets, which may include agent-monitored targets.
Tip
In general, physical components that participate in a business function are discovered and monitored as agent-monitored targets within OEM Grid Control. These targets are then related together within the OMS and a composition of many such targets is modeled as a repository target to represent a higher level business or logical function.
Availability management
One of the primary motives for an administrator to deploy a systems management solution in the enterprise is to determine if the components in the data center are up and running. This state of the component determines if it is accessible by other components and is an indicator of the health of the target. This monitor-able state that represents the health of the target is called its availability. Availability is a measure of the reliability and resilience of the component. For instance, if a database is down and inaccessible, this could impact the business functions that use the database and may cause service disruptions. Hence, it is critical for any target administrator to monitor its availability.
In OEM, most of the targets are associated with an availability status that represents the current health. The possible availability states in OEM include:
- UP: It indicates that the target is accessible and is healthy.
- DOWN: It indicates that the target is inaccessible and could cause possible service disruptions.
- BLACK OUT: It indicates that the target is currently in a scheduled maintenance window.
- METRIC COLLECTION ERROR: It indicates that the status of the target cannot be computed due to errors in executing fetchlets by the Oracle Management Agent.
- AGENT UNREACHABLE: It indicates that the status of the target cannot be ascertained by the OEM due to a failure in the communication channel between Oracle Management Agent and the Oracle Management Server (OMS).
- UNKNOWN: It indicates that the status of the target is yet to be ascertained by the OEM. This is used in repository targets.
The target specific flavors of the OEM, such as OEM DB Control and OEM FMW Control, display only the latest availability state, that is, the current health of the target. In the OEM Grid Control flavor, the availability states of the target are persisted in the OMS repository. This enables the administrator to view the historical state of the target. Within OEM Grid Control, the availability information is usually represented as a combination of the current state of the target followed by the time period for which the target is in the current state.
In addition to the current state of the target, OEM Grid Control also computes availability percentage (%) that indicates the historical health of the target. Availability percentage is defined as the ratio of the total UP time to total monitoring time, that is, sum of UP time, DOWN time and agent DOWN time.
The OEM Grid Control also provides a view that indicates the availability states of a target for a given period of time, that is, last 24 hours, last 7 days, or last 31 days. This displays the historical states of the component. This data acts as an indicator to the stability and reliability of the target.
The following image is a screenshot from OEM Grid Control that indicates the availability history of an Oracle WebLogic server. This specific page is known as availability status history page for the target.
As can be seen in the previous image, the cigar chart displays the historical availability states of the Oracle WebLogic server target for the last 24 hours. It provides the details of the total time during which the target was in various states and indicates the state changes during the last 24 hours. It also displays the calculated availability percentage as defined earlier.
Tip
The user can navigate to the Availability Status History page by clicking on the hyperlinks on the status of each target in the All Targets page.
Performance management
Each component exhibits key performance attributes that indicate its performance and responsiveness. Such attributes are referred to as performance metrics. While it is important for the administrator to know if a component is up and running, it is also equally significant to know how responsive the component is. The availability of the target indicates only its current state and if it is running. There are other vital statistics of the target that provide invaluable information about the different performance traits. For instance, a host target may be up and accessible, however due to high CPU utilization, it may be totally unresponsive to user input. Such a target also needs attention from the system administrator. Hence, it is important to monitor these key performance indicators of the target in addition to the availability. These key indicators are referred to as metrics.
Metrics form the building blocks of performance management of any target with OEM. The performance characteristics of a target are collected by the Oracle Management Agent using different executable modules called fetchlets. The agent supports a collection of different kinds of metrics using various protocols. In the target-specific flavors such as OEM DB Control and OEM FMW Control, these metrics are directly displayed to the end user. In this case, as with the availability measure, only the current or live metrics can be viewed. However, in the case of OEM Grid Control, these metrics are uploaded by the agent into the Oracle Management Server repository and the user requests are serviced by the OEM Grid Control console application directly from the repository. Hence, in the case of the OEM Grid Control, the historical metrics can also be viewed.
A target exposes multiple traits, each of which is an indicator of the performance of a specific aspect. For instance, the host target exhibits, in addition to the CPU utilization metric, other key performance indicators such as free disk space, memory utilization, load, and so on. The OEM Grid Control allows the collection each of these metrics to be enabled or disabled from the respective agent. It also supports customization of the metric collection interval—the time period between two subsequent metric uploads from the agent.
Alerts
Alerts are situations where the OEM has detected that a specific performance metric from a target has deviated from an expected level. Alert indicates degradation in performance of the related target and makes the administrator aware of the possible imminent service disruption. Alerts are available only within the OEM Grid Control flavors. They are generated whenever there is a deviant pattern observed in availability or in performance metrics.
As part of the metric collection configuration, the OEM Grid Control also provides an option to specify two thresholds—critical and warning thresholds. These thresholds indicate the expected levels of the metrics during healthy and normal conditions. Whenever the value of the metric collected crosses any of these thresholds, an alert is generated with the corresponding severity—critical or warning—and is stored in the repository. These alerts can be configured to provide different kinds of notification such as e-mail, sms, pager alert, and so on.
The following image shows a screenshot of a page from the OEM Grid Control 11g. This page is known as the Warning Alerts console. The user can navigate to this page by clicking on the Alerts link in the main tab and the Warning link in the subtab.
As can be seen in the previous image, the Alerts console within OEM Grid Control displays the various alerts based on severity. It also indicates the target name and type against which the alerts are generated, the time of alert generation, a short description of the alert, and the metric value that caused the alert generation.
Tip
The OEM Grid Control provides quick filters to view Alerts for specific targets. These quick filters can be applied by clicking on the Alerts hyperlink for the respective alert in the All Targets page.
Target home page
Each target has a summary page in OEM Grid Control that gives summary information of all the performance characteristics of the target. This view that provides the key performance details of specific target is called the target home page. The information displayed in the target home page depends on the type of the target that is selected. The targets belonging to the same target type have a similar target home page.
The following image is a screenshot from OEM Grid Control 11g that displays the target home page of the database instance named bsm. The home page for all database targets look similar to the image shown below, albeit the performance characteristics displayed in the target home page varies based on the target, its version, and its state.
Most of the target home pages show some common monitoring information. All the target home pages are composed of the following:
- General Section: This displays the current state of the target and shows the latest availability information. This section indicates the current version of the target and the host on which this target is running. This also provides the user with options that perform key process control operations such as start, shut down, or Black out to perform maintenance operations.
- Performance Metric Charts: This section displays the key performance indicators of the target displayed in a graphical format. These metrics are displayed in a chart for the selected time period.
- Alerts: This section displays any alerts for the selected target for the given time period. It provides a brief summary of the alert generated and the time at which the alert was generated. This section also displays the severity of the alert indicating if it is critical or warning.
- Policy Violations: This section provides a compliance score of the target with respect to the predefined target policies. It also indicates the number of the policy violations as well as the severity of the policy violations.
- Configuration Section: This section provides links to edit the configuration of the target. These include changing the metrics to be collected, the collection frequency, specifying the metric thresholds for alert generation, and so on.
In addition, each target home page provides links for retrieving specific information such as availability, performance metrics, charts, and so on in detail.
Tip
Throughout the OEM Grid Control console pages, the target names are hyperlinked. Clicking on these links navigate the user to the respective target home page.
Passive and active monitoring
As discussed in Chapter 1, there are multiple paradigms of modeling and monitoring various components within the enterprise. Passive monitoring involves periodic measurement of various performance metrics as exposed by the component. This does not involve injecting any new load within or interfering with the regular load of the component. Passive monitoring helps in identifying the performance degradation of the system. Active monitoring involves running certain key steps or tests from different geographical locations periodically. These involve synthetic transactions that inject specific load into the component for monitoring purposes. This load is synthetic and is in addition to the regular load. Though active monitoring adds new load into the component, they help in measuring the real end user experience periodically. This aids in proactively detecting possible service disruptions.
OEM Grid Control supports both passive and active monitoring paradigms. Passive monitoring is supported through the regular agent-monitored targets and by collecting the different metrics within a target using the agent fetchlets. Active monitoring is supported through the Beacons and Service Tests framework. The Oracle Management Agent supports a separate execution module called the beacon that is capable of executing predetermined steps periodically. These beacons can be deployed in different geographical locations to periodically execute synthetic transactions. These synthetic transactions are configured as Service Tests within OEM Grid Control. These Service Tests define the regular steps that are to be executed periodically in order to perform active monitoring on a target.
The subsequent chapters will cover both the passive and active monitoring capabilities of OEM Grid Control in greater depth.