Policy

Enterprise Manager Grid Control provides policy subsystem for configuration and security compliance.

Policy is a construct to define configurations and security recommendations for a given target type. For example, a security policy for OC4J recommends that all data sources should not have passwords in clear text; a configuration policy for WebLogic server recommends that the server should be running in production mode. The Enterprise Manager uses these policies to periodically check for conformance across multiple targets in a given datacenter.

Enterprise Manager comes with lots of out-of-the-box policies and users can customize those policies and define new policies; Enterprise Manager Console provides interface to customize or define new policies.

Policies are defined for a target type and can be enforced for all targets of a given type or only for some targets of a given type. The end user can configure what policies need to be enforced for a given target. For example, if there is a policy for a host target type that mandates that only port 80 should be open on all servers — the System Administrator may decide not to enforce that policy for a new server that is used for developmental activity.

Each policy definition is associated with a severity level. There are three severity levels, which are Informational, Warning, and Critical. Enterprise Manager evaluates these policies against the configuration data that is collected from the targets. Any violation of these policies is saved in the repository and can be used for sending out notifications.

We learnt in an earlier section how monitoring template can be used to set thresholds across multiple same targets. Policies can also be added to a monitoring template along with a metric threshold.

Configuration snapshot

Configuration snapshot of a target is a set of all configuration parameters at one point in time. Enterprise Manager keeps all related configuration for a target as configuration snapshot.

Enterprise Manager keeps a track of configuration changes by using configuration snapshots. When uploading a new configuration snapshot, it compares the new configuration snapshot with the existing snapshot, and the changes are saved separately in the repository.

Besides keeping track of changes, configuration snapshot can be used to compare the configuration of one target with multiple targets of the same type.

Comparing configurations is a critical part of any IT operations and troubleshooting. It is common to find that an application will work in one environment and not work in another environment. The fastest way to troubleshoot this is to compare the configuration between two environments, but configuration comparison can be a dreary job and issues are likely to be missed by the human eye, as configuration is spread out in multiple files across servers.

The following screenshot shows one such comparison of configuration snapshots of two WebLogic servers, where you can see the difference in heap parameters: