rollup-index-caps.asciidoc 4.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169
  1. [role="xpack"]
  2. [[rollup-get-rollup-index-caps]]
  3. === Get rollup index capabilities API
  4. ++++
  5. <titleabbrev>Get rollup index caps</titleabbrev>
  6. ++++
  7. Returns the rollup capabilities of all jobs inside of a rollup index (e.g. the
  8. index where rollup data is stored).
  9. experimental[]
  10. NOTE: For version 8.5 and above we recommend <<downsampling,downsampling>> over
  11. rollups as a way to reduce your storage costs for time series data.
  12. [[rollup-get-rollup-index-caps-request]]
  13. ==== {api-request-title}
  14. `GET <target>/_rollup/data`
  15. [[rollup-get-rollup-index-caps-prereqs]]
  16. ==== {api-prereq-title}
  17. * If the {es} {security-features} are enabled, you must have any of the `read`,
  18. `view_index_metadata`, or `manage` <<privileges-list-indices,index privilege>>
  19. on the index that stores the rollup results. For more information, see
  20. <<security-privileges>>.
  21. [[rollup-get-rollup-index-caps-desc]]
  22. ==== {api-description-title}
  23. A single rollup index may store the data for multiple {rollup-jobs}, and may
  24. have a variety of capabilities depending on those jobs.
  25. This API will allow you to determine:
  26. 1. What jobs are stored in an index (or indices specified via a pattern)?
  27. 2. What target indices were rolled up, what fields were used in those rollups
  28. and what aggregations can be performed on each job?
  29. [[rollup-get-rollup-index-caps-path-params]]
  30. ==== {api-path-parms-title}
  31. `<target>`::
  32. (Required, string) Data stream or index to check for rollup capabilities.
  33. Wildcard (`*`) expressions are supported.
  34. [[rollup-get-rollup-index-caps-example]]
  35. ==== {api-examples-title}
  36. Imagine we have an index named `sensor-1` full of raw data. We know that the
  37. data will grow over time, so there will be a `sensor-2`, `sensor-3`, etc.
  38. Let's create a {rollup-job} that stores its data in `sensor_rollup`:
  39. [source,console]
  40. --------------------------------------------------
  41. PUT _rollup/job/sensor
  42. {
  43. "index_pattern": "sensor-*",
  44. "rollup_index": "sensor_rollup",
  45. "cron": "*/30 * * * * ?",
  46. "page_size": 1000,
  47. "groups": {
  48. "date_histogram": {
  49. "field": "timestamp",
  50. "fixed_interval": "1h",
  51. "delay": "7d"
  52. },
  53. "terms": {
  54. "fields": [ "node" ]
  55. }
  56. },
  57. "metrics": [
  58. {
  59. "field": "temperature",
  60. "metrics": [ "min", "max", "sum" ]
  61. },
  62. {
  63. "field": "voltage",
  64. "metrics": [ "avg" ]
  65. }
  66. ]
  67. }
  68. --------------------------------------------------
  69. // TEST[setup:sensor_index]
  70. If at a later date, we'd like to determine what jobs and capabilities were
  71. stored in the `sensor_rollup` index, we can use the get rollup index API:
  72. [source,console]
  73. --------------------------------------------------
  74. GET /sensor_rollup/_rollup/data
  75. --------------------------------------------------
  76. // TEST[continued]
  77. Note how we are requesting the concrete rollup index name (`sensor_rollup`) as
  78. the first part of the URL. This will yield the following response:
  79. [source,console-result]
  80. ----
  81. {
  82. "sensor_rollup" : {
  83. "rollup_jobs" : [
  84. {
  85. "job_id" : "sensor",
  86. "rollup_index" : "sensor_rollup",
  87. "index_pattern" : "sensor-*",
  88. "fields" : {
  89. "node" : [
  90. {
  91. "agg" : "terms"
  92. }
  93. ],
  94. "temperature" : [
  95. {
  96. "agg" : "min"
  97. },
  98. {
  99. "agg" : "max"
  100. },
  101. {
  102. "agg" : "sum"
  103. }
  104. ],
  105. "timestamp" : [
  106. {
  107. "agg" : "date_histogram",
  108. "time_zone" : "UTC",
  109. "fixed_interval" : "1h",
  110. "delay": "7d"
  111. }
  112. ],
  113. "voltage" : [
  114. {
  115. "agg" : "avg"
  116. }
  117. ]
  118. }
  119. }
  120. ]
  121. }
  122. }
  123. ----
  124. The response that is returned contains information that is similar to the
  125. original rollup configuration, but formatted differently. First, there are some
  126. house-keeping details: the {rollup-job} ID, the index that holds the rolled data,
  127. the index pattern that the job was targeting.
  128. Next it shows a list of fields that contain data eligible for rollup searches.
  129. Here we see four fields: `node`, `temperature`, `timestamp` and `voltage`. Each
  130. of these fields list the aggregations that are possible. For example, you can
  131. use a min, max, or sum aggregation on the `temperature` field, but only a
  132. `date_histogram` on `timestamp`.
  133. Note that the `rollup_jobs` element is an array; there can be multiple,
  134. independent jobs configured for a single index or index pattern. Each of these
  135. jobs may have different configurations, so the API returns a list of all the
  136. various configurations available.
  137. Like other APIs that interact with indices, you can specify index patterns
  138. instead of explicit indices:
  139. [source,console]
  140. --------------------------------------------------
  141. GET /*_rollup/_rollup/data
  142. --------------------------------------------------
  143. // TEST[continued]