2015-07-29 09:56:57 -04:00
[[cat-nodeattrs]]
2019-08-13 08:35:08 -04:00
=== cat nodeattrs API
++++
<titleabbrev>cat nodeattrs</titleabbrev>
++++
2015-07-29 09:56:57 -04:00
2019-08-07 09:31:07 -04:00
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::{docdir}/rest-api/common-parms.asciidoc[tag=http-format]
include::{docdir}/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::{docdir}/rest-api/common-parms.asciidoc[tag=help]
include::{docdir}/rest-api/common-parms.asciidoc[tag=local]
include::{docdir}/rest-api/common-parms.asciidoc[tag=master-timeout]
include::{docdir}/rest-api/common-parms.asciidoc[tag=cat-s]
include::{docdir}/rest-api/common-parms.asciidoc[tag=cat-v]
[[cat-nodeattrs-api-example]]
==== {api-examples-title}
[[cat-nodeattrs-api-ex-default]]
===== Example with default columns
2015-07-29 09:56:57 -04:00
2019-09-09 13:38:14 -04:00
[source,console]
2015-07-29 09:56:57 -04:00
--------------------------------------------------
2016-10-13 16:42:21 -04:00
GET /_cat/nodeattrs?v
2015-07-29 09:56:57 -04:00
--------------------------------------------------
2018-06-18 12:06:42 -04:00
// TEST[s/\?v/\?v&s=node,attr/]
2019-01-07 08:44:12 -05:00
// Sort the resulting attributes so we can assert on them more easily
2015-07-29 09:56:57 -04:00
2019-08-07 09:31:07 -04:00
The API returns the following response:
2015-07-29 09:56:57 -04:00
2016-10-25 10:56:30 -04:00
[source,txt]
2015-07-29 09:56:57 -04:00
--------------------------------------------------
2016-10-13 16:42:21 -04:00
node host ip attr value
2018-06-18 12:06:42 -04:00
...
node-0 127.0.0.1 127.0.0.1 testattr test
...
2015-07-29 09:56:57 -04:00
--------------------------------------------------
2018-06-18 12:06:42 -04:00
// TESTRESPONSE[s/\.\.\.\n$/\n(.+ xpack\\.installed true\n)?\n/]
2019-06-10 09:33:32 -04:00
// TESTRESPONSE[s/\.\.\.\n/(.+ ml\\..+\n)*/ non_json]
2018-06-18 12:06:42 -04:00
// 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
2015-07-29 09:56:57 -04:00
2019-08-07 09:31:07 -04:00
The `node`, `host`, and `ip` columns provide basic information about each node.
The `attr` and `value` columns return custom node attributes, one per line.
2015-07-29 09:56:57 -04:00
2019-08-07 09:31:07 -04:00
[[cat-nodeattrs-api-ex-headings]]
===== Example with explicit columns
2015-07-29 09:56:57 -04:00
2019-08-07 09:31:07 -04:00
The following API request returns the `name`, `pid`, `attr`, and `value`
columns.
2015-07-29 09:56:57 -04:00
2019-09-09 13:38:14 -04:00
[source,console]
2016-10-13 16:42:21 -04:00
--------------------------------------------------
GET /_cat/nodeattrs?v&h=name,pid,attr,value
--------------------------------------------------
2018-06-18 12:06:42 -04:00
// TEST[s/,value/,value&s=node,attr/]
2019-01-07 08:44:12 -05:00
// Sort the resulting attributes so we can assert on them more easily
2016-10-13 16:42:21 -04:00
2019-08-07 09:31:07 -04:00
The API returns the following response:
2016-10-13 16:42:21 -04:00
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]
2015-07-29 09:56:57 -04:00
--------------------------------------------------
2016-10-13 16:42:21 -04:00
name pid attr value
2018-06-18 12:06:42 -04:00
...
node-0 19566 testattr test
...
2015-07-29 09:56:57 -04:00
--------------------------------------------------
2018-06-18 12:06:42 -04:00
// TESTRESPONSE[s/19566/\\d*/]
// TESTRESPONSE[s/\.\.\.\n$/\n(.+ xpack\\.installed true\n)?\n/]
2019-06-10 09:33:32 -04:00
// TESTRESPONSE[s/\.\.\.\n/(.+ ml\\..+\n)*/ non_json]
2018-06-18 12:06:42 -04:00
// If xpack is not installed then neither ... with match anything
// If xpack is installed then the first ... contains ml attributes
2019-08-07 09:31:07 -04:00
// and the second contains xpack.installed=true
