Agent-Based Monitoring is NOT the only way to get CIs into the Run-time Service Model

[#1]

Did you know that HP’s agentless monitoring solution – HP SiteScope – has  the ability to feed monitors and corresponding configuration items (CI) into the Run-time Service Model (RtSM)?  For those of you already using HP SiteScope and for those contemplating what HP SiteScope has to offer, this post describes in detail how to feed this wealth of information into HP’s RtSM.

As you may already know, HP SiteScope (SiS) collects all sorts of information about servers, applications, and other aspects of your IT environment after you configure your SiteScope monitors.  What you probably didn’t know is that this wealth of information can also be used to create the appropriate topology in the HP BSM RtSM.

Feeding SiteScope topology to the RtSM

There is an interface between BSM and SiteScope that provides a mechanism to synchronize SiteScope topology with BSM.  The topology sent to BSM contains CIs that correspond to the hosts, servers, and applications that SiteScope monitors. When SiteScope is registered to BSM, the full SiteScope topology is sent to BSM. Afterwards, SiteScope sends changes in topology to BSM – for example, adding or deleting monitors. 

Additionally, SiteScope leverages Jython scripts along with DDM components for topology reporting. Using DDM components has several advantages such as:

• The use of a standard technology that is used elsewhere in HP’s Business Technology Optimization (BTO) software
• Best-of-breed discovery framework
• Easier topology alignment
• Script ability and content development flexibility
• Guaranteed delivery
• Client-side caching and delta management
• Support for backwards and forwards compatibility

How SiteScope sends topology information to the RtSM/BSM

The process for sending topology information to BSM is as follows:

• Script execution - SiteScope topology is generated using Jython scripts. Each script execution creates a bulk of objects that is sent to BSM. The scripts are located on BSM to allow support of backward/forward compatibility. Scripts are downloaded to the <SiteScope root directory>\discovery folder on the SiteScope server.

• Results Processing - There are several processing steps that are run against script results before topology information is sent to the RtSM. To reduce the load on BSM, these steps are divided into data validation against class model, and are filtered for objects already reported. At the end of result processing, the objects are saved as a file inside the <SiteScope root directory>\cache\topologyresultsData folder.
  
  
• Topology sent to BSM - After result processing has finished, the topology is sent to BSM. To reduce load on the RtSM, the results are merged and saved to the <SiteScope root directory>\cache\topologyresultsData\merged folder. The merged bulk is sent to BSM using HTTP.

Default topologies reported to BSM based on the SiteScope monitor being used

While SiteScope provides all sorts of information to the RtSM related to topology, minimally there is default topology information that is based on the specific monitor being used.  Some examples include the following:

• Node Environment – Includes monitors that report the status of a host or server. (e.g.,  "CPU monitor”, “Memory monitor”, and “Disk Space monitor”)
• Database Environments – Includes monitors that report DB2 8.x and 9.x, Microsoft SQL Server, and Oracle Database topologies. (e.g., "DB2 8.x and 9.x monitor”, "Microsoft SQL Server monitor”, "Oracle Database monitor”)
• Virtualization Environments – Includes monitors that report the Solaris Zones, VMware Performance, and VMware Host Monitor topologies. (e.g.,  " Solaris Zones monitor”, "VMware Performance monitor”)
• Web Server Environments – Includes monitors that report Microsoft IIS Server, WebLogic Application Server, and WebSphere Application Server topologies. (e.g., "WebLogic Application Server monitor”, "WebSphere Application Server monitor”, "Microsoft IIS Server monitor")
• ERP/CRM Application Environments – Includes monitors that report the SAP CCMS, SAP Work Processes, Siebel Application Server, and Siebel Web Server topologies. (e.g., “ SAP CCMS monitor”)
• SOA Environments – Includes monitors that report the Web Service Topology. (e.g., “Web Service monitor”)

In some cases, you need to define the topology before sending off to the RtSM/BSM

For some monitors, it is not possible to know the CI type that is being monitored in advance (e.g., Log monitor or URL monitor).  In these cases, you must define the relevant topology when configuring these monitor types. Stay tuned for future blog posts, which will describe in detail how to customize your topology in these situations.

Conclusion

I hope you now have a better understanding of the various topologies reported by SiteScope to the RtSM and what happens “behind the scenes” of the SiteScope/BSM/RTSM world.  Stay tuned for future posts, where we will discuss customization of topology reporting, important troubleshooting information, and more …

Special thanks goes to Liron Gefen, who provided ther content for this blog post ...