OpenSearch/docs/reference/cat/nodeattrs.asciidoc

120 lines
3.4 KiB
Plaintext
Raw Normal View History

[[cat-nodeattrs]]
=== cat nodeattrs API
++++
<titleabbrev>cat nodeattrs</titleabbrev>
++++
Returns information about custom node attributes.
[[cat-nodeattrs-api-request]]
==== {api-request-title}
`GET /_cat/nodeattrs`
[[cat-nodeattrs-api-query-params]]
==== {api-query-parms-title}
include::{es-repo-dir}/rest-api/common-parms.asciidoc[tag=http-format]
include::{es-repo-dir}/rest-api/common-parms.asciidoc[tag=cat-h]
+
--
If you do not specify which columns to include, the API returns the default columns in the order listed below. If you explicitly specify one or more columns, it only returns the specified columns.
Valid columns are:
`node`,`name`::
(Default) Name of the node, such as `DKDM97B`.
`host`, `h`::
(Default) Host name, such as `n1`.
`ip`, `i`::
(Default) IP address, such as `127.0.1.1`.
`attr`, `attr.name`::
(Default) Attribute name, such as `rack`.
`value`, `attr.value`::
(Default) Attribute value, such as `rack123`.
`id`, `nodeId`::
ID of the node, such as `k0zy`.
`pid`, `p`::
Process ID, such as `13061`.
`port`, `po`::
Bound transport port, such as `9300`.
--
include::{es-repo-dir}/rest-api/common-parms.asciidoc[tag=help]
include::{es-repo-dir}/rest-api/common-parms.asciidoc[tag=local]
include::{es-repo-dir}/rest-api/common-parms.asciidoc[tag=master-timeout]
include::{es-repo-dir}/rest-api/common-parms.asciidoc[tag=cat-s]
include::{es-repo-dir}/rest-api/common-parms.asciidoc[tag=cat-v]
[[cat-nodeattrs-api-example]]
==== {api-examples-title}
[[cat-nodeattrs-api-ex-default]]
===== Example with default columns
[source,console]
--------------------------------------------------
GET /_cat/nodeattrs?v
--------------------------------------------------
// TEST[s/\?v/\?v&s=node,attr/]
// Sort the resulting attributes so we can assert on them more easily
The API returns the following response:
[source,txt]
--------------------------------------------------
node host ip attr value
...
node-0 127.0.0.1 127.0.0.1 testattr test
...
--------------------------------------------------
// TESTRESPONSE[s/\.\.\.\n$/\n(.+ xpack\\.installed true\n)?\n/]
// TESTRESPONSE[s/\.\.\.\n/(.+ ml\\..+\n)*/ non_json]
// If xpack is not installed then neither ... with match anything
// If xpack is installed then the first ... contains ml attributes
// and the second contains xpack.installed=true
The `node`, `host`, and `ip` columns provide basic information about each node.
The `attr` and `value` columns return custom node attributes, one per line.
[[cat-nodeattrs-api-ex-headings]]
===== Example with explicit columns
The following API request returns the `name`, `pid`, `attr`, and `value`
columns.
[source,console]
--------------------------------------------------
GET /_cat/nodeattrs?v&h=name,pid,attr,value
--------------------------------------------------
// TEST[s/,value/,value&s=node,attr/]
// Sort the resulting attributes so we can assert on them more easily
The API returns the following response:
Enforce that responses in docs are valid json (#26249) All of the snippets in our docs marked with `// TESTRESPONSE` are checked against the response from Elasticsearch but, due to the way they are implemented they are actually parsed as YAML instead of JSON. Luckilly, all valid JSON is valid YAML! Unfurtunately that means that invalid JSON has snuck into the exmples! This adds a step during the build to parse them as JSON and fail the build if they don't parse. But no! It isn't quite that simple. The displayed text of some of these responses looks like: ``` { ... "aggregations": { "range": { "buckets": [ { "to": 1.4436576E12, "to_as_string": "10-2015", "doc_count": 7, "key": "*-10-2015" }, { "from": 1.4436576E12, "from_as_string": "10-2015", "doc_count": 0, "key": "10-2015-*" } ] } } } ``` Note the `...` which isn't valid json but we like it anyway and want it in the output. We use substitution rules to convert the `...` into the response we expect. That yields a response that looks like: ``` { "took": $body.took,"timed_out": false,"_shards": $body._shards,"hits": $body.hits, "aggregations": { "range": { "buckets": [ { "to": 1.4436576E12, "to_as_string": "10-2015", "doc_count": 7, "key": "*-10-2015" }, { "from": 1.4436576E12, "from_as_string": "10-2015", "doc_count": 0, "key": "10-2015-*" } ] } } } ``` That is what the tests consume but it isn't valid JSON! Oh no! We don't want to go update all the substitution rules because that'd be huge and, ultimately, wouldn't buy much. So we quote the `$body.took` bits before parsing the JSON. Note the responses that we use for the `_cat` APIs are all converted into regexes and there is no expectation that they are valid JSON. Closes #26233
2017-08-17 09:02:10 -04:00
[source,txt]
--------------------------------------------------
name pid attr value
...
node-0 19566 testattr test
...
--------------------------------------------------
// TESTRESPONSE[s/19566/\\d*/]
// TESTRESPONSE[s/\.\.\.\n$/\n(.+ xpack\\.installed true\n)?\n/]
// TESTRESPONSE[s/\.\.\.\n/(.+ ml\\..+\n)*/ non_json]
// If xpack is not installed then neither ... with match anything
// If xpack is installed then the first ... contains ml attributes
// and the second contains xpack.installed=true