fix: Use Grafana provisioning for metrics

[Ktl-XV]

What was wrong?

As reported in #1551 the create-dashboard trin sub command stopped working.

The issue arose because Grafana and nanotemplate both use brackets for template placeholders. A change in the dashboard introduced new metrics which included Grafana placeholders, but nanotemplate was parsing them as it's own.

How was it fixed?

Since Grafana includes a provisioning system, switched to using that and removed the create-dashboard trin sub command. This also removed the need for nanotemplate as a dependency.

Additionally, updated the dashboard's panels to display State network data (and any networks that might be added later)

To-Do

• etc/grafana/dashboards/trin-bench-trin-metrics-dashboard.json.template is sort of dangling now, and it is also not strictly needed in this repo should it be kept, moved or deleted?

[KolbyML]

I am not the biggest fan of this approach because it makes the code/instructions platform specific, whereas before you could use the subcommand on Windows as well

[Ktl-XV]

Thanks for the feedback.

That's right, didn't think about Windows. Since currently the monitoring instructions are Linux and Docker only, that is where I focused.

Could a solution be if/when adding Windows instructions, add a step to edit the provisioning file and point to the appropriate location?

A different option could be to include an importable dashboard where the user pastes the JSON in Grafana and the web UI guides them to select a Prometheus data source (which can still be provisioned automatically). This approach would work in any OS while also making it easier to add the Trin Dashboard to Grafana instances without having to input credentials into the terminal. This template could also be uploaded to the Grafana Dashboards website to make it easier to import.

Or we could also replace nanotemplate with another templating engine which can handle this use case properly and keep the subcommand. I don't like this approach much because, imho, configuring a Grafana instance should be out of scope of the main software, but I'm willing to do it if you prefer this option.

[KolbyML]

Thanks for the feedback.

That's right, didn't think about Windows. Since currently the monitoring instructions are Linux and Docker only, that is where I focused.

Could a solution be if/when adding Windows instructions, add a step to edit the provisioning file and point to the appropriate location?

A different option could be to include an importable dashboard where the user pastes the JSON in Grafana and the web UI guides them to select a Prometheus data source (which can still be provisioned automatically). This approach would work in any OS while also making it easier to add the Trin Dashboard to Grafana instances without having to input credentials into the terminal. This template could also be uploaded to the Grafana Dashboards website to make it easier to import.

Or we could also replace nanotemplate with another templating engine which can handle this use case properly and keep the subcommand. I don't like this approach much because, imho, configuring a Grafana instance should be out of scope of the main software, but I'm willing to do it if you prefer this option.

Assuming the subcommand worked (it used to), didn't it work on Windows?

[KolbyML]

If you want a think I good solution would be doing what I did for Trin Execution https://github.com/ethereum/trin/tree/master/trin-execution/metrics

You can rename the folder from etc to something like metrics or dashboards to be more readable.

This way anybody could run metrics easier then our current system for trin, just docker compose up and they would be live

[Ktl-XV]

I agree, using docker compose up is way simpler.
I'll update the PR.
Thanks

[KolbyML]

If you want you can also delete the ## Metrics setup no docker, I don't think we should keep it as

• it is more complex to maintain especially as people are unlikely to use it so nobody will know how it works so they can fix it
• the docker solution is just better

No worries if you don't want to include that in this PR, we can always remove it on a different date

[Ktl-XV]

I'll go ahead and remove it, that way the structure of the new metrics dir can be the same as the one in trin-execution

[Ktl-XV]

Fixed the commit messages.

Thanks @KolbyML for fixing CI