2018-07-16 17:20:50 -04:00
|
|
|
[role="xpack"]
|
2018-10-18 15:24:02 -04:00
|
|
|
[testenv="basic"]
|
2018-07-16 17:20:50 -04:00
|
|
|
[[rollup-get-rollup-index-caps]]
|
2018-12-20 13:23:28 -05:00
|
|
|
=== Get rollup index capabilities API
|
2018-07-16 17:20:50 -04:00
|
|
|
++++
|
2018-12-20 13:23:28 -05:00
|
|
|
<titleabbrev>Get rollup index caps</titleabbrev>
|
2018-07-16 17:20:50 -04:00
|
|
|
++++
|
|
|
|
|
2019-11-20 13:43:53 -05:00
|
|
|
Returns the rollup capabilities of all jobs inside of a rollup index (e.g. the
|
|
|
|
index where rollup data is stored).
|
2018-07-16 17:20:50 -04:00
|
|
|
|
2019-11-20 13:43:53 -05:00
|
|
|
experimental[]
|
2018-07-16 17:20:50 -04:00
|
|
|
|
2019-11-20 13:43:53 -05:00
|
|
|
[[rollup-get-rollup-index-caps-request]]
|
|
|
|
==== {api-request-title}
|
2018-07-16 17:20:50 -04:00
|
|
|
|
2020-07-13 16:57:40 -04:00
|
|
|
`GET <target>/_rollup/data`
|
2018-07-16 17:20:50 -04:00
|
|
|
|
2019-11-20 13:43:53 -05:00
|
|
|
[[rollup-get-rollup-index-caps-prereqs]]
|
|
|
|
==== {api-prereq-title}
|
2018-07-16 17:20:50 -04:00
|
|
|
|
2019-11-20 13:43:53 -05:00
|
|
|
* If the {es} {security-features} are enabled, you must have the `read` index
|
|
|
|
privilege on the index that stores the rollup results. For more information, see
|
|
|
|
<<security-privileges>>.
|
2018-07-16 17:20:50 -04:00
|
|
|
|
2019-11-20 13:43:53 -05:00
|
|
|
[[rollup-get-rollup-index-caps-desc]]
|
|
|
|
==== {api-description-title}
|
2018-07-16 17:20:50 -04:00
|
|
|
|
2019-11-20 13:43:53 -05:00
|
|
|
A single rollup index may store the data for multiple {rollup-jobs}, and may
|
|
|
|
have a variety of capabilities depending on those jobs.
|
2018-07-16 17:20:50 -04:00
|
|
|
|
2019-11-20 13:43:53 -05:00
|
|
|
This API will allow you to determine:
|
2018-07-16 17:20:50 -04:00
|
|
|
|
2019-11-20 13:43:53 -05:00
|
|
|
1. What jobs are stored in an index (or indices specified via a pattern)?
|
|
|
|
2. What target indices were rolled up, what fields were used in those rollups
|
|
|
|
and what aggregations can be performed on each job?
|
2018-07-16 17:20:50 -04:00
|
|
|
|
2019-11-20 13:43:53 -05:00
|
|
|
[[rollup-get-rollup-index-caps-path-params]]
|
|
|
|
==== {api-path-parms-title}
|
2018-07-16 17:20:50 -04:00
|
|
|
|
2020-07-13 16:57:40 -04:00
|
|
|
`<target>`::
|
|
|
|
(Required, string) Data stream or index to check for rollup capabilities.
|
|
|
|
Wildcard (`*`) expressions are supported.
|
2018-07-16 17:20:50 -04:00
|
|
|
|
2019-11-20 13:43:53 -05:00
|
|
|
[[rollup-get-rollup-index-caps-example]]
|
|
|
|
==== {api-examples-title}
|
2018-07-16 17:20:50 -04:00
|
|
|
|
2019-11-20 13:43:53 -05:00
|
|
|
Imagine we have an index named `sensor-1` full of raw data. We know that the
|
|
|
|
data will grow over time, so there will be a `sensor-2`, `sensor-3`, etc.
|
|
|
|
Let's create a {rollup-job} that stores its data in `sensor_rollup`:
|
2018-07-16 17:20:50 -04:00
|
|
|
|
2019-09-09 12:35:50 -04:00
|
|
|
[source,console]
|
2018-07-16 17:20:50 -04:00
|
|
|
--------------------------------------------------
|
2018-12-11 19:43:17 -05:00
|
|
|
PUT _rollup/job/sensor
|
2018-07-16 17:20:50 -04:00
|
|
|
{
|
|
|
|
"index_pattern": "sensor-*",
|
|
|
|
"rollup_index": "sensor_rollup",
|
|
|
|
"cron": "*/30 * * * * ?",
|
|
|
|
"page_size" :1000,
|
|
|
|
"groups" : {
|
|
|
|
"date_histogram": {
|
|
|
|
"field": "timestamp",
|
[7.x Backport] Force selection of calendar or fixed intervals (#41906)
The date_histogram accepts an interval which can be either a calendar
interval (DST-aware, leap seconds, arbitrary length of months, etc) or
fixed interval (strict multiples of SI units). Unfortunately this is inferred
by first trying to parse as a calendar interval, then falling back to fixed
if that fails.
This leads to confusing arrangement where `1d` == calendar, but
`2d` == fixed. And if you want a day of fixed time, you have to
specify `24h` (e.g. the next smallest unit). This arrangement is very
error-prone for users.
This PR adds `calendar_interval` and `fixed_interval` parameters to any
code that uses intervals (date_histogram, rollup, composite, datafeed, etc).
Calendar only accepts calendar intervals, fixed accepts any combination of
units (meaning `1d` can be used to specify `24h` in fixed time), and both
are mutually exclusive.
The old interval behavior is deprecated and will throw a deprecation warning.
It is also mutually exclusive with the two new parameters. In the future the
old dual-purpose interval will be removed.
The change applies to both REST and java clients.
2019-05-20 12:07:29 -04:00
|
|
|
"fixed_interval": "1h",
|
2018-07-16 17:20:50 -04:00
|
|
|
"delay": "7d"
|
|
|
|
},
|
|
|
|
"terms": {
|
|
|
|
"fields": ["node"]
|
|
|
|
}
|
|
|
|
},
|
|
|
|
"metrics": [
|
|
|
|
{
|
|
|
|
"field": "temperature",
|
|
|
|
"metrics": ["min", "max", "sum"]
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"field": "voltage",
|
|
|
|
"metrics": ["avg"]
|
|
|
|
}
|
|
|
|
]
|
|
|
|
}
|
|
|
|
--------------------------------------------------
|
|
|
|
// TEST[setup:sensor_index]
|
|
|
|
|
2019-11-20 13:43:53 -05:00
|
|
|
If at a later date, we'd like to determine what jobs and capabilities were
|
|
|
|
stored in the `sensor_rollup` index, we can use the get rollup index API:
|
2018-07-16 17:20:50 -04:00
|
|
|
|
2019-09-09 12:35:50 -04:00
|
|
|
[source,console]
|
2018-07-16 17:20:50 -04:00
|
|
|
--------------------------------------------------
|
2018-12-11 19:43:17 -05:00
|
|
|
GET /sensor_rollup/_rollup/data
|
2018-07-16 17:20:50 -04:00
|
|
|
--------------------------------------------------
|
|
|
|
// TEST[continued]
|
|
|
|
|
2019-11-20 13:43:53 -05:00
|
|
|
Note how we are requesting the concrete rollup index name (`sensor_rollup`) as
|
|
|
|
the first part of the URL. This will yield the following response:
|
2018-07-16 17:20:50 -04:00
|
|
|
|
2019-09-06 09:22:08 -04:00
|
|
|
[source,console-result]
|
2018-07-16 17:20:50 -04:00
|
|
|
----
|
|
|
|
{
|
|
|
|
"sensor_rollup" : {
|
|
|
|
"rollup_jobs" : [
|
|
|
|
{
|
|
|
|
"job_id" : "sensor",
|
|
|
|
"rollup_index" : "sensor_rollup",
|
|
|
|
"index_pattern" : "sensor-*",
|
|
|
|
"fields" : {
|
|
|
|
"node" : [
|
|
|
|
{
|
|
|
|
"agg" : "terms"
|
|
|
|
}
|
|
|
|
],
|
|
|
|
"temperature" : [
|
|
|
|
{
|
|
|
|
"agg" : "min"
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"agg" : "max"
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"agg" : "sum"
|
|
|
|
}
|
|
|
|
],
|
|
|
|
"timestamp" : [
|
|
|
|
{
|
|
|
|
"agg" : "date_histogram",
|
|
|
|
"time_zone" : "UTC",
|
[7.x Backport] Force selection of calendar or fixed intervals (#41906)
The date_histogram accepts an interval which can be either a calendar
interval (DST-aware, leap seconds, arbitrary length of months, etc) or
fixed interval (strict multiples of SI units). Unfortunately this is inferred
by first trying to parse as a calendar interval, then falling back to fixed
if that fails.
This leads to confusing arrangement where `1d` == calendar, but
`2d` == fixed. And if you want a day of fixed time, you have to
specify `24h` (e.g. the next smallest unit). This arrangement is very
error-prone for users.
This PR adds `calendar_interval` and `fixed_interval` parameters to any
code that uses intervals (date_histogram, rollup, composite, datafeed, etc).
Calendar only accepts calendar intervals, fixed accepts any combination of
units (meaning `1d` can be used to specify `24h` in fixed time), and both
are mutually exclusive.
The old interval behavior is deprecated and will throw a deprecation warning.
It is also mutually exclusive with the two new parameters. In the future the
old dual-purpose interval will be removed.
The change applies to both REST and java clients.
2019-05-20 12:07:29 -04:00
|
|
|
"fixed_interval" : "1h",
|
2018-07-16 17:20:50 -04:00
|
|
|
"delay": "7d"
|
|
|
|
}
|
|
|
|
],
|
|
|
|
"voltage" : [
|
|
|
|
{
|
|
|
|
"agg" : "avg"
|
|
|
|
}
|
|
|
|
]
|
|
|
|
}
|
|
|
|
}
|
|
|
|
]
|
|
|
|
}
|
|
|
|
}
|
|
|
|
----
|
|
|
|
|
|
|
|
|
2019-11-20 13:43:53 -05:00
|
|
|
The response that is returned contains information that is similar to the
|
|
|
|
original rollup configuration, but formatted differently. First, there are some
|
|
|
|
house-keeping details: the {rollup-job} ID, the index that holds the rolled data,
|
2018-07-16 17:20:50 -04:00
|
|
|
the index pattern that the job was targeting.
|
|
|
|
|
2019-11-20 13:43:53 -05:00
|
|
|
Next it shows a list of fields that contain data eligible for rollup searches.
|
|
|
|
Here we see four fields: `node`, `temperature`, `timestamp` and `voltage`. Each
|
|
|
|
of these fields list the aggregations that are possible. For example, you can
|
|
|
|
use a min, max, or sum aggregation on the `temperature` field, but only a
|
|
|
|
`date_histogram` on `timestamp`.
|
2018-07-16 17:20:50 -04:00
|
|
|
|
2019-11-20 13:43:53 -05:00
|
|
|
Note that the `rollup_jobs` element is an array; there can be multiple,
|
|
|
|
independent jobs configured for a single index or index pattern. Each of these
|
|
|
|
jobs may have different configurations, so the API returns a list of all the
|
|
|
|
various configurations available.
|
2018-07-16 17:20:50 -04:00
|
|
|
|
2019-11-20 13:43:53 -05:00
|
|
|
Like other APIs that interact with indices, you can specify index patterns
|
|
|
|
instead of explicit indices:
|
2018-07-16 17:20:50 -04:00
|
|
|
|
2019-09-09 12:35:50 -04:00
|
|
|
[source,console]
|
2018-07-16 17:20:50 -04:00
|
|
|
--------------------------------------------------
|
2018-12-11 19:43:17 -05:00
|
|
|
GET /*_rollup/_rollup/data
|
2018-07-16 17:20:50 -04:00
|
|
|
--------------------------------------------------
|
|
|
|
// TEST[continued]
|
|
|
|
|