graphprotocol / graphprotocol/graph-node

Second Ethereum RPC metrics are not tracked

Open
#2,537 0 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

chains/ethereum monitoring
Dominant language
Rust
Stars
3.2k
Forks
1.1k
Avg merge
4d 1h
Merged PRs (30d)
1

Description

Do you want to request a feature or report a bug?
Bug

What is the current behavior?
When adding a second Ethereum RPC, we lose visibility in Grafana of the time for eth_getLogs calls - deployment_eth_rpc_request_duration. This was done recently for the matic network on the Hosted Service.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.
Add two Ethereum RPCs, the second of which should be a non-archive node (so it is used for eth_getLogs calls). The deployment_eth_rpc_request_duration is no longer tracked. eth_call duration will be tracked (as those hit the archive URL)

Hypothesis: possibly graph node tries to register the same metric twice, one for each url, which is an error

What is the expected behavior?
Metrics should be tracked for all nodes - ideally we should also be able to distinguish metrics by node?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue names no files or tests. Start by reproducing the setup with two Ethereum RPCs, then trace registration and collection of deployment_eth_rpc_request_duration for eth_getLogs and eth_call. Done means request-duration metrics remain available for every configured node, ideally distinguishable by node.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
blockchain, observability
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.