Quick insight of live service status. Example: primary node & responsible=me & status!=ok
List services matching criteria. Example, 'How many non-production services do I manage for the ERP system': primary node & app=ERP & type=!PRD Example, 'I lost a power line, which services are impacted': nb_power_supply=1 & power_supply_1=POW_A
Generate diagrams of clusters to better communicate on disaster recovery plans and allocated resources.
Trigger actions on services or group of services
Screenshot
Fields
Container type
The container type reflect the kind of service integration selected for the service. This setting is set in the service configuration file on the nodes as the mode parameter. The possible values are, as of January 2010 :
hosted
The service is hosted on bare metal, non-virtualized resources : ip plumbed on a physical interface, applications and data in filesystems mounted on a real server.
zone
The service applications and data are deployed in a Solaris zone. The ip is still plumbed in the global zone. Filesystem resources are mounted in the global zone.
lxc
The service applications and data are deployed in a Linux Container (zone-like). The ip is plumbed on a virtual interface, with virtualized mac address. Filesystem resources are mounted in the host system.
vz
The service applications and data are deployed in a Linux Container (zone-like). The ip is plumbed on a virtual interface, with virtualized mac address or tunneled. Filesystem resources are mounted in the host system.
vm
The service applications and data are deployed in a Xen or KVM virtual machine. The ip is plumbed on a virtual interface, with virtualized mac address. Filesystem resources are mounted in the virtual host.
hpvm
The service applications and data are deployed in a HP-UX native virtual machine. The ip is plumbed on a virtual interface, with virtualized mac address. Filesystem resources are mounted in the virtual host.
Responsible
The responsibles are persons receiving alerts for a service. Hovering the mouse over the icon spawns the name of the responsibles. No icon means no responsible, which is an anomaly, and as such, cause alerts to be emitted to the site's administrator/manager.
Prefered node
Upon node reboot, only the services whose prefered node is set to this node are started. During those services start-up, the nodeware verifies the service is not running on another node and aborts the start-up if so.
Service type
This property is used by the nodeware to sanity check actions asked by the admin.
PRD
Production service. Services of this type can be started on any type of node.
DEV
Development service. Services of this type are not allowed to be started on production nodes.
TMP
Temporary service. Like DEV, but alerts won't be sent for these services.
App
The application code is a way to group services dedicated/paid by some corporate entity or project. You can setup any application code you want in your services configuration file, using the app parameter.
Status
Status gizmos present the overall service health on top, and individual resource type status below. Color codes are:
green
resource is up
red
resource is down
orange
resource has warnings
grey
resource type is not used by the service
An all-greyed-out status marker indicates the presented data is too old to be trusted, though it displays the last overall known status. Hovering the mouse over the status markers will displayed the data refresh timestamp.
