- acknowledge (an alert)
- alert priority
- auto scan
- availability (of a resource)
- cluster mode
- compatible group
- configuration properties
- control action
- dashboard favorites
- deployed service
- display range
- dynamic metric
- escalation scheme
- file scan
- indicator or indicator metric
- internal service
- inventory level
- log level
- managed resource
- mixed group
- network device
- network host
- OOB (out of bounds)
- platform service
- problem resources
- quick control action
- resource type
- response time
- static metric
A user-performed task in the HQ UI that indicates that the user is aware of the alert and is taking responsibility for it. Acknowledgment kicks off the escalation chain assigned to the alert definition. Alerts without escalation schemes do not need to be and cannot be acknowledged.
A collection of services organized to fulfill a single business purpose. Applications typically have many services, which are usually hosted by many more servers and in turn more than one platform. A typical J2EE application modeled in HQ can contain Apache Virtual Hosts, Tomcat Webapps, JBoss Connection pools, and Oracle Instances. There are two application types: J2ee and Generic; in general the application type is determined by what services the application comprises (for example, a J2ee web application, C++ desktop application, and a PHP/MySQL web application).
A group that HQ automatically creates when there are multiple resources of a single resource type. This visually abstracts what would otherwise be too much information to make sense of on one page. Example. A network switch platform. A switch can contain many interfaces, and to list them all one-by-one would make it hard to manage other data easily. By rolling all the interfaces up into an autogroup, the user receives immediate visual status of everything in the group. An autogroup's inventory lists all the component services, just as happens with a manually created group, but an autogroup is not listed on the Browse Resources screen.
The same thing as auto-discovery. This term is used only in plugins.
HQ's automated process for discovering all of the resources running on the machines in your environment, from operating systems (platforms) to servers (such as Apache web servers) to services (such as Apache virtual hosts). For each of these discovered resources, HQ also discovers, collects, and stores metrics. Learn more.
A type of auto-discovery that requires no end user intervention. Auto Scans typically do not take long and are not CPU intensive. Auto Scans are automatically run by the HQ Agent on a 15 minute schedule, as well as each time an agent is started.
|Yellow||Availability between 0% to 100%|
|Orange||Resource is paused|
|Gray||No availability was collected in the time frame|
A metric's "baseline" is the value that represents the norm for that metric. The baseline value is calculated continuously and automatically for each dynamic metric on a resource: it is the average of the observed metric values over a user-specified time frame.
A group of HQ Servers configured to work as one entity. It consists of multiple nodes.
A group of resources that share a common set of monitoring metrics and control actions. For example, all Apache 2.x servers. This type of group enables users to monitor, compare, and control several resources at once.
Information that HQ needs in order to monitor and (for certain products) control a resource. There are three kinds of configuration properties: Monitoring (those data that HQ needs to collect metrics and to perform log and configuration tracking), Control (those data that HQ needs to perform control actions on a resource),and Shared (properties that apply to both "monitoring" and "control" aspects of the resource, in other words, general product configuration properties). An example of a configuration property for a service is that HQ must know the path to the apachectl file if users want to be able to control Apache through HQ.
A task a user can perform on a managed resource via the HQ interface. Example, starting or stopping Postgres. Control actions are not available for all inventory levels in HQ: Platforms, applications, and mixed groups do not have control actions. Control actions can be scheduled, performed as part of an alert, and performed on demand, when the user wants.
A user-selected set of resources that appears in the "Favorites" portlet in the Dashboard. Users can add resources to this list while looking at any resource instance or en masse from within the Dashboard.
A relationship between two resources wherein one relies on the other in order to function completely or at all. Users specify these relationships, and they do not affect the functioning of HQ. A service can depend on other services, and an application depends on its component services.
A metric whose value is constantly changing. Example. CPU usage, free memory, load average. As opposed to a static metric.
A set of user-defined instructions (for example, notify certain users via email or SMS) that HQ follows after an alert has been acknowledged or after its status has been changed. Escalation schemes are assigned to alert definitions (an alert definition can have none or one).
A type of auto-discovery that involves scanning the file system for installed products. File scans take a much deeper look at the device than auto scans. File Scans must be initiated by the user using the New Auto-Discovery links found on all platform pages. The File Scan auto-discovery is more configurable than Auto Scan.
A logical grouping of services, servers, and platforms that allows the user to easily monitor and control applications and their component servers, services, and platforms. Example: Group by geographical location, owner, or business unit. There are two kinds of groups in HQ: compatible and mixed.
The HQ inventory model comprises several levels: service, server, platform, group, and application. "Inventory level" is simply a way to refer to the set of all resources that are services or that are servers or...you get the picture. This differs from resource type, which is a more restrictive way of organizing or referring to a set of resources.
A group of resources that do not share a common set of monitoring metrics and control actions. Used solely for role-based access control. Users can view inventory information for this type of group, but they cannot control or monitor the group or edit the group's inventory properties as a whole. For example, 10 Tomcat servers and 10 Exchange servers.
An SNMP-enabled network device (considered a platform in the HQ inventory model) that cannot run an Agent directly. A network device, generally, is a small device (for example, a load balancer, switch, or router firewall, specifically, a Cisco device that does not run IOS, a Netgear device, or a Linksys device), as opposed to a networkhost.
An individual HQ Server in an HQ cluster.
A machine/operating system combination or any network or storage device. Platforms are the lowest level of management, and include components such as CPU's, Network Interfaces, and File Systems. Servers run on platforms, and services in turn are provided by servers. A platform type is simply a specific platform product, for example, Linux.
Services that require no awareness of the server-side implementation, be it Apache speaking HTTP, qmail speaking SMTP, or OpenLDAP speaking LDAP. This is in contrast to the usual implementation of the HQ inventory model, in which one platform hosts multiple servers, each of which in turn host multiple services.
Portlets are "pluggable" user-interface components that are managed and displayed in the Hyperic HQ UI. In general application usage, common examples of portlet applications are email, weather reports, discussion forums, and news. In Hyperic HQ, portlets are used, for example, to display metrics and the results of Auto-Discovery. (Source: Wikipedia.)
A resource with a problem metric (that is, a metric whose observed value that has fallen out-of-bounds of the acceptable range) within a user-specified time range.
A one-time manually initiated control action performed on a resource. When the user initiates the action, it is executed on the remote machine immediately and the user is given a status page with the control-action results. Sometimes referred to as an "on demand" control action.
A product that HQ can manage. For example, Exchange and Apache. Upon installation, HQ describes hundreds of resource types; the description includes specifications for Name, Version, Available Metrics, and Available Control Actions. Resource types span platforms, servers, and services.
A set of permissions applied to specified groups of resources. Users with this role have those permissions on those resources.
A component of a server dedicated to a specific purpose. Typically services are represented by the units of work of a given server. Different types of servers each define a list of one or more types of services they provide. Examples. Webapps deployed in Tomcat, Virtual Hosts configured in Apache. Services can also be attached directly to a platform (known as a platform services) in the case of CPU, Network Interfaces and Filesystems. There are a another couple varieties of services: deployed services and internal services. A service type is simply a specific service, for example, FileServer Mount or CPU or HTTP.
Any software that is installed on a platform under management. Databases, middleware, virtualization, application and web servers are all examples of servers. Servers run on platforms. Platforms host multiple servers. A server type is simply a specific server product, for example, MySQL 5.x or Apache httpd.
A metric whose value does not change much. Example. Response code for a web check. As opposed to a dynamic metric.