diff --git a/docs/reference/administering/backup-and-restore-security-config.asciidoc b/docs/reference/administering/backup-and-restore-security-config.asciidoc index 847557db48610..6b9ad8cd07e3a 100644 --- a/docs/reference/administering/backup-and-restore-security-config.asciidoc +++ b/docs/reference/administering/backup-and-restore-security-config.asciidoc @@ -75,7 +75,7 @@ It is preferable to have a <> for this special index. If you wish, you can also snapshot the system indices for other {stack} components to this repository. + -- -[source,js] +[source,console] ----------------------------------- PUT /_snapshot/my_backup { @@ -85,7 +85,6 @@ PUT /_snapshot/my_backup } } ----------------------------------- -// CONSOLE The user calling this API must have the elevated `manage` cluster privilege to prevent non-administrators exfiltrating data. @@ -99,7 +98,7 @@ The following example creates a new user `snapshot_user` in the {stack-ov}/native-realm.html[native realm], but it is not important which realm the user is a member of: -[source,js] +[source,console] -------------------------------------------------- POST /_security/user/snapshot_user { @@ -107,7 +106,6 @@ POST /_security/user/snapshot_user "roles" : [ "snapshot_user" ] } -------------------------------------------------- -// CONSOLE // TEST[skip:security is not enabled in this fixture] -- @@ -118,7 +116,7 @@ POST /_security/user/snapshot_user The following example shows how to use the create snapshot API to backup the `.security` index to the `my_backup` repository: -[source,js] +[source,console] -------------------------------------------------- PUT /_snapshot/my_backup/snapshot_1 { @@ -126,7 +124,6 @@ PUT /_snapshot/my_backup/snapshot_1 "include_global_state": true <1> } -------------------------------------------------- -// CONSOLE // TEST[continued] <1> This parameter value captures all the persistent settings stored in the @@ -189,18 +186,16 @@ the {security-features}. To restore your security configuration from a backup, first make sure that the repository holding `.security` snapshots is installed: -[source,js] +[source,console] -------------------------------------------------- GET /_snapshot/my_backup -------------------------------------------------- -// CONSOLE // TEST[continued] -[source,js] +[source,console] -------------------------------------------------- GET /_snapshot/my_backup/snapshot_1 -------------------------------------------------- -// CONSOLE // TEST[continued] Then log into one of the node hosts, navigate to {es} installation directory, diff --git a/docs/reference/aggregations/bucket/adjacency-matrix-aggregation.asciidoc b/docs/reference/aggregations/bucket/adjacency-matrix-aggregation.asciidoc index 5cd67877460bf..8ed900a24fa00 100644 --- a/docs/reference/aggregations/bucket/adjacency-matrix-aggregation.asciidoc +++ b/docs/reference/aggregations/bucket/adjacency-matrix-aggregation.asciidoc @@ -28,7 +28,7 @@ other than the default of the ampersand. Example: -[source,js] +[source,console] -------------------------------------------------- PUT /emails/_bulk?refresh { "index" : { "_id" : 1 } } @@ -54,7 +54,6 @@ GET emails/_search } } -------------------------------------------------- -// CONSOLE In the above example, we analyse email messages to see which groups of individuals have exchanged messages. diff --git a/docs/reference/aggregations/bucket/autodatehistogram-aggregation.asciidoc b/docs/reference/aggregations/bucket/autodatehistogram-aggregation.asciidoc index c09d1a67bf253..575a3e75894c0 100644 --- a/docs/reference/aggregations/bucket/autodatehistogram-aggregation.asciidoc +++ b/docs/reference/aggregations/bucket/autodatehistogram-aggregation.asciidoc @@ -10,7 +10,7 @@ The buckets field is optional, and will default to 10 buckets if not specified. Requesting a target of 10 buckets. -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -24,7 +24,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] ==== Keys @@ -37,7 +36,7 @@ date string using the format specified with the `format` parameter: TIP: If no `format` is specified, then it will use the first date <> specified in the field mapping. -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -52,7 +51,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] <1> Supports expressive date <> @@ -119,7 +117,7 @@ Time zones may either be specified as an ISO 8601 UTC offset (e.g. `+01:00` or Consider the following example: -[source,js] +[source,console] --------------------------------- PUT my_index/log/1?refresh { @@ -148,7 +146,6 @@ GET my_index/_search?size=0 } } --------------------------------- -// CONSOLE UTC is used if no time zone is specified, three 1-hour buckets are returned starting at midnight UTC on 1 October 2015: @@ -186,7 +183,7 @@ starting at midnight UTC on 1 October 2015: If a `time_zone` of `-01:00` is specified, then midnight starts at one hour before midnight UTC: -[source,js] +[source,console] --------------------------------- GET my_index/_search?size=0 { @@ -201,7 +198,6 @@ GET my_index/_search?size=0 } } --------------------------------- -// CONSOLE // TEST[continued] @@ -273,7 +269,7 @@ The accepted units for `minimum_interval` are: * minute * second -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -288,7 +284,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] ==== Missing value @@ -297,7 +292,7 @@ The `missing` parameter defines how documents that are missing a value should be By default they will be ignored but it is also possible to treat them as if they had a value. -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -312,7 +307,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] <1> Documents without a value in the `publish_date` field will fall into the same bucket as documents that have the value `2000-01-01`. diff --git a/docs/reference/aggregations/bucket/children-aggregation.asciidoc b/docs/reference/aggregations/bucket/children-aggregation.asciidoc index d5ac6b5e09d14..67d75c39448bf 100644 --- a/docs/reference/aggregations/bucket/children-aggregation.asciidoc +++ b/docs/reference/aggregations/bucket/children-aggregation.asciidoc @@ -9,7 +9,7 @@ This aggregation has a single option: For example, let's say we have an index of questions and answers. The answer type has the following `join` field in the mapping: -[source,js] +[source,console] -------------------------------------------------- PUT child_example { @@ -25,7 +25,6 @@ PUT child_example } } -------------------------------------------------- -// CONSOLE The `question` document contain a tag field and the `answer` documents contain an owner field. With the `children` aggregation the tag buckets can be mapped to the owner buckets in a single request even though the two fields exist in @@ -33,7 +32,7 @@ two different kinds of documents. An example of a question document: -[source,js] +[source,console] -------------------------------------------------- PUT child_example/_doc/1 { @@ -49,12 +48,11 @@ PUT child_example/_doc/1 ] } -------------------------------------------------- -// CONSOLE // TEST[continued] Examples of `answer` documents: -[source,js] +[source,console] -------------------------------------------------- PUT child_example/_doc/2?routing=1 { @@ -86,12 +84,11 @@ PUT child_example/_doc/3?routing=1&refresh "creation_date": "2009-05-05T13:45:37.030" } -------------------------------------------------- -// CONSOLE // TEST[continued] The following request can be built that connects the two together: -[source,js] +[source,console] -------------------------------------------------- POST child_example/_search?size=0 { @@ -120,7 +117,6 @@ POST child_example/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[continued] <1> The `type` points to type / mapping with the name `answer`. diff --git a/docs/reference/aggregations/bucket/composite-aggregation.asciidoc b/docs/reference/aggregations/bucket/composite-aggregation.asciidoc index 44a0ac79929c1..2c50c844940fa 100644 --- a/docs/reference/aggregations/bucket/composite-aggregation.asciidoc +++ b/docs/reference/aggregations/bucket/composite-aggregation.asciidoc @@ -112,7 +112,7 @@ The values are extracted from a field or a script exactly like the `terms` aggre Example: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -127,11 +127,10 @@ GET /_search } } -------------------------------------------------- -// CONSOLE Like the `terms` aggregation it is also possible to use a script to create the values for the composite buckets: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -155,7 +154,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE ===== Histogram @@ -166,7 +164,7 @@ a value of `101` would be translated to `100` which is the key for the interval Example: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -181,11 +179,10 @@ GET /_search } } -------------------------------------------------- -// CONSOLE The values are built from a numeric field or a script that return numerical values: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -210,7 +207,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE ===== Date Histogram @@ -218,7 +214,7 @@ GET /_search The `date_histogram` is similar to the `histogram` value source except that the interval is specified by date/time expression: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -233,7 +229,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE The example above creates an interval per day and translates all `timestamp` values to the start of its closest intervals. Available expressions for interval: `year`, `quarter`, `month`, `week`, `day`, `hour`, `minute`, `second` @@ -248,7 +243,7 @@ Internally, a date is represented as a 64 bit number representing a timestamp in These timestamps are returned as the bucket keys. It is possible to return a formatted date string instead using the format specified with the format parameter: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -271,7 +266,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE <1> Supports expressive date <> @@ -291,7 +285,7 @@ The `sources` parameter accepts an array of values source. It is possible to mix different values source to create composite buckets. For example: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -307,14 +301,13 @@ GET /_search } } -------------------------------------------------- -// CONSOLE This will create composite buckets from the values created by two values source, a `date_histogram` and a `terms`. Each bucket is composed of two values, one for each value source defined in the aggregation. Any type of combinations is allowed and the order in the array is preserved in the composite buckets. -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -331,7 +324,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE ==== Order @@ -344,7 +336,7 @@ It is possible to define the direction of the sort for each value source by sett or `desc` (descending order) directly in the value source definition. For example: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -360,7 +352,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE \... will sort the composite bucket in descending order when comparing values from the `date_histogram` source and in ascending order when comparing values from the `terms` source. @@ -371,7 +362,7 @@ By default documents without a value for a given source are ignored. It is possible to include them in the response by setting `missing_bucket` to `true` (defaults to `false`): -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -386,7 +377,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE In the example above the source `product_name` will emit an explicit `null` value for documents without a value for the field `product`. @@ -411,7 +401,7 @@ If all composite buckets should be retrieved it is preferable to use a small siz and then use the `after` parameter to retrieve the next results. For example: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -428,7 +418,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE // TEST[s/_search/_search\?filter_path=aggregations/] \... returns: @@ -477,7 +466,7 @@ the last composite buckets returned in a previous round. For the example below the last bucket can be found in `after_key` and the next round of result can be retrieved with: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -495,7 +484,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE <1> Should restrict the aggregation to buckets that sort **after** the provided values. @@ -507,7 +495,7 @@ parent aggregation. For instance the following example computes the average value of a field per composite bucket: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -528,7 +516,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE // TEST[s/_search/_search\?filter_path=aggregations/] \... returns: diff --git a/docs/reference/aggregations/bucket/datehistogram-aggregation.asciidoc b/docs/reference/aggregations/bucket/datehistogram-aggregation.asciidoc index 2ee9025b6ded8..b5633cecd0263 100644 --- a/docs/reference/aggregations/bucket/datehistogram-aggregation.asciidoc +++ b/docs/reference/aggregations/bucket/datehistogram-aggregation.asciidoc @@ -103,7 +103,7 @@ specified timezone, so that the date and time are the same at the start and end. ===== Calendar Interval Examples As an example, here is an aggregation requesting bucket intervals of a month in calendar time: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -117,13 +117,12 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] If you attempt to use multiples of calendar units, the aggregation will fail because only singular calendar units are supported: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -137,7 +136,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] // TEST[catch:bad_request] @@ -199,7 +197,7 @@ Defined as 24 hours (86,400,000 milliseconds) If we try to recreate the "month" `calendar_interval` from earlier, we can approximate that with 30 fixed days: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -213,12 +211,11 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] But if we try to use a calendar unit that is not supported, such as weeks, we'll get an exception: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -232,7 +229,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] // TEST[catch:bad_request] @@ -290,7 +286,7 @@ date string using the `format` parameter specification: TIP: If you don't specify `format`, the first date <> specified in the field mapping is used. -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -305,7 +301,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] <1> Supports expressive date <> @@ -353,7 +348,7 @@ such as`America/Los_Angeles`. Consider the following example: -[source,js] +[source,console] --------------------------------- PUT my_index/_doc/1?refresh { @@ -377,7 +372,6 @@ GET my_index/_search?size=0 } } --------------------------------- -// CONSOLE If you don't specify a timezone, UTC is used. This would result in both of these documents being placed into the same day bucket, which starts at midnight UTC @@ -405,7 +399,7 @@ on 1 October 2015: If you specify a `time_zone` of `-01:00`, midnight in that timezone is one hour before midnight UTC: -[source,js] +[source,console] --------------------------------- GET my_index/_search?size=0 { @@ -420,7 +414,6 @@ GET my_index/_search?size=0 } } --------------------------------- -// CONSOLE // TEST[continued] Now the first document falls into the bucket for 30 September 2015, while the @@ -474,7 +467,7 @@ For example, when using an interval of `day`, each bucket runs from midnight to midnight. Setting the `offset` parameter to `+6h` changes each bucket to run from 6am to 6am: -[source,js] +[source,console] ----------------------------- PUT my_index/_doc/1?refresh { @@ -499,7 +492,6 @@ GET my_index/_search?size=0 } } ----------------------------- -// CONSOLE Instead of a single bucket starting at midnight, the above request groups the documents into buckets starting at 6am: @@ -536,7 +528,7 @@ adjustments have been made. Setting the `keyed` flag to `true` associates a unique string key with each bucket and returns the ranges as a hash rather than an array: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -552,7 +544,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] Response: @@ -606,7 +597,7 @@ The `missing` parameter defines how to treat documents that are missing a value. By default, they are ignored, but it is also possible to treat them as if they have a value. -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -621,7 +612,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] <1> Documents without a value in the `publish_date` field will fall into the @@ -640,7 +630,7 @@ When you need to aggregate the results by day of the week, use a script that returns the day of the week: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -656,7 +646,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] Response: diff --git a/docs/reference/aggregations/bucket/daterange-aggregation.asciidoc b/docs/reference/aggregations/bucket/daterange-aggregation.asciidoc index 828bafb8fb6e3..c116bfcc785a4 100644 --- a/docs/reference/aggregations/bucket/daterange-aggregation.asciidoc +++ b/docs/reference/aggregations/bucket/daterange-aggregation.asciidoc @@ -12,7 +12,7 @@ for each range. Example: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -30,7 +30,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales s/now-10M\/M/10-2015/] <1> < now minus 10 months, rounded down to the start of the month. @@ -75,7 +74,7 @@ be treated. By default they will be ignored but it is also possible to treat them as if they had a value. This is done by adding a set of fieldname : value mappings to specify default values per field. -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -100,7 +99,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] <1> Documents without a value in the `date` field will be added to the "Older" @@ -267,7 +265,7 @@ The `time_zone` parameter is also applied to rounding in date math expressions. As an example, to round to the beginning of the day in the CET time zone, you can do the following: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -286,7 +284,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] <1> This date will be converted to `2016-02-01T00:00:00.000+01:00`. @@ -297,7 +294,7 @@ POST /sales/_search?size=0 Setting the `keyed` flag to `true` will associate a unique string key with each bucket and return the ranges as a hash rather than an array: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -316,7 +313,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales s/now-10M\/M/10-2015/] Response: @@ -347,7 +343,7 @@ Response: It is also possible to customize the key for each range: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -366,7 +362,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] Response: diff --git a/docs/reference/aggregations/bucket/diversified-sampler-aggregation.asciidoc b/docs/reference/aggregations/bucket/diversified-sampler-aggregation.asciidoc index edd6c6163da85..7c825eebc6461 100644 --- a/docs/reference/aggregations/bucket/diversified-sampler-aggregation.asciidoc +++ b/docs/reference/aggregations/bucket/diversified-sampler-aggregation.asciidoc @@ -26,7 +26,7 @@ Example: We might want to see which tags are strongly associated with `#elasticsearch` on StackOverflow forum posts but ignoring the effects of some prolific users with a tendency to misspell #Kibana as #Cabana. -[source,js] +[source,console] -------------------------------------------------- POST /stackoverflow/_search?size=0 { @@ -53,7 +53,6 @@ POST /stackoverflow/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:stackoverflow] Response: @@ -92,7 +91,7 @@ Response: In this scenario we might want to diversify on a combination of field values. We can use a `script` to produce a hash of the multiple values in a tags field to ensure we don't have a sample that consists of the same repeated combinations of tags. -[source,js] +[source,console] -------------------------------------------------- POST /stackoverflow/_search?size=0 { @@ -123,7 +122,6 @@ POST /stackoverflow/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:stackoverflow] Response: diff --git a/docs/reference/aggregations/bucket/filter-aggregation.asciidoc b/docs/reference/aggregations/bucket/filter-aggregation.asciidoc index bff4096e2dd3a..d65b1851a947f 100644 --- a/docs/reference/aggregations/bucket/filter-aggregation.asciidoc +++ b/docs/reference/aggregations/bucket/filter-aggregation.asciidoc @@ -5,7 +5,7 @@ Defines a single bucket of all the documents in the current document set context Example: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -19,7 +19,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] In the above example, we calculate the average price of all the products that are of type t-shirt. diff --git a/docs/reference/aggregations/bucket/filters-aggregation.asciidoc b/docs/reference/aggregations/bucket/filters-aggregation.asciidoc index 4e83c14a18ba7..0e7b11a010c42 100644 --- a/docs/reference/aggregations/bucket/filters-aggregation.asciidoc +++ b/docs/reference/aggregations/bucket/filters-aggregation.asciidoc @@ -7,7 +7,7 @@ filter. Example: -[source,js] +[source,console] -------------------------------------------------- PUT /logs/_bulk?refresh { "index" : { "_id" : 1 } } @@ -32,7 +32,6 @@ GET logs/_search } } -------------------------------------------------- -// CONSOLE In the above example, we analyze log messages. The aggregation will build two collection (buckets) of log messages - one for all those containing an error, @@ -70,7 +69,7 @@ Response: The filters field can also be provided as an array of filters, as in the following request: -[source,js] +[source,console] -------------------------------------------------- GET logs/_search { @@ -87,7 +86,6 @@ GET logs/_search } } -------------------------------------------------- -// CONSOLE // TEST[continued] The filtered buckets are returned in the same order as provided in the @@ -133,7 +131,7 @@ this parameter will implicitly set the `other_bucket` parameter to `true`. The following snippet shows a response where the `other` bucket is requested to be named `other_messages`. -[source,js] +[source,console] -------------------------------------------------- PUT logs/_doc/4?refresh { @@ -156,7 +154,6 @@ GET logs/_search } } -------------------------------------------------- -// CONSOLE // TEST[continued] The response would be something like the following: diff --git a/docs/reference/aggregations/bucket/geodistance-aggregation.asciidoc b/docs/reference/aggregations/bucket/geodistance-aggregation.asciidoc index 21886686b67ac..82838808a3e01 100644 --- a/docs/reference/aggregations/bucket/geodistance-aggregation.asciidoc +++ b/docs/reference/aggregations/bucket/geodistance-aggregation.asciidoc @@ -3,7 +3,7 @@ A multi-bucket aggregation that works on `geo_point` fields and conceptually works very similar to the <> aggregation. The user can define a point of origin and a set of distance range buckets. The aggregation evaluate the distance of each document value from the origin point and determines the buckets it belongs to based on the ranges (a document belongs to a bucket if the distance between the document and the origin falls within the distance range of the bucket). -[source,js] +[source,console] -------------------------------------------------- PUT /museums { @@ -47,7 +47,6 @@ POST /museums/_search?size=0 } } -------------------------------------------------- -// CONSOLE Response: @@ -90,7 +89,7 @@ The specified field must be of type `geo_point` (which can only be set explicitl By default, the distance unit is `m` (meters) but it can also accept: `mi` (miles), `in` (inches), `yd` (yards), `km` (kilometers), `cm` (centimeters), `mm` (millimeters). -[source,js] +[source,console] -------------------------------------------------- POST /museums/_search?size=0 { @@ -110,14 +109,13 @@ POST /museums/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[continued] <1> The distances will be computed in kilometers There are two distance calculation modes: `arc` (the default), and `plane`. The `arc` calculation is the most accurate. The `plane` is the fastest but least accurate. Consider using `plane` when your search context is "narrow", and spans smaller geographical areas (~5km). `plane` will return higher error margins for searches across very large areas (e.g. cross continent search). The distance calculation type can be set using the `distance_type` parameter: -[source,js] +[source,console] -------------------------------------------------- POST /museums/_search?size=0 { @@ -138,14 +136,13 @@ POST /museums/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[continued] ==== Keyed Response Setting the `keyed` flag to `true` will associate a unique string key with each bucket and return the ranges as a hash rather than an array: -[source,js] +[source,console] -------------------------------------------------- POST /museums/_search?size=0 { @@ -165,7 +162,6 @@ POST /museums/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[continued] Response: @@ -200,7 +196,7 @@ Response: It is also possible to customize the key for each range: -[source,js] +[source,console] -------------------------------------------------- POST /museums/_search?size=0 { @@ -220,7 +216,6 @@ POST /museums/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[continued] Response: diff --git a/docs/reference/aggregations/bucket/geohashgrid-aggregation.asciidoc b/docs/reference/aggregations/bucket/geohashgrid-aggregation.asciidoc index d956ef4bfdc9a..3c84f65492992 100644 --- a/docs/reference/aggregations/bucket/geohashgrid-aggregation.asciidoc +++ b/docs/reference/aggregations/bucket/geohashgrid-aggregation.asciidoc @@ -17,7 +17,7 @@ The specified field must be of type `geo_point` (which can only be set explicitl ==== Simple low-precision request -[source,js] +[source,console] -------------------------------------------------- PUT /museums { @@ -56,7 +56,6 @@ POST /museums/_search?size=0 } } -------------------------------------------------- -// CONSOLE Response: @@ -90,7 +89,7 @@ Response: When requesting detailed buckets (typically for displaying a "zoomed in" map) a filter like <> should be applied to narrow the subject area otherwise potentially millions of buckets will be created and returned. -[source,js] +[source,console] -------------------------------------------------- POST /museums/_search?size=0 { @@ -116,13 +115,12 @@ POST /museums/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[continued] The geohashes returned by the `geohash_grid` aggregation can be also used for zooming in. To zoom into the first geohash `u17` returned in the previous example, it should be specified as both `top_left` and `bottom_right` corner: -[source,js] +[source,console] -------------------------------------------------- POST /museums/_search?size=0 { @@ -148,7 +146,6 @@ POST /museums/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[continued] [source,js] diff --git a/docs/reference/aggregations/bucket/geotilegrid-aggregation.asciidoc b/docs/reference/aggregations/bucket/geotilegrid-aggregation.asciidoc index ac173ec2b002f..43ca6b0176b14 100644 --- a/docs/reference/aggregations/bucket/geotilegrid-aggregation.asciidoc +++ b/docs/reference/aggregations/bucket/geotilegrid-aggregation.asciidoc @@ -30,7 +30,7 @@ fields, in which case all points will be taken into account during aggregation. ==== Simple low-precision request -[source,js] +[source,console] -------------------------------------------------- PUT /museums { @@ -69,7 +69,6 @@ POST /museums/_search?size=0 } } -------------------------------------------------- -// CONSOLE Response: @@ -106,7 +105,7 @@ a filter like <> should be applied to narrow the subject area otherwise potentially millions of buckets will be created and returned. -[source,js] +[source,console] -------------------------------------------------- POST /museums/_search?size=0 { @@ -132,7 +131,6 @@ POST /museums/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[continued] [source,js] diff --git a/docs/reference/aggregations/bucket/global-aggregation.asciidoc b/docs/reference/aggregations/bucket/global-aggregation.asciidoc index affabc5067e66..9a17b7755d67b 100644 --- a/docs/reference/aggregations/bucket/global-aggregation.asciidoc +++ b/docs/reference/aggregations/bucket/global-aggregation.asciidoc @@ -11,7 +11,7 @@ NOTE: Global aggregators can only be placed as top level aggregators because Example: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -29,7 +29,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] <1> The `global` aggregation has an empty body diff --git a/docs/reference/aggregations/bucket/histogram-aggregation.asciidoc b/docs/reference/aggregations/bucket/histogram-aggregation.asciidoc index 32a540130ef35..33dcecb450ade 100644 --- a/docs/reference/aggregations/bucket/histogram-aggregation.asciidoc +++ b/docs/reference/aggregations/bucket/histogram-aggregation.asciidoc @@ -19,7 +19,7 @@ The `interval` must be a positive decimal, while the `offset` must be a decimal The following snippet "buckets" the products based on their `price` by interval of `50`: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -33,7 +33,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] And the following may be the response: @@ -78,7 +77,7 @@ The response above show that no documents has a price that falls within the rang response will fill gaps in the histogram with empty buckets. It is possible change that and request buckets with a higher minimum count thanks to the `min_doc_count` setting: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -93,7 +92,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] Response: @@ -154,7 +152,7 @@ under a range `filter` aggregation with the appropriate `from`/`to` settings. Example: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -175,7 +173,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] ==== Order @@ -199,7 +196,7 @@ documents. By default, the buckets are returned as an ordered array. It is also possible to request the response as a hash instead keyed by the buckets keys: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -214,7 +211,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] Response: @@ -259,7 +255,7 @@ The `missing` parameter defines how documents that are missing a value should be By default they will be ignored but it is also possible to treat them as if they had a value. -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -274,7 +270,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] <1> Documents without a value in the `quantity` field will fall into the same bucket as documents that have the value `0`. diff --git a/docs/reference/aggregations/bucket/iprange-aggregation.asciidoc b/docs/reference/aggregations/bucket/iprange-aggregation.asciidoc index 0aabd3a71ed30..67578af3694de 100644 --- a/docs/reference/aggregations/bucket/iprange-aggregation.asciidoc +++ b/docs/reference/aggregations/bucket/iprange-aggregation.asciidoc @@ -5,7 +5,7 @@ Just like the dedicated < Example: -[source,js] +[source,console] -------------------------------------------------- GET /ip_addresses/_search { @@ -23,7 +23,6 @@ GET /ip_addresses/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:iprange] Response: @@ -55,7 +54,7 @@ Response: IP ranges can also be defined as CIDR masks: -[source,js] +[source,console] -------------------------------------------------- GET /ip_addresses/_search { @@ -73,7 +72,6 @@ GET /ip_addresses/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:iprange] Response: @@ -109,7 +107,7 @@ Response: Setting the `keyed` flag to `true` will associate a unique string key with each bucket and return the ranges as a hash rather than an array: -[source,js] +[source,console] -------------------------------------------------- GET /ip_addresses/_search { @@ -128,7 +126,6 @@ GET /ip_addresses/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:iprange] Response: @@ -158,7 +155,7 @@ Response: It is also possible to customize the key for each range: -[source,js] +[source,console] -------------------------------------------------- GET /ip_addresses/_search { @@ -177,7 +174,6 @@ GET /ip_addresses/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:iprange] Response: diff --git a/docs/reference/aggregations/bucket/missing-aggregation.asciidoc b/docs/reference/aggregations/bucket/missing-aggregation.asciidoc index b670529119673..e37b73ed97af9 100644 --- a/docs/reference/aggregations/bucket/missing-aggregation.asciidoc +++ b/docs/reference/aggregations/bucket/missing-aggregation.asciidoc @@ -5,7 +5,7 @@ A field data based single bucket aggregation, that creates a bucket of all docum Example: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -16,7 +16,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] In the above example, we get the total number of products that do not have a price. diff --git a/docs/reference/aggregations/bucket/nested-aggregation.asciidoc b/docs/reference/aggregations/bucket/nested-aggregation.asciidoc index d323eb1c134ee..329b937bbc35c 100644 --- a/docs/reference/aggregations/bucket/nested-aggregation.asciidoc +++ b/docs/reference/aggregations/bucket/nested-aggregation.asciidoc @@ -6,7 +6,7 @@ A special single bucket aggregation that enables aggregating nested documents. For example, lets say we have an index of products, and each product holds the list of resellers - each having its own price for the product. The mapping could look like: -[source,js] +[source,console] -------------------------------------------------- PUT /index { @@ -23,13 +23,12 @@ PUT /index } } -------------------------------------------------- -// CONSOLE // TESTSETUP <1> The `resellers` is an array that holds nested documents under the `product` object. The following aggregations will return the minimum price products can be purchased in: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -48,7 +47,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE // TEST[s/GET \/_search/GET \/_search\?filter_path=aggregations/] // TEST[s/^/PUT index\/_doc\/0\?refresh\n{"name":"led", "resellers": [{"name": "foo", "price": 350.00}, {"name": "bar", "price": 500.00}]}\n/] diff --git a/docs/reference/aggregations/bucket/parent-aggregation.asciidoc b/docs/reference/aggregations/bucket/parent-aggregation.asciidoc index 37d98f8b9be3d..208c643b31a0f 100644 --- a/docs/reference/aggregations/bucket/parent-aggregation.asciidoc +++ b/docs/reference/aggregations/bucket/parent-aggregation.asciidoc @@ -9,7 +9,7 @@ This aggregation has a single option: For example, let's say we have an index of questions and answers. The answer type has the following `join` field in the mapping: -[source,js] +[source,console] -------------------------------------------------- PUT parent_example { @@ -25,7 +25,6 @@ PUT parent_example } } -------------------------------------------------- -// CONSOLE The `question` document contain a tag field and the `answer` documents contain an owner field. With the `parent` aggregation the owner buckets can be mapped to the tag buckets in a single request even though the two fields exist in @@ -33,7 +32,7 @@ two different kinds of documents. An example of a question document: -[source,js] +[source,console] -------------------------------------------------- PUT parent_example/_doc/1 { @@ -49,12 +48,11 @@ PUT parent_example/_doc/1 ] } -------------------------------------------------- -// CONSOLE // TEST[continued] Examples of `answer` documents: -[source,js] +[source,console] -------------------------------------------------- PUT parent_example/_doc/2?routing=1 { @@ -86,12 +84,11 @@ PUT parent_example/_doc/3?routing=1&refresh "creation_date": "2009-05-05T13:45:37.030" } -------------------------------------------------- -// CONSOLE // TEST[continued] The following request can be built that connects the two together: -[source,js] +[source,console] -------------------------------------------------- POST parent_example/_search?size=0 { @@ -120,7 +117,6 @@ POST parent_example/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[continued] <1> The `type` points to type / mapping with the name `answer`. diff --git a/docs/reference/aggregations/bucket/range-aggregation.asciidoc b/docs/reference/aggregations/bucket/range-aggregation.asciidoc index 8ff26c7c92f5c..b27af0b3be5f4 100644 --- a/docs/reference/aggregations/bucket/range-aggregation.asciidoc +++ b/docs/reference/aggregations/bucket/range-aggregation.asciidoc @@ -6,7 +6,7 @@ Note that this aggregation includes the `from` value and excludes the `to` value Example: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -24,7 +24,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] // TEST[s/GET \/_search/GET \/_search\?filter_path=aggregations/] @@ -64,7 +63,7 @@ Response: Setting the `keyed` flag to `true` will associate a unique string key with each bucket and return the ranges as a hash rather than an array: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -83,7 +82,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] // TEST[s/GET \/_search/GET \/_search\?filter_path=aggregations/] @@ -118,7 +116,7 @@ Response: It is also possible to customize the key for each range: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -137,7 +135,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] // TEST[s/GET \/_search/GET \/_search\?filter_path=aggregations/] @@ -177,7 +174,7 @@ will be executed during aggregation execution. The following example shows how to use an `inline` script with the `painless` script language and no script parameters: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -198,11 +195,10 @@ GET /_search } } -------------------------------------------------- -// CONSOLE It is also possible to use stored scripts. Here is a simple stored script: -[source,js] +[source,console] -------------------------------------------------- POST /_scripts/convert_currency { @@ -212,12 +208,11 @@ POST /_scripts/convert_currency } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] And this new stored script can be used in the range aggregation like this: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -240,7 +235,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE // TEST[s/GET \/_search/GET \/_search\?filter_path=aggregations/] // TEST[continued] <1> Id of the stored script @@ -278,7 +272,7 @@ GET /_search Lets say the product prices are in USD but we would like to get the price ranges in EURO. We can use value script to convert the prices prior the aggregation (assuming conversion rate of 0.8) -[source,js] +[source,console] -------------------------------------------------- GET /sales/_search { @@ -302,14 +296,13 @@ GET /sales/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] ==== Sub Aggregations The following example, not only "bucket" the documents to the different buckets but also computes statistics over the prices in each price range -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -332,7 +325,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] // TEST[s/GET \/_search/GET \/_search\?filter_path=aggregations/] @@ -391,7 +383,7 @@ Response: If a sub aggregation is also based on the same value source as the range aggregation (like the `stats` aggregation in the example above) it is possible to leave out the value source definition for it. The following will return the same response as above: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -414,5 +406,4 @@ GET /_search } } -------------------------------------------------- -// CONSOLE <1> We don't need to specify the `price` as we "inherit" it by default from the parent `range` aggregation diff --git a/docs/reference/aggregations/bucket/rare-terms-aggregation.asciidoc b/docs/reference/aggregations/bucket/rare-terms-aggregation.asciidoc index e2537b61aefda..7757883a40fe9 100644 --- a/docs/reference/aggregations/bucket/rare-terms-aggregation.asciidoc +++ b/docs/reference/aggregations/bucket/rare-terms-aggregation.asciidoc @@ -85,7 +85,7 @@ better approximation, but higher memory usage. Cannot be smaller than `0.00001` Example: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -98,7 +98,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE // TEST[s/_search/_search\?filter_path=aggregations/] Response: @@ -124,7 +123,7 @@ Response: In this example, the only bucket that we see is the "swing" bucket, because it is the only term that appears in one document. If we increase the `max_doc_count` to `2`, we'll see some more buckets: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -138,7 +137,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE // TEST[s/_search/_search\?filter_path=aggregations/] This now shows the "jazz" term which has a `doc_count` of 2": @@ -275,7 +273,7 @@ It is possible to filter the values for which buckets will be created. This can ===== Filtering Values with regular expressions -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -290,7 +288,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE In the above example, buckets will be created for all the tags that starts with `swi`, except those starting with `electro` (so the tag `swing` will be aggregated but not `electro_swing`). The `include` regular expression will determine what @@ -304,7 +301,7 @@ The syntax is the same as <>. For matching based on exact values the `include` and `exclude` parameters can simply take an array of strings that represent the terms as they are found in the index: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -319,7 +316,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE ==== Missing value @@ -328,7 +324,7 @@ The `missing` parameter defines how documents that are missing a value should be By default they will be ignored but it is also possible to treat them as if they had a value. -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -342,7 +338,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE <1> Documents without a value in the `tags` field will fall into the same bucket as documents that have the value `N/A`. diff --git a/docs/reference/aggregations/bucket/reverse-nested-aggregation.asciidoc b/docs/reference/aggregations/bucket/reverse-nested-aggregation.asciidoc index f922d90331fd0..8e3b65bfe71e1 100644 --- a/docs/reference/aggregations/bucket/reverse-nested-aggregation.asciidoc +++ b/docs/reference/aggregations/bucket/reverse-nested-aggregation.asciidoc @@ -15,7 +15,7 @@ a nested object field that falls outside the `nested` aggregation's nested struc For example, lets say we have an index for a ticket system with issues and comments. The comments are inlined into the issue documents as nested documents. The mapping could look like: -[source,js] +[source,console] -------------------------------------------------- PUT /issues { @@ -33,7 +33,7 @@ PUT /issues } } -------------------------------------------------- -// CONSOLE + <1> The `comments` is an array that holds nested documents under the `issue` object. The following aggregations will return the top commenters' username that have commented and per top commenter the top @@ -41,17 +41,16 @@ tags of the issues the user has commented on: ////////////////////////// -[source,js] +[source,console] -------------------------------------------------- POST /issues/_doc/0?refresh {"tags": ["tag_1"], "comments": [{"username": "username_1"}]} -------------------------------------------------- -// CONSOLE // TEST[continued] ////////////////////////// -[source,js] +[source,console] -------------------------------------------------- GET /issues/_search { @@ -86,7 +85,6 @@ GET /issues/_search } } -------------------------------------------------- -// CONSOLE // TEST[continued] // TEST[s/_search/_search\?filter_path=aggregations/] diff --git a/docs/reference/aggregations/bucket/sampler-aggregation.asciidoc b/docs/reference/aggregations/bucket/sampler-aggregation.asciidoc index d3a255be1d5fe..4a6c7bf8c7cc5 100644 --- a/docs/reference/aggregations/bucket/sampler-aggregation.asciidoc +++ b/docs/reference/aggregations/bucket/sampler-aggregation.asciidoc @@ -15,7 +15,7 @@ A query on StackOverflow data for the popular term `javascript` OR the rarer ter the `significant_terms` aggregation on top-scoring documents that are more likely to match the most interesting parts of our query we use a sample. -[source,js] +[source,console] -------------------------------------------------- POST /stackoverflow/_search?size=0 { @@ -41,7 +41,6 @@ POST /stackoverflow/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:stackoverflow] Response: @@ -85,7 +84,7 @@ Without the `sampler` aggregation the request query considers the full "long tai less significant terms such as `jquery` and `angular` rather than focusing on the more insightful Kibana-related terms. -[source,js] +[source,console] -------------------------------------------------- POST /stackoverflow/_search?size=0 { @@ -105,7 +104,6 @@ POST /stackoverflow/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:stackoverflow] Response: diff --git a/docs/reference/aggregations/bucket/significantterms-aggregation.asciidoc b/docs/reference/aggregations/bucket/significantterms-aggregation.asciidoc index 50c238edb93c5..11e0c28323bbc 100644 --- a/docs/reference/aggregations/bucket/significantterms-aggregation.asciidoc +++ b/docs/reference/aggregations/bucket/significantterms-aggregation.asciidoc @@ -64,7 +64,7 @@ set used for statistical comparisons is the index or indices from which the resu Example: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -78,12 +78,11 @@ GET /_search } } -------------------------------------------------- -// CONSOLE // TEST[s/_search/_search\?filter_path=aggregations/] Response: -[source,js] +[source,console] -------------------------------------------------- { ... @@ -125,7 +124,7 @@ A simpler way to perform analysis across multiple categories is to use a parent- Example using a parent aggregation for segmentation: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -141,7 +140,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE // TEST[s/_search/_search\?filter_path=aggregations/] Response: @@ -203,7 +201,7 @@ Now we have anomaly detection for each of the police forces using a single reque We can use other forms of top-level aggregations to segment our data, for example segmenting by geographic area to identify unusual hot-spots of a particular crime type: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -222,7 +220,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE This example uses the `geohash_grid` aggregation to create result buckets that represent geographic areas, and inside each bucket we can identify anomalous levels of a crime type in these tightly-focused areas e.g. @@ -464,7 +461,7 @@ NOTE: `shard_size` cannot be smaller than `size` (as it doesn't make much sens It is possible to only return terms that match more than a configured number of hits using the `min_doc_count` option: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -478,7 +475,7 @@ GET /_search } } -------------------------------------------------- -// CONSOLE + The above aggregation would only return tags which have been found in 10 hits or more. Default value is `3`. @@ -507,7 +504,7 @@ The default source of statistical information for background term frequencies is scope can be narrowed through the use of a `background_filter` to focus in on significant terms within a narrower context: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -528,7 +525,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE The above filter would help focus in on terms that were peculiar to the city of Madrid rather than revealing terms like "Spanish" that are unusual in the full index's worldwide context but commonplace in the subset of documents containing the @@ -566,7 +562,7 @@ is significantly faster. By default, `map` is only used when running an aggregat ordinals. -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -580,7 +576,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE <1> the possible values are `map`, `global_ordinals` diff --git a/docs/reference/aggregations/bucket/significanttext-aggregation.asciidoc b/docs/reference/aggregations/bucket/significanttext-aggregation.asciidoc index 3a9221c3c4372..95655f60ccbee 100644 --- a/docs/reference/aggregations/bucket/significanttext-aggregation.asciidoc +++ b/docs/reference/aggregations/bucket/significanttext-aggregation.asciidoc @@ -32,7 +32,7 @@ and the _background_set used for statistical comparisons is the index or indices Example: -[source,js] +[source,console] -------------------------------------------------- GET news/_search { @@ -53,7 +53,6 @@ GET news/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:news] @@ -147,7 +146,7 @@ The uncleansed documents have thrown up some odd-looking terms that are, on the correlated with appearances of our search term "elasticsearch" e.g. "pozmantier". We can drill down into examples of these documents to see why pozmantier is connected using this query: -[source,js] +[source,console] -------------------------------------------------- GET news/_search { @@ -167,8 +166,8 @@ GET news/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:news] + The results show a series of very similar news articles about a judging panel for a number of tech projects: [source,js] @@ -215,7 +214,7 @@ Fortunately similar documents tend to rank similarly so as part of examining the aggregation can apply a filter to remove sequences of any 6 or more tokens that have already been seen. Let's try this same query now but with the `filter_duplicate_text` setting turned on: -[source,js] +[source,console] -------------------------------------------------- GET news/_search { @@ -241,7 +240,6 @@ GET news/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:news] The results from analysing our deduplicated text are obviously of higher quality to anyone familiar with the elastic stack: @@ -418,7 +416,7 @@ The default source of statistical information for background term frequencies is scope can be narrowed through the use of a `background_filter` to focus in on significant terms within a narrower context: -[source,js] +[source,console] -------------------------------------------------- GET news/_search { @@ -439,7 +437,6 @@ GET news/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:news] The above filter would help focus in on terms that were peculiar to the city of Madrid rather than revealing @@ -457,7 +454,7 @@ JSON field(s) and the indexed field being aggregated can differ. In these cases it is possible to list the JSON _source fields from which text will be analyzed using the `source_fields` parameter: -[source,js] +[source,console] -------------------------------------------------- GET news/_search { @@ -476,7 +473,6 @@ GET news/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:news] diff --git a/docs/reference/aggregations/bucket/terms-aggregation.asciidoc b/docs/reference/aggregations/bucket/terms-aggregation.asciidoc index b40302b6120e9..763a7074ee718 100644 --- a/docs/reference/aggregations/bucket/terms-aggregation.asciidoc +++ b/docs/reference/aggregations/bucket/terms-aggregation.asciidoc @@ -53,7 +53,7 @@ POST /products/_bulk?refresh Example: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -64,8 +64,8 @@ GET /_search } } -------------------------------------------------- -// CONSOLE // TEST[s/_search/_search\?filter_path=aggregations/] + <1> `terms` aggregation should be a field of type `keyword` or any other data type suitable for bucket aggregations. In order to use it with `text` you will need to enable <>. @@ -130,7 +130,7 @@ combined to give a final view. Consider the following scenario: A request is made to obtain the top 5 terms in the field product, ordered by descending document count from an index with 3 shards. In this case each shard is asked to give its top 5 terms. -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -144,7 +144,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE // TEST[s/_search/_search\?filter_path=aggregations/] The terms for each of the three shards are shown below with their @@ -260,7 +259,7 @@ could have the 4th highest document count. The second error value can be enabled by setting the `show_term_doc_count_error` parameter to true: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -275,7 +274,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE // TEST[s/_search/_search\?filter_path=aggregations/] @@ -338,7 +336,7 @@ but at least the top buckets will be correctly picked. Ordering the buckets by their doc `_count` in an ascending manner: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -352,11 +350,10 @@ GET /_search } } -------------------------------------------------- -// CONSOLE Ordering the buckets alphabetically by their terms in an ascending manner: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -370,13 +367,12 @@ GET /_search } } -------------------------------------------------- -// CONSOLE deprecated[6.0.0, Use `_key` instead of `_term` to order buckets by their term] Ordering the buckets by single value metrics sub-aggregation (identified by the aggregation name): -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -393,11 +389,10 @@ GET /_search } } -------------------------------------------------- -// CONSOLE Ordering the buckets by multi value metrics sub-aggregation (identified by the aggregation name): -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -414,7 +409,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE [NOTE] .Pipeline aggs cannot be used for sorting @@ -444,7 +438,7 @@ METRIC = [ , ]* [ , ] ; -------------------------------------------------- -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -466,13 +460,12 @@ GET /_search } } -------------------------------------------------- -// CONSOLE The above will sort the artist's countries buckets based on the average play count among the rock songs. Multiple criteria can be used to order the buckets by providing an array of order criteria such as the following: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -494,7 +487,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE The above will sort the artist's countries buckets based on the average play count among the rock songs and then by their `doc_count` in descending order. @@ -506,7 +498,7 @@ tie-breaker in ascending alphabetical order to prevent non-deterministic orderin It is possible to only return terms that match more than a configured number of hits using the `min_doc_count` option: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -520,7 +512,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE The above aggregation would only return tags which have been found in 10 hits or more. Default value is `1`. @@ -548,7 +539,7 @@ WARNING: When NOT sorting on `doc_count` descending, high values of `min_doc_cou Generating the terms using a script: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -564,13 +555,12 @@ GET /_search } } -------------------------------------------------- -// CONSOLE This will interpret the `script` parameter as an `inline` script with the default script language and no script parameters. To use a stored script use the following syntax: ////////////////////////// -[source,js] +[source,console] -------------------------------------------------- POST /_scripts/my_script { @@ -580,11 +570,10 @@ POST /_scripts/my_script } } -------------------------------------------------- -// CONSOLE ////////////////////////// -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -602,12 +591,11 @@ GET /_search } } -------------------------------------------------- -// CONSOLE // TEST[continued] ==== Value Script -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -624,7 +612,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE ==== Filtering Values @@ -634,7 +621,7 @@ It is possible to filter the values for which buckets will be created. This can ===== Filtering Values with regular expressions -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -649,7 +636,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE In the above example, buckets will be created for all the tags that has the word `sport` in them, except those starting with `water_` (so the tag `water_sports` will not be aggregated). The `include` regular expression will determine what @@ -663,7 +649,7 @@ The syntax is the same as <>. For matching based on exact values the `include` and `exclude` parameters can simply take an array of strings that represent the terms as they are found in the index: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -683,7 +669,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE ===== Filtering Values with partitions @@ -693,7 +678,7 @@ This can be achieved by grouping the field's values into a number of partitions only one partition in each request. Consider this request which is looking for accounts that have not logged any access recently: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -722,7 +707,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE This request is finding the last logged access date for a subset of customer accounts because we might want to expire some customer accounts who haven't been seen for a long while. @@ -786,7 +770,7 @@ are expanded in one depth-first pass and only then any pruning occurs. In some scenarios this can be very wasteful and can hit memory constraints. An example problem scenario is querying a movie database for the 10 most popular actors and their 5 most common co-stars: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -808,7 +792,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE Even though the number of actors may be comparatively small and we want only 50 result buckets there is a combinatorial explosion of buckets during calculation - a single actor can produce n² buckets where n is the number of actors. The sane option would be to first determine @@ -818,7 +801,7 @@ mode as opposed to the `depth_first` mode. NOTE: The `breadth_first` is the default mode for fields with a cardinality bigger than the requested size or when the cardinality is unknown (numeric fields or scripts for instance). It is possible to override the default heuristic and to provide a collect mode directly in the request: -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -841,7 +824,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE <1> the possible values are `breadth_first` and `depth_first` @@ -870,7 +852,7 @@ so memory usage is linear to the number of values of the documents that are part is significantly faster. By default, `map` is only used when running an aggregation on scripts, since they don't have ordinals. -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -884,7 +866,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE <1> The possible values are `map`, `global_ordinals` @@ -896,7 +877,7 @@ The `missing` parameter defines how documents that are missing a value should be By default they will be ignored but it is also possible to treat them as if they had a value. -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -910,7 +891,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE <1> Documents without a value in the `tags` field will fall into the same bucket as documents that have the value `N/A`. diff --git a/docs/reference/aggregations/matrix/stats-aggregation.asciidoc b/docs/reference/aggregations/matrix/stats-aggregation.asciidoc index df5afc82523f8..ea1cd8063e6d1 100644 --- a/docs/reference/aggregations/matrix/stats-aggregation.asciidoc +++ b/docs/reference/aggregations/matrix/stats-aggregation.asciidoc @@ -35,7 +35,7 @@ POST /_refresh The following example demonstrates the use of matrix stats to describe the relationship between income and poverty. -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -48,7 +48,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE // TEST[s/_search/_search\?filter_path=aggregations/] The aggregation type is `matrix_stats` and the `fields` setting defines the set of fields (as an array) for computing @@ -119,7 +118,7 @@ The `missing` parameter defines how documents that are missing a value should be By default they will be ignored but it is also possible to treat them as if they had a value. This is done by adding a set of fieldname : value mappings to specify default values per field. -[source,js] +[source,console] -------------------------------------------------- GET /_search { @@ -133,7 +132,6 @@ GET /_search } } -------------------------------------------------- -// CONSOLE <1> Documents without a value in the `income` field will have the default value `50000`. diff --git a/docs/reference/aggregations/metrics/avg-aggregation.asciidoc b/docs/reference/aggregations/metrics/avg-aggregation.asciidoc index 0607dadf85729..ca7328859c970 100644 --- a/docs/reference/aggregations/metrics/avg-aggregation.asciidoc +++ b/docs/reference/aggregations/metrics/avg-aggregation.asciidoc @@ -6,7 +6,7 @@ A `single-value` metrics aggregation that computes the average of numeric values Assuming the data consists of documents representing exams grades (between 0 and 100) of students we can average their scores with: -[source,js] +[source,console] -------------------------------------------------- POST /exams/_search?size=0 { @@ -15,7 +15,6 @@ POST /exams/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:exams] The above aggregation computes the average grade over all documents. The aggregation type is `avg` and the `field` setting defines the numeric field of the documents the average will be computed on. The above will return the following: @@ -39,7 +38,7 @@ The name of the aggregation (`avg_grade` above) also serves as the key by which Computing the average grade based on a script: -[source,js] +[source,console] -------------------------------------------------- POST /exams/_search?size=0 { @@ -54,12 +53,11 @@ POST /exams/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:exams] This will interpret the `script` parameter as an `inline` script with the `painless` script language and no script parameters. To use a stored script use the following syntax: -[source,js] +[source,console] -------------------------------------------------- POST /exams/_search?size=0 { @@ -77,14 +75,13 @@ POST /exams/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:exams,stored_example_script] ===== Value Script It turned out that the exam was way above the level of the students and a grade correction needs to be applied. We can use value script to get the new average: -[source,js] +[source,console] -------------------------------------------------- POST /exams/_search?size=0 { @@ -104,7 +101,6 @@ POST /exams/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:exams] ==== Missing value @@ -113,7 +109,7 @@ The `missing` parameter defines how documents that are missing a value should be By default they will be ignored but it is also possible to treat them as if they had a value. -[source,js] +[source,console] -------------------------------------------------- POST /exams/_search?size=0 { @@ -127,7 +123,6 @@ POST /exams/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:exams] <1> Documents without a value in the `grade` field will fall into the same bucket as documents that have the value `10`. diff --git a/docs/reference/aggregations/metrics/cardinality-aggregation.asciidoc b/docs/reference/aggregations/metrics/cardinality-aggregation.asciidoc index 405a9d89107f2..534c69e704d96 100644 --- a/docs/reference/aggregations/metrics/cardinality-aggregation.asciidoc +++ b/docs/reference/aggregations/metrics/cardinality-aggregation.asciidoc @@ -7,7 +7,7 @@ document or generated by a script. Assume you are indexing store sales and would like to count the unique number of sold products that match a query: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -20,7 +20,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] Response: @@ -42,7 +41,7 @@ Response: This aggregation also supports the `precision_threshold` option: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -56,7 +55,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] <1> The `precision_threshold` options allows to trade memory for accuracy, and @@ -183,7 +181,7 @@ make sure that hashes are computed at most once per unique value per segment. The `cardinality` metric supports scripting, with a noticeable performance hit however since hashes need to be computed on the fly. -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -199,12 +197,11 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] This will interpret the `script` parameter as an `inline` script with the `painless` script language and no script parameters. To use a stored script use the following syntax: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -223,7 +220,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[skip:no script] ==== Missing value @@ -232,7 +228,7 @@ The `missing` parameter defines how documents that are missing a value should be By default they will be ignored but it is also possible to treat them as if they had a value. -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -246,6 +242,5 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] <1> Documents without a value in the `tag` field will fall into the same bucket as documents that have the value `N/A`. diff --git a/docs/reference/aggregations/metrics/extendedstats-aggregation.asciidoc b/docs/reference/aggregations/metrics/extendedstats-aggregation.asciidoc index 6eb2f18928a81..17a313202cb0f 100644 --- a/docs/reference/aggregations/metrics/extendedstats-aggregation.asciidoc +++ b/docs/reference/aggregations/metrics/extendedstats-aggregation.asciidoc @@ -7,7 +7,7 @@ The `extended_stats` aggregations is an extended version of the < `sigma` controls how many standard deviations +/- from the mean should be displayed @@ -89,7 +87,7 @@ if your data is skewed heavily left or right, the value returned will be mislead Computing the grades stats based on a script: -[source,js] +[source,console] -------------------------------------------------- GET /exams/_search { @@ -106,12 +104,11 @@ GET /exams/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:exams] This will interpret the `script` parameter as an `inline` script with the `painless` script language and no script parameters. To use a stored script use the following syntax: -[source,js] +[source,console] -------------------------------------------------- GET /exams/_search { @@ -130,14 +127,13 @@ GET /exams/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:exams,stored_example_script] ===== Value Script It turned out that the exam was way above the level of the students and a grade correction needs to be applied. We can use value script to get the new stats: -[source,js] +[source,console] -------------------------------------------------- GET /exams/_search { @@ -158,7 +154,6 @@ GET /exams/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:exams] ==== Missing value @@ -167,7 +162,7 @@ The `missing` parameter defines how documents that are missing a value should be By default they will be ignored but it is also possible to treat them as if they had a value. -[source,js] +[source,console] -------------------------------------------------- GET /exams/_search { @@ -182,7 +177,6 @@ GET /exams/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:exams] <1> Documents without a value in the `grade` field will fall into the same bucket as documents that have the value `0`. diff --git a/docs/reference/aggregations/metrics/geobounds-aggregation.asciidoc b/docs/reference/aggregations/metrics/geobounds-aggregation.asciidoc index 3859f1977ecbb..e012ae78159fe 100644 --- a/docs/reference/aggregations/metrics/geobounds-aggregation.asciidoc +++ b/docs/reference/aggregations/metrics/geobounds-aggregation.asciidoc @@ -6,7 +6,7 @@ A metric aggregation that computes the bounding box containing all geo_point val Example: -[source,js] +[source,console] -------------------------------------------------- PUT /museums { @@ -48,7 +48,6 @@ POST /museums/_search?size=0 } } -------------------------------------------------- -// CONSOLE <1> The `geo_bounds` aggregation specifies the field to use to obtain the bounds <2> `wrap_longitude` is an optional parameter which specifies whether the bounding box should be allowed to overlap the international date line. The default value is `true` diff --git a/docs/reference/aggregations/metrics/geocentroid-aggregation.asciidoc b/docs/reference/aggregations/metrics/geocentroid-aggregation.asciidoc index 9ce69a3dd395e..cd9b4acfe9679 100644 --- a/docs/reference/aggregations/metrics/geocentroid-aggregation.asciidoc +++ b/docs/reference/aggregations/metrics/geocentroid-aggregation.asciidoc @@ -5,7 +5,7 @@ A metric aggregation that computes the weighted https://en.wikipedia.org/wiki/Ce Example: -[source,js] +[source,console] -------------------------------------------------- PUT /museums { @@ -43,7 +43,6 @@ POST /museums/_search?size=0 } } -------------------------------------------------- -// CONSOLE <1> The `geo_centroid` aggregation specifies the field to use for computing the centroid. (NOTE: field must be a <> type) @@ -72,7 +71,7 @@ The `geo_centroid` aggregation is more interesting when combined as a sub-aggreg Example: -[source,js] +[source,console] -------------------------------------------------- POST /museums/_search?size=0 { @@ -88,7 +87,6 @@ POST /museums/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[continued] The above example uses `geo_centroid` as a sub-aggregation to a diff --git a/docs/reference/aggregations/metrics/max-aggregation.asciidoc b/docs/reference/aggregations/metrics/max-aggregation.asciidoc index cd9f4282e4d72..70731dbb51577 100644 --- a/docs/reference/aggregations/metrics/max-aggregation.asciidoc +++ b/docs/reference/aggregations/metrics/max-aggregation.asciidoc @@ -12,7 +12,7 @@ whose absolute value is greater than +2^53+. Computing the max price value across all documents -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -21,7 +21,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] Response: @@ -48,7 +47,7 @@ response. The `max` aggregation can also calculate the maximum of a script. The example below computes the maximum price: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search { @@ -63,13 +62,12 @@ POST /sales/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] This will use the <> scripting language and no script parameters. To use a stored script use the following syntax: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search { @@ -87,7 +85,6 @@ POST /sales/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales,stored_example_script] ==== Value Script @@ -97,7 +94,7 @@ would like to compute the max in EURO (and for the sake of this example, let's say the conversion rate is 1.2). We can use a value script to apply the conversion rate to every value before it is aggregated: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search { @@ -116,7 +113,6 @@ POST /sales/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] ==== Missing value @@ -125,7 +121,7 @@ The `missing` parameter defines how documents that are missing a value should be treated. By default they will be ignored but it is also possible to treat them as if they had a value. -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search { @@ -139,7 +135,6 @@ POST /sales/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] <1> Documents without a value in the `grade` field will fall into the same diff --git a/docs/reference/aggregations/metrics/median-absolute-deviation-aggregation.asciidoc b/docs/reference/aggregations/metrics/median-absolute-deviation-aggregation.asciidoc index 2e88b12d92cd1..336074fd2f48f 100644 --- a/docs/reference/aggregations/metrics/median-absolute-deviation-aggregation.asciidoc +++ b/docs/reference/aggregations/metrics/median-absolute-deviation-aggregation.asciidoc @@ -24,7 +24,7 @@ In this example we have a product which has an average rating of 3 stars. Let's look at its ratings' median absolute deviation to determine how much they vary -[source,js] +[source,console] --------------------------------------------------------- GET reviews/_search { @@ -43,7 +43,6 @@ GET reviews/_search } } --------------------------------------------------------- -// CONSOLE // TEST[setup:reviews] <1> `rating` must be a numeric field @@ -84,7 +83,7 @@ cost of higher memory usage. For more about the characteristics of the TDigest `compression` parameter see <>. -[source,js] +[source,console] --------------------------------------------------------- GET reviews/_search { @@ -99,7 +98,6 @@ GET reviews/_search } } --------------------------------------------------------- -// CONSOLE // TEST[setup:reviews] The default `compression` value for this aggregation is `1000`. At this @@ -114,7 +112,7 @@ of one to ten, we can using scripting. To provide an inline script: -[source,js] +[source,console] --------------------------------------------------------- GET reviews/_search { @@ -134,12 +132,11 @@ GET reviews/_search } } --------------------------------------------------------- -// CONSOLE // TEST[setup:reviews] To provide a stored script: -[source,js] +[source,console] --------------------------------------------------------- GET reviews/_search { @@ -158,7 +155,6 @@ GET reviews/_search } } --------------------------------------------------------- -// CONSOLE // TEST[setup:reviews,stored_example_script] ==== Missing value @@ -170,7 +166,7 @@ as if they had a value. Let's be optimistic and assume some reviewers loved the product so much that they forgot to give it a rating. We'll assign them five stars -[source,js] +[source,console] --------------------------------------------------------- GET reviews/_search { @@ -185,5 +181,4 @@ GET reviews/_search } } --------------------------------------------------------- -// CONSOLE // TEST[setup:reviews] diff --git a/docs/reference/aggregations/metrics/min-aggregation.asciidoc b/docs/reference/aggregations/metrics/min-aggregation.asciidoc index 4225beff3f777..bc904e7403b09 100644 --- a/docs/reference/aggregations/metrics/min-aggregation.asciidoc +++ b/docs/reference/aggregations/metrics/min-aggregation.asciidoc @@ -12,7 +12,7 @@ whose absolute value is greater than +2^53+. Computing the min price value across all documents: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -21,7 +21,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] Response: @@ -49,7 +48,7 @@ response. The `min` aggregation can also calculate the minimum of a script. The example below computes the minimum price: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search { @@ -64,13 +63,12 @@ POST /sales/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] This will use the <> scripting language and no script parameters. To use a stored script use the following syntax: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search { @@ -88,7 +86,6 @@ POST /sales/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales,stored_example_script] ==== Value Script @@ -98,7 +95,7 @@ would like to compute the min in EURO (and for the sake of this example, let's say the conversion rate is 1.2). We can use a value script to apply the conversion rate to every value before it is aggregated: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search { @@ -117,7 +114,6 @@ POST /sales/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] ==== Missing value @@ -126,7 +122,7 @@ The `missing` parameter defines how documents that are missing a value should be treated. By default they will be ignored but it is also possible to treat them as if they had a value. -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search { @@ -140,7 +136,6 @@ POST /sales/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] <1> Documents without a value in the `grade` field will fall into the same diff --git a/docs/reference/aggregations/metrics/percentile-aggregation.asciidoc b/docs/reference/aggregations/metrics/percentile-aggregation.asciidoc index 1903bbc6bcadf..aafc99a6a51b8 100644 --- a/docs/reference/aggregations/metrics/percentile-aggregation.asciidoc +++ b/docs/reference/aggregations/metrics/percentile-aggregation.asciidoc @@ -24,7 +24,7 @@ but it can be easily skewed by a single slow response. Let's look at a range of percentiles representing load time: -[source,js] +[source,console] -------------------------------------------------- GET latency/_search { @@ -38,7 +38,6 @@ GET latency/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:latency] <1> The field `load_time` must be a numeric field @@ -76,7 +75,7 @@ Often, administrators are only interested in outliers -- the extreme percentiles We can specify just the percents we are interested in (requested percentiles must be a value between 0-100 inclusive): -[source,js] +[source,console] -------------------------------------------------- GET latency/_search { @@ -91,7 +90,6 @@ GET latency/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:latency] <1> Use the `percents` parameter to specify particular percentiles to calculate @@ -99,7 +97,7 @@ GET latency/_search By default the `keyed` flag is set to `true` which associates a unique string key with each bucket and returns the ranges as a hash rather than an array. Setting the `keyed` flag to `false` will disable this behavior: -[source,js] +[source,console] -------------------------------------------------- GET latency/_search { @@ -114,7 +112,6 @@ GET latency/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:latency] Response: @@ -168,7 +165,7 @@ The percentile metric supports scripting. For example, if our load times are in milliseconds but we want percentiles calculated in seconds, we could use a script to convert them on-the-fly: -[source,js] +[source,console] -------------------------------------------------- GET latency/_search { @@ -188,7 +185,6 @@ GET latency/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:latency] <1> The `field` parameter is replaced with a `script` parameter, which uses the @@ -197,7 +193,7 @@ script to generate values which percentiles are calculated on This will interpret the `script` parameter as an `inline` script with the `painless` script language and no script parameters. To use a stored script use the following syntax: -[source,js] +[source,console] -------------------------------------------------- GET latency/_search { @@ -216,7 +212,6 @@ GET latency/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:latency,stored_example_script] [[search-aggregations-metrics-percentile-aggregation-approximation]] @@ -262,7 +257,7 @@ it. It would not be the case on more skewed distributions. Approximate algorithms must balance memory utilization with estimation accuracy. This balance can be controlled using a `compression` parameter: -[source,js] +[source,console] -------------------------------------------------- GET latency/_search { @@ -279,7 +274,6 @@ GET latency/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:latency] <1> Compression controls memory usage and approximation error @@ -313,7 +307,7 @@ for values up to 1 millisecond and 3.6 seconds (or better) for the maximum track The HDR Histogram can be used by specifying the `method` parameter in the request: -[source,js] +[source,console] -------------------------------------------------- GET latency/_search { @@ -331,7 +325,6 @@ GET latency/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:latency] <1> `hdr` object indicates that HDR Histogram should be used to calculate the percentiles and specific settings for this algorithm can be specified inside the object @@ -346,7 +339,7 @@ The `missing` parameter defines how documents that are missing a value should be By default they will be ignored but it is also possible to treat them as if they had a value. -[source,js] +[source,console] -------------------------------------------------- GET latency/_search { @@ -361,7 +354,6 @@ GET latency/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:latency] <1> Documents without a value in the `grade` field will fall into the same bucket as documents that have the value `10`. diff --git a/docs/reference/aggregations/metrics/percentile-rank-aggregation.asciidoc b/docs/reference/aggregations/metrics/percentile-rank-aggregation.asciidoc index b9dac1dd0fb0c..cb6624d25b2b4 100644 --- a/docs/reference/aggregations/metrics/percentile-rank-aggregation.asciidoc +++ b/docs/reference/aggregations/metrics/percentile-rank-aggregation.asciidoc @@ -22,7 +22,7 @@ Assume your data consists of website load times. You may have a service agreeme Let's look at a range of percentiles representing load time: -[source,js] +[source,console] -------------------------------------------------- GET latency/_search { @@ -37,8 +37,8 @@ GET latency/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:latency] + <1> The field `load_time` must be a numeric field The response will look like this: @@ -67,7 +67,7 @@ hitting the 95% load time target By default the `keyed` flag is set to `true` associates a unique string key with each bucket and returns the ranges as a hash rather than an array. Setting the `keyed` flag to `false` will disable this behavior: -[source,js] +[source,console] -------------------------------------------------- GET latency/_search { @@ -83,7 +83,6 @@ GET latency/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:latency] Response: @@ -118,7 +117,7 @@ The percentile rank metric supports scripting. For example, if our load times are in milliseconds but we want to specify values in seconds, we could use a script to convert them on-the-fly: -[source,js] +[source,console] -------------------------------------------------- GET latency/_search { @@ -139,15 +138,15 @@ GET latency/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:latency] + <1> The `field` parameter is replaced with a `script` parameter, which uses the script to generate values which percentile ranks are calculated on <2> Scripting supports parameterized input just like any other script This will interpret the `script` parameter as an `inline` script with the `painless` script language and no script parameters. To use a stored script use the following syntax: -[source,js] +[source,console] -------------------------------------------------- GET latency/_search { @@ -167,7 +166,6 @@ GET latency/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:latency,stored_example_script] ==== HDR Histogram @@ -183,7 +181,7 @@ microseconds) in a histogram set to 3 significant digits, it will maintain a val The HDR Histogram can be used by specifying the `method` parameter in the request: -[source,js] +[source,console] -------------------------------------------------- GET latency/_search { @@ -201,8 +199,8 @@ GET latency/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:latency] + <1> `hdr` object indicates that HDR Histogram should be used to calculate the percentiles and specific settings for this algorithm can be specified inside the object <2> `number_of_significant_value_digits` specifies the resolution of values for the histogram in number of significant digits @@ -215,7 +213,7 @@ The `missing` parameter defines how documents that are missing a value should be By default they will be ignored but it is also possible to treat them as if they had a value. -[source,js] +[source,console] -------------------------------------------------- GET latency/_search { @@ -231,6 +229,6 @@ GET latency/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:latency] + <1> Documents without a value in the `load_time` field will fall into the same bucket as documents that have the value `10`. diff --git a/docs/reference/aggregations/metrics/scripted-metric-aggregation.asciidoc b/docs/reference/aggregations/metrics/scripted-metric-aggregation.asciidoc index 1f2ec113d31fd..cfded78bbdf5b 100644 --- a/docs/reference/aggregations/metrics/scripted-metric-aggregation.asciidoc +++ b/docs/reference/aggregations/metrics/scripted-metric-aggregation.asciidoc @@ -5,7 +5,7 @@ A metric aggregation that executes using scripts to provide a metric output. Example: -[source,js] +[source,console] -------------------------------------------------- POST ledger/_search?size=0 { @@ -24,7 +24,6 @@ POST ledger/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:ledger] <1> `init_script` is an optional parameter, all other scripts are required. @@ -50,7 +49,7 @@ The response for the above aggregation: The above example can also be specified using stored scripts as follows: -[source,js] +[source,console] -------------------------------------------------- POST ledger/_search?size=0 { @@ -77,7 +76,6 @@ POST ledger/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:ledger,stored_scripted_metric_script] <1> script parameters for `init`, `map` and `combine` scripts must be specified @@ -145,7 +143,7 @@ final combined profit which will be returned in the response of the aggregation. Imagine a situation where you index the following documents into an index with 2 shards: -[source,js] +[source,console] -------------------------------------------------- PUT /transactions/_bulk?refresh {"index":{"_id":1}} @@ -157,7 +155,6 @@ PUT /transactions/_bulk?refresh {"index":{"_id":4}} {"type": "sale","amount": 130} -------------------------------------------------- -// CONSOLE Lets say that documents 1 and 3 end up on shard A and documents 2 and 4 end up on shard B. The following is a breakdown of what the aggregation result is at each stage of the example above. diff --git a/docs/reference/aggregations/metrics/stats-aggregation.asciidoc b/docs/reference/aggregations/metrics/stats-aggregation.asciidoc index 770b9c523fec6..233d8139ff446 100644 --- a/docs/reference/aggregations/metrics/stats-aggregation.asciidoc +++ b/docs/reference/aggregations/metrics/stats-aggregation.asciidoc @@ -7,7 +7,7 @@ The stats that are returned consist of: `min`, `max`, `sum`, `count` and `avg`. Assuming the data consists of documents representing exams grades (between 0 and 100) of students -[source,js] +[source,console] -------------------------------------------------- POST /exams/_search?size=0 { @@ -16,7 +16,6 @@ POST /exams/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:exams] The above aggregation computes the grades statistics over all documents. The aggregation type is `stats` and the `field` setting defines the numeric field of the documents the stats will be computed on. The above will return the following: @@ -46,7 +45,7 @@ The name of the aggregation (`grades_stats` above) also serves as the key by whi Computing the grades stats based on a script: -[source,js] +[source,console] -------------------------------------------------- POST /exams/_search?size=0 { @@ -62,12 +61,11 @@ POST /exams/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:exams] This will interpret the `script` parameter as an `inline` script with the `painless` script language and no script parameters. To use a stored script use the following syntax: -[source,js] +[source,console] -------------------------------------------------- POST /exams/_search?size=0 { @@ -85,14 +83,13 @@ POST /exams/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:exams,stored_example_script] ===== Value Script It turned out that the exam was way above the level of the students and a grade correction needs to be applied. We can use a value script to get the new stats: -[source,js] +[source,console] -------------------------------------------------- POST /exams/_search?size=0 { @@ -112,7 +109,6 @@ POST /exams/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:exams] ==== Missing value @@ -121,7 +117,7 @@ The `missing` parameter defines how documents that are missing a value should be By default they will be ignored but it is also possible to treat them as if they had a value. -[source,js] +[source,console] -------------------------------------------------- POST /exams/_search?size=0 { @@ -135,7 +131,6 @@ POST /exams/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:exams] <1> Documents without a value in the `grade` field will fall into the same bucket as documents that have the value `0`. diff --git a/docs/reference/aggregations/metrics/sum-aggregation.asciidoc b/docs/reference/aggregations/metrics/sum-aggregation.asciidoc index 8825f07952155..eeff864e0ada7 100644 --- a/docs/reference/aggregations/metrics/sum-aggregation.asciidoc +++ b/docs/reference/aggregations/metrics/sum-aggregation.asciidoc @@ -6,7 +6,7 @@ A `single-value` metrics aggregation that sums up numeric values that are extrac Assuming the data consists of documents representing sales records we can sum the sale price of all hats with: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -22,7 +22,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] Resulting in: @@ -46,7 +45,7 @@ The name of the aggregation (`hat_prices` above) also serves as the key by which We could also use a script to fetch the sales price: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -68,12 +67,11 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] This will interpret the `script` parameter as an `inline` script with the `painless` script language and no script parameters. To use a stored script use the following syntax: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -98,7 +96,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales,stored_example_script] ===== Value Script @@ -106,7 +103,7 @@ POST /sales/_search?size=0 It is also possible to access the field value from the script using `_value`. For example, this will sum the square of the prices for all hats: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -129,7 +126,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] ==== Missing value @@ -139,7 +135,7 @@ be treated. By default documents missing the value will be ignored but it is also possible to treat them as if they had a value. For example, this treats all hat sales without a price as being `100`. -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -160,5 +156,4 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] diff --git a/docs/reference/aggregations/metrics/tophits-aggregation.asciidoc b/docs/reference/aggregations/metrics/tophits-aggregation.asciidoc index 29949bd3582c4..1b8f224e5f012 100644 --- a/docs/reference/aggregations/metrics/tophits-aggregation.asciidoc +++ b/docs/reference/aggregations/metrics/tophits-aggregation.asciidoc @@ -32,7 +32,7 @@ The top_hits aggregation returns regular search hits, because of this many per h In the following example we group the sales by type and per type we show the last sale. For each sale only the date and price fields are being included in the source. -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -63,7 +63,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] Possible response: @@ -185,7 +184,7 @@ belong to. By defining a `terms` aggregator on the `domain` field we group the r Also a `max` aggregator is defined which is used by the `terms` aggregator's order feature to return the buckets by relevancy order of the most relevant document in a bucket. -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search { @@ -218,7 +217,6 @@ POST /sales/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] At the moment the `max` (or `min`) aggregator is needed to make sure the buckets from the `terms` aggregator are @@ -239,7 +237,7 @@ and includes the array field and the offset in the array field the nested hit be Let's see how it works with a real sample. Considering the following mapping: -[source,js] +[source,console] -------------------------------------------------- PUT /sales { @@ -257,12 +255,12 @@ PUT /sales } } -------------------------------------------------- -// CONSOLE + <1> The `comments` is an array that holds nested documents under the `product` object. And some documents: -[source,js] +[source,console] -------------------------------------------------- PUT /sales/_doc/1?refresh { @@ -274,12 +272,11 @@ PUT /sales/_doc/1?refresh ] } -------------------------------------------------- -// CONSOLE // TEST[continued] It's now possible to execute the following `top_hits` aggregation (wrapped in a `nested` aggregation): -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search { @@ -308,7 +305,6 @@ POST /sales/_search } } -------------------------------------------------- -// CONSOLE // TEST[continued] // TEST[s/_search/_search\?filter_path=aggregations.by_sale.by_user.buckets/] diff --git a/docs/reference/aggregations/metrics/valuecount-aggregation.asciidoc b/docs/reference/aggregations/metrics/valuecount-aggregation.asciidoc index 8d5c72994c4a5..1a617c36ca470 100644 --- a/docs/reference/aggregations/metrics/valuecount-aggregation.asciidoc +++ b/docs/reference/aggregations/metrics/valuecount-aggregation.asciidoc @@ -6,7 +6,7 @@ These values can be extracted either from specific fields in the documents, or b this aggregator will be used in conjunction with other single-value aggregations. For example, when computing the `avg` one might be interested in the number of values the average is computed over. -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -15,7 +15,6 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] Response: @@ -40,7 +39,7 @@ retrieved from the returned response. Counting the values generated by a script: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -55,12 +54,11 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] This will interpret the `script` parameter as an `inline` script with the `painless` script language and no script parameters. To use a stored script use the following syntax: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search?size=0 { @@ -78,5 +76,4 @@ POST /sales/_search?size=0 } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales,stored_example_script] diff --git a/docs/reference/aggregations/metrics/weighted-avg-aggregation.asciidoc b/docs/reference/aggregations/metrics/weighted-avg-aggregation.asciidoc index 70804a7904f1f..16c14b9205271 100644 --- a/docs/reference/aggregations/metrics/weighted-avg-aggregation.asciidoc +++ b/docs/reference/aggregations/metrics/weighted-avg-aggregation.asciidoc @@ -51,7 +51,7 @@ The `value` and `weight` objects have per-field specific configuration: If our documents have a `"grade"` field that holds a 0-100 numeric score, and a `"weight"` field which holds an arbitrary numeric weight, we can calculate the weighted average using: -[source,js] +[source,console] -------------------------------------------------- POST /exams/_search { @@ -70,7 +70,6 @@ POST /exams/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:exams] Which yields a response like: @@ -98,7 +97,7 @@ This single weight will be applied independently to each value extracted from th This example show how a single document with multiple values will be averaged with a single weight: -[source,js] +[source,console] -------------------------------------------------- POST /exams/_doc?refresh { @@ -123,7 +122,6 @@ POST /exams/_search } } -------------------------------------------------- -// CONSOLE // TEST The three values (`1`, `2`, and `3`) will be included as independent values, all with the weight of `2`: @@ -149,7 +147,7 @@ The aggregation returns `2.0` as the result, which matches what we would expect Both the value and the weight can be derived from a script, instead of a field. As a simple example, the following will add one to the grade and weight in the document using a script: -[source,js] +[source,console] -------------------------------------------------- POST /exams/_search { @@ -168,7 +166,6 @@ POST /exams/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:exams] @@ -182,7 +179,7 @@ If the `weight` field is missing, it is assumed to have a weight of `1` (like a Both of these defaults can be overridden with the `missing` parameter: -[source,js] +[source,console] -------------------------------------------------- POST /exams/_search { @@ -203,6 +200,5 @@ POST /exams/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:exams] diff --git a/docs/reference/aggregations/misc.asciidoc b/docs/reference/aggregations/misc.asciidoc index 678ebc0a8a4c6..36bb2a9afd0ce 100644 --- a/docs/reference/aggregations/misc.asciidoc +++ b/docs/reference/aggregations/misc.asciidoc @@ -15,7 +15,7 @@ See <> for more details. There are many occasions when aggregations are required but search hits are not. For these cases the hits can be ignored by setting `size=0`. For example: -[source,js] +[source,console] -------------------------------------------------- GET /twitter/_search { @@ -29,7 +29,6 @@ GET /twitter/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:twitter] Setting `size` to `0` avoids executing the fetch phase of the search making the request more efficient. @@ -42,7 +41,7 @@ at response time. Consider this example where we want to associate the color blue with our `terms` aggregation. -[source,js] +[source,console] -------------------------------------------------- GET /twitter/_search { @@ -59,7 +58,6 @@ GET /twitter/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:twitter] Then that piece of metadata will be returned in place for our `titles` terms aggregation @@ -94,7 +92,7 @@ Considering the following <> named `top_users`: -[source,js] +[source,console] -------------------------------------------------- GET /twitter/_search?typed_keys { @@ -115,7 +113,6 @@ GET /twitter/_search?typed_keys } } -------------------------------------------------- -// CONSOLE // TEST[setup:twitter] In the response, the aggregations names will be changed to respectively `date_histogram#tweets_over_time` and diff --git a/docs/reference/aggregations/pipeline.asciidoc b/docs/reference/aggregations/pipeline.asciidoc index f31aaa08b9f31..b6ec7512647ce 100644 --- a/docs/reference/aggregations/pipeline.asciidoc +++ b/docs/reference/aggregations/pipeline.asciidoc @@ -50,7 +50,7 @@ Paths are relative from the position of the pipeline aggregation; they are not a aggregation tree. For example, this derivative is embedded inside a date_histogram and refers to a "sibling" metric `"the_sum"`: -[source,js] +[source,console] -------------------------------------------------- POST /_search { @@ -72,7 +72,7 @@ POST /_search } } -------------------------------------------------- -// CONSOLE + <1> The metric is called `"the_sum"` <2> The `buckets_path` refers to the metric via a relative path `"the_sum"` @@ -80,7 +80,7 @@ POST /_search instead of embedded "inside" them. For example, the `max_bucket` aggregation uses the `buckets_path` to specify a metric embedded inside a sibling aggregation: -[source,js] +[source,console] -------------------------------------------------- POST /_search { @@ -106,8 +106,8 @@ POST /_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] + <1> `buckets_path` instructs this max_bucket aggregation that we want the maximum value of the `sales` aggregation in the `sales_per_month` date histogram. @@ -115,7 +115,7 @@ If a Sibling pipeline agg references a multi-bucket aggregation, such as a `term select specific keys from the multi-bucket. For example, a `bucket_script` could select two specific buckets (via their bucket keys) to perform the calculation: -[source,js] +[source,console] -------------------------------------------------- POST /_search { @@ -152,8 +152,8 @@ POST /_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] + <1> `buckets_path` selects the hats and bags buckets (via `['hat']`/`['bag']``) to use in the script specifically, instead of fetching all the buckets from `sale_type` aggregation @@ -164,7 +164,7 @@ Instead of pathing to a metric, `buckets_path` can use a special `"_count"` path the pipeline aggregation to use the document count as its input. For example, a derivative can be calculated on the document count of each bucket, instead of a specific metric: -[source,js] +[source,console] -------------------------------------------------- POST /_search { @@ -183,14 +183,14 @@ POST /_search } } -------------------------------------------------- -// CONSOLE + <1> By using `_count` instead of a metric name, we can calculate the derivative of document counts in the histogram The `buckets_path` can also use `"_bucket_count"` and path to a multi-bucket aggregation to use the number of buckets returned by that aggregation in the pipeline aggregation instead of a metric. for example a `bucket_selector` can be used here to filter out buckets which contain no buckets for an inner terms aggregation: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search { @@ -222,8 +222,8 @@ POST /sales/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] + <1> By using `_bucket_count` instead of a metric name, we can filter out `histo` buckets where they contain no buckets for the `categories` aggregation diff --git a/docs/reference/aggregations/pipeline/avg-bucket-aggregation.asciidoc b/docs/reference/aggregations/pipeline/avg-bucket-aggregation.asciidoc index 33ccf505e5b8b..12fced9c6dd22 100644 --- a/docs/reference/aggregations/pipeline/avg-bucket-aggregation.asciidoc +++ b/docs/reference/aggregations/pipeline/avg-bucket-aggregation.asciidoc @@ -33,7 +33,7 @@ An `avg_bucket` aggregation looks like this in isolation: The following snippet calculates the average of the total monthly `sales`: -[source,js] +[source,console] -------------------------------------------------- POST /_search { @@ -61,8 +61,8 @@ POST /_search } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] + <1> `buckets_path` instructs this avg_bucket aggregation that we want the (mean) average value of the `sales` aggregation in the `sales_per_month` date histogram. diff --git a/docs/reference/aggregations/pipeline/bucket-script-aggregation.asciidoc b/docs/reference/aggregations/pipeline/bucket-script-aggregation.asciidoc index 6ecd1248a4e31..e3e6be8718d59 100644 --- a/docs/reference/aggregations/pipeline/bucket-script-aggregation.asciidoc +++ b/docs/reference/aggregations/pipeline/bucket-script-aggregation.asciidoc @@ -41,7 +41,7 @@ for more details) |Required | The following snippet calculates the ratio percentage of t-shirt sales compared to total sales each month: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search { @@ -86,7 +86,6 @@ POST /sales/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] And the following may be the response: diff --git a/docs/reference/aggregations/pipeline/bucket-selector-aggregation.asciidoc b/docs/reference/aggregations/pipeline/bucket-selector-aggregation.asciidoc index 41ce04803fbe1..a710901b943d4 100644 --- a/docs/reference/aggregations/pipeline/bucket-selector-aggregation.asciidoc +++ b/docs/reference/aggregations/pipeline/bucket-selector-aggregation.asciidoc @@ -44,7 +44,7 @@ for more details) |Required | The following snippet only retains buckets where the total sales for the month is more than 200: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search { @@ -74,7 +74,6 @@ POST /sales/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] And the following may be the response: diff --git a/docs/reference/aggregations/pipeline/bucket-sort-aggregation.asciidoc b/docs/reference/aggregations/pipeline/bucket-sort-aggregation.asciidoc index a11da760edd02..25d4ccef4b016 100644 --- a/docs/reference/aggregations/pipeline/bucket-sort-aggregation.asciidoc +++ b/docs/reference/aggregations/pipeline/bucket-sort-aggregation.asciidoc @@ -47,7 +47,7 @@ is ascending. The following snippet returns the buckets corresponding to the 3 months with the highest total sales in descending order: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search { @@ -77,8 +77,8 @@ POST /sales/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] + <1> `sort` is set to use the values of `total_sales` in descending order <2> `size` is set to `3` meaning only the top 3 months in `total_sales` will be returned @@ -135,7 +135,7 @@ without specifying `sort`. The following example simply truncates the result so that only the second bucket is returned: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search { @@ -158,7 +158,6 @@ POST /sales/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] Response: diff --git a/docs/reference/aggregations/pipeline/cumulative-cardinality-aggregation.asciidoc b/docs/reference/aggregations/pipeline/cumulative-cardinality-aggregation.asciidoc index 2e316164d64b9..99dd32f85c420 100644 --- a/docs/reference/aggregations/pipeline/cumulative-cardinality-aggregation.asciidoc +++ b/docs/reference/aggregations/pipeline/cumulative-cardinality-aggregation.asciidoc @@ -38,7 +38,7 @@ A `cumulative_cardinality` aggregation looks like this in isolation: The following snippet calculates the cumulative cardinality of the total daily `users`: -[source,js] +[source,console] -------------------------------------------------- GET /user_hits/_search { @@ -65,7 +65,6 @@ GET /user_hits/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:user_hits] <1> `buckets_path` instructs this aggregation to use the output of the `distinct_users` aggregation for the cumulative cardinality @@ -138,7 +137,7 @@ are added each day, rather than the total cumulative count. This can be accomplished by adding a `derivative` aggregation to our query: -[source,js] +[source,console] -------------------------------------------------- GET /user_hits/_search { @@ -170,7 +169,6 @@ GET /user_hits/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:user_hits] diff --git a/docs/reference/aggregations/pipeline/cumulative-sum-aggregation.asciidoc b/docs/reference/aggregations/pipeline/cumulative-sum-aggregation.asciidoc index 226fd9c1bd106..6cc06d65bd53c 100644 --- a/docs/reference/aggregations/pipeline/cumulative-sum-aggregation.asciidoc +++ b/docs/reference/aggregations/pipeline/cumulative-sum-aggregation.asciidoc @@ -31,7 +31,7 @@ A `cumulative_sum` aggregation looks like this in isolation: The following snippet calculates the cumulative sum of the total monthly `sales`: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search { @@ -58,7 +58,6 @@ POST /sales/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] <1> `buckets_path` instructs this cumulative sum aggregation to use the output of the `sales` aggregation for the cumulative sum diff --git a/docs/reference/aggregations/pipeline/derivative-aggregation.asciidoc b/docs/reference/aggregations/pipeline/derivative-aggregation.asciidoc index d987294f96566..b0f2eb6cabb35 100644 --- a/docs/reference/aggregations/pipeline/derivative-aggregation.asciidoc +++ b/docs/reference/aggregations/pipeline/derivative-aggregation.asciidoc @@ -34,7 +34,7 @@ A `derivative` aggregation looks like this in isolation: The following snippet calculates the derivative of the total monthly `sales`: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search { @@ -61,7 +61,6 @@ POST /sales/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] <1> `buckets_path` instructs this derivative aggregation to use the output of the `sales` aggregation for the derivative @@ -128,7 +127,7 @@ A second order derivative can be calculated by chaining the derivative pipeline pipeline aggregation as in the following example which will calculate both the first and the second order derivative of the total monthly sales: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search { @@ -160,7 +159,6 @@ POST /sales/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] <1> `buckets_path` for the second derivative points to the name of the first derivative @@ -228,7 +226,7 @@ The derivative aggregation allows the units of the derivative values to be speci `normalized_value` which reports the derivative value in the desired x-axis units. In the below example we calculate the derivative of the total sales per month but ask for the derivative of the sales as in the units of sales per day: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search { @@ -256,7 +254,6 @@ POST /sales/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] <1> `unit` specifies what unit to use for the x-axis of the derivative calculation diff --git a/docs/reference/aggregations/pipeline/extended-stats-bucket-aggregation.asciidoc b/docs/reference/aggregations/pipeline/extended-stats-bucket-aggregation.asciidoc index 8f9522ec3e5db..6ad9f61f3a164 100644 --- a/docs/reference/aggregations/pipeline/extended-stats-bucket-aggregation.asciidoc +++ b/docs/reference/aggregations/pipeline/extended-stats-bucket-aggregation.asciidoc @@ -35,7 +35,7 @@ A `extended_stats_bucket` aggregation looks like this in isolation: The following snippet calculates the extended stats for monthly `sales` bucket: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search { @@ -62,7 +62,6 @@ POST /sales/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] <1> `bucket_paths` instructs this `extended_stats_bucket` aggregation that we want the calculate stats for the `sales` aggregation in the diff --git a/docs/reference/aggregations/pipeline/max-bucket-aggregation.asciidoc b/docs/reference/aggregations/pipeline/max-bucket-aggregation.asciidoc index 58bdab6128bfa..07f72d655792d 100644 --- a/docs/reference/aggregations/pipeline/max-bucket-aggregation.asciidoc +++ b/docs/reference/aggregations/pipeline/max-bucket-aggregation.asciidoc @@ -33,7 +33,7 @@ A `max_bucket` aggregation looks like this in isolation: The following snippet calculates the maximum of the total monthly `sales`: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search { @@ -60,7 +60,6 @@ POST /sales/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] <1> `buckets_path` instructs this max_bucket aggregation that we want the maximum value of the `sales` aggregation in the diff --git a/docs/reference/aggregations/pipeline/min-bucket-aggregation.asciidoc b/docs/reference/aggregations/pipeline/min-bucket-aggregation.asciidoc index 8f075f7e071d0..217c3dc0ad74f 100644 --- a/docs/reference/aggregations/pipeline/min-bucket-aggregation.asciidoc +++ b/docs/reference/aggregations/pipeline/min-bucket-aggregation.asciidoc @@ -33,7 +33,7 @@ A `min_bucket` aggregation looks like this in isolation: The following snippet calculates the minimum of the total monthly `sales`: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search { @@ -60,7 +60,6 @@ POST /sales/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] <1> `buckets_path` instructs this min_bucket aggregation that we want the minimum value of the `sales` aggregation in the diff --git a/docs/reference/aggregations/pipeline/movfn-aggregation.asciidoc b/docs/reference/aggregations/pipeline/movfn-aggregation.asciidoc index cdea58d45ae07..7f221d2359006 100644 --- a/docs/reference/aggregations/pipeline/movfn-aggregation.asciidoc +++ b/docs/reference/aggregations/pipeline/movfn-aggregation.asciidoc @@ -38,7 +38,7 @@ A `moving_fn` aggregation looks like this in isolation: `moving_fn` aggregations must be embedded inside of a `histogram` or `date_histogram` aggregation. They can be embedded like any other metric aggregation: -[source,js] +[source,console] -------------------------------------------------- POST /_search { @@ -65,7 +65,6 @@ POST /_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] <1> A `date_histogram` named "my_date_histo" is constructed on the "timestamp" field, with one-day intervals @@ -140,7 +139,7 @@ kind of calculation and emit a single `double` as the result. Emitting `null` i For example, this script will simply return the first value from the window, or `NaN` if no values are available: -[source,js] +[source,console] -------------------------------------------------- POST /_search { @@ -167,7 +166,6 @@ POST /_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] [[shift-parameter]] @@ -211,7 +209,7 @@ is only calculated over the real values. If the window is empty, or all values a |`values` |The window of values to find the maximum |=== -[source,js] +[source,console] -------------------------------------------------- POST /_search { @@ -238,7 +236,6 @@ POST /_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] ===== min Function @@ -254,7 +251,7 @@ is only calculated over the real values. If the window is empty, or all values a |`values` |The window of values to find the minimum |=== -[source,js] +[source,console] -------------------------------------------------- POST /_search { @@ -281,7 +278,6 @@ POST /_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] ===== sum Function @@ -297,7 +293,7 @@ the sum is only calculated over the real values. If the window is empty, or all |`values` |The window of values to find the sum of |=== -[source,js] +[source,console] -------------------------------------------------- POST /_search { @@ -324,7 +320,6 @@ POST /_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] ===== stdDev Function @@ -342,7 +337,7 @@ This function accepts a collection of doubles and average, then returns the stan |`avg` |The average of the window |=== -[source,js] +[source,console] -------------------------------------------------- POST /_search { @@ -369,7 +364,6 @@ POST /_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] The `avg` parameter must be provided to the standard deviation function because different styles of averages can be computed on the window @@ -394,7 +388,7 @@ values. |`values` |The window of values to find the sum of |=== -[source,js] +[source,console] -------------------------------------------------- POST /_search { @@ -421,7 +415,6 @@ POST /_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] ==== linearWeightedAvg Function @@ -440,7 +433,7 @@ If the window is empty, or all values are `null`/`NaN`, `NaN` is returned as the |`values` |The window of values to find the sum of |=== -[source,js] +[source,console] -------------------------------------------------- POST /_search { @@ -467,7 +460,6 @@ POST /_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] ==== ewma Function @@ -492,7 +484,7 @@ values. |`alpha` |Exponential decay |=== -[source,js] +[source,console] -------------------------------------------------- POST /_search { @@ -519,7 +511,6 @@ POST /_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] @@ -550,7 +541,7 @@ values. |`beta` |Trend decay value |=== -[source,js] +[source,console] -------------------------------------------------- POST /_search { @@ -577,7 +568,6 @@ POST /_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] In practice, the `alpha` value behaves very similarly in `holtMovAvg` as `ewmaMovAvg`: small values produce more smoothing @@ -616,7 +606,7 @@ values. |`multiplicative` |True if you wish to use multiplicative holt-winters, false to use additive |=== -[source,js] +[source,console] -------------------------------------------------- POST /_search { @@ -643,7 +633,6 @@ POST /_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] [WARNING] diff --git a/docs/reference/aggregations/pipeline/percentiles-bucket-aggregation.asciidoc b/docs/reference/aggregations/pipeline/percentiles-bucket-aggregation.asciidoc index 6620e5689cb60..dd9017807d93e 100644 --- a/docs/reference/aggregations/pipeline/percentiles-bucket-aggregation.asciidoc +++ b/docs/reference/aggregations/pipeline/percentiles-bucket-aggregation.asciidoc @@ -34,7 +34,7 @@ A `percentiles_bucket` aggregation looks like this in isolation: The following snippet calculates the percentiles for the total monthly `sales` buckets: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search { @@ -62,7 +62,6 @@ POST /sales/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] <1> `buckets_path` instructs this percentiles_bucket aggregation that we want to calculate percentiles for diff --git a/docs/reference/aggregations/pipeline/serial-diff-aggregation.asciidoc b/docs/reference/aggregations/pipeline/serial-diff-aggregation.asciidoc index 7a414b95d4025..9d2464a48ab49 100644 --- a/docs/reference/aggregations/pipeline/serial-diff-aggregation.asciidoc +++ b/docs/reference/aggregations/pipeline/serial-diff-aggregation.asciidoc @@ -60,7 +60,7 @@ A `serial_diff` aggregation looks like this in isolation: `serial_diff` aggregations must be embedded inside of a `histogram` or `date_histogram` aggregation: -[source,js] +[source,console] -------------------------------------------------- POST /_search { @@ -88,7 +88,6 @@ POST /_search } } -------------------------------------------------- -// CONSOLE <1> A `date_histogram` named "my_date_histo" is constructed on the "timestamp" field, with one-day intervals <2> A `sum` metric is used to calculate the sum of a field. This could be any metric (sum, min, max, etc) diff --git a/docs/reference/aggregations/pipeline/stats-bucket-aggregation.asciidoc b/docs/reference/aggregations/pipeline/stats-bucket-aggregation.asciidoc index 8c6359fb7765e..827dc1b5559a1 100644 --- a/docs/reference/aggregations/pipeline/stats-bucket-aggregation.asciidoc +++ b/docs/reference/aggregations/pipeline/stats-bucket-aggregation.asciidoc @@ -32,7 +32,7 @@ A `stats_bucket` aggregation looks like this in isolation: The following snippet calculates the stats for monthly `sales`: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search { @@ -59,7 +59,6 @@ POST /sales/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] <1> `bucket_paths` instructs this `stats_bucket` aggregation that we want the calculate stats for the `sales` aggregation in the diff --git a/docs/reference/aggregations/pipeline/sum-bucket-aggregation.asciidoc b/docs/reference/aggregations/pipeline/sum-bucket-aggregation.asciidoc index f0a19f3254126..0c88ca406675e 100644 --- a/docs/reference/aggregations/pipeline/sum-bucket-aggregation.asciidoc +++ b/docs/reference/aggregations/pipeline/sum-bucket-aggregation.asciidoc @@ -32,7 +32,7 @@ A `sum_bucket` aggregation looks like this in isolation: The following snippet calculates the sum of all the total monthly `sales` buckets: -[source,js] +[source,console] -------------------------------------------------- POST /sales/_search { @@ -59,7 +59,6 @@ POST /sales/_search } } -------------------------------------------------- -// CONSOLE // TEST[setup:sales] <1> `buckets_path` instructs this sum_bucket aggregation that we want the sum of the `sales` aggregation in the diff --git a/docs/reference/search/suggesters/misc.asciidoc b/docs/reference/search/suggesters/misc.asciidoc index 1cd6e6fdbfc52..075b2a6532338 100644 --- a/docs/reference/search/suggesters/misc.asciidoc +++ b/docs/reference/search/suggesters/misc.asciidoc @@ -6,7 +6,7 @@ Sometimes you need to know the exact type of a suggester in order to parse its r Considering the following example with two suggesters `term` and `phrase`: -[source,js] +[source,console] -------------------------------------------------- POST _search?typed_keys { @@ -25,7 +25,6 @@ POST _search?typed_keys } } -------------------------------------------------- -// CONSOLE // TEST[setup:twitter] In the response, the suggester names will be changed to respectively `term#my-first-suggester` and diff --git a/docs/reference/search/suggesters/phrase-suggest.asciidoc b/docs/reference/search/suggesters/phrase-suggest.asciidoc index 46dfec5db1c1a..9d49fc16bd00e 100644 --- a/docs/reference/search/suggesters/phrase-suggest.asciidoc +++ b/docs/reference/search/suggesters/phrase-suggest.asciidoc @@ -21,7 +21,7 @@ In general the `phrase` suggester requires special mapping up front to work. The `phrase` suggester examples on this page need the following mapping to work. The `reverse` analyzer is used only in the last example. -[source,js] +[source,console] -------------------------------------------------- PUT test { @@ -74,13 +74,12 @@ POST test/_doc?refresh=true POST test/_doc?refresh=true {"title": "nobel prize"} -------------------------------------------------- -// CONSOLE // TESTSETUP Once you have the analyzers and mappings set up you can use the `phrase` suggester in the same spot you'd use the `term` suggester: -[source,js] +[source,console] -------------------------------------------------- POST test/_search { @@ -104,7 +103,6 @@ POST test/_search } } -------------------------------------------------- -// CONSOLE The response contains suggestions scored by the most likely spell correction first. In this case we received the expected correction "nobel prize". @@ -222,7 +220,7 @@ The response contains suggestions scored by the most likely spell correction fir matching documents for the phrase was found, `false` otherwise. The default value for `prune` is `false`. -[source,js] +[source,console] -------------------------------------------------- POST test/_search { @@ -253,7 +251,7 @@ POST test/_search } } -------------------------------------------------- -// CONSOLE + <1> This query will be run once for every suggestion. <2> The `{{suggestion}}` variable will be replaced by the text of each suggestion. @@ -291,7 +289,7 @@ properties that can be configured. All parameters (`trigram_lambda`, `bigram_lambda`, `unigram_lambda`) must be supplied. -[source,js] +[source,console] -------------------------------------------------- POST test/_search { @@ -311,7 +309,6 @@ POST test/_search } } -------------------------------------------------- -// CONSOLE ===== Candidate Generators @@ -412,7 +409,7 @@ of the direct generators to require a constant prefix to provide high-performance suggestions. The `pre_filter` and `post_filter` options accept ordinary analyzer names. -[source,js] +[source,console] -------------------------------------------------- POST test/_search { @@ -436,7 +433,6 @@ POST test/_search } } -------------------------------------------------- -// CONSOLE `pre_filter` and `post_filter` can also be used to inject synonyms after candidates are generated. For instance for the query `captain usq` we diff --git a/docs/reference/search/uri-request.asciidoc b/docs/reference/search/uri-request.asciidoc index 86e2ee4551b49..5e0a1fc8b7baa 100644 --- a/docs/reference/search/uri-request.asciidoc +++ b/docs/reference/search/uri-request.asciidoc @@ -3,11 +3,10 @@ Specifies search criteria as query parameters in the request URI. -[source,js] +[source,console] -------------------------------------------------- GET twitter/_search?q=user:kimchy -------------------------------------------------- -// CONSOLE // TEST[setup:twitter] @@ -110,11 +109,10 @@ include::{docdir}/rest-api/common-parms.asciidoc[tag=terminate_after] [[search-uri-request-api-example]] ==== {api-examples-title} -[source,js] +[source,console] -------------------------------------------------- GET twitter/_search?q=user:kimchy -------------------------------------------------- -// CONSOLE // TEST[setup:twitter] diff --git a/docs/reference/search/validate.asciidoc b/docs/reference/search/validate.asciidoc index 6e27059837071..94853c49e323d 100644 --- a/docs/reference/search/validate.asciidoc +++ b/docs/reference/search/validate.asciidoc @@ -4,7 +4,7 @@ The validate API allows a user to validate a potentially expensive query without executing it. We'll use the following test data to explain _validate: -[source,js] +[source,console] -------------------------------------------------- PUT twitter/_bulk?refresh {"index":{"_id":1}} @@ -12,16 +12,14 @@ PUT twitter/_bulk?refresh {"index":{"_id":2}} {"user" : "kimchi", "post_date" : "2009-11-15T14:12:13", "message" : "My username is similar to @kimchy!"} -------------------------------------------------- -// CONSOLE // TESTSETUP When sent a valid query: -[source,js] +[source,console] -------------------------------------------------- GET twitter/_validate/query?q=user:foo -------------------------------------------------- -// CONSOLE The response contains `valid:true`: @@ -58,7 +56,7 @@ not. Defaults to `false`. The query may also be sent in the request body: -[source,js] +[source,console] -------------------------------------------------- GET twitter/_validate/query { @@ -76,7 +74,6 @@ GET twitter/_validate/query } } -------------------------------------------------- -// CONSOLE NOTE: The query being sent in the body must be nested in a `query` key, same as the <> works @@ -85,7 +82,7 @@ If the query is invalid, `valid` will be `false`. Here the query is invalid because Elasticsearch knows the post_date field should be a date due to dynamic mapping, and 'foo' does not correctly parse into a date: -[source,js] +[source,console] -------------------------------------------------- GET twitter/_validate/query { @@ -97,7 +94,6 @@ GET twitter/_validate/query } } -------------------------------------------------- -// CONSOLE [source,js] -------------------------------------------------- @@ -108,7 +104,7 @@ GET twitter/_validate/query An `explain` parameter can be specified to get more detailed information about why a query failed: -[source,js] +[source,console] -------------------------------------------------- GET twitter/_validate/query?explain=true { @@ -120,7 +116,6 @@ GET twitter/_validate/query?explain=true } } -------------------------------------------------- -// CONSOLE responds with: @@ -148,7 +143,7 @@ is more detailed showing the actual Lucene query that will be executed. For More Like This: -[source,js] +[source,console] -------------------------------------------------- GET twitter/_validate/query?rewrite=true { @@ -162,7 +157,6 @@ GET twitter/_validate/query?rewrite=true } } -------------------------------------------------- -// CONSOLE // TEST[skip:the output is randomized depending on which shard we hit] Response: @@ -195,7 +189,7 @@ all available shards. For Fuzzy Queries: -[source,js] +[source,console] -------------------------------------------------- GET twitter/_validate/query?rewrite=true&all_shards=true { @@ -209,7 +203,6 @@ GET twitter/_validate/query?rewrite=true&all_shards=true } } -------------------------------------------------- -// CONSOLE Response: diff --git a/docs/reference/setup/install/check-running.asciidoc b/docs/reference/setup/install/check-running.asciidoc index 6a9bab2ae0941..e25d9f6a35fbc 100644 --- a/docs/reference/setup/install/check-running.asciidoc +++ b/docs/reference/setup/install/check-running.asciidoc @@ -3,11 +3,10 @@ You can test that your Elasticsearch node is running by sending an HTTP request to port `9200` on `localhost`: -[source,js] +[source,console] -------------------------------------------- GET / -------------------------------------------- -// CONSOLE which should give you a response something like this: diff --git a/docs/reference/setup/logging-config.asciidoc b/docs/reference/setup/logging-config.asciidoc index ce747c76621e3..29a125ec47227 100644 --- a/docs/reference/setup/logging-config.asciidoc +++ b/docs/reference/setup/logging-config.asciidoc @@ -151,7 +151,7 @@ PUT /_cluster/settings For example: -[source,js] +[source,console] ------------------------------- PUT /_cluster/settings { @@ -160,7 +160,6 @@ PUT /_cluster/settings } } ------------------------------- -// CONSOLE This is most appropriate when you need to dynamically need to adjust a logging level on an actively-running cluster. diff --git a/docs/reference/setup/secure-settings.asciidoc b/docs/reference/setup/secure-settings.asciidoc index 82b61848a846d..7385d31467386 100644 --- a/docs/reference/setup/secure-settings.asciidoc +++ b/docs/reference/setup/secure-settings.asciidoc @@ -104,11 +104,12 @@ can be re-read and applied on a running node. The values of all secure settings, *reloadable* or not, must be identical across all cluster nodes. After making the desired secure settings changes, using the `bin/elasticsearch-keystore add` command, call: -[source,js] + +[source,console] ---- POST _nodes/reload_secure_settings ---- -// CONSOLE + This API will decrypt and re-read the entire keystore, on every cluster node, but only the *reloadable* secure settings will be applied. Changes to other settings will not go into effect until the next restart. Once the call returns, diff --git a/docs/reference/setup/sysconfig/file-descriptors.asciidoc b/docs/reference/setup/sysconfig/file-descriptors.asciidoc index 4c22a0021ff53..27d330b6a5415 100644 --- a/docs/reference/setup/sysconfig/file-descriptors.asciidoc +++ b/docs/reference/setup/sysconfig/file-descriptors.asciidoc @@ -25,8 +25,7 @@ descriptors to 65535 and do not require further configuration. You can check the `max_file_descriptors` configured for each node using the <> API, with: -[source,js] +[source,console] -------------------------------------------------- GET _nodes/stats/process?filter_path=**.max_file_descriptors -------------------------------------------------- -// CONSOLE diff --git a/docs/reference/setup/sysconfig/swap.asciidoc b/docs/reference/setup/sysconfig/swap.asciidoc index d41fe8abf8d20..5dbbb16a4f878 100644 --- a/docs/reference/setup/sysconfig/swap.asciidoc +++ b/docs/reference/setup/sysconfig/swap.asciidoc @@ -67,11 +67,10 @@ After starting Elasticsearch, you can see whether this setting was applied successfully by checking the value of `mlockall` in the output from this request: -[source,js] +[source,console] -------------- GET _nodes?filter_path=**.mlockall -------------- -// CONSOLE If you see that `mlockall` is `false`, then it means that the `mlockall` request has failed. You will also see a line with more information in the logs diff --git a/docs/reference/sql/endpoints/rest.asciidoc b/docs/reference/sql/endpoints/rest.asciidoc index 4fb644a62ba53..28e4d294cbdd4 100644 --- a/docs/reference/sql/endpoints/rest.asciidoc +++ b/docs/reference/sql/endpoints/rest.asciidoc @@ -17,14 +17,13 @@ The SQL REST API accepts SQL in a JSON document, executes it, and returns the results. For example: -[source,js] +[source,console] -------------------------------------------------- POST /_sql?format=txt { "query": "SELECT * FROM library ORDER BY page_count DESC LIMIT 5" } -------------------------------------------------- -// CONSOLE // TEST[setup:library] Which returns: @@ -107,7 +106,7 @@ Here are some examples for the human readable formats: ==== CSV -[source,js] +[source,console] -------------------------------------------------- POST /_sql?format=csv { @@ -115,7 +114,6 @@ POST /_sql?format=csv "fetch_size": 5 } -------------------------------------------------- -// CONSOLE // TEST[setup:library] Which returns: @@ -133,7 +131,7 @@ James S.A. Corey,Leviathan Wakes,561,2011-06-02T00:00:00.000Z ==== JSON -[source,js] +[source,console] -------------------------------------------------- POST /_sql?format=json { @@ -141,7 +139,6 @@ POST /_sql?format=json "fetch_size": 5 } -------------------------------------------------- -// CONSOLE // TEST[setup:library] Which returns: @@ -169,7 +166,7 @@ Which returns: ==== TSV -[source,js] +[source,console] -------------------------------------------------- POST /_sql?format=tsv { @@ -177,7 +174,6 @@ POST /_sql?format=tsv "fetch_size": 5 } -------------------------------------------------- -// CONSOLE // TEST[setup:library] Which returns: @@ -196,7 +192,7 @@ James S.A. Corey Leviathan Wakes 561 2011-06-02T00:00:00.000Z ==== TXT -[source,js] +[source,console] -------------------------------------------------- POST /_sql?format=txt { @@ -204,7 +200,6 @@ POST /_sql?format=txt "fetch_size": 5 } -------------------------------------------------- -// CONSOLE // TEST[setup:library] Which returns: @@ -224,7 +219,7 @@ James S.A. Corey |Leviathan Wakes |561 |2011-06-02T00:00:00.000Z ==== YAML -[source,js] +[source,console] -------------------------------------------------- POST /_sql?format=yaml { @@ -232,7 +227,6 @@ POST /_sql?format=yaml "fetch_size": 5 } -------------------------------------------------- -// CONSOLE // TEST[setup:library] Which returns: @@ -279,14 +273,13 @@ cursor: "sDXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAAEWWWdrRlVfSS1TbDYtcW9lc1FJNmlYdw==:BAFmB Using the example above, one can continue to the next page by sending back the `cursor` field. In case of text format the cursor is returned as `Cursor` http header. -[source,js] +[source,console] -------------------------------------------------- POST /_sql?format=json { "cursor": "sDXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAAEWYUpOYklQMHhRUEtld3RsNnFtYU1hQQ==:BAFmBGRhdGUBZgVsaWtlcwFzB21lc3NhZ2UBZgR1c2Vy9f///w8=" } -------------------------------------------------- -// CONSOLE // TEST[continued] // TEST[s/sDXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAAEWYUpOYklQMHhRUEtld3RsNnFtYU1hQQ==:BAFmBGRhdGUBZgVsaWtlcwFzB21lc3NhZ2UBZgR1c2Vy9f\/\/\/w8=/$body.cursor/] @@ -317,14 +310,13 @@ Elasticsearch state is cleared. To clear the state earlier, you can use the clear cursor command: -[source,js] +[source,console] -------------------------------------------------- POST /_sql/close { "cursor": "sDXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAAEWYUpOYklQMHhRUEtld3RsNnFtYU1hQQ==:BAFmBGRhdGUBZgVsaWtlcwFzB21lc3NhZ2UBZgR1c2Vy9f///w8=" } -------------------------------------------------- -// CONSOLE // TEST[continued] // TEST[s/sDXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAAEWYUpOYklQMHhRUEtld3RsNnFtYU1hQQ==:BAFmBGRhdGUBZgVsaWtlcwFzB21lc3NhZ2UBZgR1c2Vy9f\/\/\/w8=/$body.cursor/] @@ -347,7 +339,7 @@ You can filter the results that SQL will run on using a standard {es} query DSL by specifying the query in the filter parameter. -[source,js] +[source,console] -------------------------------------------------- POST /_sql?format=txt { @@ -363,7 +355,6 @@ POST /_sql?format=txt "fetch_size": 5 } -------------------------------------------------- -// CONSOLE // TEST[setup:library] Which returns: @@ -386,7 +377,7 @@ in a columnar fashion: one row represents all the values of a certain column fro The following formats can be returned in columnar orientation: `json`, `yaml`, `cbor` and `smile`. -[source,js] +[source,console] -------------------------------------------------- POST /_sql?format=json { @@ -395,7 +386,6 @@ POST /_sql?format=json "columnar": true } -------------------------------------------------- -// CONSOLE // TEST[setup:library] Which returns: @@ -423,7 +413,7 @@ Which returns: Any subsequent calls using a `cursor` still have to contain the `columnar` parameter to preserve the orientation, meaning the initial query will not _remember_ the columnar option. -[source,js] +[source,console] -------------------------------------------------- POST /_sql?format=json { @@ -431,7 +421,6 @@ POST /_sql?format=json "columnar": true } -------------------------------------------------- -// CONSOLE // TEST[continued] // TEST[s/sDXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAAEWWWdrRlVfSS1TbDYtcW9lc1FJNmlYdw==:BAFmBmF1dGhvcgFmBG5hbWUBZgpwYWdlX2NvdW50AWYMcmVsZWFzZV9kYXRl\+v\/\/\/w8=/$body.cursor/] diff --git a/docs/reference/sql/endpoints/translate.asciidoc b/docs/reference/sql/endpoints/translate.asciidoc index 978fae4103903..403a8011ad4e4 100644 --- a/docs/reference/sql/endpoints/translate.asciidoc +++ b/docs/reference/sql/endpoints/translate.asciidoc @@ -6,7 +6,7 @@ The SQL Translate API accepts SQL in a JSON document and translates it into native {es} queries. For example: -[source,js] +[source,console] -------------------------------------------------- POST /_sql/translate { @@ -14,7 +14,6 @@ POST /_sql/translate "fetch_size": 10 } -------------------------------------------------- -// CONSOLE // TEST[setup:library] Which returns: diff --git a/docs/reference/sql/getting-started.asciidoc b/docs/reference/sql/getting-started.asciidoc index ffd52060e2b0f..dbcdb68d5e6a3 100644 --- a/docs/reference/sql/getting-started.asciidoc +++ b/docs/reference/sql/getting-started.asciidoc @@ -6,7 +6,7 @@ To start using {es-sql}, create an index with some data to experiment with: -[source,js] +[source,console] -------------------------------------------------- PUT /library/book/_bulk?refresh {"index":{"_id": "Leviathan Wakes"}} @@ -16,18 +16,16 @@ PUT /library/book/_bulk?refresh {"index":{"_id": "Dune"}} {"name": "Dune", "author": "Frank Herbert", "release_date": "1965-06-01", "page_count": 604} -------------------------------------------------- -// CONSOLE And now you can execute SQL using the <> right away: -[source,js] +[source,console] -------------------------------------------------- POST /_sql?format=txt { "query": "SELECT * FROM library WHERE release_date < '2000-01-01'" } -------------------------------------------------- -// CONSOLE // TEST[continued] Which should return something along the lines of: diff --git a/docs/reference/upgrade/close-ml.asciidoc b/docs/reference/upgrade/close-ml.asciidoc index affcd27926677..92be1e4106d87 100644 --- a/docs/reference/upgrade/close-ml.asciidoc +++ b/docs/reference/upgrade/close-ml.asciidoc @@ -3,11 +3,10 @@ //////////// Take us out of upgrade mode after running any snippets on this page. -[source,js] +[source,console] -------------------------------------------------- POST _ml/set_upgrade_mode?enabled=false -------------------------------------------------- -// CONSOLE // TEARDOWN //////////// @@ -25,11 +24,10 @@ it puts increased load on the cluster. prevent new jobs from opening by using the <>: + -[source,js] +[source,console] -------------------------------------------------- POST _ml/set_upgrade_mode?enabled=true -------------------------------------------------- -// CONSOLE + When you disable upgrade mode, the jobs resume using the last model state that was automatically saved. This option avoids the overhead of managing diff --git a/docs/reference/upgrade/cluster_restart.asciidoc b/docs/reference/upgrade/cluster_restart.asciidoc index d5d78bc04c912..eeb533138d4dd 100644 --- a/docs/reference/upgrade/cluster_restart.asciidoc +++ b/docs/reference/upgrade/cluster_restart.asciidoc @@ -79,13 +79,12 @@ cluster and elect a master. At that point, you can use <> and <> to monitor nodes joining the cluster: -[source,sh] +[source,console] -------------------------------------------------- GET _cat/health GET _cat/nodes -------------------------------------------------- -// CONSOLE The `status` column returned by `_cat/health` shows the health of each node in the cluster: `red`, `yellow`, or `green`. @@ -113,7 +112,7 @@ When all nodes have joined the cluster and recovered their primary shards, reenable allocation by restoring `cluster.routing.allocation.enable` to its default: -[source,js] +[source,console] ------------------------------------------------------ PUT _cluster/settings { @@ -122,7 +121,6 @@ PUT _cluster/settings } } ------------------------------------------------------ -// CONSOLE Once allocation is reenabled, the cluster starts allocating replica shards to the data nodes. At this point it is safe to resume indexing and searching, @@ -133,13 +131,12 @@ is `green`. You can monitor progress with the <> and <> APIs: -[source,sh] +[source,console] -------------------------------------------------- GET _cat/health GET _cat/recovery -------------------------------------------------- -// CONSOLE -- . *Restart machine learning jobs.* diff --git a/docs/reference/upgrade/disable-shard-alloc.asciidoc b/docs/reference/upgrade/disable-shard-alloc.asciidoc index 839488f541f51..8f238a2c2c6a5 100644 --- a/docs/reference/upgrade/disable-shard-alloc.asciidoc +++ b/docs/reference/upgrade/disable-shard-alloc.asciidoc @@ -7,7 +7,7 @@ restarted, this I/O is unnecessary. You can avoid racing the clock by <> of replicas before shutting down the node: -[source,js] +[source,console] -------------------------------------------------- PUT _cluster/settings { @@ -16,5 +16,4 @@ PUT _cluster/settings } } -------------------------------------------------- -// CONSOLE // TEST[skip:indexes don't assign] diff --git a/docs/reference/upgrade/open-ml.asciidoc b/docs/reference/upgrade/open-ml.asciidoc index a8882e7f13450..59bcc651c7d45 100644 --- a/docs/reference/upgrade/open-ml.asciidoc +++ b/docs/reference/upgrade/open-ml.asciidoc @@ -3,11 +3,10 @@ If you temporarily halted the tasks associated with your {ml} jobs, use the <> to return them to active states: -[source,js] +[source,console] -------------------------------------------------- POST _ml/set_upgrade_mode?enabled=false -------------------------------------------------- -// CONSOLE If you closed all {ml} jobs before the upgrade, open the jobs and start the datafeeds from {kib} or with the <> and diff --git a/docs/reference/upgrade/reindex_upgrade.asciidoc b/docs/reference/upgrade/reindex_upgrade.asciidoc index faa8fbc1639b4..4beda3b532049 100644 --- a/docs/reference/upgrade/reindex_upgrade.asciidoc +++ b/docs/reference/upgrade/reindex_upgrade.asciidoc @@ -156,7 +156,7 @@ cluster and remove nodes from the old one. remote index into the new {version} index: + -- -[source,js] +[source,console] -------------------------------------------------- POST _reindex { @@ -178,7 +178,6 @@ POST _reindex } } -------------------------------------------------- -// CONSOLE // TEST[setup:host] // TEST[s/^/PUT source\n/] // TEST[s/oldhost:9200",/\${host}"/] diff --git a/docs/reference/upgrade/rolling_upgrade.asciidoc b/docs/reference/upgrade/rolling_upgrade.asciidoc index 5ee75dd62b896..ddc1e55ba3b07 100644 --- a/docs/reference/upgrade/rolling_upgrade.asciidoc +++ b/docs/reference/upgrade/rolling_upgrade.asciidoc @@ -73,11 +73,10 @@ particular, the placement of the realm type changed. See Start the newly-upgraded node and confirm that it joins the cluster by checking the log file or by submitting a `_cat/nodes` request: -[source,sh] +[source,console] -------------------------------------------------- GET _cat/nodes -------------------------------------------------- -// CONSOLE -- . *Reenable shard allocation.* @@ -87,7 +86,7 @@ GET _cat/nodes Once the node has joined the cluster, remove the `cluster.routing.allocation.enable` setting to enable shard allocation and start using the node: -[source,js] +[source,console] -------------------------------------------------- PUT _cluster/settings { @@ -96,7 +95,6 @@ PUT _cluster/settings } } -------------------------------------------------- -// CONSOLE -- . *Wait for the node to recover.* @@ -106,11 +104,10 @@ PUT _cluster/settings Before upgrading the next node, wait for the cluster to finish shard allocation. You can check progress by submitting a <> request: -[source,sh] +[source,console] -------------------------------------------------- GET _cat/health?v -------------------------------------------------- -// CONSOLE Wait for the `status` column to switch from `yellow` to `green`. Once the node is `green`, all primary and replica shards have been allocated. @@ -137,11 +134,10 @@ Shards that were not <> might take longer to recover. You can monitor the recovery status of individual shards by submitting a <> request: -[source,sh] +[source,console] -------------------------------------------------- GET _cat/recovery -------------------------------------------------- -// CONSOLE If you stopped indexing, it is safe to resume indexing as soon as recovery completes. diff --git a/docs/reference/upgrade/synced-flush.asciidoc b/docs/reference/upgrade/synced-flush.asciidoc index d909688f6a434..59bdea15ba742 100644 --- a/docs/reference/upgrade/synced-flush.asciidoc +++ b/docs/reference/upgrade/synced-flush.asciidoc @@ -1,9 +1,8 @@ -[source,sh] +[source,console] -------------------------------------------------- POST _flush/synced -------------------------------------------------- -// CONSOLE When you perform a synced flush, check the response to make sure there are no failures. Synced flush operations that fail due to pending indexing diff --git a/docs/reference/vectors/vector-functions.asciidoc b/docs/reference/vectors/vector-functions.asciidoc index 31b6b211e6aec..1a4876096b0c2 100644 --- a/docs/reference/vectors/vector-functions.asciidoc +++ b/docs/reference/vectors/vector-functions.asciidoc @@ -17,7 +17,7 @@ to limit the number of matched documents with a `query` parameter. Let's create an index with the following mapping and index a couple of documents into it. -[source,js] +[source,console] -------------------------------------------------- PUT my_index { @@ -52,13 +52,12 @@ PUT my_index/_doc/2 } -------------------------------------------------- -// CONSOLE // TESTSETUP For dense_vector fields, `cosineSimilarity` calculates the measure of cosine similarity between a given query vector and document vectors. -[source,js] +[source,console] -------------------------------------------------- GET my_index/_search { @@ -83,7 +82,7 @@ GET my_index/_search } } -------------------------------------------------- -// CONSOLE + <1> To restrict the number of documents on which script score calculation is applied, provide a filter. <2> The script adds 1.0 to the cosine similarity to prevent the score from being negative. <3> To take advantage of the script optimizations, provide a query vector as a script parameter. @@ -94,7 +93,7 @@ different from the query's vector, an error will be thrown. Similarly, for sparse_vector fields, `cosineSimilaritySparse` calculates cosine similarity between a given query vector and document vectors. -[source,js] +[source,console] -------------------------------------------------- GET my_index/_search { @@ -119,12 +118,11 @@ GET my_index/_search } } -------------------------------------------------- -// CONSOLE For dense_vector fields, `dotProduct` calculates the measure of dot product between a given query vector and document vectors. -[source,js] +[source,console] -------------------------------------------------- GET my_index/_search { @@ -152,14 +150,13 @@ GET my_index/_search } } -------------------------------------------------- -// CONSOLE <1> Using the standard sigmoid function prevents scores from being negative. Similarly, for sparse_vector fields, `dotProductSparse` calculates dot product between a given query vector and document vectors. -[source,js] +[source,console] -------------------------------------------------- GET my_index/_search { @@ -187,13 +184,12 @@ GET my_index/_search } } -------------------------------------------------- -// CONSOLE For dense_vector fields, `l1norm` calculates L^1^ distance (Manhattan distance) between a given query vector and document vectors. -[source,js] +[source,console] -------------------------------------------------- GET my_index/_search { @@ -218,7 +214,6 @@ GET my_index/_search } } -------------------------------------------------- -// CONSOLE <1> Unlike `cosineSimilarity` that represent similarity, `l1norm` and `l2norm` shown below represent distances or differences. This means, that @@ -232,7 +227,7 @@ we added `1` in the denominator. For sparse_vector fields, `l1normSparse` calculates L^1^ distance between a given query vector and document vectors. -[source,js] +[source,console] -------------------------------------------------- GET my_index/_search { @@ -257,13 +252,12 @@ GET my_index/_search } } -------------------------------------------------- -// CONSOLE For dense_vector fields, `l2norm` calculates L^2^ distance (Euclidean distance) between a given query vector and document vectors. -[source,js] +[source,console] -------------------------------------------------- GET my_index/_search { @@ -288,12 +282,11 @@ GET my_index/_search } } -------------------------------------------------- -// CONSOLE Similarly, for sparse_vector fields, `l2normSparse` calculates L^2^ distance between a given query vector and document vectors. -[source,js] +[source,console] -------------------------------------------------- GET my_index/_search { @@ -318,7 +311,6 @@ GET my_index/_search } } -------------------------------------------------- -// CONSOLE NOTE: If a document doesn't have a value for a vector field on which a vector function is executed, an error will be thrown.