This chapter explains how Oracle Enterprise Manager Cloud Control (Cloud Control) simplifies the monitoring and management of the deployments in your enterprise.
This chapter covers the following:
Cloud Control collects configuration information for all managed targets across the enterprise. Collected configuration information is periodically sent to the Management Repository over HTTP or HTTPS, allowing you to access up-to-date configuration information for your entire enterprise through Cloud Control.
Cloud Control enables you to view, save, track, compare, search, and customize collected configuration information for all managed targets known to Enterprise Manager. Additionally, the Configuration Topology Viewer provides a visual layout of a target's relationships with other targets; for example, you can determine a system's structure by viewing the members of a system and their interrelationships.
Table 47-1 provides a snippet of configuration information collected for a small sampling of target types as an example.
Table 47-1 Collected Configurations for Various Targets
Target Type | Collected Configuration Information |
---|---|
HostFoot 1 |
|
DatabaseFoot 2 |
|
Middleware such as WebLogic Server |
|
Elastic Cloud Infrastructure |
|
VM Server Pool |
VM Server member details |
Client |
|
Non-Oracle Systems |
|
Footnote 1
The default collection period for host configuration information is 24 hours.
Footnote 2
The default collection period for database configuration information is 12 hours.
Use Cloud Control to manage enterprise configurations:
Search collected configuration data
Compare configurations
View latest and saved configurations as well as inventory and usage details
Monitor configuration history for changes
Build configuration extensions and introduce custom target types
Collect and analyze external client configurations
Perform root cause analysis and impact analysis
Use configuration search to search configuration data across the enterprise. Cloud Control ships with a set of configuration searches provided by Oracle, which you can use as a starting point to explore the volume of configuration data collected. As you work with a provided search, you can tailor the search criteria to refine or broaden the results, and save the altered search under a new name.
Perform powerful searches across the enterprise using sophisticated combinations of search filters, options, and relationships.
Enhance the search filtering criteria by adding your own SQL query statements. Save interesting search results by printing a report or exporting to a file.
To access the search capability, from the Enterprise menu, select Configuration, then select Search. The Configuration Search library page enables you to perform the following tasks:
To manage configuration searches, access the Configuration Search Library from the Enterprise menu. Select Configuration, and then select Search.
On the Configuration Search Library page, you can perform the following tasks for existing configuration searches:
The Configuration Search Library page displays a table containing saved configuration searches.
To search for an existing configuration search, scroll down the table or use the Search option by doing the following:
Expand Search.
Specify the name of the configuration search.
Specify the owner of the configuration search.
Note:
The search name and owner fields recognize containment, so you can specify a text string as a partial name to find all searches where the name or owner contains the string.
Select the target type.
Select Latest or History search type.
Select the mode that was used to create the search, such as All, Modeler, or SQL.
Specify if the configuration search is system defined or not.
Click Go. The search results are displayed in the table.
The View menu enables you to change how the content gets displayed in the table. You can select the columns that you want to view, sort the table content in ascending or descending order, and reorder the columns.
To run a configuration search, do the following:
On the Configuration Search library page, select a configuration search from the table, and then click Run to execute the search.
The Edit/Run Search page displays the search parameters applied in the search execution, the number of selected configuration items, and the search results.
You can edit the configuration items by clicking on the edit icon or the link next to it. The Apply Configuration Items dialog box appears. You can search for configuration items in the left panel, and then refine the configuration items using the right panel. Once you have selected the configuration items that you want to apply to the configuration search, click Apply. Else, click Reset to obtain the previous configuration items, or Cancel.
You can also export, print, and detach the configuration search page.
You can only edit configuration searches that have an opened lock icon displayed next to the search name. Oracle saved configuration searches are usually locked searches which you cannot edit.
To edit an existing configuration search, do the following:
On the Configuration Search Library page, select a configuration search in the table and click Edit.
The Run/Edit Search page displays the search parameters and the results of the search.
Change the search criteria to achieve the desired results.
You can edit the configuration items by clicking on the edit icon or the link next to it. The Apply Configuration Items dialog box appears. You can search for configuration items in the left panel, and then refine the configuration items using the right panel. Once you have selected the configuration items that you want to apply to the configuration search, click Apply. Else, click Reset to obtain the previous configuration items, or Cancel.
Click Save to overwrite the existing search. Click Save As to save the edited search under a new name. If you are working with an Oracle-provided search, use Save As.
You can also export, print, or detach the configuration search.
To delete an existing search, on the Configuration Search Library page, select the configuration search from the table, and click Delete.
In the dialog that opens, confirm the operation. You must be either the owner or the administrator of the configuration search in order to delete a search. A search in use cannot be deleted. Oracle recommends that you not delete a configuration search provided by Oracle.
The Configuration Search Library page enables you to search for and import or export existing configuration searches.
To import a configuration search, click Actions, and then select Import. In the Import box that appears, browse for the configuration search file that you want to import, and click OK.
To export a configuration search, select a configuration search from the table, click Actions, and then select Export. A dialog box appears with the options to Open or Save the configuration search as an XML file.
The Configuration Search Library page enables you to create a configuration search using any of the three usecases:
To create a new configuration search, do the following:
From the Enterprise menu, select Configuration, and then select Search.
On the Configuration Search Library page, select Create..., and then select Configuration Search.
On the Configuration Search page, in the New Search section, select the target type of the configuration search. The table containing the targets gets refreshed to display the target type that you have selected.
To apply configuration items to the configuration search, do the following:
Click the Configuration Items Add link.
In the Apply Configuration Items dialog box, in the left panel, in the search field, specify the name of the configuration item. You can view a list of the configuration items in this panel in a flat or hierarchical view.
Select a configuration item from the left panel. You can refine the selected configuration item using the search criteria options in the right panel. Ensure that you deselect the configuration items in the right panel that you do not want to see in the search results.
Click Advanced Search Options if you want to further refine your search. This search method enables you to view the configuration items in groups, and add configuration items to each group. This search also provides OR and AND operators, unlike the Simple search which just gives you the option of OR operator.
You can further refine each group, by clicking the refine icon next to the group name. This enables you to select any of the following conditions:
None - Displays results based on specified property values.
Exists - Displays targets that contain the configuration item identified by the specified property values. For example, display database instances that contain patch 13343438.
Does not exist - Display targets that do not contain the configuration item identified by the specified property values. For example, display database instances that do not contain patch 13343438.
The first selection option returns not only matching entities but also actual property values. The rest return only the matching entities.
Click on Related Target Types link to associate the target type with other targets. For example, you may want to know the Management Agent that is monitoring a host you have selected.
Click Apply to add the configuration items to the configuration search. Click Reset if you want to revert to the previously saved configuration items.
The number of configuration items selected will now be displayed next to Configuration Items. The configuration items get added to New Search section and are displayed in the table against the targets.
As you add criteria, click Search to see the results. Continue to revise the search by adding and removing filters until the results are satisfactory.
Notice in the search results table that the column names are a concatenation of the filters you specify and elect to display. So, for example, If you filter on hardware vendor name for target type host, the column name in the search results table reads Host Hardware Vendor Name.
Click Advanced if you want to specify more specific search criteria such as target name, member of, and the host that the target is on. You can also choose to Reset all the changes that you have made.
Click Save As. In the Create Configuration Search dialog box, specify a name for the configuration search, and click OK.
To create a configuration search from an existing configuration search, do the following:
From the Enterprise menu, select Configuration, and then select Search.
On the Configuration Search Library page, search for and select the configuration search that you want to copy from the table.
Click Create Like...
In the Copy Configuration Search dialog box, specify a name for the new configuration search that you are creating.
Click OK.
Select the new row in the table and click Edit. Make the desired changes to the search parameters and then, save the configuration search.
Sometimes, despite all the filtering criteria, search results still fall short. To refine the search even further, you can create a configuration search using SQL by following these steps:
From the Enterprise menu, select Configuration, and then select Search.
On the Configuration Search Library page, click Create and then select Search Using SQL.
On the Search Using SQL page, you can create a SQL Query statement and then click Search to run the search. You can also edit the SQL Query statements for an existing configuration search by selecting the search from the table on the Configuration Search Library page and then clicking Search Using SQL.
Note:
You use views in this case. You cannot access the underlying tables. Your SQL edits apply only to the current search execution. If you want to preserve the edited statement, you can choose to Export as an XML file or Print the SQL statement.
Click Save As. In the Create Configuration Search dialog box, specify a name for the configuration search, and click OK.
Use the Configuration Browser to view configuration data in the context of a single managed entity. Configuration data can include:
Configuration items and properties
System configuration data as well as all system members and their configuration data
System and target relationships (immediate, member of, uses, used by, and so forth)
Configuration extension collection data
The browser window consists of left and right panes. The left pane is a tree hierarchy. The right pane consists of tabs that display information in tables. As you navigate in the tree, your selection dictates the contents in the right pane. Depending on the selection, tabs appear containing data such as properties and values, relationships, a hierarchical structure of a system and its members, and file contents in both a parsed and raw text format.
You can take any of several actions as you view a configuration in the browser. These actions are available from the Actions menu above the tabs. The tree hierarchy in the left pane also has context menus available.
This section covers the following topics:
Saved configurations are snapshots in time of collected data preserved for future reference. You may simply want to view the saved data, or you may want to use it as the basis of a comparison.
You can save standard as well as composite configurations. Saving a configuration saves all configuration item and relationship data for the selected target and for all member targets.
Note that there are various ways to save a configuration:
While viewing a table of all targets, right-click a target and select Configuration, then select Save.
While viewing a target's last collected configuration in the Configuration Browser, select Save Latest from the Actions drop-down menu.
A save, particularly one that involves systems or groups, can take several minutes. So, for performance reasons, a save action submits a job that occurs asynchronously. To check job status, do the following:
From the Enterprise menu, select Job, then select Activity.
Click Advanced Search and set the following criteria:
Set Job Type to ECM Save (or Save Latest).
Set Target Type to Targetless.
Click Go.
Drill down in the search results for save details.
To view a saved configuration:
From the Enterprise menu, select Configuration, then select Saved.
In the table of saved configurations, select the configuration you want to browse, then click View.
Navigate the tree hierarchy to expose the following categories of data:
Managed entities, configuration items, their properties, and relationships
System structures
Configuration extension collections
You can also view a saved configuration in the Configuration Browser: right-click a target tree node and select Configuration, then select Saved.
To compare a saved configuration:
From the Enterprise menu, select Configuration, then select Saved.
In the table of saved configurations, select the configuration you want to compare against, then click Compare.
The selected configuration becomes the first configuration in the comparison workflow. Continue the process of setting up the comparison.
To import a previously exported configuration:
View inventory summaries for deployments such as hosts, database installations, and fusion middleware installations on an enterprise basis or for specific targets.
View inventory summary information in the context of different dimensions. For example, for host inventory summary, you can view by platform, vendor, or OS version.
Drill down multiple levels of inventory details.
See trends in inventory counts charted across a time line. Chart bars are color-coded to match the view selection.
Switch to a pie chart to break down the inventory data for the rollup option by color-coded percentages.
For Hosts (OS Patches) and Databases (Patches Applied), click a patch indicator to link to patch details.
Repeatedly revise selections to refresh chart and details based on new selections.
Export deployment and details tables to CSV files.
To view inventory and usage details:
Note that you can export either the master (deployments) table or the details table. In either case, click the Export button to open a dialog where you can browse to a file location and save the table as a CSV file.
Note:
In a shared Oracle Home deployment the inventory location is /scratch/myCentralInventory
. This inventory location inside the Oracle Home is used by all the other hosts to execute the attachHome script.
The oraInst.loc file inside the Oracle Home points to this inventory location. Ensure that this inventory location is locally available in all destination hosts. Else, this location is created if required. This way there is coherence as all the hosts using the same Oracle Home also use the same inventory location.
Configuration history is a log of changes to a managed entity (target) recorded over a period of one year. The recorded history includes changes both to configurations and to relationships. Relationships are the associations that exist among managed entities.
Configuration history is a powerful tool for monitoring change activity across the enterprise. Consider these use cases:
You have noticed that an Oracle RAC system has been underperforming for the past month. As an administrator it would be useful to know what changes have occurred during that time. Have members been added or removed? Have there been configuration changes to the system itself?
The daytime administrator notices that detected changes are the result of a patch having been applied and adds an annotation to that effect. The overnight administrator is alerted to the changes and sees the annotation upon follow-up.
A hardware memory change to production hosts has been detected. The administrator wants to keep the IT group posted on any future changes in this area. The administrator schedules a recurring job to check history specifically for changes to hardware memory on production hosts and to notify the IT group of such changes.
While viewing a configuration history, you can:
Track changes to targets over time by specifying and refining search criteria.
View change history and manipulate how the information is presented.
Annotate change records with comments that become part of the change history. Annotations have a timestamp and an owner.
Schedule a history search to capture future changes based on the same criteria.
View the status of scheduled history jobs.
Notify others of future change detection.
Save change history details to a file.
This section covers the following topics:
Use any of the following methods to access configuration history:
From the Enterprise menu, select Configuration, then select History. Proceed with a configuration history search.
Perform a search of all targets. Right-click in a row of returned targets and select Configuration, then select History in the popup menu. View the results for the selected target, identified by type and name in the respective search criteria fields; change the filtering criteria to see a different result. Select a specific configuration item, for example, or change the date range.
On a target home page, select Configuration, then select History in the target type-specific menu (top left corner). View the results for the target, identified by type and name in the respective search criteria fields; change the filtering criteria to see a different result. Select a specific configuration item, for example, or change the date range.
The Configuration History Perform the following tasks within configuration history:
Drill down within configuration change history
Enter annotations and comments
Schedule a recurring history search and send the results
Save a change history to a file
Save configuration history
Create a search using SQL
To search configuration history, follow these steps:
Note:
One search strategy to consider is perform a gross-level search to see the volume of changes, then go back and refine the search by adding filters.
Click See Real-Time Observations to search actions monitored by compliance rules. Observations are the actions that users have taken on a host or target that were configured to be monitored through real-time monitoring rules.
Click Export to save the search results to a CSV file such as a spreadsheet. The value in each column represents a comma-separated value.
Click the number in the History Records column to display the changes detected for the selected target.
In the change details table, select a table row and do any of the following:
Click Details to see the change details in a pop-up window, including old and new values, and the specifics of any annotations. The Change link in the Type of Change column pops up the same window.
Click See Real-Time Observations to search actions monitored by compliance rules. Observations are the actions that users have taken on a host or target that were configured to be monitored through real-time monitoring rules.
Click Add Annotation to enter a comment about the change.
Click Export to save the search results to a CSV file such as a spreadsheet. The value in each column represents a comma-separated value.
To annotate configuration changes:
Note that you can also remove an annotation, provided you are the one who entered the comment (or have super administrator privileges). Select the row that contains the annotation and click the Remove Annotation button. Confirm the removal in the popup message that opens.
You can schedule the change history search to run as a background job (click the Schedule and Notify button). The search can be run once-only or on a recurring basis. Run the search immediately or at some later date. You also can supply e-mail addresses to which to send a link to the search results.
Use a scheduled history search as a tracking mechanism to generate alerts when changes occur.
You can capture the snapshot of change history you have culled for further review and to share with a wider audience, by saving the change details to a CSV file. Click Export and follow instructions in the export dialog.
You can save your configuration history search, by clicking on the Save As button on the Configuration History page. In the Configuration History - Oracle Enterprise Manager dialog box that appears, specify a name for the saved configuration history.
Click OK.
Your configuration history search gets stored in the Configuration Search Library. To navigate to the Configuration Search Library, from the Enterprise menu, select Configuration, and then click Search.
You can select your saved configuration history and perform tasks such as edit, delete, and run.
Sometimes, despite all the filtering criteria, search results still fall short. To refine the search even further, on the Configuration History page, click Search Using SQL, and then select Configuration Changes or Relationship Changes.
On the Search Using SQL page, you can edit the SQL Query statement to extend search expressions and rerun the search. Note that you use views in this case; you cannot access the underlying tables.
Click Search.
You can also save the SQL search by clicking Save As. In the Create Configuration Search dialog box that appears, specify a name for the SQL search, and click OK.
Your SQL search gets stored in the Configuration Search Library. To navigate to the Configuration Search Library, from the Enterprise menu, select Configuration, and then click Search.
You can select your saved configuration history and perform tasks such as edit, delete, and run.
View a list of all current and past history searches. Use search criteria to filter the list of history jobs (click the History Job Activity button). For example, show all scheduled history searches started over the past 24 hours; or, show all successful history searches involving hosts started over the past 31 days. The jobs engine purges history jobs older than 31 days.
The history jobs you can view beyond your own depend on your role and access level granted.
Select a table row and click View Result to go to the Jobs page that reports the history search. From there you can drill down to the changes the history search detected. The job name is a hyperlink that takes you to the same place. Use the bread crumb on the Jobs page to navigate back to the list.
If you are the job owner or otherwise have the proper access level, you can perform list maintenance by deleting history jobs that no longer have relevance.
This section describes the template creation process and the use of rules in the process. It also provides information on setting up comparisons and managing comparison templates.
This section covers the following topics:
A comparison template is an exemplar for fine-tuning a comparison of like configurations. A template is associated with a specific target type, which determines the configuration item types, items, and properties to be compared. Oracle provides a set of default templates to support certain target types. A template enables you to establish specific settings to take into account when comparing configurations of the given target type; for example, which property differences to ignore, and which property differences trigger an alert. You also can use constraints to establish acceptable values for specific properties. A configuration being compared that does not comply with the constraint constitutes a difference.
A template can invoke rules, or expressions, to be evaluated in determining when there is a match for comparison purposes, and when to disregard differences detected in a comparison.
Templates can be used as is, or as a guideline. So, for example, you might decide that an existing comparison template, with just a few tweaks, can meet your requirements. Perhaps the template ignores property differences that you are concerned about. In this case, use the create-like feature to make the adjustments to an existing template and save it under another name.
For systems, you design a system template that references member templates, based on the target types that make up the system. Create the member templates before you create the system template.
This section describes how to create, edit, and otherwise manage comparison templates.
Use these instructions when creating a new template or editing an existing template; this includes create-like.
From the Enterprise menu, select Configuration, then select Comparison & Drift Management. Click the Templates tab.
To search for a template, click Search. You can search for multiple target types from the target type list. Select the target types that you want to search for. You can also specify the Template Name, the name of the Owner, and specify if the template is a default template or an Oracle provided template. Click Search.
Each template has a lock beside the template name. A closed lock represents an Oracle provided template. These templates cannot be edited. The templates that have an open lock are user defined comparison templates, and can be edited.
For a new template, click Create and provide a name and target type. To base a template on an existing one, select the template row, click Create Like, and provide a name. In either case, the action creates a new template row.
Select the appropriate template row in the table and click the Edit button. The Template Details page appears.
The compared configurations' target type drives the hierarchy of configuration item types and configuration items on the left. The settings in play for the respective properties on the right derive from the selected template, unless you are creating a new template from scratch, in which case there are no settings.
A system comparison takes an overall template and a template for each system member. Thus there is an additional tab for Member Settings. Edit the tab as follows:
Optionally select the member template to use for each system member type.
For any given member type, you can elect to compare configurations by checking the check box.
For member types that you are comparing, select a target property to use as a matching key. The default is target name, but typically you would want to use a distinguishable property to align comparison entities, such as department or location.
To create or edit the comparison template for each member, select the Member Settings tab.
You can choose to view the mapping display in a tree or table format. If you set the Mapping Display to Tree, the View mapping and Comparison results will display the system members in a hierarchical tree format. If you set the Mapping Display to Table, the View mapping and Comparison results will display the system members in a table format. You can edit the following:
Optionally select the member template to use for each system member type.
For any given member type, you can elect not to compare configurations by clearing the check box.
Note:
When you clear a check box for a system member, the children instances of the system member will automatically be ignored during the comparison that uses this template.
For member types that you are comparing, select a target property to use as a matching key. The default is target name, but typically you would want to use a distinguishable property to align comparison entities, such as department or location.
In the Template Settings tab, select a configuration item type or item in the left pane to expose its properties in the right pane. A key icon denotes a property that is defined as a key column in the configuration item type's metadata.
Tip:
Notice the Compare check box column on the Template Settings tab. This is a powerful feature that enables you to streamline the comparison by selecting only those items you want to compare. When you select the check box, the comparison engine includes the corresponding configuration item type and all of its descendants.
Contrast this with the ability to compare individual columns and rows on the Property Settings tab, in which the settings are stored as part of comparison results, giving you the option to view the compared properties on the results page.
So, for example, in comparing host configurations, you may decide that any differences in CPU properties are immaterial. Simply expand the Hardware configuration item type and deselect the CPUs check box to exclude all properties associated with the item.
Click the Property Settings tab and check boxes for property differences to be compared and alerted if different. They are mutually exclusive. When you compare differences in a property value in this fashion, you are doing so unconditionally for all differences detected in the property value for the configuration item type.
Use a value constraint rule to filter the property value. In this case, the comparison engine compares the property value in the configurations being compared (the second through n configurations) to the constrained value. A property value that satisfies the constraint constitutes a difference. For example, test for a version equal to or greater than 6. Any instance in the compared configurations of a version property value under 6 constitutes a difference. Clearly, you would not set a value constraint if you checked compare differences. Specify a rule expression to set a value constraint. See Specifying Rules for details.
Repeat the preceding steps to set additional property settings on other configuration items.
Optionally, select an item in the left pane and click the Rules for Matching Configuration Items tab. For a given property, specify a rule expression to be evaluated to determine when a match exists between configuration instances. In other words, if the expression resolves to true, compare the instances. See Specifying Rules for details.
Match rules are column-based; they apply an AND logical operator. If you specify rules for multiple properties, they must all resolve to true to constitute a match.
Optionally, select an item in the left pane and click the Rules for Including or Excluding Configuration Items tab. For a given property, specify a rule expression to be evaluated:
Compare all - Compares everything in the configuration item.
Excludes items that match these rules - Compares everything except the properties listed.
Includes items that match these rules - Only compares the properties listed, that is, ignores everything else.
The rules for including or excluding configuration items are row-based; they apply an AND logical operator within a subset of rules and an OR logical operator between rule subsets. So, if you specify two rules for property A and two rules for property B, either both rules set on property A OR both rules set on property B must resolve to true to constitute a match.
View a template's settings and composition; this is read-only
Delete a template (requires the proper permissions)
Share templates by exporting them in XML file format and importing them into other Cloud Control systems
Viewing a Comparison Template
You can view templates provided by Oracle and other users' templates to which you have access. Viewing a template is read-only: you see its makeup, but you cannot change anything, even temporarily.
Select a template in the Comparison Templates page and click the View button.
Expand items in the tree on the left and peruse the settings and rules on the various tabs.
You cannot delete an Oracle provided template. An Oracle provided template is represented by a closed lock beside the template name.
You cannot delete a comparison template unless you have the proper permissions.
You cannot delete a default comparison template.
You cannot delete a comparison template currently in use.
To delete a template, select it in the Comparison Templates page, click Delete, and confirm the operation.
Exporting a Comparison Template
Use the export feature to save a template as an external file that can be imported into another Cloud Control system.
Select a template in the Comparison Templates page, select the Actions menu and click Export.
A platform-specific file dialog opens. For example, if you are using Firefox, the dialog notes that you have chosen to open the named template, which it identifies as an XML file. The dialog asks what you want Firefox to do, open the file in an XML editor or save the file.
Select the save radio button and click OK.
Browse to the desired location in the file system and save the file, changing the name if applicable. You cannot change the name of a template provided by Oracle on export.
Importing a Comparison Template
Any comparison template import must comply with the comparison template .xsd. So, for all intents and purposes, the import should be a previously exported template to ensure compliance.
An exported template is associated with its owner. A template whose owner is not the same as the login ID of the person importing the template retains its original ownership. If you want to be the owner of the imported template, you have to edit the owner
attribute in the template XML file prior to import, changing the value to your login ID. Or, you can simply remove the attribute, in which case the default owner will be set to the ID of the person initiating the import operation.
The Template Manager disallows import of a template provided by Oracle of the same name. Similarly, you could change the name
attribute in the template XML file prior to import to allow the import to occur.
Specify rules in the context of creating or editing a comparison template (see Creating or Editing a Comparison Template).
Rules enable you to parse configuration data in order to fine-tune comparisons. In terms of the comparison, a rule applies the expression to the value of the selected item in the configuration instance that is being compared to the benchmark configuration. Matching rules are intended to devise a comparison key that aligns the instances being compared. Ignore rules are intended to establish a basis for disregarding any differences detected between instances being compared.
To access the rules functionality, select Configuration from the Enterprise menu, then select Comparison & Drift Management. Click the Templates tab on the left. Select a template to edit and click Edit.
Specify value constraint rules as follows:
Select a configuration item in the left pane.
Click the Property Settings tab in the right pane and select the property on which you want to set a value constraint.
When the Property Settings tab is selected, keys are displayed in the column to the left of the Property Name.
Click the Edit Rule button in the toolbar. In the dialog that opens:
Select an operator from the drop-down list.
Type an operands expression, then click OK. An operand is a value that you want to either include or exclude from the constraint. For example, if you want to exclude Patch ID 12,34,56,78, you would enter operand as '12', '34', '56', '78'.
To clear a rule, select the table row and click the Remove Rule button in the toolbar.
See About Rules Expression and Syntax for details on the formation of a rules expression.
Specify matching rules as follows:
Select a configuration item in the left pane.
Click the Rules for Matching Configuration Items tab in the right pane, then click New.
Select a property in the drop-down list that appears under Property Name.
To create the rule, select the table row and click the Edit Rule button in the toolbar. In the dialog that opens:
Select an operator from the drop-down list.
Type an operands expression, then click OK.
To specify additional rules, click New and repeat Steps a and b
To clear a rule, select the table row and click the Remove Rule button in the toolbar.
For more information on the formation of a rule expressions, see About Rules Expression and Syntax.
You can enter additional rules for the same or for a different configuration item. When there are multiple rules, they resolve in the order specified. Matching rules take an AND logical operator, which means all conditions must resolve to true to constitute a match.
Specify ignore rules as follows:
Click the Rules for Including or Excluding Configuration Items tab in the right pane.
Choose one of the following options: Compare all, Exclude those that satisfy rules, Include only those that satisfy rules. Click New.
Select a property in the drop-down list that appears under Property Name.
To create the rule, select the table row and click the Edit Rules button in the toolbar. In the dialog that opens:
Select an operator from the drop-down list.
Type an operands expression, then click OK.
To specify additional rules, click New and repeat Steps a and b.
To clear a rule, select the table row and click the Remove Rule button in the toolbar.
See About Rules Expression and Syntax for details on the formation of a rules expression.
You can enter additional rules for the same or for a different configuration item. When there are multiple rules, they resolve in the order specified. Including and Excluding rules take an AND logical operator for rules within a subset, and an OR logical operator between subsets. So, for two subsets, each with multiple rules, all rules in the first subset OR all rules in the second subset must resolve to true to constitute a match.
Select New Or to indicate the end of one rule subset and the beginning of another.
A rule consists of an operator and operands. Taken together, they form an expression that resolves to a value that is then compared to the value of the selected item. A true condition satisfies the rule.
Operands can be literals (string literals are enclosed in single quotes), legal numbers, or dates of the form YYYY-MM-DD HH24:MI:SS.FF.
Operands that directly reference the value of a configuration item must be of the same date type as that value. Operands in square brackets in the syntax are optional.
Operator | Operands |
---|---|
is equal to* |
An optional literal value to match; string values are case-sensitive; if unspecified, expression evaluates value of the property to which the rule applies Note that a matching rule compares the values of the configuration items in the respective configuration to one another, not to a third specified value, so the operator does not take an operand in this case. [match-literal] |
is case-insensitive equal to* |
An optional case-insensitive string literal; if unspecified, expression evaluates value of the property to which the rule applies Note that a matching rule compares the values of the configuration items in the respective configuration to one another, not to a third specified value, so the operator does not take an operand in this case. ['match-literal'] |
is greater than or equal† |
A literal value to match; required match-literal |
is greater than † |
A literal value to match; required match-literal |
is less than or equal to† |
A literal value to match; required match-literal |
is less than† |
A literal value to match; required match-literal |
is one of† |
A comma-separated list of literal values, at least one of which must be specified, but only one of which need match match-literal-1[,match-literal-n,...] |
is between† |
A range specified as start and end literal values; both must be specified; range is inclusive start-range-literal , end-range-literal |
contains† |
A string literal on which to perform pattern matching; required [FALSE|TRUE,] 'pattern-literal'
|
replace‡ |
A string literal to match and replace with a second string literal [FALSE|TRUE,]'pattern-literal'[,'replacement-literal'][,position-integer][,occurrence-integer]
Mandatory pattern literal represents the string value to match If the replacement string literal is unspecified, replace the matched string literal with nothing |
substring‡ |
Extract specified segment of string value [FALSE|TRUE,]position-integer[,length-integer][,'pattern-literal'[,occurrence-integer]]
Mandatory positional integer argument indicates where to begin string extraction:
Optional length integer argument indicates character count starting at position integer pattern literal represents the value to match; optional if the first argument is occurrence integer argument indicates character count to match; valid only if pattern literal is specified |
Notations are as follows:
These rule examples assume that you are in the process of creating or editing a template and are at the point where you have selected the configuration item in the tree on the left.
Suppose, when comparing the hardware of host configurations, you want, for matching purposes, to ignore case in respective vendor names. Here's a simple rule to make the comparison case-insensitive.
In the Rules for Matching Configuration Items tab, click New.
Note: For this example, ensure you are using a Host target type template.
Select Vendor Name in the drop-down list under Property Name.
Select the table row and click the Edit Rules button in the toolbar to open the rule dialog.
Set Operator to is-case-insensitive-equal-to
. As this operator takes no operands for a matching rule, you are done.
Click OK.
Suppose you want to compare WebLogic Servers, aligning on server name, where the names are different: ManagedServer1 and ManagedServer2, for example. To ensure the comparison occurs, you need to fashion a match on server name.
In the Template Settings tab, highlight Server Information.
In the Rules for Matching Configuration Items tab, click New. In the Property Name drop-down list, select Machine Name.
Select the table row and click the Edit Rules button in the toolbar to open the rule dialog.
Set Operator to substring
.
Set Operands to 1, 13
.
Click OK.
Effectively, the rule says use the first 13 characters of the name (ManagedServer), thus excluding the qualifying integer.
Another way to achieve the same result:
Set Operator to replace
.
Set Operands to true, '(*)(\d*)', '\1'
.
Click OK.
This example uses a regular expression (TRUE
) to resolve all characters prior to the qualifying integer.
For a more advanced example, consider a database instance comparison that requires a match on Datafiles file names within a Tablespace, where file names are of the form:
/u01/jblack_abc2d/oracle/dbs/dabc2/mgmt_ad4j.dbf
Effectively, the rule says use a regular expression (TRUE
) to construct a matching key from the value between /u01/
and oracle
, combined with what remains of the original filename after dabc2 /
, or jblack_abc2d/mgmt_ad4j.dbf
.
Generally, you use ignore rules to ignore differences in collections that are row-oriented, as opposed to column-oriented. Configuration extension snapshots, for example, are row-oriented data collections.
Say, for example, you wanted to ignore in configuration extension parsed data, any row where the property Attribute
identifies an internal ID or checksum.
In the Rules for Including or Excluding Configuration Items tab, click New.
Select Attribute in the drop-down list.
Select the table row and click the Edit Rules button in the toolbar to open the rule dialog.
Set Operator to is one of
.
Set Operands to 'id', 'checksum'
.
Click OK.
The rule ensures that the comparison ignores any row in the collection data that contains either of the specified values.
Now consider an ignore rule that demonstrates how the comparison engine applies the logical operators AND and OR against the same configuration item type. In this example the objective is to ignore rows in configuration extension parsed data when any of three rule sets satisfies the following conditions:
‘sqlnet.ora'
AND Attribute = ‘ADR_BASE'
‘tnsnames.ora'
AND Attribute = ‘HOST'
‘resources.xml'
AND Attribute = ‘authMechanismPreference'
Notice that the comparison engine applies the AND operator to rules within a set and the OR operator between rule sets. Rules for ignoring instances support inheritance; thus, in this case, the Data Source property is available in rules creation, as demonstrated in the example.
The comparison ignores any row in the collection data that satisfies any of the three rule sets.
Enterprise Configuration Management deals with the collection, storage, and monitoring of configuration data tied to managed entities within the enterprise. A host, for example, has configuration item types related to its hardware and software components—number of CPUs, memory, IO devices, OS platform and version, installed software products, and so forth.
Changes to configuration data invariably happen, typically because of common events like patches and upgrades. At some point a change to one component can affect the overall system in a negative way. Detecting the root cause becomes paramount.
Enterprise Manager provides the following types of comparisons:
Configuration drift
Enables you to compare configurations of a target with configurations of another target of the same type.
Configuration consistency
Reflects the changes of target members within a system. For example, you would use configuration consistency to ensure that the configuration parameters for all databases within a cluster database are the same
The comparisons can be done on the current configuration or on configurations previously saved (for example, just before applying a patch or doing an upgrade).
Comparisons allow you to:
Ignore certain attributes during a comparison. Define comparison templates to disregard unnecessary attributes.
Notify key personnel when differences are detected
Design and share comparison templates with other administrators
Compare complete target systems; match target system members automatically or manually
Compare configuration file data as raw file content or in a parsed format
Note that after you define and save comparisons, a change in configuration automatically starts a recomparison. If you have setup notifications, you will be notified of the changes.
Comparisons are an important factor in managing the enterprise. Setting up a comparison involves the following steps:
Select the first configuration in the comparison (the one to compare against)
Select additional configurations (the one or more configurations to compare to the first configuration)
Select a comparison template to fine-tune the attributes being compared (or no template)
For system comparisons, map members as needed. It's a way to selectively indicate how members of respective systems should match up in a comparison.
Review your work
Set up email notification by setting up mail servers and then creating incident rules
Review BI Publisher Reports (From the Enterprise menu, select Reports, then select BI Publisher Reports.)
A follow-on step would be to review the results and drill down to differences details.
When creating a drift or consistency comparison:
Determine what configuration items you want to compare.
Create a template or use an existing template.
Create a definition of either a drift comparison or a consistency comparison.
Perform the comparison.
Set up email notification by setting up mail servers and then creating incident rules. See Creating Notifications for Comparisons.
View the results from the Comparison & Drift Management Drift Results tab or the Comparison & Drift Management Consistency Results tab. You can also view the results as a BI Report. To view BI Reports: from the Enterprise menu, select Reports, then select BI Publisher Reports.
One-time comparisons are used to immediately view the differences between target configurations. One-time comparisons differ from drift and consistency comparisons in that the comparison is only evaluated once, even if you choose to save the results for later viewing.
If you are thinking of creating a drift or consistency comparison, consider creating a one-time comparison to verify that the initial drift or consistency evaluation will not result in immediate differences. Using the results, you can change the errant configuration values, or fine-tune your comparison template to ensure that only configuration items of interest are compared.
To perform a one-time comparison:
From the Enterprise menu, select Configuration, then select Comparison & Drift Management.
In the One-Time Comparison section of the Dashboard page, click Create Comparison.
Decide whether you are performing a Basic or Advanced comparison.
The Basic One-Time Comparison is a simple comparison between two or more targets. The fields are:
Reference Target (Current)
Target against which the comparison is being made.
Comparison Template
Template or pattern to be used for the comparison. This template can contain property settings, rules for matching configuration items, and rules for including and excluding configuration items.
The Advanced One-Time Comparison provides more options than the Basic One-Time Comparison. For example, you can use saved configurations and perform a consistency comparison within a system.
The fields are:
Reference Target (Current)
Target against which the comparison is being made. Use this option when comparing targets.
Use this option to test against the latest configuration of the selected target you deem to be good. This configuration may or may not be to your liking but it is what is available at the moment.
This is the target against which the other target is being compared. Note that the list of the targets is restricted to 2,000. Use the Search option to restrict the list of targets.
Reference Target (Saved)
Configuration that was created at an earlier time and which will be used as the base for the comparison. Use this option when you want to compare targets against your gold configuration.
Use this option to use an existing configuration. The benefit is that you have (hopefully) already tested this configuration and it meets your requirements.
Consistency Target Type (use for systems)
When comparing systems, provide the type of system, for example, Cluster Database or Database System.
Use this option to test the consistency of targets among systems. Note that all cluster members have the same saved configuration. For example, you can determine if all the configuration database parameters are the same within a cluster database.
Comparison Template
Select a template that has gone through rigorous testing or use this one-time comparison to fine tune the comparison template to compare only what you need.
An example of an existing template is one that you created or a template provided by Oracle. If you don't supply a template, there will be a one-to-one comparison between the fields in the reference target and the compared targets.
Click Add to select targets or Add Saved to select saved configurations for the comparison. Remember that you can only compare targets of the same target type.
Note that the more targets you add, the longer it will take for the compare operation to complete.
After you have added the targets, and you decide to minimize the number of targets, on the Target menu, highlight the targets to eliminate and click Remove.
Click OK. The comparison begins immediately and results are displayed on the Comparison Results page.
Depending on the options you chose, it may take a while for the results to display. Click the Enterprise Manager Refresh button until the comparison is completed and the In Progress icon disappears. Click the i icon located by Comparison Results name for a listing of the options chosen for the comparison.
Configuration drift ensures consistency (uniformity) across a large number of targets. For example, ensures that the configuration of the personnel database is the same across all the personnel databases throughout the company. This is particularly useful in this day and age of company acquisitions.
To perform a Drift Management Comparison:
From the Enterprise menu, select Configuration, then select Comparison & Drift Management.
In the Drift Management section of the Dashboard page, click Create Definition.
On the Compare Configurations dialog box, select the Target Type and Template. For example, select Database Instance and the template of choice, in this case Database Instance Template. Then, click OK.
On the Drift Definition page, provide the following information:
Definition Name - Make the name meaningful. The information from the Compare Configurations popup is replicated.
Source Configuration
Select either Latest Configuration or Saved Configuration. Either one is the gold configuration against which the other targets will be compared. When using the Latest Configuration, choose the source target. When using the Saved Configuration, choose the appropriate configuration.
Advanced
Expand this section to provide additional factors on the comparison.
Choose the severity of the drift. Options are: Minor Warning, Warning, and Critical.
Target Property Filter
You can specify specific target properties that determine which targets this definition can work against. These properties are Operating System, Target Lifecycle State, Version, and Platform. When you specify a target property filter for this definition, for instance for Linux OS, it will only be applicable to targets on Linux Operating Systems.
Description
Describe this drift definition and provide as much detail as possible. This information provides information for others who will be using this definition in the future.
Rationale
Explain the reason for this comparison, for example: This content will detect configuration drifts for the targets.
Keywords
Enables you to categorize this drift definition for quick reference.
After you have provided the information, select one of these options:
Save and Test Targets
Once a target is associated with a comparison, comparisons are automatically triggered for that target when appropriate. For example, when the target's configuration changes, a comparison will be triggered, and if the automatic comparison results in a difference from the reference target, notifications will be sent, and the differences will be available in any reports for the drift comparison.
Before associating targets with a comparison, you may want to run a test comparison. Configuration differences detected during a test comparison do not cause notifications to be sent, and will not appear in reports. The results from the test comparison can be used to verify that the comparison template is only comparing items of interest. Also, the test results can give a preliminary indication of how different a target is from the reference target. The Save and Test Targets option lets you run these test comparisons.
To test targets, in the Test Targets page, clickAddto add a compared target. Select the target, and click Run Test. This will trigger a test comparison, and the number of differences generated will be placed in the Differences column of the table. To view the results of the test comparison, click on the difference count. Once you are satisfied with the comparison results, select the target and click Associate to permanently associate the target with the drift comparison, enabling automatic re-comparisons, notifications, and visibility of the target in reports.
Save and Associate Targets
Saves the input, triggers automatic comparisons that use this comparison definition, and directs you to the Target Association for Drift Definition page.
Click Add and select the targets you want to associate with this definition. Click OK. You will be prompted on whether you really want to save the associations.
Save and Return
Saves the input for future use. You can view the saved comparison definition in the Definition Library tab of the Comparison & Drift Management dashboard.
You are returned to the page from where the configuration drift was launched. For example, if you started from Drift Definition Library page, you will return to that page. If you started from the Overview tab, you will return to the Overview tab. If you started from the Drift Results page, you will return to the Drift Results page.
Cancel
Aborts the operation. None of the input will be saved.
Configuration consistency reflects the changes of target members within a system or group. For example, you would use configuration consistency to ensure that all of the databases within a cluster database have the same configuration.
To perform a Consistency Management Comparison:
From the Enterprise menu, select Configuration, then select Comparison & Drift Management.
Locate the Consistency Management section of the Dashboard Overview page. Click Create Definition.
Note: You can create comparison definitions from several locations. You can create comparison definitions from:
Overview tab
Definition Library tab
Comparison Templates tab, after selecting a template
On the popup, select the Target Type and Template. For example, select Cluster Database and the template of choice. The template can be one that you have defined, or as in this case, Cluster Database Template. Then click OK.
On the Consistency Definition Details page, change the Definition Name as needed. The Compare Template and Applicable To information are replicated.
Click Advanced to provide information which is used for compliance.
Compliance Standard Name is the same name as used for the Consistency Definition Name. This is the name to search for when using compliance standards.
Rule Name is the same name as the compliance standard name.
Compliance Rule State is automatically considered Production.
Choose the severity of the drift. Options are: Minor Warning, Warning, and Critical. When a consistency is in a Critical state, it needs to be addressed in a timely manner. For example, if the space on a database is getting very low, it needs to be addressed before it crashes.
Target Property Filter
You can specify specific target properties that determine which targets this definition can work against when it is associated with a compliance standard. These properties are Operating System, Target Lifecycle State, Version, and Platform. When you specify a target property filter for this definition, for instance for Linux OS, it will only be applicable to targets on Linux Operating Systems.
Description
Describe this consistency definition and provide as much detail as possible. This information provides information for others who will be using this definition in the future.
Rationale
Explain the reason for this comparison, for example: This content will detect configuration consistency for the systems.
Keywords
Enables you to categorize this consistency definition for quick reference.
For consistency comparisons, Oracle chooses one target of each member target type as the reference target. All other members will be compared against the reference target of the same target type.
Note: Since all members of the same type should be the same, it should not matter which target is selected as the reference target. However, if you would prefer to choose specific targets as reference targets, click the Edit icon in the Reference Targets when associating targets, or click the Reference Targets button when creating a one-time comparison. This allows you to choose your own reference targets for each member target type.
After you have provided the information, select one of these options:
Save and Test Targets
Saves the comparison definition which compares the members against reference members within the system. You can then run test comparisons to verify that the comparison template only compares attributes of interest to you.
To review the results, click the number in the Differences column. The Comparison Results page appears.
Save and Associate Targets
Saves the input and directs you to the Target Association for Consistency Definition page. Click Add and select the systems you want to associate with this definition. Click OK.
Once the targets are associated with a comparison, comparisons are automatically triggered for the targets when appropriate. For example, when a target's configuration changes, a comparison will be triggered, and if the automatic comparison results in a difference from the reference target, notifications will be sent, and the differences will be seen in any reports for the consistency comparison.
Save and Return
Saves the input for future use. You will be returned to the Comparison Dashboard.
Cancel
Aborts the operation. None of the input will be saved.
The Definition Library is the repository for all the drift and consistency definitions created using the Comparison & Drift Management Dashboard.
To access the Definition Library, select Comparison & Drift Management from the Enterprise menu. On the Dashboard page, click the Definition Library.
From this page, you can:
Create a new definition
Edit an existing definition (as needed)
Run tests against a definition
Associate targets or groups to a definition (perform the association after you have verified test results from the Test Association page)
Delete a definition
To set up a comparison template:
From the Enterprise menu, select Configuration, then select Comparison & Drift Management.
On the left of the Dashboard page, click the Templates icon.
On the Comparison Templates page, click Create to create a new template or Create Like to create a template similar to one that already exists. Using the Create Like option enables you to use existing templates and make minor changes as needed.
Provide data for the Name and Target Type. When providing a name, make it obvious so folks can determine the reason for the template. For historical purposes, provide a description that explains the reasons and specifics of this template. When you provide the target type, configuration items for that target are automatically added to the template definition.
After you create (or create like) the template, edit the template to delete or modify configuration items.
When the Save Only Differences option is checked, only differences will be saved when this template is used in drift, consistency, and one time comparisons. If the box is not checked, then all information will be stored in the comparisons in which this template is a part.
Note: When creating a system template, for example, a cluster database, the template page provides more information when there is a target with members like a Cluster Database.
Compare Configurations: This option provides the same functionality as if you were on the Dashboard page and clicked Create Comparison for One-Time Comparison, Create Definition for Drift Management, or Create Definition for Consistency Management.
After you associate targets to the comparison definition, the comparison will rerun automatically whenever there is a change to the configuration for a target, when the system members change, or when the template changes.
If you choose Table for the Mapping Display, and do not override the default flat map when defining the comparison, the members of the systems will be matched for comparison without regard to their level in the system hierarchy. Thus, when viewing the results, the original system hierarchy cannot be retrieved.
Chose the Table option only if you are not concerned about how the members of the system are related to each other.
To be notified of a comparison change, you need to setup and enable notifications. There are two parts to setting up notification: setting up the mail servers and creating an incident rule.
Follow these steps to setup notifications:
From the Setup menu, select Notifications, then select Mail Servers.
On the Mail Servers page, provide the Server Identity information then add the outgoing mail (SMTP) server.
After you have set up the Mail Servers, set up the Incident Rules as follows:
From the Setup menu, select Incidents then select Incident Rules.
On the Incident Rules - All Enterprise Rules page, click Create Rule Set.
Provide a name and description and apply the rule set to Targets. This should apply to All Targets.
Create a rule as follows:
Select - Incoming events and updates to events.
Select - Specific events of type Compliance Standard Rule Violation.
Select either Compliance Standard or Compliance Standard Rule. If selecting a Compliance Standard, select a standard of type Drift or Consistency. If selecting a Compliance Standard rule, select a rule of type Drift or Consistency.
Add a rule - If you selected a compliance standard in the previous step, add a compliance standard of type Configuration Drift or Configuration Consistency. If you selected a compliance rule, select either a Configuration Drift Rule or a Configuration Consistency Rule.
Add Actions - Basic Notifications (E-mail to). Enter the e-mail addresses of those who are to be notified when the comparison detects a difference. Use a comma to separate addresses. Remember that the properties for which differences are alerted were specifically selected in the comparison template.
Click Next and specify rule name and description. Click Continue.
Click Save.
This section covers comparison results from the following perspectives:
Consistency results display when you click the Consistency Results tab on the Comparison & Drift Management Dashboard page. The view summarizes the results of all the consistency comparisons. Red signifies the number of inconsistent targets within the system, whereas green signifies the number of consistent targets within the system. To view the differences for a particular consistency definition, click the number of differences associated with the consistency definition. The Comparison Results page appears.
Select Only Differences in the Show drop-down list to eliminate the "noise" of the same results.
The icons that appear in the view are mostly intuitive: equal–same, not equal–different.
The table displays a hierarchy of system and member target types where:
The Target Type column displays the system and member tree hierarchy.
The Result column shows comparison results based on the mappings established as part of comparison setup. A boxed 1 (left only) or 2 (right only) means there was nothing to compare to the first or second member target, respectively. Note that if the parent target configurations are the same, but one or the other parent has child members marked as left only or right only, the parents are marked as different.
To resolve unmatched members, rerun the comparison, this time ensuring in the mapping step that the left and right member pairs appear in the mapped members table. Select an appropriate system comparison template with target matching rules defined, such that these members are mapped, or map the pairs manually.
When the Member column displays both an equal and a not equal icon, it indicates equality at the parent level, but a difference in some member.
To view a summary of all the differences found when comparing the system target and any member targets, click Export, located at the top of the table that displays the system members. An XLS report will be downloaded.
Drift results display when you click the Drift Results tab on the Comparison & Drift Management Dashboard page. The view summarizes the results of all the drift comparisons. Red signifies how many targets have drifted from the gold standard, whereas green signifies how many targets are similar to the gold standard. To view the differences for a particular drift definition, click the number of differences associated with the drift definition. The Comparison Results page appears.
Simple Target (Non-System Target) Results
When a simple target (non-system target) comparison is completed, the left pane displays a hierarchy of configuration items for the target being compared, and, if applicable, configuration extensions. Refine the scope comparison results as follows:
Select Only Differences in the Show drop-down list to eliminate the "noise" of the same results.
Select Left Only to display items that are only present on the target displayed on the left and NOT present on the target displayed on the right.
Select Right Only to display items that are only present on the target displayed on the right and NOT present on the target displayed on the left.
The icons that appear in the view are mostly intuitive: equal–same, not equal–different. The key icon denotes the key properties of the configuration item type. An indication of Out of Range means that the property value failed a value constraint set on the property. A boxed 1 (left only) or 2 (right only) means that the comparison did not find a matching item to compare to the first or second configuration, respectively.
System Drift Comparison Results
When a system drift comparison is completed, the system results page displays the system and its members along with its comparison results. Drill down from the system results to the simple target results to view additional configuration comparison result details.
Use this feature to perform on-demand file synchronization when a comparison of file-based configurations returns differences. Often, this involves configuration extensions that users create. See Overview of Configuration Extensions and Collections, for information on configuration extensions.
Note:
This feature is available only for file-based configuration extensions. Differences resulting from comparisons of command-based or SQL query-based configuration extensions cannot be synchronized.
On the Synchronize Files popup, click the link to track the synchronization job. When the job completes, you can rerun the comparison to verify the update, assuming you requested a refresh. You can also open the configuration extension in the Configuration Browser and confirm the update there.
You may notice in the comparison results differences view that some files, though different, cannot be selected for synchronization (their check boxes are disabled). There are several possible reasons, including:
The destination file is non-writable.
There is no source file.
Files that do not have differences.
During the configuration extension definition, the file was associated with a parser that does not support a process called reverse transform, which is, effectively, the ability to return the parsed form of a file to a syntax tree structure that can then be rendered back into a physical representation. Not all parsers support reverse transform.
Note: It is on the File Synchronization page where the files are marked as eligible or ineligible for synchronization. It is on this page where you can determine whether the selections are valid.
Business Intelligence Publisher (BI Publisher) is the primary reporting system that provides a single, Web-based platform for authoring, managing, and delivering interactive reports and all types of highly formatted documents.
Using BI Publishes, Enterprise Manager provides the following Comparison and Drift Management reports:
Drift Report for Systems - Drift results report for system targets. It includes Drift definition summary, various roll-ups and Drift Comparison results. Examples of system targets are databases and fusion applications.
Drift Report - Drift results report. It includes Drift definition summary, various roll-ups and Drift Comparison results. Use this report to view simple targets, for example, host.
Patch Differences for Fusion Instances (Scheduled)
Note: This is a Bursting/Scheduler only report. Preconditions include:
Comparison template for Fusion Instance and its corresponding Oracle Home target type is available.
Oracle Home comparison template contains the 'Patches Installed In Oracle Home' configuration item, and has the 'Patches ID' and 'Patch Language' properties enabled.
Comparison was performed using the proper template.
Patch Differences for Fusion Instances
Preconditions include:
Comparison template for Fusion Instance and its corresponding Oracle Home target type is available.
Oracle Home comparison template contains the 'Patches Installed In Oracle Home' configuration item, and has the 'Patches ID' and 'Patch Language' configuration properties enabled.
Drift definition was created using the proper Fusion Instance template.
To access the Comparison and Drift Management BI Publisher reports:
From the Enterprise menu, select Reports, then select BI Publisher Enterprise Reports.
In the list of Enterprise Manager Reports, select Comparison and Drift Management.
In the login screen, provide your credentials to access the reports.
NOTE:
To see information in these reports, you must have had to run a comparison
Only differences are reported
Information is grouped by compared targets
Configuration extensions provide a way to identify files and other configuration data that Cloud Control does not already collect. These customized configurations can be collected on well-known target types or on a target type introduced as part of the configuration extension definition. A set of configuration extensions called blueprints is available for download from Oracle. They are called blueprints because they lay out precisely the files and data to collect for a given platform such as Apache Tomcat.
A typical life cycle of a configuration extension might be as follows:
Create a configuration extension and deploy it to several targets.
Assess its effectiveness over time.
Modify and fine-tune the specification and redeploy, perhaps across a wider spectrum.
Undeploy and delete the specification if no longer pertinent.
This section covers the following topics:
This section describes how to create, edit, and otherwise manage configuration extensions. If you want to create a configuration extension that uses a custom target type, the suggested workflow is to first create the custom target type. Concurrent with that activity, you can also add a complementary new target to serve as a sample target instance.
If no existing target type satisfies your configuration extension requirements, you can create a custom target type.
Before creating a new target type, ensure that the administrator has installed the Software Library (from the Setup menu, select Provisioning and Patching, then select Software Library). This must be done once, after Cloud Control installation.
It's not imperative that you add a new target instance during custom target type creation.You can do so subsequently by selecting Add New Custom Target from the Actions menu and following Steps 4 and 5 in the process above, this time selecting a custom target type from the drop-down list.
Use the following instructions to create, create like, or edit a configuration extension.
Given appropriate privileges, you can edit a configuration extension and save the edited version, in which case, the version number increases. You might also edit and save as a draft, or edit a draft for publishing. Note that when you edit a configuration extension, you cannot change the target type, as this would cause the underlying metadata to be incompatible with existing deployments of the configuration extension, see About Configuration Extensions and Privileges.
Note:
When you edit a deployed configuration extension, it is automatically redeployed upon saving. This does not apply to saving as draft.
When done, you can begin collecting configuration data by deploying the configuration extension to target instances, see About Configuration Extensions and Deployment.
Return to Creating or Editing a Configuration Extension and resume with 7.
Create SQL query specifications as follows:
Return to Creating or Editing a Configuration Extension and resume with Step 7.
If you create a credential set while creating a configuration extension, you have to specify the credentials that make up the credential set. To do this, you have to return to the Configuration Extensions library and proceed as follows:
Use rules to differentiate nodes in the parsed representation that have the same name. This is particularly important in comparisons and change history when trying to match nodes in the parsed tree, or when expressing SQL queries to verify compliance. Rules resolve to an identifier that is appended in square brackets to node text in the tree as a way of uniquely identifying the node. An operation such as a comparison will then use the combination of node text and bracketed identifier for evaluation purposes.
A rule consists of a condition and an expression, both of which must be valid XPath expressions. The condition resolves to a node that requires the identifier. The expression resolves to a string computation for the identifier. You can use a special case SKIP
expression to bypass the node specified in the condition; this is a convenient way to eliminate "noise." In other words, for purposes of comparison, ignore the node the condition resolves to.
Some parsers have default parser rules already defined. They execute automatically on the parsed representation. You can elect to use a subset of default rules, edit them, or override them with custom rules that you define.
The number in the Rules column is significant. Initially, the number is zero (0). A whole number greater than zero indicates the number of custom rules defined. Zero also appears for a parser that has default parser rules. So the appearance of a whole number in the column stipulates an override of default parser rules, if any, with the custom rules the number represents.
Set up rules as follows:
For examples of rules, see Using Parsed Files and Rules.
Return to the Files & Commands tab (Using the Files & Commands Tab) or SQL tab (Using the SQL Tab) description.
In addition to creating and editing configuration extensions, you manage them by doing the following:
View the selected specification (read-only)
Synchronize the selected specification with facets in the Compliance Library for real-time facet monitoring
Share configuration extensions by exporting them in XML file format and importing them from the local file system
Delete the selected specification (requires the proper permissions)
Viewing a Configuration Extension
You can view a configuration extension in read-only mode to get an idea of the make-up of a specification. Perhaps, for example, to see if it is a likely candidate on which to base a new specification.
In the Configuration Extensions library, select the specification table row and click View Details.
Peruse the settings and rules on the various tabs.
Enabling Facet Synchronization
You can synchronize a configuration extension specification with real-time monitoring facets to monitor real-time changes to the configuration files and queries that make up the configuration extension. Real-time monitoring enables you to know such things as when files and database settings change, who made the change, whether observations were automatically reconciled, whether the actions observed were authorized, and so forth.
When you synchronize configuration extensions with real-time monitoring facets, future changes to configuration extensions automatically propagate to corresponding facets, which means configurations are not only collected, compared, tracked, and so forth, but also are monitored for authorized real-time changes. Note that to associate a configuration extension with a facet and to subsequently edit a configuration extension synchronized with a facet requires the additional role of EM_COMPLIANCE_DESIGNER.
In the Configuration Extensions library, select the specification table row, then select Enable Facet Synchronization from the Actions menu.
The Facet Synchronization column displays a Use Facet link in the configuration extension table row. Click the link to go to the Real-time Monitoring Facets tab in the Compliance Library where you can manage the synchronization of facets with the configuration extension.
Exporting a Configuration Extension
You can export a configuration extension as an XML file that can subsequently be imported into the same or another system.
In the Configuration Extensions library, select the specification table row, then select Export from the Actions menu.
Browse to a file system location where you want to save the specification as an XML file. The saved file takes the name of the configuration extension by default.
Importing a Configuration Extension
Given appropriate privileges, you can import a configuration extension that was previously exported as an XML file.
In the Configuration Extensions library, select the specification table row, then select Import from the Actions menu.
Browse to the file location. Select the file and click the Import button on the dialog.
The imported specification appears in the Configuration Extensions library.
Deleting a Configuration Extension
You must be the owner or otherwise have sufficient privileges to delete a configuration extension. Note that there are dependencies that potentially impact deletion, including deployments, job schedules, existing collections, and so forth.
When you create a configuration extension, you have options to save or save as draft. A normal save action makes the specification publicly available to the general user community. A save as draft action keeps the specification private to you. How you use these actions when creating and editing specifications influences the mechanics of versioning. Consider the following scenarios:
You create and save a configuration extension; this is public version 1. You subsequently edit public1 and save as a draft; this becomes draft1. Public1 is still generally available. You edit draft1 and publish; this becomes public2. Note that in parallel, someone else with the proper permissions can also edit public1 and save as a draft to create version 1 of draft2.
You create and save a configuration extension as a draft; this is version1 of draft1. You edit and save again; this becomes version 2 of draft1. Repeat the edit-and-save operation; this becomes version 3 of draft1. Edit version 3 of draft1 and publish; this becomes public version 1.
Working with configuration extensions requires privileges specific to the given operation you want to perform.
Operation | Required Privilege (Role) |
---|---|
Create new target type |
To create a new target type, ensure that the administrator has installed a software library (from the Setup menu, select Provisioning and Patching, then select Software Library). This must be done once, after Cloud Control installation. |
Create new target instance |
|
Create or import configuration extension |
"Manage configuration extensions owned by user" (or the more powerful "Manage configuration extensions owned by any user") |
Associate configuration extension with an auto-synchronized real-time monitoring facet |
|
Edit or delete configuration extension |
Differs, depending on the specific activity within the realm of editing:
|
Deploy or undeploy configuration extension on a target |
"Manage target metrics" privilege on the target instance; "Create" privilege for Job System resource type (to schedule deployment/undeployment;) EM_PLUGIN_AGENT_ADMIN (to deploy a plug-in to a Management Agent) |
Create a new credential set |
Superuser |
View configuration extension definition |
None |
View configuration extension collected data |
Regular "target instance view" privilege |
Note that editing an imported configuration extension may be restricted to edits that do not change the version, depending on options set during export. One such permissible edit would be to credential set information.
Deployment of a configuration extension means to direct the specification to a target where a monitoring Management Agent will collect configuration data based on the specification's definition. A configuration extension can be deployed to multiple targets. You must have sufficient privileges to deploy and undeploy configuration extensions.
Manage deployments by performing the following actions:
Deployment of a configuration extension means to direct the specification to a target where a monitoring Management Agent will collect configuration data based on the specification's definition. A configuration extension can be deployed to multiple targets. You must have sufficient privileges to deploy and undeploy configuration extensions.
To deploy a configuration extension:
In the Configuration Extensions library, select the specification table row and click Manage Deployments.
On the Deployments page, click Add. In the dialog that opens, search for and select targets of the specified target type where you want to deploy the configuration extension.
When you close the dialog (click Select), a new column appears denoting a pending action of Deploy and the status becomes Selected for Deployment.
Proceed as follows:
Click Apply to confirm the action while remaining on the Deployments page. The action column disappears, and the status becomes Deployment job in progress.
Click OK to schedule the deployment and return to the library.
Click Cancel to void the request and return to the library.
Click Refresh Status on the Deployments page to confirm a successful outcome.
Usually, if you update a deployed configuration extension (CE), redeployment occurs automatically. However, redeployment will not be initiated when certain CE attributes are modified, such as the sample target.
To undeploy a configuration extension:
When viewing configuration extensions in the library, a green check mark in the Deployments column denotes currently deployed configuration extensions. The number in the column indicates how many targets the configuration extension has been deployed to. Click the number to navigate to the relevant deployments page.
There are two options available to extend configuration data collections using a configuration extension specification:
Add additional collection items to an existing target type
Add a custom target type with new collection items
The following instructions describe how to extend the configuration data Cloud Control collects for an existing target type. The listener target type, for example, does not collect the sqlnet.ora
file as provided by Oracle. To extend the listener data collection to include this item, take the following steps:
Use this description as a template for extending existing configuration data collections.
The following instructions describe how to extend the configuration data Cloud Control collects by adding a new target type. The example assumes to collect data for a custom Apache web server target type.
First, create a custom target type.
Use this description as a template for extending configuration data collections through custom target types.
Specially formed configuration extensions called blueprints are available for download from Oracle. They are called blueprints because they lay out precisely the files and data to collect for a given platform. Platform support currently includes:
Apache Tomcat
Apache Web Server
GlassFish
iPlanet
JBoss
JRun
Tuxedo
You can download these blueprints, also called configuration extensions, from the Configuration Management Best Practice Center, where you can also check for new platform support.
A Parser takes raw configuration data and parses it into a nested attribute structure. This structure is a tree hierarchy where nodes are containers and leaves are name value pairs of attributes, or properties.
Configuration extensions include a host of parsers provided by Oracle. Each parser consists of a base parser and parser parameters. Some parsers also contain post-parsing rules. A base parser essentially is a category of parser capable of parsing data of a particular format. Parser parameters provide a way to tailor the base format to accommodate variations in data formatting. Post-parsing rules are a mechanism for aligning nodes in the tree that otherwise have no distinct identity. This is important when comparing configurations and tracking change history to avoid flagging "false positive" differences. It also aids in specifying search criteria and crafting SQL queries used in compliance rules.
There are four varieties of base parser:
XML
Format-specific
Columnar
Properties
Some parsers have default rules provided by Oracle. These rules address well-known instances where nodes need to be aligned. Specifically, the WebLogic and WebSphere parsers contain default rules to address such instances. You can leave these rules as is, execute a subset of them, or replace them with your own custom rules.
This section covers the following topics:
While creating, editing, or viewing configuration extensions, you can peruse the list of available parers, their default parameters, and post-parser rules, if applicable. Parser parameters dictate formatting such as comment character, delimiters, start and end characters, and so forth. You cannot edit these parameters, but you can export a parser as an XML file, edit the file, and import it back into the application under a new name. Some parsers also have default rules that serve to align nodes in the parsed tree for purposes of comparison, for example.
In the Configuration Extensions library, select Manage Parsers from the Actions menu. A list of available parsers appears in a table. The column on the right (Base Parsers) denotes a general parser category, Properties for example, which implies file types that contain name/value pairs.
Select a parser and click Details. This dialog also shows default rules, if any.
Click the Parameters tab to see the parameter defaults in effect. You can then judge if you need to edit the parser to conform with your file format conventions.
Click the Default Rules tab to see the post-parsing rules that ship with certain parsers. This is a good way to get exposure to rules formation.
Assume you want to change the delimiter character in a given parser.
With the parser selected in the table, click Export.
In the dialog that opens click Save and navigate to a file system location. Save the XML file with an appropriate name.
In making your edits, be sure to change the parser ID and parser name in the XML, as you are creating a customized version of a parser provided by Oracle.
Assume you now want to import the new parser you saved for use in creating configuration extensions.
With the Parsers table open, click Import.
In the dialog that opens, browse to the file location where you saved the exported parser file. Select it and click Import on the dialog.
The new parser now appears in the Parsers table where it can be used in configuration extension creation.
Cloud Control has two XML parsers: a default (attribute-keyed) XML parser and a generic XML parser.
XML elements with no XML attributes or child elements become parsed attributes; all other elements become containers.
XML attributes become parsed attributes.
Element text content becomes a parsed attribute, with its name dependent on whether or not the tag contains any XML attributes. If the tag contains XML attributes, the parsed attribute name takes the value specified in the STORE_CONTENT_AS
parameter; otherwise, the parsed attribute name takes the tag name.
The default XML parser accepts the following parameters:
Parameter | Description |
---|---|
|
Delimiter that separates a list of XML attribute names in the |
|
Name to give to parsed attributes derived from element text content, where the element contains XML attributes; default is |
|
A list of XML attribute names delimited by the value of the For example, the list includes attribute names Moe and Larry in this order. The original file contains an XML tag Stooges that has attributes Moe, Larry, and Curly. As Moe appears first in the delimited list, its value, leader, becomes the parsed container name; Larry and Curly become parsed attributes. The tag name Stooges is discarded. The original XML fragment might be as follows: <?xml version="1.0" encoding="UTF-8"?> <Comedy> <Stooges Moe="leader", Larry="zany", Curly="bald"> </Stooges> </Comedy> |
WebLogic Attribute-keyed Parser
Cloud Control provides an attribute-keyed parser provided by Oracle specifically designed to parse the WebLogic config.xml
file. It has the same parameters as the default XML parser and comes with 26 default post-parsing rules to uniquely identify nodes with the same name.
WebSphere Attribute-keyed Parsers
Cloud Control provides several attribute-keyed parsers provided by Oracle designed to parse specific WebSphere configuration files. Each parser has the same parameters as the default XML parser and comes with a set of default post-parsing rules to uniquely identify nodes with the same name. There are parsers for the following WebSphere configuration files:
node.xml
(1 default post-parsing rule)
plugin-cfg.xml
(7 default post-parsing rules)
resource.xml
(9 default post-parsing rules)
server.xml
(13 default post-parsing rules)
variables.xml
(1 default post-parsing rule)
All XML elements become containers.
All XML attributes become parsed attributes.
Element text content becomes a parsed attribute that takes the name text_value
, where the text content becomes the parsed attribute value.
The generic XML parser accepts no parameters.
This section contains three XML parser examples:
As parsed using the default XML parser, with parameter values provided by Oracle
As parsed using the default XML parser, with modified parameter values
As parsed using the generic XML parser
Parsed examples derive from the following original XML file:
<?xml version="1.0" encoding="UTF-8"?> <Application> <AppName>foo</AppName> <Server name="ajax" os="linux">production</Server> </Application>
Default XML Parser (Parameter Values Provided by Oracle)
When parsed using the default XML parser with parameter values provided by Oracle, the parsed version appears as follows:
Application AppName = foo Server name = ajax os = linux text_value = production
Note the following about this parsed version:
The element contents of the AppName and Server tags become parsed attributes.
Since the AppName tag contains no XML attributes, the parsed attribute name takes the tag name.
Contrast with the Server tag, which has XML attributes (name and os). This results in a container named for the tag (Server), with three parsed attributes, one for each of the XML attributes, and a third for the text content of the Server tag, which is set to the value of the STORE_CONTENT_AS
parameter (text_value
).
Default XML Parser (Modified Parameter Values)
To modify parameter values, you have to create a new parser by exporting the default XML parser, modifying the exported XML file, and importing the modified parser, using a new name and parser ID.
Assume you followed this process, making the following modifications:
Set the STORE_CONTENT_AS
parameter to the value myVal
Set the CONTAINER_NAME
parameter to the value name
When parsed using the default XML parser with modified parameter values, the parsed version appears as follows:
Application AppName = foo ajax os = linux myVal = production
Note the following about this parsed version:
The AppName tag remains the same; that is, it has no XML attributes so it becomes a parsed attribute.
Since the Server tag has an XML attribute that matches the value of CONTAINER_NAME
, the container takes the value of the attribute (ajax), obviating the name=ajax parsed attribute. Remember that the CONTAINER_NAME
parameter provided by Oracle has a placeholder but no actual default value; thus, the difference in this version of the parsed representation.
The remaining Server tag attribute (os) becomes a parsed attribute as usual, and the text content associated with the tag becomes the value of the attribute myVal, per the edited STORE_CONTENT_AS
parameter.
Generic XML Parser
When parsed using the generic XML parser (the one that takes no parameters), the parsed version appears as follows:
Application AppName text_value = foo Server name = ajax os = linux text_value = production
See About the Default XML Parser for a reminder of how parsing occurs.
Format-specific base parsers are applicable only to a particular data format. Format-specific parsers run the gamut from having no parameters to a few to many with which to tailor formatting.
Parser | Description |
---|---|
Parser for Blue Martini DNA files (no parameters). |
|
Parser for Connect:Direct |
|
Database Query (see Sample SQL Query Parsing and Rule Application for an example) |
Parser for configuration extension database query output. Cloud Control automatically transforms query results into a format the parser accepts, organizing results into sections similar to a Windows |
Parser for configuration extension database query output. Cloud Control automatically transforms query results into a format the parser accepts, organizing results into sections similar to a Windows .ini file. Each section represents one record; each line in a section contains a name and value, where both the name and the value are values of returned columns. As such, the parser requires an even number of columns to be returned by the query in order to parse the data. A query which returns an odd number of columns will result in a parsing error. See Database Query Paired Column Parser Parameters. |
|
Parser for the output of the DB2 |
|
Parser for files containing multiple name value pairs on the same line, where each line may have varying numbers of pairs. For example, the first line might be a=b j=k, the second line c=d m=n y=z, and so forth. See Directory Parser Parameters. |
|
Parser for E-Business Suite |
|
Parser for Galaxy |
|
Parser for Introscope files (no parameters). |
|
Parser for MQ-Series files. See MQ-Series Parser Parameters. |
|
Parser for Odin files (no parameters). |
|
Parser for Oracle |
|
Parser for Siebel |
|
Parser for BEA Tuxedo files (no parameters). The parser converts sections prefixed with an asterisk (*), and names in double quotes at the start of a new line, into containers. It converts all other data into attributes. |
|
Parser for Unix installed patches data. The parser creates one container per (non-comment) line of the file. It treats every field ending with a colon (:) on each line as a property name field and the value following, if any, as the property value. Note that a property does not have to have a value. See Unix Installed Patches Parser Parameters. |
|
Parser for output of Unix recursive directory listing ( |
Remember, to modify a format-specific parser, you have to create a new parser by exporting the particular parser, modifying the exported XML file, and importing the modified parser, using a new name and parser ID.
The following table describes the parameters with which you can customize the Database Query parser:
Parameter | Description |
---|---|
|
Character that separates name value pairs; default is =. |
|
Character that separates the length of a name or value from the value itself; default is _. |
|
Character that tells the parser to ignore the line that follows; default is #. |
|
Character that denotes the start of a section; default is \[ (backslash is escape character). |
|
Character that denotes the end of a section; default is \] (backslash is escape character). |
|
Flag that tells the parser to use Windows |
The following table describes the parameters with which you can customize the Database Query parser:
Parameter | Description |
---|---|
|
Character that separates name value pairs; default is =. |
|
Character that separates the length of a name or value from the value itself; default is _. |
|
Character that tells the parser to ignore the line that follows; default is #. |
|
Character that denotes the start of a section; default is \[ (backslash is escape character). |
|
Character that denotes the end of a section; default is \] (backslash is escape character). |
|
Flag that tells the parser to use Windows |
The following table describes the parameters with which you can customize the Directory parser:
Parameter | Description |
---|---|
|
Character that separates one property from another; default is a space. |
|
Character that separates a property name from its value; default is =. |
|
Character that tells the parser to ignore the line that follows; default is #. |
The following table describes the parameters with which you can customize the E-Business Suite parser:
Parameter | Description |
---|---|
|
A tilde-delimited list of attribute names for directory specifications. |
|
A tilde-delimited list of regular expressions denoting the start of a structure. |
|
A tilde-delimited list of regular expressions denoting name value pair delimiters. |
|
A tilde-delimited list of attribute names for file specifications. |
|
A tilde-delimited list of regular expressions denoting comments. |
|
A tilde-delimited list of regular expressions denoting the end of a structure. |
|
Flag that tells the parser to ignore cell delimiters in the last value of a directory or file specification; default is true. |
|
A tilde-delimited list of file specification attribute names. The parser concatenates values of the specified attributes to form the name of the container associated with the file specification. |
|
A tilde-delimited list of directory specification attribute names the parser uses to determine the name of the container associated with the directory specification. |
The following table describes the parameters with which you can customize the Galaxy CFG parser:
Parameter | Description |
---|---|
|
Character that tells the parser to ignore the line that follows; default is !. |
|
Names of attributes whose values to append to a container name. |
|
Names of sections that have a single property. |
|
Names of sections that have multiple properties. |
|
Names of section start and end elements |
The following table describes the parameters with which you can customize the Siebel parser:
Parameter | Description |
---|---|
|
Tells the parser the number of lines to ignore at the beginning of the file; default is 4. |
|
A tilde-delimited list of regular expressions denoting name value pair delimiters. |
|
A tilde -delimited list of regular expressions denoting comments. |
|
A tilde-delimited list of regular expressions denoting the start of a unique path specification section. |
|
A tilde-delimited list of regular expressions denoting the end of a unique path specification section. |
|
Flag that tells the parser to use Windows |
The following table describes the parameters with which you can customize the Unix Installed Patches parser:
Parameter | Description |
---|---|
|
Character that separates name value pairs; default is a space. |
|
Character that separates a property name from its value; default is :. |
|
Character that tells the parser to ignore the line that follows; default is #. |
The following table describes the parameters with which you can customize the Unix Recursive Directory List parser:
Parameter | Description |
---|---|
|
Tells the parser the number of lines to ignore at the beginning of the file; default is 4. |
|
A tilde-delimited list of regular expressions denoting name value pair delimiters. |
|
A tilde-delimited list of regular expressions denoting comments. |
|
A tilde-delimited list of attribute names. |
|
Flag that tells the parser to ignore cell delimiters in the last value of a line; default is true. |
|
A tilde-delimited list of regular expressions denoting the start of a subdirectory section. |
|
A tilde-delimited list of regular expressions denoting the end of a subdirectory section. |
|
A tilde-delimited list of attribute names. The parser concatenates values of the specified attributes to form the name of the container associated with the line. |
Columnar parsers are inherently flexible owing to the parameters they can accept to tailor formatting. All columnar parsers use a subset of the same parameters.
Parser | Description |
---|---|
Parser for |
|
Parser for Unix |
|
Parser for comma-separated-value (CSV) data. Because the number of columns in the CSV parser is unknown, use the CSV parser provided by Oracle as a template for the new CSV parser. Export the provided CSV parser, update the parameters, and re-import the new CSV parser tailored to your format. The parameter values provided by Oracle support CSV files with these characteristics:
Text inside double quotes is considered part of a value; to specify a value that contains a double quote, escape the double quote with a backslash (\). Use a backslash to escape the backslash character itself (\\). |
|
Parser for |
|
Parser for |
|
Parser for Linux directory listing data format (for example, output of a |
|
Parser for |
|
PAM Directory |
Parser for Unix |
Parser for |
|
Parser for Unix |
|
Parser for Solaris installed packages files. |
|
Parser for Unix crontab files. |
|
Parser for Unix directory listing data format for example, the output of a |
|
Parser for Unix |
|
Parser for Unix |
|
Parser for Unix |
|
Parser for Unix |
|
Parser for Unix |
|
Parser for Unix |
|
Parser for Unix |
|
Parser for Unix |
|
Parser for Unix system crontab files. System crontab files are very similar to crontab files, but may contain name value pairs such as |
This section describes all columnar base parser parameters. Although the base parser can accept values for any of these parameters, a given parser specification does not necessarily need to provide values for all of them. All parameters have default values, which are used in the absence of a specified value, although in some cases, parameters have explicit values.
Use quotes when delimiters or other special text such as comment characters or new lines are part of some value. The QUOTE_DELIMITER
determines the character value to use. Prefix the quote delimiter with a backslash (\) if you need to escape the character. Use a backslash to escape the backslash character itself (\\) in quoted strings.
Parameter | Description |
---|---|
|
A tilde-delimited list of regular expressions that denote comment characters or sequences. For example, |
|
The number of initial lines (excluding blank or comment lines) to ignore for parsing purposes, treating them in effect as comments. Default is 0; that is, skip no lines. |
|
A tilde-delimited list of regular expressions that delimit line values. Default is an empty list; that is, no delimiters (it is unusual to use the default). |
|
A tilde-delimited list of regular expressions that define how quoted values begin and end (usually either a single or double quote character). The beginning and end quote delimiter must be the same. Default is an empty list; that is, parser does not recognize quoted values. |
|
A tilde-delimited list of regular expressions that delimit property names and values. Default is an empty list; that is, no property delimiters. Rarely, a columnar file may contain name value pairs of the syntax a=b. |
|
A tilde-delimited list of property keywords. Some crontab files contain lines of simple name value pairs, separated by a delimiter (foo=bar), thus violating the requirement that each line have the same number of fields. This parameter provides a workaround to specify property keywords. In the example, the property keyword would be foo. This says, in effect, parse any line beginning with this keyword as a parsed attribute name value pair under the root container. Default is an empty list; that is, no property keywords. |
|
An alternate delimiter for property names and values. Default is '/' (used only if |
|
A tilde-delimited list of fields separated by alternate delimiters. Default is an empty list; that is, no alternate delimiters. |
|
A flag specifying whether or not the file has a header line that specifies the column names. Default is false. |
|
A tilde-delimited list of column names to use if there is no header line. Default is an empty list; that is, no column names (it is unusual to use the default). |
|
A tilde-delimited list of column names whose values the parser concatenates to create the container name associated with a line. Default is an empty list; that is, no column names (it is unusual to use the default). |
|
A tilde-delimited list of column names to ignore. No parsing of values in these columns occurs. Default is an empty list; that is, ignore nothing. |
|
A flag that specifies whether the last column is free form. The parser ignores all delimiters in a free form column value. Default is false. |
|
A flag that specifies whether to treat end of line comments as a value to appear in the parsed representation of the data. Default is false. |
Properties parsers are inherently flexible owing to the parameters they can accept to tailor formatting and handle disparate organizational elements. All properties parsers use the same set of basic and advanced parameters, as well as advanced constructs.
Parser | Description |
---|---|
Parser for AIX installed packages files. |
|
Parser for Apache |
|
Parser for |
|
Parser for custom |
|
Parser for |
|
Parser for |
|
Parser for LDAP |
|
Parser for |
|
Parser for Radia |
|
Parser for files containing name value pairs organized into sections, such as a Windows |
|
Parser for SiteMinder agent files. |
|
Parser for SiteMinder |
|
Parser for SiteMinder |
|
Parser for SiteMinder |
|
Parser for Sun ONE |
|
Parser for Sun ONE |
|
Parser for Tuxedo files. |
|
Parser for Unix |
|
Parser for Unix |
|
Parser for Unix |
|
Parser for Unix |
|
Parser for Unix |
|
Parser for Unix |
|
Parser for Unix |
|
Parser for Unix |
|
Parser for WebAgent files. |
|
Parser for Windows checksum output generated with |
This section describes basic properties parser parameters that are required to parse simple property data formats. Simple property data formats specify a property as a name value pair, usually with a defined delimiter separating the name and the value: foo=bar. The basic data format is a list of properties, one property to a line, together with optional comments; a java.properties
file, for example. All parameters have default values, which are used in the absence of a specified value.
Use quotes when delimiters or other special text such as comment characters or new lines are part of some value. The QUOTE_DELIMITER
determines the character value to use. Prefix the quote delimiter with a backslash (\) if you need to escape the character. Use a backslash to escape the backslash character itself (\\) in quoted strings.
A comment character such as the pound sign (#), or a particular character sequence (//) usually denotes a comment. Special sequences such as a C style comment (/*….*/) might denote the beginning and end of a comment. Some files might have generic informational content in the first couple of lines. In this case, a parameter is available to tell the parser to ignore these lines.
Parameter | Description |
---|---|
|
A tilde-delimited list of regular expressions that denote comment characters or sequences. For example, |
|
The number of initial lines (excluding blank or comment lines) to ignore for parsing purposes, treating them in effect as comments. Default is 0; that is, skip no lines. |
|
A tilde-delimited list of regular expressions that delimit line values. Default is an empty list; that is, no delimiters (it is unusual to use the default). |
|
A tilde-delimited list of regular expressions that define how quoted values begin and end (usually either a single or double quote character). The beginning and end quote delimiter must be the same. Default is an empty list; that is, parser does not recognize quoted values. |
|
A flag that indicates whether the parser allows property names without a delimiter or a value. Default: false. |
|
A flag that indicates whether the parser allows the value to come before the delimiter and property name. Default: false. |
This section describes advanced properties parser parameters that are required to parse more complex property data formats. All parameters have default values, which are used in the absence of a specified value.
Parameter | Description |
---|---|
|
A tilde-delimited list of regular expressions denoting property delimiters. For example, the text "a=b : x=y" could be interpreted in either of two ways:
If a colon (:) is the property delimiter, the parsing engine interprets the text as containing two separate properties. Default is an empty list; that is, parser does not recognize property delimiters. |
|
A tilde-delimited list of regular expressions denoting line end sequences. When the parser encounters a line end delimiter, it assumes a new property or construct starts on the next line. Default is an empty list; that is, parser does not recognize line end delimiters. |
|
A tilde-delimited list of regular expressions denoting continue line sequences. When the parser encounters a continue line pattern, it interprets data on the following line as a continuation of the construct or property on the previous line, as opposed to interpreting the new line as the beginning of a new property or construct. For example, the parser must encounter a line continuation pattern to recognize property values that span multiple lines. Default is an empty list; that is, parser does not recognize line continuation patterns. |
|
A tilde-delimited list of regular expressions denoting the beginning of a section. Sections cannot be nested. Default is an empty list; that is, parser does not recognize sections. |
|
A tilde-delimited list of regular expressions denoting the end of a section. Default is an empty list. |
|
A tilde-delimited list of regular expressions denoting the beginning of a structure. Structures can be nested. Default is an empty list; that is, parser does not recognize structures. |
|
A tilde-delimited list of regular expressions denoting the end of a structure. Default is an empty list. |
|
A flag that indicates whether structures in the file are XML style tags. Default: false. |
|
A flag that indicates whether INI style sections are present. Default: false. |
|
A tilde-delimited list of reserved names indicating the start of a reserved directive. Default is an empty list; that is, parser does not recognize reserved directives. |
|
A tilde-delimited list of reserved names indicating the start of a reserved function. Default is an empty list; that is, parser does not recognize reserved functions. |
|
A tilde-delimited list of reserved directive- implicit property names. Default is an empty list. |
|
A tilde-delimited list of required reserved function-explicit property names. Default is an empty list. |
|
A tilde-delimited list of section-implicit property names. Default is an empty list. |
|
A tilde-delimited list of structure-implicit property names. Default is an empty list. |
|
A keyword to be ignored by the parser when parsing properties. This typically applies to data formats that specify a keyword before a name value pair; "set a=b" for example. Default is an empty list; that is, parser ignores nothing. |
|
A flag that indicates whether the file format supports element cell structures. Default: false. |
|
A flag that indicates whether sections support explicit properties. Default: false. |
|
A flag that indicates whether structures support explicit properties. Default: false. |
|
A flag that indicates whether newlines can be line continuation sequences. Default: false. |
|
A tilde-delimited list of regular expressions denoting keywords that precede properties that use a whitespace delimiter. Default is an empty list; that is, parser does not recognize keywords. |
Properties files come in variety of file formats. To accommodate the widest possible range of formats, the generic properties base parser uses combinations of constructs found in most files.
The constructs fall into two categories:
Container constructs, which can be reserved functions, reserved directives, XML structures, structures, delimited structures, INI sections, delimited sections, sections, and element cells
Property constructs, which can be simple properties, reverse properties, keyword properties, keyword name properties, bracket properties, implicit properties and explicit properties
Of the element constructs, section constructs cannot be nested, but can contain any other construct. Structure constructs can be nested, and can contain any construct except a section. Element cells can be nested, but can only contain element cells and simple properties. Reserved directives and reserved functions cannot be nested, nor can they contain any other constructs.
The rest of this section describes the constructs the base properties parser supports.
Simple Property
A simple property consists of a property name, cell delimiter, property value, and newline sequence, in that order. A simple property may take up more than one line, although properties that span multiple lines usually contain a line continuation character or sequence. The parser ignores whitespace such as tabs and spaces, unless a parameter specifies whitespace as having some significance (cell delimiter, for example).
Example: name=value_that_wraps_to_next_line_/
, where the forward slash serves as a line continuation character. A Java Properties file typifies this data format.
Keyword Property
This construct is the same as a simple property, only with a keyword in front, which the parser ignores.
Example: set name=value
, where set
is the ignored keyword. A Unix System file typifies this data format.
Keyword Name Property
This construct is a simple property where the property name matches a regular expression specified in the KEYWORD_FIELD
parser parameter. This is a special case property type specific to the Unix XINETD parser. The XINETD file uses an equal sign (=) as a cell delimiter except when the property begins with the keyword "include" or "includedir", in which case the cell delimiter is whitespace.
While added specifically for XINETD files, the property can be used for other file types where appropriate.
Example: includedir /etc
, where includedir
is the parser parameter regular expression and whitespace is the cell delimiter.
Explicit Property
An explicit property consists of a property name, a delimiter, and a property value. Unlike a simple or keyword property, an explicit property is bound to a container construct such as a section or a structure; an XML tag attribute, for example.
Examples:
[SectionName p1=v1 p2=v2] <StructureName p1=v1 p2=v2> ... </StructureName>
In these constructs, the name value pairs p1 v1 and p2 v2 are explicit properties. A Sun ONE Obj file typifies this data format.
Implicit Property
An implicit property is a property value without an associated property name. Like an explicit property, an implicit property is bound to a container construct, usually a reserved directive. The DIRECTIVE_PROPERTIES
parser parameter contains the property names of implicit properties.
Examples:
[SectionName myName myPath]
<StructureName myName myPath> ... </StructureName>
In these constructs, the implicit properties have the values myName
and myPath
, with the presumed property names name
and path
, as declared in the DIRECTIVE_PROPERTIES
parser parameter. An Apache HTTPD file typifies this data format.
Reserved Function
A reserved function is a keyword followed by one or more explicit properties. The RESERVED_FUNCTIONS
parser parameter specifies keywords that denote reserved functions.
Example: Error fn="query-handler" type="forbidden"
, where Error
is the reserved function keyword specified in the RESERVED_FUNCTIONS
parser parameter. A Sun ONE Magnus file typifies this data format.
Reserved Directive
A reserved directive is a keyword followed by one or more implicit properties. The RESERVED_DIRECTIVES
parser parameter specifies keywords that denote reserved directives.
Example: LoadModule cgi_module "/bin/modules/std/cgi"
, where LoadModule
is the reserved function keyword specified in the RESERVED_DIRECTIVES
parser parameter. An Apache HTTPD file typifies this data format.
XML Structure
An XML structure is a standard XML tag that can contain a name only, a name followed by explicit properties, or a name followed by implicit properties.
Examples:
<Name> ... </Name> <Name p1=v1 p2=v2> ... </Name> <Name "implicit_property1" "implicit_property2"> ... </Name>
A WebAgent file typifies this data format.
Structure name
Delimiter
Start structure character or character sequence
Structure contents
End structure character or character sequence
Example:
StructureName = { ... }
Explicit and implicit properties are not allowed. Java Policy and Custom CFG files typify this data format.
Structure name
Start structure character or character sequence
Structure contents
End structure character or character sequence
The only difference between a delimited structure and a structure is the delimiter; that is, a structure does not require a delimiter between the structure name and the start structure indicator.
Example:
StructureName { ... }
Explicit and implicit properties are not allowed. A Unix XINETD file typifies this data format.
Section start character or character sequence
Section name
Optional (explicit and implicit) properties
Section end character or character sequence
Examples:
[SectionName] [SectionName p1=v1 p2=v2] [SectionName "implicit_property1" "implicit_ property2"]
SmWalker and Sectioned Properties files typify this data format.
Delimited Section
A delimited section is a line that begins with a common pattern, but otherwise resembles a simple property.
Examples:
HKEY_LOCAL_MACHINE\SOFTWARE\A\B\C=789 HKEY_LOCAL_MACHINE\SOFTWARE\X\Y\Z=123
These are two delimited section headings where the common pattern is HKEY_
. SiteMinder Registry and LDAP files typify this data format.
Element Cell
An element cell consists of an element cell name and a property name value pair of the form A = B = C
. Element cells typically use line continuation sequences and nesting to clarify the structure. An element cell that has multiple properties uses a property delimiter to separate them.
Example 1:
EC = \ B = C, D = F
This example is an element cell named EC
with two property name value pairs, B = C
and D = F
, separated by a comma. The structure uses the backslash character (\) to indicate line continuation. The advanced properties parser parameters PROPERTY_DELIMITER
and CONTINUE_LINE
define the respective format characters.
Example 2:
EC = \ EC2 = \ A = B, \ C = D
This example is an element cell named EC
that has a nested element cell named EC2
that contains two property name value pairs, A = B
and C = D
. This example uses the same delimiter and line continuation characters.
A collected configuration file is stored in raw form and, if a parser is specified, in a tree structure of nodes, or containers, and attributes, or properties. The file also is generated internally in XML format for the purpose of applying post-parsing rules, which consist of XPath conditions and expressions. Note that even non-XML files are generated in this internal format. Since the internal format must accommodate other file types, it introduces an additional root node in the XML to compensate for files such as Java properties files that have only attribute names and values.
Examples of how files are parsed and displayed, and the effects of post-parsing rules help to clarify:
Consider the following simple XML file:
<dir name="/a/b/c"> <file name="file1" size=120/> <file name="file2" size=350/> </dir>
Its parsed form, using the default XML parser, appears in the user interface in the following tree structure:
dir name = /a/b/c file name = file1 size = 120 file name = file2 size = 350
Notice that two containers have the same name (file), which makes it impossible to distinguish between the two, at the container level, at least. Thus, this file is a candidate for a post-parsing rule. As mentioned, there is a special internal XML format against which to apply a rule's XPath condition and expression. This format treats nodes and attributes as XML elements, and converts attribute values into corresponding element text content. It also adds a root element that doesn't appear in the original file:
<root> <dir> <name>/a/b/c</name> <file> <name>file1</name> <size>120</size> </file> <file> <name>file2</name> <size>350</size> </file> </dir> </root>
Given the problem in the parsed form of having two containers with the same name, a rule resolution might consist of the following:
/root/dir/file
name/text()
Effectively, this says: for each file evaluate name/text()
to produce an identifier that distinguishes one file from another within the dir node.
After applying the post-parsing rule, the parsed tree structure appears as follows:
dir name = /a/b/c file[file1] name = file1 size = 120 file[file2] name = file2 size = 350
The rule resolves to an identifier appended in square brackets to the container name. The combination (file[file1]
, for example) enables various operations such as compare, search, change history, and so forth, to distinguish between file containers.
Consider the following simple ORA file:
acme= (DESCRIPTION= (SOURCE_ROUTE=yes) (ADDRESS=(PROTOCOL=tcp)(HOST=host1)(PORT=1630)) (ADDRESS_LIST= (FAILOVER=on) (LOAD_BALANCE=off) (ADDRESS=(PROTOCOL=tcp)(HOST=host2a)(PORT=1630)) (ADDRESS=(PROTOCOL=tcp)(HOST=host2b)(PORT=1630))) (ADDRESS=(PROTOCOL=tcp)(HOST=host3)(PORT=1630)) (CONNECT_DATA=(SERVICE_NAME=Sales.us.acme.com)))
Its parsed form, using the Oracle ORA parser, appears in the user interface in the following tree structure:
acme DESCRIPTION SOURCE_ROUTE yes ADDRESS PROTOCOL tcp HOST host1 PORT 1630 ADDRESS_LIST FAILOVER on LOAD_BALANCE off ADDRESS PROTOCOL tcp HOST host2a PORT 1630 ADDRESS PROTOCOL tcp HOST host2b PORT 1630 ADDRESS PROTOCOL tcp HOST host3 PORT 1630 CONNECT_DATA SERVICE_NAME Sales.us.acme.com
Notice that the address containers, both standalone and within ADDRESS_LIST
are indistinguishable. Thus, this file is a candidate for a post-parsing rule. As mentioned, there is a special internal XML format against which to apply a rule's XPath condition and expression. This format treats nodes and attributes as XML elements, and converts attribute values into corresponding element text content. It also adds a root element that doesn't appear in the original file:
<root> <acme> <DESCRIPTION> <SOURCE_ROUTE>yes</SOURCE_ROUTE> <ADDRESS> <PROTOCOL>tcp</PROTOCOL> <HOST>host1</HOST> <PORT>1630</PORT> </ADDRESS> <ADDRESS_LIST> <FAILOVER>on</FAILOVER> <LOAD_BALANCE>off</LOAD_BALANCE> <ADDRESS> <PROTOCOL>tcp</PROTOCOL> <HOST>host2a</HOST> <PORT>1630</PORT> </ADDRESS> <ADDRESS> <PROTOCOL>tcp</PROTOCOL> <HOST>host2b</HOST> <PORT>1630</PORT> </ADDRESS> </ADDRESS_LIST> <ADDRESS> <PROTOCOL>tcp</PROTOCOL> <HOST>host3</HOST> <PORT>1630</PORT> </ADDRESS> <CONNECT_DATA> <SERVICE_NAME>Sales.us.acme.com</SERVICE_NAME> </CONNECT_DATA> </DESCRIPTION> </acme> </root>
Given the problem in the parsed form of having containers with the same name, a rule resolution might consist of the following:
//ADDRESS
/HOST/text()
Effectively, this says: for each address element evaluate /HOST/text()
to extract the host name as the address identifier.
After applying the post-parsing rule, the parsed tree structure appears as follows:
acme DESCRIPTION SOURCE_ROUTE yes ADDRESS[host1] PROTOCOL tcp HOST host1 PORT 1630 ADDRESS_LIST FAILOVER on LOAD_BALANCE off ADDRESS[host2a] PROTOCOL tcp HOST host2a PORT 1630 ADDRESS[host2b] PROTOCOL tcp HOST host2b PORT 1630 ADDRESS[host3] PROTOCOL tcp HOST host3 PORT 1630 CONNECT_DATA SERVICE_NAME Sales.us.acme.com
The rule resolves to an identifier appended in square brackets to the container name. The combination (ADDRESS[host2a]
, for example) enables various operations such as compare, search, change history, and so forth, to distinguish between address containers.
Consider the following three-column database table SERVER_DETAILS
:
SERVER_NAME | ENVIRONMENT | HOSTED_APPLICATIONS |
---|---|---|
webserver-100 |
QA |
5 |
webserver-200 |
PERFORMANCE |
6 |
webserver-500 |
PRODUCTION |
3 |
The SQL query expressed as part of the configuration extension creation is as follows:
select * from SERVER_DETAILS
This query returns the following raw output:
[row] 11_SERVER_NAME=13_ webserver-100 11_ENVIRONMENT=2_ QA 19_HOSTED_APPLICATIONS=1_5 [row] 11_SERVER_NAME=13_ webserver-200 11_ENVIRONMENT=11_ PERFORMANCE 19_HOSTED_APPLICATIONS=1_6 [row] 11_SERVER_NAME=13_ webserver-500 11_ENVIRONMENT=10_ PRODUCTION 19_HOSTED_APPLICATIONS=1_3
The Configuration Browser Source tab renders the data the same way.
Its parsed form, using the Database Query parser, appears in the user interface in the following tree structure:
row SERVER_NAME=webserver-100 ENVIRONMENT=QA HOSTED_APPLICATIONS=5 row SERVER_NAME=webserver-200 ENVIRONMENT=PERFORMANCE HOSTED_APPLICATIONS=6 row SERVER_NAME=webserver-500 ENVIRONMENT=PRODUCTION HOSTED_APPLICATIONS=3
Notice that the row
containers are indistinguishable. Thus, this query result is a candidate for a post-parsing rule. As mentioned, there is a special internal XML format against which to apply a rule's XPath condition and expression. This format treats nodes and attributes as XML elements, and converts attribute values into corresponding element text content. It also adds a root element that doesn't appear in the original file:
<root> <row> <SERVER_NAME>webserver-100</SERVER_NAME> <ENVIRONMENT>QA</ENVIRONMENT> <HOSTED_APPLICATIONS>5</HOSTED_APPLICATIONS> </row> <row> <SERVER_NAME>webserver-200</SERVER_NAME> <ENVIRONMENT>PERFORMANCE</ENVIRONMENT> <HOSTED_APPLICATIONS>6</HOSTED_APPLICATIONS> </row> <row> <SERVER_NAME>webserver-500</SERVER_NAME> <ENVIRONMENT>PRODUCTION</ENVIRONMENT> <HOSTED_APPLICATIONS>3</HOSTED_APPLICATIONS> </row> </root>
Given the problem in the parsed form of having three containers with the same name, a rule resolution might consist of the following:
/root/row/SERVER_NAME
SERVER_NAME/text()
Effectively, this says: for each row evaluate SERVER_NAME/text()
to produce an identifier that distinguishes one row from another within the tree structure.
After applying the post-parsing rule, the parsed tree structure appears as follows:
row[webserver-100] SERVER_NAME=webserver-100 ENVIRONMENT=QA HOSTED_APPLICATIONS=5 row[webserver-200] SERVER_NAME=webserver-200 ENVIRONMENT=PERFORMANCE HOSTED_APPLICATIONS=6 row[webserver-500] SERVER_NAME=webserver-500 ENVIRONMENT=PRODUCTION HOSTED_APPLICATIONS=3
The rule resolves to an identifier appended in square brackets to the container name. The combination (row[webserver-100]
, for example) enables various operations such as compare, search, change history, and so forth, to distinguish between row containers.
Relationships define the associations that exist among targets, or more extensively, among managed entities. In general, relationships are inherent to a target type definition. But not all relationships can be anticipated at target type creation. Thus, Cloud Control supports creation of supplemental relationships. There are two methods available to create new relationships:
Manually, by adding a generic system target
Interactively, within the Configuration Topology Viewer
This section describes the manual process. For information on creating relationships within the Configuration Topology Viewer, see Creating a Relationship to a Target.
There are two ways to access the generic system wizard:
From the Setup menu, select Add Target, then select Generic System
From the Targets menu, select Systems, then click the Add button
Specify a meaningful target name
Indicate whether this is to be a privilege-propagating system
Set system properties such as cost center and life cycle status
Add system members; there should a logical correspondence to the selections
Review member dependencies and indicate whether to include them
Set the time zone appropriately (defaults to Greenwich Mean Time)
When done, click Next.
Define Associations
Select the check box to display any associations (relationships) that Cloud Control automatically detects based on the members added to the system. Add additional associations as follows:
Click Add.
Complete the dialog that opens as follows:
Select a member target in the left table. This populates the right table.
Select an associated target in the right table. This populates the association drop-down list.
Select the association you want to create.
Click OK. The new association appears in the associations table.
Click Add and repeat to create additional associations.
When done, click Next.
Availability Criteria
Use this page to declare the key members of the system; that is, the members that must be running for the system to be considered available. You can select any one, some, or all members, but you must select at least one.
When done, click Next.
Charts
Customize how you want charts to appear on the System Charts page:
Supplement suggested charts with charts you add
Edit certain suggested charts to fit your needs
Deselect the suggested charts check box and customize the page entirely
Alter the appearance of the Members page by adding and removing columns and abbreviations
When done, click Next.
Review
Verify the makeup of the generic system target. If everything appears in order, click Finish.
Upon confirmation that the target was successfully created, use the Configuration Topology Viewer to review and traverse the relationships you created.
The Configuration Topology Viewer provides a visual layout of a target's relationships with other targets.
This section covers the following topics:
The Configuration Topology Viewer provides a visual layout of a target's relationships with other targets. To access the Configuration Topology Viewer from a target's home page, select Configuration, then select Topology in the dynamic target menu. A topology graph appears for the current target. Using the viewer, you can:
Determine the source of a target's health problems, that is, detect which targets might be causing the failure. For example, a database is down because its host is down.
Analyze the impact of a target on other targets. For example, the payroll and finance applications will be impacted if the database goes down.
Determine the system's structure by viewing the members of a system and their interrelationships.
Add additional relationships between targets. These relationships will be reflected in other Cloud Control tools.
Customize your configuration topology views to focus on the targets for which you have responsibility.
Share custom topology views that you have created with other Cloud Control users.
The following are examples of when to use the topology feature:
Determine a system's component structure (see Determining System Component Structure)
Analyze dependencies in relationships (see About Dependency Analysis)
Analyze the impact of relationships (see About Impact Analysis)
The Configuration Topology Viewer provides a visual layout of a target's relationships with other targets.
In the situations where the topology you are viewing is larger than your browser window, you can adjust the view by:
Clicking the small arrow icon in the bottom right corner of the window to bring up a navigator, which allows you to select which portion of the topology is in view.
Decreasing the size of the nodes in the display using the zoom control in the top left of the display.
Perform the following steps:
To determine which components (targets and target components) comprise your IT system and their interrelationships, use the Configuration Topology Viewer.
To see the specific relationship between two targets, hover over the link between them and the relationship name will pop up.
Note the following:
The topology feature is available any time you are in the context of a target: select Configuration from the target type menu, then select Topology.
Not all target types have configuration data. For these target types, the Configuration menu and topology graphs are not available.
Topology enables you to view system health by displaying relationships among system entities, structure of a target, and target components, thus enabling you to analyze configuration health and status of the configuration.
Perform the following steps:
Dependency analysis, also known as root cause analysis, traverses the relationships top to bottom to see if there is cause of a problem due to an issue with an asset on which the item is dependent.
To find the source of a target's health problem, perform the following steps:
Access the Configuration Topology Viewer.
In the View list, select Uses. This shows a topology of the targets that the selected target depends on.
Paths to the target or targets potentially causing the problem are colored.
If your target is not up, paths to the target or targets that may be causing the problem are colored. Red links lead from your target to targets that are down, and yellow links lead to targets whose status is not known.
By default the topology includes all depths of the tree, including the dependency relationships between those targets.
Impact analysis traverses the relationships from the bottom to the top of the tree to see if a problem will occur if changes are made to the element (target or system) in which I'm interested. It answers the question: What items are dependent on my element that would be effected should I do something to my element. For example, if I shut down a listener, what databases would be affected?
Perform the following steps:
Access the Configuration Topology Viewer.
On the Topology page, analyze the Used By view. The topology will show the targets that depend on the selected target.
When a custom topology view is no longer of use, delete it so it no longer clutters the View list. Note: System owned views cannot be deleted.
Perform the following steps:
After you create a topology view, you may find it necessary to include more relationships in the custom view. This will add targets to your custom view if they are related to the currently displayed targets using relationships you include.
Perform the following steps:
In cases where you find that Cloud Control has incomplete information about your systems, you can create relationships between targets.
Note: Once new relationships are created, any topology showing the specified relationships and containing the targets will automatically show the new relationships.
Perform the following steps:
The related target will be added to the view.
If you have created a relationship between two targets, you may decide that the relationship no longer exists. Reflect this change by deleting extraneous relationships where appropriate. Note that once relationships are removed, they no longer show in any topology views.
Perform the following steps:
Relationships are used in various places in Cloud Control, such as System templates, topology views, configuration comparisons, and so on. Deleting a relationship from this topology can impact these other areas.
If you create a relationship, you can later delete it by using the Delete Relationship... menu item.
To control the way the targets are displayed in a custom topology, you can customize the tier in which a target type is shown, and you can group target types together.
The tier in which a target type is shown will affect its vertical or horizontal placement in the topology, depending on whether the layout is left-right or top-down.
To customize the appearance, perform the following steps:
Access the Configuration Topology Viewer.
Create or select an existing custom view.
To control highlighted paths to targets that are down, toggle the "Highlight 'Down' Root Cause" menu item.
When this menu item is selected and the root target is down, paths from the root node to other down targets are highlighted. By visually following the highlighted paths, you may determine which targets are causing the root target's down status.
Note:
When this option is selected, you will not be able to group nodes together.
To manipulate tiers:
On the Customize menu, select Select Tiers.
Select either Specify Tiers or Use Default Tiers. If you choose to specify tiers, drag target types to their desired tier.
To turn the coloring of the links on and off, on the Customize menu, select Highlight "Down" Root Cause.
To group targets:
Select a link that represents one or more associations between the source and destination target types.
On the Customize menu, select Relationship, then select Group Targets...(Another way to select group targets is to right mouse click a link and select Group Targets.)
All matching associations are placed into group boxes.
Note:
Grouping targets is not possible when "Highlight 'Down' Root Cause' is selected.