1
0

rollup-index-caps.asciidoc 4.7 KB

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