Files
nats-server/server
Matthias Hanel d53d2d0484 [Added] account specific monitoring endpoint(s) (#3250)
Added http monitoring endpoint /accstatz
It responds with a list of statz for all accounts with local connections
the argument "unused=1" can be provided to get statz for all accounts
This endpoint is also exposed as nats request under:

This monitoring endpoint is exposed via the system account.
$SYS.REQ.ACCOUNT.*.STATZ
Each server will respond with connection statistics for the requested
account. The format of the data section is a list (size 1) identical to the event
$SYS.ACCOUNT.%s.SERVER.CONNS which is sent periodically as well as on
connect/disconnect. Unless requested by options, server without the account,
or server where the account has no local connections, will not respond.

A PING endpoint exists as well. The response format is identical to
$SYS.REQ.ACCOUNT.*.STATZ
(however the data section will contain more than one account, if they exist)
In addition to general filter options the request takes a list of accounts and
an argument to include accounts without local connections (disabled by default)
$SYS.REQ.ACCOUNT.PING.STATZ

Each account has a new system account import where the local subject
$SYS.REQ.ACCOUNT.PING.STATZ essentially responds as if
the importing account name was used for $SYS.REQ.ACCOUNT.*.STATZ

The only difference between requesting ACCOUNT.PING.STATZ from within
the system account and an account is that the later can only retrieve
statz for the account the client requests from.

Also exposed the monitoring /healthz via the system account under
$SYS.REQ.SERVER.*.HEALTHZ
$SYS.REQ.SERVER.PING.HEALTHZ
No dedicated options are available for these.
HEALTHZ also accept general filter options.

Signed-off-by: Matthias Hanel <mh@synadia.com>
2022-07-12 21:50:32 +02:00
..
2021-11-15 17:23:08 -07:00
2021-11-15 17:23:08 -07:00
2022-01-21 11:03:19 -08:00
2022-07-06 13:16:13 -07:00
2022-07-06 13:16:13 -07:00
2022-07-07 17:54:46 -07:00
2021-11-15 17:23:08 -07:00
2021-11-15 17:23:08 -07:00
2021-11-15 17:23:08 -07:00
2021-11-15 17:23:08 -07:00
2022-03-17 17:53:06 -06:00
2022-02-04 13:32:18 -08:00
2022-04-01 17:55:33 -06:00
2022-07-06 20:54:13 -07:00
2022-01-21 11:03:19 -08:00
2022-03-17 17:53:06 -06:00
2021-11-15 17:23:08 -07:00
2021-11-15 17:23:08 -07:00
2021-11-15 17:23:08 -07:00
2021-09-01 14:55:26 -07:00
2021-11-15 17:23:08 -07:00
2022-06-24 09:17:12 -07:00
2022-03-25 12:11:55 -06:00

Tests

Tests that run on Travis have been split into jobs that run in their own VM in parallel. This reduces the overall running time but also is allowing recycling of a job when we get a flapper as opposed to have to recycle the whole test suite.

JetStream Tests

For JetStream tests, we need to observe a naming convention so that no tests are omitted when running on Travis.

The script runTestsOnTravis.sh will run a given job based on the definition found in ".travis.yml".

As for the naming convention:

  • All JetStream tests name should start with TestJetStream
  • Cluster tests should go into jetstream_cluster_test.go and start with TestJetStreamCluster
  • Super-cluster tests should go into jetstream_super_cluster_test.go and start with TestJetStreamSuperCluster

Not following this convention means that some tests may not be executed on Travis.