nats-server
nats-server copied to clipboard
Standardize and Document System Account endpoints for `$SYS.REQ.ACCOUNT.PING.<endpoint>`
Currently, there are 2 endpoints active under $SYS.REQ.ACCOUNT.PING.<endpoint>
that were introduced in #3250
-
$SYS.REQ.ACCOUNT.PING.STATZ
- equivalent of HTTP endpoint/accstatz
-
$SYS.REQ.ACCOUNT.PING.CONNS
- I can't tell what this is for. #3250 mentions that it is a legacy endpoint, it has a listener, but no messages get replied on
These endpoints are not documented on the Available Events and Services page.
The confusing part about these endpoints being under $SYS.REQ.ACCOUNT.PING
is how this acts for other account-related endpoints. For the following endpoints, PING
will be treated as the Account Name for a lookup, and will not aggregate all accounts:
$SYS.REQ.ACCOUNT.PING.CONNZ
$SYS.REQ.ACCOUNT.PING.LEAFZ
$SYS.REQ.ACCOUNT.PING.SUBSZ
$SYS.REQ.ACCOUNT.PING.JSZ // this actually could work by returning the equivalent of /jsz?accounts=1
$SYS.REQ.ACCOUNT.PING.INFO
Looking for feedback on the following 2 options to standardize:
- Move
$SYS.REQ.ACCOUNT.PING.STATZ
to$SYS.REQ.SERVER.PING.ACCSTATZ
to make this more closely align with HTTP endpoint - Keep
$SYS.REQ.ACCOUNT.PING.STATZ
where it is and document it
Another thing that could be considered, is that we could add support for parameter passing to these responders so that they are more closely able to return the data that the HTTP monitoring endpoints do. For example we could achieve getting all of the account JSZ data with nats req --header=accounts=1 $SYS.REQ.SERVER.PING.JSZ
, and not have to add another request subject such as $SYS.REQ.ACCOUNT.PING.JSZ
/cc @bruth @wallyqs
There was a period of just seemingly randomly adding crazy sibjects. All for stabilising and documenting.
You wouldn’t “nats req” tbem most (and I think this one not) are under “nats server req” where all the various options they take are surfaced as easy to discover CLI flags.
I am in favor of changing to $SYS.REQ.SERVER.PING.ACCSTATZ
for consistency and avoid confusion/conflict with the account name of PING
.
I know this all is in the context of the system account, but the header suggestion makes me nervous as a general practice since permissions only apply to subjects. I think if there are variations of an endpoint desired, additional tokens could be added to make the request explicit.