Inventory Model
Hyperic HQ Inventory Model
Available in HQ Open Source unless marked by * for HQ Enterprise only
Hyperic HQ stores information about your managed systems in an inventory repository. The items in this repository are called "resources." When you run HQ's Auto-Discovery scans on your systems (called "platforms" in HQ), HQ will discover servers and services running on those platforms; you can then choose to import these resources into HQ's inventory. If there has been a change in the managed resources on a platform since the last time an Auto-Discovery scan was run, HQ will alert you to the change.
You can use the Hyperic HQ UI portal to manage, monitor, and control the resources you have placed in inventory. Starting from the Dashboard, you can view the status of all your managed resources. The UI also provides an interactive network map that displays how an individual resource fits into the inventory model: all the resources that it hosts, and the resource that hosts it.
HQ's inventory model has 5 levels:
This diagram illustrates one example of an application and its component services, and the hosting platforms and and servers:
If you have any comments or suggestions for this help page, please submit them at the bottom of the page by clicking Add Comment.
Platforms
In HQ, a platform is an operating system running on a physical machine. Usually, an HQ Agent will run on each platform being managed by HQ. However, sometimes a platform will not have an agent running on it: examples include a network device (such as a router or firewall) and a network host (a platform managed remotely via SMTP). Platforms "host" servers (servers run on the platforms), and sometimes they directly host services (called "platform services"), too, although typically servers host services.
See the list of supported platforms.
Servers
In HQ, a server is a software product that runs on (is hosted by) a platform and that in turn supports (hosts) services. Servers provide a communications interface, and they respond to requests to perform specific tasks. A single platform can host multiple servers. Servers, by way of the services they host, can be shared across multiple applications (because applications solely comprise services).
Services
In HQ, a service is an individual piece of software that is dedicated to a particular task. Applications comprise various services (which are hosted by servers).
Examples of services:
- Apache Virtual Hosts dedicated to servicing requests that are directed to a specific application
- Tomcat Application Contexts (Webapp)
- Oracle Database Instance
- EJB Service
Platform Services
Although services are typically hosted by servers, sometimes they are hosted directly by platforms. Users can add services directly to a platform when viewing a platform. When HQ does not automatically discover a platform service, users should add the services to the platform so that HQ can then gather metrics from them.
Users must manually add a platform service under these circumstances:
- It is a technology that is not monitored by default by HQ.
- It is a custom plugin.
- It is installed in a nonstandard location that HQ does not look in by default.
- It has a nonstandard name in the process list.
"Internal" and "Deployed" Services
HQ distinguishes between two categories of services:
- "Internal" services: Services that are provided by (and internal to) the application server. Examples are JDBC connection pools and Message Queues. Providing these services is the primarily value of an application server.
- "Deployed" services: Services that are provided by the application creator and deployed onto an application server. Examples are web apps and Enterprise Java Beans.
Both internal and deployed services exist in most applications. HQ distinguishes between the two because they have very different roles in an application and significantly different levels of reliability in an application. Internal services are generally more reliable because they are very extensively tested as part of the server product that provides them.
Hyperic HQ allows you to define applications that comprise both internal and deployed services, but it is usually best to define an application as a collection of deployed services. An application can comprise clusters of deployed services because most applications use clustering to enhance availability and performance. By defining an application as a set of clusters, you also add a level of abstraction, in which you can add or remove resources from the cluster without having to change the definition of the application.
Groups
Once HQ has detailed inventory information about your managed systems, you can gather applications, platforms, servers, and services into useful groups. (You can also make groups of groups.) Grouping resources lets you easily monitor and control them.
You can create a group from any arbitrary set of resources, based on any attribute, such as geographical location, owner, business unit, and so on.
"Compatible" ("Cluster") and "Mixed" Groups
If you group resources that share a common set of monitoring metrics and control actions, that group is considered a "compatible group" or "cluster." For example, you can organize all Apache 2.x servers into a compatible group. Compatible groups are a powerful tool in HQ: they allows you to easily monitor, compare, and control several resources at once.
If you group resources that do not share a common set of monitoring metrics and control actions, that group is considered a "mixed" group. Mixed groups are used solely for role-based access control. You can view inventory information for a mixed group, but you cannot perform control actions on or monitor the group as whole, nor edit its inventory properties as a whole.
Samples Uses of Groups
| Business Need | How Groups Can Help |
|---|---|
| "I have 20 web servers that use Tomcat that I want to view them all at the same time." | Create a compatible/cluster group, name it "Tomcat," and add all 20 Tomcat servers to the group's inventory. |
| "I want to look at all of the CPUs for these 100 machines." | Create a compatible/cluster group, name it "CPUs" and add all 100 CPU services to the group's inventory. |
| "I have 10 Solaris boxes that I want to alert on if more than two of them go down." | Create a compatible/cluster group, name it "Solaris," and then add all 10 Solaris platforms to the group's inventory. |
| "I have a guy in New Jersey that needs to monitor five Windows boxes and 12 Tomcat servers but nothing else." | Create a mixed group that includes the five Windows platforms and 12 Tomcat servers. Then create a role, assign the mixed group to the role, and put the New Jersey guy in that role. |
How to Create a Group
There are several locations in the UI where you can create a group:
- "Browse Resources" screen
- The Dashboard's "Summary Counts" portlet
Applications
In HQ, an application is a collection of services that serves a specific function. An application is usually identified by the functionality it provides, such as a purchase-order-entry application or an online-banking application. An example of an application that can span multiple physical resources is an Apache virtual host front ending a Weblogic application server that uses an Oracle database. The many services involved are hosted by servers running on multiple platforms, but they all come together to provide a piece of functionality called the application.
When you specify a set of services as an application, HQ measures the availability, performance, and throughput of the resources on which the services reside and correlates it so you can see the service level of the entire application from end to end. You can also easily drill down to the service levels of the individual resources to see how they are performing.
HQ's application model exposes the following resources: the platforms (machine/OS combinations), the servers (application, database, and Web servers), services provided by those servers (including EJBs, servlets, VHosts, and database instances), and, most importantly, the application that is made up of combinations of those services. Through this application model, you can improve service levels, increase utilization of your Web infrastructure, and report service levels accurately.
Learn more about how to manage your infrastructure with applications.