chore: create new RLN Grafana panel that counts the number of attached proofs per light client

[Ivansete-status]

Description

The following has been implemented in js-waku. We need to have an appropriate Grafana panel where we can see the number of proofs generated per light-client within a RLN epoch (10 min at this time.)

Ideally, the panel should show:

• number of proofs generated per light-client
• Representation of the proof budget a full node has per epoch. For example, TWN nodes are configured with a max limit 100 messages per 10 minutes. Then, we need to show the proofs that are left each time to reach the max limit.

For more context, the current limit for TWN is configured in:

nwaku/waku/factory/networks_config.nim

Lines 29 to 30 in 01fe4d1

	rlnEpochSizeSec: 600,
	rlnRelayUserMessageLimit: 100,

Related issue

[Epic: js-waku] RLN in resource-restricted environments - waku-org/pm#169
https://docs.google.com/document/d/1L8HvXtAYk-JqQL6w3RgCskXwegcTa0J5nyH9YL4LrQE/edit#heading=h.vqpbd9ne1q33

[fryorcraken]

In grafana you can set and display thresholds. Would be useful for this graph

[Ivansete-status]

Thanks so much for the work so far @darshankabariya !
Nevertheless, we need to add the new panels in the infra dashboard:
https://grafana.infra.status.im/d/qrp_ZCTGz/nim-waku-v2?orgId=1&refresh=30s
( apologies that I didn't describe it properly .)

[darshankabariya]

Thanks so much for the work so far @darshankabariya ! Nevertheless, we need to add the new panels in the infra dashboard: https://grafana.infra.status.im/d/qrp_ZCTGz/nim-waku-v2?orgId=1&refresh=30s ( apologies that I didn't describe it properly .)

It's my bad actually @Ivansete-status . will add panal there also. Thanks for adding comments !

[Ivansete-status]

Wonderful @darshankabariya ! Thanks so much indeed!
We need though to wait for the changes to be reflected in a release. I expect this to happen at the end of Dec and therefore, I think we will be able to see this results by January.

Let's keep this issue blocked until we can confirm is fully implemented.
Cheers!

[fryorcraken]

@darshankabariya could we have a 10min rate (epoch) instead of 1 min for https://grafana.infra.status.im/d/qrp_ZCTGz/nim-waku-v2?orgId=1&refresh=30s&var-host=.*&var-fleet=waku.sandbox&var-dc=All&from=1734325185332&to=1734411585332&viewPanel=113 ?

[darshankabariya]

@darshankabariya could we have a 10min rate (epoch) instead of 1 min for https://grafana.infra.status.im/d/qrp_ZCTGz/nim-waku-v2?orgId=1&refresh=30s&var-host=.*&var-fleet=waku.sandbox&var-dc=All&from=1734325185332&to=1734411585332&viewPanel=113 ?

Hi @fryorcraken , you're right—I didn't include that one, but I agree that 1 minute doesn't make much sense. Updating it to 10 minutes sounds like a better.

new one look like this Image

[fryorcraken]

new one look like this Image

Looks like it's capping at 19/20. Is is because the membership rate limit deployed on those nodes is 20 msg per epoch?

[darshankabariya]

new one look like this Image

Looks like it's capping at 19/20. Is is because the membership rate limit deployed on those nodes is 20 msg per epoch?

Hi @fryorcraken , I think there might be a small misunderstanding. This metric changes(waku_rln_proof_generation_duration_seconds[10m]) is actually measuring something different than message rate limits.

This metric reflects the frequency of changes in RLN proof generation duration within a 10-minute window. It measures the entropy of RLN activity rather than the number of messages per epoch. ( From another perspective, it might indicate the changes in user message sizes per epoch, as the length of a message seems proportional to the proof generation time. i am not sure what's is actual purpose of this metrics )

along with your suggestio, also add some improvements to the dashboard ( just RLN section ) by providing clearer explanations and seperate the verification and generation metrics for better clarity. currently it's look like this