25 lines
2.3 KiB
Markdown
25 lines
2.3 KiB
Markdown
# visualiser-go
|
|
This is an experimental Node.js visualiser for Waku message hashes.
|
|
|
|
## theory
|
|
We can query for messages, like so:
|
|
|
|
curl https://vmselect.riff.cc/select/logsql/query -d 'query=_time:1m relay received'
|
|
|
|
This gives us the last 1 minute of messages relating to receiving relay messages from VictoriaLogs.
|
|
|
|
The output of this looks like this:
|
|
|
|
```
|
|
{"_time":"2024-06-27T04:29:36.304246Z","_stream":"{kubernetes_container_name=\"waku\",kubernetes_namespace_name=\"zerotesting\",kubernetes_pod_name=\"nodes-37\",stream=\"stdout\"}","_msg":"NTC 2024-06-27 04:29:36.304+00:00 waku.relay received topics=\"waku node\" tid=7 file=waku_node.nim:231 my_peer_id=16U*FhSqeV pubsubTopic=/waku/2/default-waku/proto msg_hash=0x46e45b1e604a25e53e1ebe0bcec18152fa7ca9e248d64ebfdbbef387e4b95bb2 receivedTime=1719462576304022272 payloadSizeBytes=10000","_p":"F","kubernetes_container_hash":"docker.io/soutullostatus/nwaku-jq-curl@sha256:4485e760104ae8e0d9093851510b325ca6cc08064fd4b7f20ea52f18311c261a","kubernetes_container_image":"docker.io/soutullostatus/nwaku-jq-curl:v0.29.0","kubernetes_container_name":"waku","kubernetes_docker_id":"ad0ba2249862cec39f9ba38d0fd18135d5a68549e65b4213356a91f60b052209","kubernetes_host":"ruby-k8s-w48","kubernetes_labels.app":"zerotenkay","kubernetes_labels.apps.kubernetes.io/pod-index":"37","kubernetes_labels.controller-revision-hash":"nodes-646d5bd99b","kubernetes_labels.statefulset.kubernetes.io/pod-name":"nodes-37","kubernetes_namespace_name":"zerotesting","kubernetes_pod_id":"4ed8a3ec-8c63-4cdc-88ad-b2490f0f6bdf","kubernetes_pod_name":"nodes-37","stream":"stdout","time":"2024-06-27T04:29:36.304246029Z"}
|
|
```
|
|
|
|
Note from it we can determine which peer - 16U*FhSqeV - received which message hash - 0x46e45b1e604a25e53e1ebe0bcec18152fa7ca9e248d64ebfdbbef387e4b95bb2
|
|
|
|
## Visualising it
|
|
We can naively do the following:
|
|
* We represent each node as a dot on screen
|
|
* Each time we hear about a new peer from the logs that we didn't know about, we elastically rearrange the screen to include the new peer
|
|
* Each time a node receives a message, it lights up the colour of the message. The colour of the message is determined by taking the hash and using it to calculate a colour.
|
|
* Once a particular log line (uniquely identified by msg_hash= and receivedTime=) has been processed, we do not use it to light up nodes again.
|