2015-07-29 09:56:57 -04:00
|
|
|
[[cat-nodeattrs]]
|
|
|
|
|
== cat nodeattrs
|
|
|
|
|
|
|
|
|
|
The `nodeattrs` command shows custom node attributes.
|
2016-10-13 16:42:21 -04:00
|
|
|
For example:
|
2015-07-29 09:56:57 -04:00
|
|
|
|
2016-10-13 16:42:21 -04:00
|
|
|
[source,js]
|
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
|
|
|
--------------------------------------------------
|
2016-10-13 16:42:21 -04:00
|
|
|
// CONSOLE
|
2015-07-29 09:56:57 -04:00
|
|
|
|
2016-10-13 16:42:21 -04:00
|
|
|
Could look like:
|
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
|
|
|
|
|
EK_AsJb 127.0.0.1 127.0.0.1 testattr test
|
2015-07-29 09:56:57 -04:00
|
|
|
--------------------------------------------------
|
2016-10-13 16:42:21 -04:00
|
|
|
// TESTRESPONSE[s/EK_AsJb/.+/ _cat]
|
2015-07-29 09:56:57 -04:00
|
|
|
|
2016-10-13 16:42:21 -04:00
|
|
|
The first few columns (`node`, `host`, `ip`) give you basic info per node
|
|
|
|
|
and the `attr` and `value` columns give you the custom node attributes,
|
|
|
|
|
one per line.
|
2015-07-29 09:56:57 -04:00
|
|
|
|
|
|
|
|
[float]
|
|
|
|
|
=== Columns
|
|
|
|
|
|
|
|
|
|
Below is an exhaustive list of the existing headers that can be
|
2015-09-18 07:05:19 -04:00
|
|
|
passed to `nodeattrs?h=` to retrieve the relevant details in ordered
|
2015-07-29 09:56:57 -04:00
|
|
|
columns. If no headers are specified, then those marked to Appear
|
|
|
|
|
by Default will appear. If any header is specified, then the defaults
|
|
|
|
|
are not used.
|
|
|
|
|
|
|
|
|
|
Aliases can be used in place of the full header name for brevity.
|
|
|
|
|
Columns appear in the order that they are listed below unless a
|
|
|
|
|
different order is specified (e.g., `h=attr,value` versus `h=value,attr`).
|
|
|
|
|
|
|
|
|
|
When specifying headers, the headers are not placed in the output
|
|
|
|
|
by default. To have the headers appear in the output, use verbose
|
|
|
|
|
mode (`v`). The header name will match the supplied value (e.g.,
|
|
|
|
|
`pid` versus `p`). For example:
|
|
|
|
|
|
2016-10-13 16:42:21 -04:00
|
|
|
[source,js]
|
|
|
|
|
--------------------------------------------------
|
|
|
|
|
GET /_cat/nodeattrs?v&h=name,pid,attr,value
|
|
|
|
|
--------------------------------------------------
|
|
|
|
|
// CONSOLE
|
|
|
|
|
|
|
|
|
|
Might look like:
|
|
|
|
|
|
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
|
|
|
|
|
EK_AsJb 19566 testattr test
|
2015-07-29 09:56:57 -04:00
|
|
|
--------------------------------------------------
|
2016-10-13 16:42:21 -04:00
|
|
|
// TESTRESPONSE[s/EK_AsJb/.+/ s/19566/\\d*/ _cat]
|
2015-07-29 09:56:57 -04:00
|
|
|
|
|
|
|
|
[cols="<,<,<,<,<",options="header",subs="normal"]
|
|
|
|
|
|=======================================================================
|
|
|
|
|
|Header |Alias |Appear by Default |Description |Example
|
2016-09-16 08:32:03 -04:00
|
|
|
|`node`|`name`|Yes|Name of the node|DKDM97B
|
2015-07-29 09:56:57 -04:00
|
|
|
|`id` |`nodeId` |No |Unique node ID |k0zy
|
|
|
|
|
|`pid` |`p` |No |Process ID |13061
|
|
|
|
|
|`host` |`h` |Yes |Host name |n1
|
|
|
|
|
|`ip` |`i` |Yes |IP address |127.0.1.1
|
|
|
|
|
|`port` |`po` |No |Bound transport port |9300
|
|
|
|
|
|`attr` | `attr.name` | Yes | Attribute name | rack
|
|
|
|
|
|`value` | `attr.value` | Yes | Attribute value | rack123
|
|
|
|
|
|=======================================================================
|
