HP Operations Manager for Windows

Design effective service IDs


Service IDs are unique identifiers or strings that you can choose freely when you define a component service. They are important because you use them when defining message attributes to indicate which messages match which services.

Note, however, that you don't have to create a new policy or rule for each service that you monitor. You can devise a structured naming schema for your services, and use HP Operations' predefined variables to construct the service IDs. This makes it possible to keep your policies generic, while still specifically identifying each individual service.

Consider the following example: your IT company is managing several database installations for different customers. You know that each database installation can have several instances, and that each instance has several tablespaces which you want to monitor. Your service hierarchy draft might look similar to this one:

When you know this general layout, you can begin think about creating service IDs. You will want to use the same HP Operations policy to monitor all the tablespaces, so you need to come up with a naming schema that allows you to reuse your policies, while still providing service IDs that are unique for every instance of the service.  In order to do this, think of what makes each service unique and then compose the service ID with this information. In the example above, the customer name, the instance name,  tablespace name, and the system name where the database is installed would uniquely identify each tablespace service. A service ID that contained exactly this information could look like this:

company.instance_name.tablespace_name.system.com

Note Note:
Service IDs can contain a maximum of 2048 characters. Service IDs cannot contain the following characters: ' (apostrophe), " (inch mark), \ (backslash), ` (grave accent), ยด (acute accent).

Although you could type this information directly into the service ID box for each policy, you would then need a different copy of the policy for each customer site. Instead of hardcoding this information, you can use the following methods to include this information in the Service ID.

HP Operations automatically includes the name of the system on which the message originated as a property of every Service ID, so it is not necessary for you to include this information in the Service ID. The company name, instance name and tablespace name of the particular service instance can be found by using variables. For example, if the policy was monitoring entries in a database log file, a log file like this might exist:

Sample log file entry:

Error Number: 110 tablespace_1 for instance_1 full in database Smith_Inc
Error Number: 110 tablespace_2 for instance_1 full in database Jones_Inc

In order to match Error Number 110 and to assign parts of this message to variables, you could type the following in the log file line box for the policy that monitors the log file:

^Error Number: 110 <instance_#.instance> for <tablespace_#.tablespace> full in database <*.customer>
Then, in the Message Attributes tab, you would use the following entries in the Service ID and Hosted on boxes:

Service ID: <customer>.<instance>.<tablespace>
Hosted on: <$MSG_NODE_NAME>

For the first line of the sample log file, this would resolve to a service ID that looks like this:

Smith_Inc.instance_1.tablespace_1

This is the service ID that you would type in the service ID box for the component service that represents this tablespace for customer Smith Inc. The figure below shows a variable-based naming schema for all services in the example service hierarchy.

Related Topics: