Overview

Server API

These assumptions are based on a REST API documentation from the Hawkular website.

This is a diagram of components and their interactions.

Alerts

Alerts are generated by triggers. Triggers can have attached actions, as well as trigger conditions and dampenings.

Alerts are self-explanatory — they are just produced events for cases when trigger conditions become true. Actions are for doing some sort of work when triggers are activated, i. e. sending an email. Trigger conditions basically define what are reasons for activating a particular trigger. Dampenings are a sort of blockers which limit triggering alerts only when their conditions were activated multiple times in a row.

Inventory

Term	Description	Characteristics	Example
Tenant	Isolated view of the system	UUID	f9a7a378-16e4-4e0e-9bb0-1791d94e1508
Environment	State of a tenant	Name	test, integration, production
Resource type	Template of a characteristic	Name	URL
Resource	Instance of a characteristic	Value	http://hawkular.org for URL
Metric type	Template of a parameter	Name, unit, type	status.code.type with none unit, status.duration.type with millisecond unit — both are of numeric type
Metric	Instance of a parameter	UUID	45f53587-bacc-4630-bb4b-3ad9d40d5e84
Metric data	Value of a parameter instance	Value, time	500 status code and 1432807339113 milliseconds as its time stamp for status.code.type and status.dyration.type respectively

Combining examples from the table above we can compose a full picture.

• We have a Hawkular instance with a tenant f9a7a378-16e4-4e0e-9bb0-1791d94e1508. Its purpose is to separate information from other tenants if we need it. For example, we have multiple departments of a company and want to separate their data using a single Hawkular instance.
• The tenant is in a test environment. We can switch it later to production or just store information there for development purposes clearly indicating that we are testing things.
• The tenant has a resource type URL as a sort of a characteristic. Probably we want to use it to describe a server.
• The environment we are working in has a resource of a resource type URL with a value of http://hawkular.org. Clearly we are stating that we have a server with such address.
• The tenant has a couple of metric types: status.code.type and status.duration.type. We want to describe the server: status.code.type can show us what response code do we have when sending a request to it and status.duration.type will show us how much time did it took to receive it.
• The environment we are working in has metrics of described metric types. In other words we are saying that yes, the server we are trying to describe has metrics for status code and status duration.
• The metrics of the environment have metric data associated with them. For example, our server gave us 404 error code at Thu, 28 May 2015 13:14:34 +0300.

Application Structure

The initial proposal from the March 2015 has these concepts based on the Hawkular version from that time built from the master branch.

There are three base Hawkular areas. They can be set as a basis for application’s sections.

• Metrics. Information provided via various hosts and reported to Hawkular.
  • Response time. Time measurements required to get a response. Displayed as a chart.
  • Downtime. Time when a host was down. Can be displayed as a chart or as a table.
  • Alerts. Various signals for critical metric conditions. Displayed as a table.
• Alerts. Signals for defined metric conditions.
  • Dashboard. Summary of generated alerts over time. Displayed as a timeline.
  • Definitions. Triggers activating alerts. Displayed as a table.
  • Notifiers. Essentially alert senders to various destinations such as email. Displayed as a table.
• Inventory. Metrics coordination and organization.
  • Inventory List. Metrics browser based on a tenant, a resource and a metric. Displayed as a table.

Application sections description above suggests using charts and tables for displaying metrics and statistics. It would be useful to have an ability to receive push notifications for triggered alerts. Of course application should be consistent with the platform and, at the same time, with a Hawkular and JBoss branding.

The current Hawkular version from the May 2015 has differences based on the version from the master branch. It basically defines application servers at the UI and provides its alerts.

The RHQ Android application basically have the same sections as the initial proposal: metrics, resources and alerts.