feat: Chain & explorer Prometheus metrics

[vbaranov]

Resolves #10064

Motivation

Add chain & explorer metrics to /metrics endpoint.

Changelog

New metrics exposed at /metrics endpoint:

# TYPE weekly_new_wallet_addresses_number gauge
# HELP weekly_new_wallet_addresses_number Number of new wallet addresses in the last 7 days
weekly_new_wallet_addresses_number 65210
# TYPE weekly_new_tokens_number gauge
# HELP weekly_new_tokens_number Number of new tokens detected in the last 7 days
weekly_new_tokens_number 1551
# TYPE weekly_active_addresses_number gauge
# HELP weekly_active_addresses_number Number of active EOA addresses (participated in transactions in to/from) in the last 7 days
weekly_active_addresses_number 49046
# TYPE weekly_deployed_smart_contracts_number gauge
# HELP weekly_deployed_smart_contracts_number Number of deployed smart-contracts in the last 7 days
weekly_deployed_smart_contracts_number 5734
# TYPE weekly_new_token_transfers_number gauge
# HELP weekly_new_token_transfers_number Number of new token transfers detected in the last 7 days
weekly_new_token_transfers_number 138388
# TYPE weekly_verified_smart_contracts_number gauge
# HELP weekly_verified_smart_contracts_number Number of verified smart-contracts in the last 7 days
weekly_verified_smart_contracts_number 0
# TYPE weekly_success_transactions_number gauge
# HELP weekly_success_transactions_number Number of successful transactions in the last 7 days
weekly_success_transactions_number 190598

Checklist for your Pull Request (PR)

• If I added new functionality, I added tests covering it.
• If I fixed a bug, I added a regression test to prevent the bug from silently reappearing again.
• I checked whether I should update the docs and did so by submitting a PR to https://github.com/blockscout/docs
• If I added/changed/removed ENV var, I submitted a PR to https://github.com/blockscout/docs to update the list of env vars at https://github.com/blockscout/docs/blob/master/for-developers/information-and-settings/env-variables.md and I updated the version to master in the Version column. Changes will be reflected in this table: https://docs.blockscout.com/for-developers/information-and-settings/env-variables.
• If I added new DB indices, I checked, that they are not redundant with PGHero or other tools.
• If I added/removed chain type, I modified the Github CI matrix and PR labels accordingly.

[k1rill-fedoseev]

Was an example from the PR description fetched from a live instance? How it's possible that weekly_new_wallet_addresses_number is larger than weekly_active_addresses_number?

[k1rill-fedoseev]

It's going to be executed synchronously right, each metric one by one? Can we realistically hit a 1 hour duration for all queries in total, so that it will impact interval duration? Does it make sense to run them concurrently?

[vbaranov]

Good point, I wrapped all metrics to asynchronous task in c400611.

[k1rill-fedoseev]

If set_metrics() is synchronous and blocking, then intervals between calls to set_metrics will be greater than 1 hour and can become uneven. I think it might make sense to either make set_metrics asynchronous or switch the order of this 2 statements.

[vbaranov]

I've put schedule_next_run before running setting metrics task. c400611

[vbaranov]

Was an example from the PR description fetched from a live instance? How it's possible that weekly_new_wallet_addresses_number is larger than weekly_active_addresses_number?

That was a local run - so it might happen because of accounts participated in token transfers, internal transactions etc, and current version of active accounts query takes into account only transactions. I extended the query for active accounts with join of extracting active users from token transfers and internal transactions - though this will increase query execution time.