The motivations for pre-computed aggregates are discussed in https://developer.jboss.org/thread/249480. For the initial implementation we want to support,
- Tenant level configuration for rollup intervals, e.g., 5 min, 15 min, 1 hr, 1 day, etc.
- Default to 1 hr, 6 hr, and 24 hr if the client does not specify anything for the tenant
- Compute max/min/avg
- Use fixed time windows as we did in RHQ
- Investigate using sliding windows, like moving averages
This is intentionally a minimal feature set in order to 1) solicit feedback sooner and 2) use that feedback to help determine what additional features we want.
Note that the data and tags tables have a interval column. The purpose of this column was to more explicitly identify rollups. Every metric has an id, and every id consists of a name and an interval. For raw metrics, the interval is the empty string. Since there is no support yet for pre-computed aggregates, the interval is excluded from requests/responses in the REST API. We might want to rename the interval column to rollup to be more descriptive in its purpose.
There is some other stuff in the schema, specifically in schema.cql for dealing with pre-computed aggregates, but nothing has been done with it so we can change it freely as we see fit.
Let's say for example that we create a tenant with the following rollups,
- 15 minutes
- 30 minutes
- 1 hr
- 1 day
The 15 minute aggregate metric data would be computed from the raw metric data. The 30 minute data would be computed from the 15 minute data. The 1 hour data would be computed from the 30 minute data. And finally the 1 day data would be computed from the 30 minute data.
We can address querying pre-computed aggregate data in a separate ticket.
Lastly, for this ticket assume that there is only a single RHQ Metrics instance. There is ongoing investigation into multi-node deployments and coordinating work between nodes. We will start addressing that in subsequent tickets/iterations.