SLA monitoring of nodes

[dcolley]

Please add additional tests for each node:

availability

• "ping" for network sockets (equivalents of: 30333, 9900, 9933, 9944)
• syncing? is the node up-to-date?

performance

• RPC connection, query

• peers (api.rpc.sytem.health)

  {
  "peers": 16
  "isSyncing": false
  "shouldHavePeers": true
  }

• telemetry: we can subscribe to performance data

reliability

• software version - get from telemetry
• (get this from the latest release from paritytech/polkadot)

  get_latest_release() {
  curl --silent "https://api.github.com/repos/paritytech/polkadot/releases/latest" | # Get latest release from GitHub api
  grep '"tag_name":' |                                            # Get tag line
  sed -E 's/.*"([^"]+)".*/\1/'                                    # Pluck JSON value
  }

member rank

• implement rank (scoring) as per proposal document

security

• --rpc-methods="safe"

other

• ssl certificate expired?

[dcolley]

Tom | Stake.Plus Basically, we need to connect to an ip address of a member, talk in websockets and have that connection think it's communicating with rpc.dotters.network or rpc.ibp.network, etc. Just like a host files rewrite or using the resolve function on the curl command. Then instead of monitoring rpc.stake.plus it would monitor rpc.dotters.network at 192.96.202.175 or rpc.dotters.network at 195.144.22.136. We need to track not only the websockets functionality of the node but also that it's responsive on the urls it's supposed to be responsive on (still processing SSL validation).

derek // metaspan there are 2 methods for doing this: either

write to /etc/hosts and then make the http request, or inject a custom dnsResolver into the request. here is an example:

https://github.com/axios/axios/issues/94 that way you can connect to rpc.stake.plus and have control over the underlying ip address