More redirect changes and small tweaks (#4022)
* more redirect changes and small tweaks Signed-off-by: Heather Halter <hdhalter@amazon.com> * Update _api-reference/cluster-api/cluster-allocation.md Co-authored-by: Naarcha-AWS <97990722+Naarcha-AWS@users.noreply.github.com> Signed-off-by: Heather Halter <HDHALTER@AMAZON.COM> * Update _api-reference/cluster-api/cluster-awareness.md Co-authored-by: Naarcha-AWS <97990722+Naarcha-AWS@users.noreply.github.com> Signed-off-by: Heather Halter <HDHALTER@AMAZON.COM> * Update _api-reference/cluster-api/cluster-health.md Co-authored-by: Naarcha-AWS <97990722+Naarcha-AWS@users.noreply.github.com> Signed-off-by: Heather Halter <HDHALTER@AMAZON.COM> * Update _api-reference/cluster-api/cluster-decommission.md Co-authored-by: kolchfa-aws <105444904+kolchfa-aws@users.noreply.github.com> Signed-off-by: Heather Halter <HDHALTER@AMAZON.COM> * Update _im-plugin/ism/managedindexes.md Co-authored-by: Naarcha-AWS <97990722+Naarcha-AWS@users.noreply.github.com> Signed-off-by: Heather Halter <HDHALTER@AMAZON.COM> --------- Signed-off-by: Heather Halter <hdhalter@amazon.com> Signed-off-by: Heather Halter <HDHALTER@AMAZON.COM> Signed-off-by: Naarcha-AWS <97990722+Naarcha-AWS@users.noreply.github.com> Co-authored-by: Naarcha-AWS <97990722+Naarcha-AWS@users.noreply.github.com> Co-authored-by: kolchfa-aws <105444904+kolchfa-aws@users.noreply.github.com>
This commit is contained in:
Heather Halter
GitHub
parent
d1c22f9f68
commit
ec648b8f83
|
|
@ -2,7 +2,7 @@
|
|||
layout: default
|
||||
title: Alias
|
||||
nav_order: 5
|
||||
Redirect_from:
|
||||
redirect_from:
|
||||
- /opensearch/rest-api/alias/
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -4,6 +4,8 @@ title: Cluster allocation explain
|
|||
nav_order: 10
|
||||
parent: Cluster APIs
|
||||
has_children: false
|
||||
redirect_from:
|
||||
- /opensearch/rest-api/cluster-allocation/
|
||||
---
|
||||
|
||||
# Cluster allocation explain
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ parent: Cluster APIs
|
|||
has_children: false
|
||||
redirect_from:
|
||||
- /api-reference/cluster-awareness/
|
||||
- /opensearch/rest-api/cluster-awareness/
|
||||
---
|
||||
|
||||
# Cluster routing and awareness
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ parent: Cluster APIs
|
|||
has_children: false
|
||||
redirect_from:
|
||||
- /api-reference/cluster-decommission/
|
||||
- /opensearch/rest-api/cluster-decommission/
|
||||
---
|
||||
|
||||
# Cluster decommission
|
||||
|
|
|
|||
|
|
@ -4,7 +4,9 @@ title: Cluster health
|
|||
nav_order: 40
|
||||
parent: Cluster APIs
|
||||
has_children: false
|
||||
redirect_from: /api-reference/cluster-health/
|
||||
redirect_from:
|
||||
- /api-reference/cluster-health/
|
||||
- /opensearch/rest-api/cluster-health/
|
||||
---
|
||||
|
||||
# Cluster health
|
||||
|
|
@ -101,7 +103,7 @@ The following table lists all response fields.
|
|||
|active_primary_shards | Integer | The number of active primary shards. |
|
||||
|active_shards | Integer | The total number of active shards, including primary and replica shards. |
|
||||
|relocating_shards | Integer | The number of relocating shards. |
|
||||
|initializing_shards | Integer | The number of intializing shards. |
|
||||
|initializing_shards | Integer | The number of initializing shards. |
|
||||
|unassigned_shards | Integer | The number of unassigned shards. |
|
||||
|delayed_unassigned_shards | Integer | The number of delayed unassigned shards. |
|
||||
|number_of_pending_tasks | Integer | The number of pending tasks in the cluster. |
|
||||
|
|
|
|||
|
|
@ -5,6 +5,7 @@ nav_order: 50
|
|||
parent: Cluster APIs
|
||||
redirect_from:
|
||||
- /api-reference/cluster-settings/
|
||||
- /opensearch/rest-api/cluster-settings/
|
||||
---
|
||||
|
||||
# Cluster settings
|
||||
|
|
|
|||
|
|
@ -6,6 +6,7 @@ parent: Cluster APIs
|
|||
has_children: false
|
||||
redirect_from:
|
||||
- /api-reference/cluster-stats/
|
||||
- /opensearch/rest-api/cluster-stats/
|
||||
---
|
||||
|
||||
# Cluster stats
|
||||
|
|
@ -481,7 +482,7 @@ indices.analysis | Information about analyzers used in the cluster.
|
|||
nodes | Statistics about the nodes in the cluster.
|
||||
nodes.count | How many nodes were returned from the request.
|
||||
nodes.versions | OpenSearch's version number.
|
||||
nodes.os | Information abotu the operating systems used in the nodes.
|
||||
nodes.os | Information about the operating systems used in the nodes.
|
||||
nodes.process | The processes the returned nodes use.
|
||||
nodes.jvm | Statistics about the Java Virtual Machines in use.
|
||||
nodes.fs | The nodes' file storage.
|
||||
|
|
|
|||
|
|
@ -2,6 +2,8 @@
|
|||
layout: default
|
||||
title: Count
|
||||
nav_order: 21
|
||||
redirect_from:
|
||||
- /opensearch/rest-api/count/
|
||||
---
|
||||
|
||||
# Count
|
||||
|
|
@ -78,13 +80,13 @@ All count parameters are optional.
|
|||
|
||||
Parameter | Type | Description
|
||||
:--- | :--- | :---
|
||||
`allow_no_indices` | Boolean | If false, the request returns an error if any wildcard expression or index alias targets any closed or missing indices. Default is false.
|
||||
`allow_no_indices` | Boolean | If false, the request returns an error if any wildcard expression or index alias targets any closed or missing indexes. Default is false.
|
||||
`analyzer` | String | The analyzer to use in the query string.
|
||||
`analyze_wildcard` | Boolean | Specifies whether to analyze wildcard and prefix queries. Default is false.
|
||||
`default_operator` | String | Indicates whether the default operator for a string query should be AND or OR. Default is OR.
|
||||
`df` | String | The default field in case a field prefix is not provided in the query string.
|
||||
`expand_wildcards` | String | Specifies the type of index that wildcard expressions can match. Supports comma-separated values. Valid values are `all` (match any index), `open` (match open, non-hidden indices), `closed` (match closed, non-hidden indices), `hidden` (match hidden indices), and `none` (deny wildcard expressions). Default is `open`.
|
||||
`ignore_unavailable` | Boolean | Specifies whether to include missing or closed indices in the response. Default is false.
|
||||
`expand_wildcards` | String | Specifies the type of index that wildcard expressions can match. Supports comma-separated values. Valid values are `all` (match any index), `open` (match open, non-hidden indexes), `closed` (match closed, non-hidden indexes), `hidden` (match hidden indexes), and `none` (deny wildcard expressions). Default is `open`.
|
||||
`ignore_unavailable` | Boolean | Specifies whether to include missing or closed indexes in the response. Default is false.
|
||||
`lenient` | Boolean | Specifies whether OpenSearch should accept requests if queries have format errors (for example, querying a text field for an integer). Default is false.
|
||||
`min_score` | Float | Include only documents with a minimum `_score` value in the result.
|
||||
`routing` | String | Value used to route the operation to a specific shard.
|
||||
|
|
|
|||
|
|
@ -32,9 +32,9 @@ All parameters are optional.
|
|||
|
||||
Parameter | Type | Description
|
||||
:--- | :--- | :---
|
||||
allow_no_indices | Boolean | Whether to ignore wildcards that don't match any indices. Default is true.
|
||||
expand_wildcards | String | Expands wildcard expressions to different indices. Combine multiple values with commas. Available values are all (match all indices), open (match open indices), closed (match closed indices), hidden (match hidden indices), and none (do not accept wildcard expressions), which must be used with open, closed, or both. Default is open.
|
||||
ignore_unavailable | Boolean | If true, OpenSearch does not include missing or closed indices in the response.
|
||||
allow_no_indices | Boolean | Whether to ignore wildcards that don't match any indexes. Default is true.
|
||||
expand_wildcards | String | Expands wildcard expressions to different indexes. Combine multiple values with commas. Available values are all (match all indexes), open (match open indexes), closed (match closed indexes), hidden (match hidden indexes), and none (do not accept wildcard expressions), which must be used with open, closed, or both. Default is open.
|
||||
ignore_unavailable | Boolean | If true, OpenSearch does not include missing or closed indexes in the response.
|
||||
master_timeout | Time | How long to wait for a connection to the master node. Default is `30s`.
|
||||
timeout | Time | How long to wait for the response to return. Default is `30s`.
|
||||
|
||||
|
|
|
|||
|
|
@ -8,18 +8,18 @@ nav_order: 13
|
|||
|
||||
If you're ingesting continuously generated time-series data such as logs, events, and metrics into OpenSearch, you're likely in a scenario where the number of documents grows rapidly and you don't need to update older documents.
|
||||
|
||||
A typical workflow to manage time-series data involves multiple steps, such as creating a rollover index alias, defining a write index, and defining common mappings and settings for the backing indices.
|
||||
A typical workflow to manage time-series data involves multiple steps, such as creating a rollover index alias, defining a write index, and defining common mappings and settings for the backing indexes.
|
||||
|
||||
Data streams simplify this process and enforce a setup that best suits time-series data, such as being designed primarily for append-only data and ensuring that each document has a timestamp field.
|
||||
|
||||
A data stream is internally composed of multiple backing indices. Search requests are routed to all the backing indices, while indexing requests are routed to the latest write index. [ISM]({{site.url}}{{site.baseurl}}/im-plugin/ism/index/) policies let you automatically handle index rollovers or deletions.
|
||||
A data stream is internally composed of multiple backing indexes. Search requests are routed to all the backing indexes, while indexing requests are routed to the latest write index. [ISM]({{site.url}}{{site.baseurl}}/im-plugin/ism/index/) policies let you automatically handle index rollovers or deletions.
|
||||
|
||||
|
||||
## Get started with data streams
|
||||
|
||||
### Step 1: Create an index template
|
||||
|
||||
To create a data stream, you first need to create an index template that configures a set of indices as a data stream. The `data_stream` object indicates that it’s a data stream and not a regular index template. The index pattern matches with the name of the data stream:
|
||||
To create a data stream, you first need to create an index template that configures a set of indexes as a data stream. The `data_stream` object indicates that it’s a data stream and not a regular index template. The index pattern matches with the name of the data stream:
|
||||
|
||||
```json
|
||||
PUT _index_template/logs-template
|
||||
|
|
@ -109,7 +109,7 @@ GET _data_stream/logs-nginx
|
|||
}
|
||||
```
|
||||
|
||||
You can see the name of the timestamp field, the list of the backing indices, and the template that's used to create the data stream. You can also see the health of the data stream, which represents the lowest status of all its backing indices.
|
||||
You can see the name of the timestamp field, the list of the backing indexes, and the template that's used to create the data stream. You can also see the health of the data stream, which represents the lowest status of all its backing indexes.
|
||||
|
||||
To see more insights about the data stream, use the `_stats` endpoint:
|
||||
|
||||
|
|
@ -161,7 +161,7 @@ POST logs-redis/_doc
|
|||
### Step 4: Searching a data stream
|
||||
|
||||
You can search a data stream just like you search a regular index or an index alias.
|
||||
The search operation applies to all of the backing indices (all data present in the stream).
|
||||
The search operation applies to all of the backing indexes (all data present in the stream).
|
||||
|
||||
```json
|
||||
GET logs-redis/_search
|
||||
|
|
@ -235,7 +235,7 @@ POST logs-redis/_rollover
|
|||
If you now perform a `GET` operation on the `logs-redis` data stream, you see that the generation ID is incremented from 1 to 2.
|
||||
|
||||
You can also set up an [Index State Management (ISM) policy]({{site.url}}{{site.baseurl}}/im-plugin/ism/policies/) to automate the rollover process for the data stream.
|
||||
The ISM policy is applied to the backing indices at the time of their creation. When you associate a policy to a data stream, it only affects the future backing indices of that data stream.
|
||||
The ISM policy is applied to the backing indexes at the time of their creation. When you associate a policy to a data stream, it only affects the future backing indexes of that data stream.
|
||||
|
||||
You also don’t need to provide the `rollover_alias` setting, because the ISM policy infers this information from the backing index.
|
||||
|
||||
|
|
@ -243,7 +243,7 @@ You also don’t need to provide the `rollover_alias` setting, because the ISM p
|
|||
|
||||
To manage data streams from OpenSearch Dashboards, open **OpenSearch Dashboards**, choose **Index Management**, select **Indices** or **Policy managed indices**.
|
||||
|
||||
You see a toggle switch for data streams that you can use to show or hide indices belonging to a data stream.
|
||||
You see a toggle switch for data streams that you can use to show or hide indexes belonging to a data stream.
|
||||
|
||||
When you enable this switch, you see a data stream multi-select dropdown menu that you can use for filtering data streams.
|
||||
You also see a data stream column that shows you the name of the data stream the index is contained in.
|
||||
|
|
@ -256,9 +256,9 @@ You can performing visualizations on a data stream just like you would on a regu
|
|||
|
||||
### Step 7: Delete a data stream
|
||||
|
||||
The delete operation first deletes the backing indices of a data stream and then deletes the data stream itself.
|
||||
The delete operation first deletes the backing indexes of a data stream and then deletes the data stream itself.
|
||||
|
||||
To delete a data stream and all of its hidden backing indices:
|
||||
To delete a data stream and all of its hidden backing indexes:
|
||||
|
||||
```json
|
||||
DELETE _data_stream/<name_of_data_stream>
|
||||
|
|
|
|||
|
|
@ -1,12 +1,12 @@
|
|||
---
|
||||
layout: default
|
||||
title: Managed Indices
|
||||
title: Managed indexes
|
||||
nav_order: 3
|
||||
parent: Index State Management
|
||||
has_children: false
|
||||
---
|
||||
|
||||
# Managed indices
|
||||
# Managed indexes
|
||||
|
||||
You can change or update a policy using the managed index operations.
|
||||
|
||||
|
|
@ -58,7 +58,7 @@ The following example shows a managed index policy:
|
|||
|
||||
## Change policy
|
||||
|
||||
You can change any managed index policy, but ISM has a few constraints in place to make sure that policy changes don't break indices.
|
||||
You can change any managed index policy, but ISM has a few constraints in place to make sure that policy changes don't break indexes.
|
||||
|
||||
If an index is stuck in its current state, never proceeding, and you want to update its policy immediately, make sure that the new policy includes the same state---same name, same actions, same order---as the old policy. In this case, even if the policy is in the middle of executing an action, ISM applies the new policy.
|
||||
|
||||
|
|
@ -66,8 +66,8 @@ If you update the policy without including an identical state, ISM updates the p
|
|||
|
||||
To change a policy using OpenSearch Dashboards, do the following:
|
||||
|
||||
- Under **Managed indices**, choose the indices that you want to attach the new policy to.
|
||||
- To attach the new policy to indices in specific states, choose **Choose state filters**, and then choose those states.
|
||||
- Under **Index Management**, choose the indexes that you want to attach the new policy to.
|
||||
- To attach the new policy to indexes in specific states, choose **Choose state filters**, and then choose those states.
|
||||
- Under **Choose New Policy**, choose the new policy.
|
||||
- To start the new policy for indices in the current state, choose **Keep indices in their current state after the policy takes effect**.
|
||||
- To start the new policy for indexes in the current state, choose **Keep indices in their current state after the policy takes effect**.
|
||||
- To start the new policy in a specific state, choose **Start from a chosen state after changing policies**, and then choose the default start state in your new policy.
|
||||
|
|
|
|||
|
|
@ -17,13 +17,13 @@ Setting | Default | Description
|
|||
:--- | :--- | :---
|
||||
`plugins.index_state_management.enabled` | True | Specifies whether ISM is enabled or not.
|
||||
`plugins.index_state_management.job_interval` | 5 minutes | The interval at which the managed index jobs are run.
|
||||
`plugins.index_state_management.jitter` | 0.6 | A randomized delay that is added to a job's base run time to prevent a surge of activity from all indices at the same time. A value of 0.6 means a delay of 0-60% of a job interval is added to the base interval. For example, if you have a base interval time of 30 minutes, a value of 0.6 means an amount anywhere between 0 to 18 minutes gets added to your job interval. Maximum is 1, which means an additional interval time of 100%. This maximum cannot exceed `plugins.jobscheduler.jitter_limit`, which also has a default of 0.6. For example, if `plugins.index_state_management.jitter` is set to 0.8, ISM uses `plugins.jobscheduler.jitter_limit` of 0.6 instead.
|
||||
`plugins.index_state_management.jitter` | 0.6 | A randomized delay that is added to a job's base run time to prevent a surge of activity from all indexes at the same time. A value of 0.6 means a delay of 0-60% of a job interval is added to the base interval. For example, if you have a base interval time of 30 minutes, a value of 0.6 means an amount anywhere between 0 to 18 minutes gets added to your job interval. Maximum is 1, which means an additional interval time of 100%. This maximum cannot exceed `plugins.jobscheduler.jitter_limit`, which also has a default of 0.6. For example, if `plugins.index_state_management.jitter` is set to 0.8, ISM uses `plugins.jobscheduler.jitter_limit` of 0.6 instead.
|
||||
`plugins.index_state_management.coordinator.sweep_period` | 10 minutes | How often the routine background sweep is run.
|
||||
`plugins.index_state_management.coordinator.backoff_millis` | 50 milliseconds | The backoff time between retries for failures in the `ManagedIndexCoordinator` (such as when we update managed indices).
|
||||
`plugins.index_state_management.coordinator.backoff_millis` | 50 milliseconds | The backoff time between retries for failures in the `ManagedIndexCoordinator` (such as when we update managed indexes).
|
||||
`plugins.index_state_management.coordinator.backoff_count` | 2 | The count of retries for failures in the `ManagedIndexCoordinator`.
|
||||
`plugins.index_state_management.history.enabled` | True | Specifies whether audit history is enabled or not. The logs from ISM are automatically indexed to a logs document.
|
||||
`plugins.index_state_management.history.max_docs` | 2,500,000 | The maximum number of documents before rolling over the audit history index.
|
||||
`plugins.index_state_management.history.max_age` | 24 hours | The maximum age before rolling over the audit history index.
|
||||
`plugins.index_state_management.history.rollover_check_period` | 8 hours | The time between rollover checks for the audit history index.
|
||||
`plugins.index_state_management.history.rollover_retention_period` | 30 days | How long audit history indices are kept.
|
||||
`plugins.index_state_management.history.rollover_retention_period` | 30 days | How long audit history indexes are kept.
|
||||
`plugins.index_state_management.allow_list` | All actions | List of actions that you can use.
|
||||
|
|
|
|||
|
|
@ -9,13 +9,13 @@ has_children: false
|
|||
|
||||
Using the Security plugin with index management lets you limit non-admin users to certain actions. For example, you might want to set up your security such that a group of users can only read ISM policies, while others can create, delete, or change policies.
|
||||
|
||||
All index management data are protected as system indices, and only a super admin or an admin with a Transport Layer Security (TLS) certificate can access system indices. For more information, see [System indices]({{site.url}}{{site.baseurl}}/security/configuration/system-indices).
|
||||
All index management data are protected as system indexes, and only a super admin or an admin with a Transport Layer Security (TLS) certificate can access system indexes. For more information, see [System indexes]({{site.url}}{{site.baseurl}}/security/configuration/system-indices).
|
||||
|
||||
## Basic permissions
|
||||
|
||||
The Security plugin comes with one role that offers full access to index management: `index_management_full_access`. For a description of the role's permissions, see [Predefined roles]({{site.url}}{{site.baseurl}}/security/access-control/users-roles#predefined-roles).
|
||||
|
||||
With security enabled, users not only need the correct index management permissions, but they also need permissions to execute actions to involved indices. For example, if a user wants to use the REST API to attach a policy that executes a rollup job to an index named `system-logs`, they would need the permissions to attach a policy and execute a rollup job, as well as access to `system-logs`.
|
||||
With security enabled, users not only need the correct index management permissions, but they also need permissions to execute actions to involved indexes. For example, if a user wants to use the REST API to attach a policy that executes a rollup job to an index named `system-logs`, they would need the permissions to attach a policy and execute a rollup job, as well as access to `system-logs`.
|
||||
|
||||
Finally, with the exceptions of Create Policy, Get Policy, and Delete Policy, users also need the `indices:admin/opensearch/ism/managedindex` permission to execute [ISM APIs]({{site.url}}{{site.baseurl}}/im-plugin/ism/api).
|
||||
|
||||
|
|
|
|||
|
|
@ -39,7 +39,7 @@ Stop any nonessential indexing before you begin the upgrade procedure to elimina
|
|||
|
||||
### Reviewing breaking changes
|
||||
|
||||
It's important to determine how the new version of OpenSearch will integreate with your environment. Review [Breaking changes]({{site.url}}{{site.baseurl}}/breaking-changes/) before beginning any upgrade procedures to determine whether you will need to make adjustments to your workflow. For example, upstream or downstream components might need to be modified to be compatible with an API change (see meta issue [#2589](https://github.com/opensearch-project/OpenSearch/issues/2589)).
|
||||
It's important to determine how the new version of OpenSearch will integrate with your environment. Review [Breaking changes]({{site.url}}{{site.baseurl}}/breaking-changes/) before beginning any upgrade procedures to determine whether you will need to make adjustments to your workflow. For example, upstream or downstream components might need to be modified to be compatible with an API change (see meta issue [#2589](https://github.com/opensearch-project/OpenSearch/issues/2589)).
|
||||
|
||||
### Reviewing the OpenSearch tools compatibility matrices
|
||||
|
||||
|
|
|
|||
|
|
@ -2,6 +2,8 @@
|
|||
layout: default
|
||||
title: Logs
|
||||
nav_order: 60
|
||||
redirect_from:
|
||||
- /opensearch/logs/
|
||||
---
|
||||
|
||||
# Logs
|
||||
|
|
@ -89,7 +91,7 @@ There are other ways to change log levels:
|
|||
|
||||
OpenSearch has two *slow logs*, logs that help you identify performance issues: the search slow log and the indexing slow log.
|
||||
|
||||
These logs rely on thresholds to define what qualifies as a "slow" search or indexing operation. For example, you might decide that a query is slow if it takes more than 15 seconds to complete. Unlike application logs, which you configure for modules, you configure slow logs for indices. By default, both logs are disabled (all thresholds are set to `-1`):
|
||||
These logs rely on thresholds to define what qualifies as a "slow" search or indexing operation. For example, you might decide that a query is slow if it takes more than 15 seconds to complete. Unlike application logs, which you configure for modules, you configure slow logs for indexes. By default, both logs are disabled (all thresholds are set to `-1`):
|
||||
|
||||
```json
|
||||
GET <some-index>/_settings?include_defaults=true
|
||||
|
|
|
|||
|
|
@ -128,7 +128,7 @@ Option | Type | Description
|
|||
`label` | String or integer | The text in the upper-left corner of the box.
|
||||
`labelColor` | String or integer | The color of the label.
|
||||
`refreshInterval` | Integer | The number of milliseconds between calls to the Performance Analyzer API for new data. Minimum value is 5000.
|
||||
`dimensionFilters` | String array | The dimension value to diplay for the graph. For example, if you query for `metric=Net_Throughput&agg=sum&dim=Direction` and the possible dimension values are `in` and `out`, you can define `dimensionFilters: ["in"]` to only display the metric data for `in` dimension
|
||||
`dimensionFilters` | String array | The dimension value to display for the graph. For example, if you query for `metric=Net_Throughput&agg=sum&dim=Direction` and the possible dimension values are `in` and `out`, you can define `dimensionFilters: ["in"]` to only display the metric data for `in` dimension
|
||||
`nodeName` | String | If non-null, lets you restrict elements to individual nodes. You can specify the node name directly in the dashboard file, but the better approach is to use `"nodeName": "#nodeName"` in the dashboard and include the `--nodename <node_name>` argument when starting PerfTop.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -7,6 +7,7 @@ nav_order: 10
|
|||
permalink: /query-dsl/compound/bool/
|
||||
redirect_from:
|
||||
- /opensearch/query-dsl/compound/bool/
|
||||
- /opensearch/query-dsl/bool/
|
||||
---
|
||||
|
||||
# Boolean queries
|
||||
|
|
|
|||
Loading…
Reference in New Issue