IT Operations Management (ITOM)

Three faces of SiteScope monitors in the Wild West

Three faces of SiteScope monitors in the Wild West

Asaf Shechter

Note: before starting reading this blog, if you want to enhance your reading experience and get into the groove, click on this link and play the best theme tune ever!


Run Time Service Model (RTSM) is the secret sauce in BSM, you’ve probably heard that before. You also have probably heard that modeling is important, because this is the way to correlate the logical layer CIs (Configuration Items) with the infrastructure. By doing so, you will be able to understand how issues in your infrastructure impact your business services and applications.


RTSM can be populated by many sources, for example: synchronization from uCMDB, topology sync from Operations Manager x (OMx), Business Process Monitor (BPM), Real Users Monitor (RUM), SiteScope and more. In this article I want to focus on the topology SiteScope 11.23 reports in RTSM.

When looking at the different SiteScope monitors, and the topology they report in RTSM, you can identify three different types of monitors. I am using one of the best movies ever made, The good, The bad and The ugly, as analogy for these monitors’ types.


If you are looking to get started with SiteScope you can download v. 11.20 here. This is your chance to kick the tires a bit and see what it can do for you.


Why do we need custom topology?

Most SiteScope monitors report the monitored CI by default. Think about them as “the good” monitors, since they “know” what they are monitoring. They are “topology aware” monitors.

For example, the CPU monitor reports the “Computer” CI type by default:


But there are several generic monitors that do not report monitored CI by default. Think about them as “the bad” monitors, since they “don’t know” what they are monitoring. They are “ignorant topology” monitors.

For example, let take a look at the “Log file” monitor, SiteScope is unable to know the CI type that is being monitored in advance by this monitor because it does not know what information is kept in the log file.

The log file can contain information on the server itself, such as disk utilization:

The log file can also contain information on software running on the server, such as JBoss status:

And in some cases, the log file can contain information about logical entity such as Business Application (for example: number of logged in users):


There is actually another type of monitors, “the ugly” monitors, since they think they are “good” but they are actually “bad” monitors. They are the “topology confused” monitors.

In these cases, there is a default monitored CI type, but you are actually using the monitor to monitor something else. For example: Database Query monitor will report “Database” CI type, but in some cases, you are using this monitor to perform SQL query to the database and are actually interested in the monitor’s result. That result can tell you something on a different CI type, like Business Application or Running Software.


As you can see in the above screenshots, you can configure the monitored CI according to the monitored information, and sometimes YOU need to help SiteScope report that CI.

To configure the monitored CI and report the CI information to BSM, you must:

  • Select the CI type from the CI type list for the SiteScope monitor in Properties > HP Integration Setting > BSM Integration Data and Topology Settings.
  • Enter the required CI key attributes (make sure you enter in the correct values in order to be aligned with the topology you have in RTSM).
  • Select an indicator relevant for the CI type linked to the monitor in the Indicator Settings section.

It is important to configure topology reporting for each monitor to enable the monitor data to impact BSM’s Service Health and other solutions such as SHA and SLM.


What’s new in custom topology for SiteScope 11.23:

The generic “Running Software” CI type was added to the list of available CI types in SiteScope 11.23 when integrated with BSM 9.23 (or later), as can be seen in the CI types table list below:


Relevant CI type list


Node, Computer, Unix, Windows

Business Elements

Business Application, Business Service, Infrastructure   Service

Running Software

Running  Software


Database, SQL Server, Oracle, Sybase, DB2

Application Server

JBoss AS, Oracle iAS, Weblogic AS, Websphere AS


Since “Running Software” is a generic CI type, it can reconcile with any of its descendant types. This means that you can discover some running software in CMDB, which will then be synchronized into RTSM as the concrete CIT (Apache for example), and by configuring SiteScope to report Running Software with the same identification attributes as your concrete CIT, RTSM will reconcile the CIs and SiteScope will report its data directly to the concrete CIT (Apache in our example).

When choosing the “Running Software” as your monitored CI type, you will need to provide these attributes:

Name: the name of the Running Software CI
Server: the name of the Node hosting the Running Software
Product Name: one of the predefined values best representing your Running Software product
Discovered Product Name: free text representing your Running Software product.


Note: even though both Product Name and Discovered Product Name are marked as required, for reconciliation with existing Cis in RTSM only one of the attributes can be used (as long as the other attribute is empty on the existing CI). If you are planning to reconcile with existing CI that has values for both these attributes, then make sure that both attributes from SiteScope monitor match. If you are not planning to reconcile with any CI in RTSM, you can fill any value in the monitor (just don’t leave it empty).


For the full list of “Running Software” descendant CI types go to Admin > RTSM Administration > Modeling > CI Type Manager and search for Running Software CI type:


In addition, a new “SiteScope Monitors without Monitored CIs” view was added to RTSM in BSM 9.23 which enables users to obtain all the SiteScope monitors that are not reporting topology (Monitored CI)

In order to deploy the new “SiteScope Monitors without Monitored CIs” view:

Go to Admin > RTSM Administration > Administration tab > Package Manager > Deploy Packages to Server                          > Add  > Browse to HPBSM\odb\conf\factory_packages > Select > Open > Click the file > Select the below files and click Deploy:

cmdbview – SiteScope Monitor without Monitored CIs

tql – SiteScope Monitor without Monitored CIs

Example for “SiteScope Monitors without Monitored CIs” View in RTSM:

Go to Admin > RTSM Administration > Modeling tab > IT Universe Manager


Why Running Software should be used in Modeling?

From the Effective Modeling best practices (which can be found in your BSM Help menu or in this link):

When modeling an application, you should use Running Software CIs whenever possible, for two main reasons:

1)      It is more accurate to map the model to the Running Software, because this is what the model is using from that node, and not anything else. For example, if you have an Oracle server running on a computer which is shared among multiple applications, you should use the DB Schema when you model a specific business application, because that is the only part it is using from that Oracle server and from that computer.

2)      Regarding Impact calculation, the Running Software is impacted by the node and not vice-versa. This is needed for correct status calculation and propagation in BSM. (See details in "Appendix A - The Impact Layer" on page 21.)


With the new Running Software in SiteScope custom topology, you can now create more accurate topology of your monitored environment, and enhance your models accordingly. Please note that from the example above, the DB Schema is an Application Resource CI type, so you cannot create it with SiteScope custom topology.


Running Software —Having the right CI Type from your SiteScope monitors

SiteScope allows you to customize the monitored CI for its monitors. You should leverage this capability in those monitors which there is no default monitored CI or it is not representing your monitoring information (“the bad” and “the ugly”). After doing so, you can enhance your Models in RTSM with more accurate topology of your monitored environment.

Visit our homepage here for more information on Business Service Management. If you are ready to begin your journey with SiteScope, you can download it here. If you have any more questions on SiteScope custom topology or Modeling you can reach out to me in the comments section below.

Did you click the on link to the best theme tune ever before reading the blog? Leave me a comment if you found it useful.


Until next time,



Tal Blizowsky, Software Engineer, SiteScope R&D assisted me in writing this blog. 


  • infrastructure management
About the Author

Asaf Shechter

Respected Contributor.

Great Blog!

Indeed a real customer problem + how to better understand it and solve it.



Great Blog!


I like this variant better :





New Member.

Great article!


Everyone working with monitoring or a data collectors need to understand this.  I made my entire team read this as I have spent a lot of time in this topic with my admins.  Love it! :0)




Acclaimed Contributor.

Thank you for taking time to write this article. Appreciate your effort. Very good article for BSM folks out there. Looking forward for more.

Good luck!