This sections lists some handy tips for using RightITnow ECM and will grow from release to release.
This section describes some tips and tricks to help you get the most out of integrations with third party systems.
Alarms originating from VMware can be represented in RightITnow as alerts, mapping the severity of the alarm to a severity and/or priority in RightITnow. Alarms can be in any of 4 states, and are mapped as follows by default Categorization rules in RightITnow which are fully configurable by the end user:
This is how the corresponding categorization rules appear on the Categorization page:
See Categorizing Events for more on categorization.
By collecting all the state changes on an alarm, RightITnow preserves the history of alarm state changes, in the form of the events making up the RightITnow alert. By default, the events generated by VMware to indicate that an alarm has changed status de-duplicate to a single alert in RightITnow, and the Events Window can be used from the Alerts Console to observe all the state changes that have happened, as shown below:
See Working with Alerts for more on working with alerts and events.
Additionally, a configurable Correlation rule is setup by default to update the severity of the alert to always reflect the latest severity of the alarm, allowing the end-user to have a clear picture of current VMware alarms and act accordingly.
This is how the correlation rule appears on the Correlation page:
See Correlating Events for more information on correlating events into alerts.
The VMware vSphere Client allows users to acknowledge alarms. This feature is also available in RightITnow as an Action, which can then be executed either manually on the alerts console, or through rules such as Correlations and SLA.
Here is how the action appears on the Actions page:
See Configuring Actions for complete details on working with actions.
The VMware Browser utility inside RightITnow ECM displays the alarms currently active on each entity, and allows you to acknowledge these alarms as well, as shown below:
See Using_the_VMware_Browser
for more information.
You can use the wildcard character (*) in the condition section of the Categorization or Correlation rules tabs as follows:
To use the wildcard character:
Choose the operator equals in the filter builder, as shown above.
Add * to the search text where you want the wildcard. See the example above for the different supported patterns.
Users choose the operator equals and type PREFIX* in the text box to define the condition.
For a message "PREFIX This is a message", this condition will return true.
For a message "Hello, PREFIX this is a message", this condition will return false.
Users choose the operator equals and type *SUFFIX in the text box to define the condition.
For a message "This is a message SUFFIX", this condition will return true.
For a message "This is a message SUFFIX for testing", this condition will return false.
Users choose the operator equals and type PREFIX*SUFFIX in the text box to define the condition.
For a message "PREFIX This is a message SUFFIX", this condition will return true.
For a message "Hello, PREFIX this is a message SUFFIX for testing", this condition will return false.
Note:
The * is implicitly added to the beginning and the end of search text when using the contains operator
The import/export functionality allows you to select one or multiple rules and actions for export into to an XML file. Then you can import the XML file into another instance.
To export rules or actions, navigate
to the Categorization, Correlations, Manage
SLAs, or Actions tab and then follow the instructions in the figure
below:
To import rules or actions, navigate to the Categorization, Correlations, Manage SLAs, or Actions tab and then follow the instructions in the figure below:
If actions and rules are being imported, then it is recommended that actions be imported first. This way, if an imported action is used in an imported rule, the rule will be imported with all the details.
After clicking the button, a dialog will appear to upload the file with the rules. If the types of the rules do not correspond to the ones in the tab, then an error message will be shown to the user. When importing the rule, the owner will be user who is importing the rules. All imported rules will be un-deployed.
At the moment of importing a rule, the actions, users, and connector names associated to the backed up rule will be searched in the database. If there exists an object with that name, then it will be linked to the new imported rule. Otherwise, the rule will be saved with that field empty.
Actions
If when importing “Assign To” actions, the new owner does not exist in the database, then the action will be imported as unassigned.
If the action being imported is of type “Update Custom Alert Fields” and it is to update a custom alert field that does not exist in the database, then the action will not be imported.
Rules
There are some restrictions and limitations that may affect the result of importing rules because some fields are compared against the ID of the value. For example, if the rule is “connector = Solarwinds_1”, in the back-end the rule is translated to “connector.id = ID of connector with name Solarwinds_1”. The fields that have this issue are the following:
Connector
Tags
Entity Group
Owner
Because of this, it is recommended that the condition be checked after the rule is imported, when the condition has any of these fields, in order to select the correct element.
You can Shift-click items to select multiple contiguous items, and Control-click items to select multiple non-contiguous items:
