[RPC Metric Part 1] Support two basic metrics in RPC client : Latency and error rate by guandali · Pull Request #89 · smartcontractkit/chainlink-framework

guandali · 2026-03-13T08:07:42Z

Description

Allow RPC client to capture two metrics, so it later can be exported to beholder

Requires Dependencies

Resolves Dependencies

…ency, RPC error rate

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a3174e7ea3

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

multinode/go.mod

vlfig

Couple of comments, grab me if you need.

vlfig · 2026-03-18T18:10:43Z

metrics/rpc_client.go

+// RPCClientMetricsConfig holds labels for RPC client metrics.
+// Empty strings are allowed; they will still be emitted as labels for filtering.
+type RPCClientMetricsConfig struct {
+	Env         string // e.g. "staging", "production"


I don't think this label should ever be populated by the application itself.

vlfig · 2026-03-18T18:13:27Z

metrics/rpc_client.go

+	Env         string // e.g. "staging", "production"
+	Network     string // chain/network name
+	ChainID     string // chain ID
+	RPCProvider string // RPC provider or node name (optional)


Where does this come from? I'd imagine this being called from logResult in rpc_client.go.

vlfig · 2026-03-18T18:18:27Z

metrics/rpc_client.go

@@ -0,0 +1,125 @@
+// RPC client observability using Beholder.


Instead of a new module I'd imagine this becoming an expansion of metrics/client.go, which already has a (promauto) latency metric, to 1) include beholder as a "target" like in metrics/multinode.go; and 2) add the request error rate metric.

vlfig · 2026-03-18T18:26:04Z

docs/rpc_observability.md

@@ -0,0 +1,54 @@
+# RPC Observability (Beholder)


Not sure you intended to commit this. I do like the idea of having a /docs folder in this style but I think that's better pursued with a broader effort. Leaving such a slim slice here would end up be more confusing, I think.

vlfig · 2026-03-18T18:26:31Z

docs/rpc_observability.md

+
+Create `RPCClientMetrics` with `metrics.NewRPCClientMetrics(metrics.RPCClientMetricsConfig{...})` and pass it as the last argument to `multinode.NewRPCClientBase(...)`. The follow-up interface refactor will make it easier for multinode/chain integrations to supply `env`, `network`, `chain_id`, and `rpc_provider`.
+
+## Follow-up: multinode integration (PR 2)


Better not mix the plan of what to do with description of what is.

vlfig

Couple of comments. Do tag Dmytro once you feel we're past these. I think we'll need approval from someone other than me.

vlfig · 2026-03-20T18:13:17Z

metrics/client.go

 	RPCCallLatency = promauto.NewHistogramVec(prometheus.HistogramOpts{
 		Name: "rpc_call_latency",
-		Help: "The duration of an RPC call in milliseconds",
+		Help: "The duration of an RPC call in seconds",


You sure about this?

vlfig · 2026-03-20T18:38:11Z

metrics/client.go

+	rpcCallLatencyBeholder     = "rpc_call_latency"
+	rpcCallErrorsTotalBeholder = "rpc_call_errors_total"


If we're defining these, let's use them above.

vlfig · 2026-03-20T18:47:10Z

metrics/client.go

+}
+
+// RPCClientMetricsConfig holds fixed labels for an RPC client instance.
+type RPCClientMetricsConfig struct {


If this is going to be called from chainlink-evm's logResult, If I'm reading this correctly, the only "static" fields are ChainFamily and ChainID, no? The others come from the request and would be passed on each increment, not when creating the metrics instance. Did you test locally logResult calling RecordRequest instead of RPCCallLatency directly?

vlfig · 2026-03-20T18:53:13Z

metrics/client.go

+		latency:     latency,
+		errorsTotal: errorsTotal,


maybe call them latencyHist and errorsCounter for clarity?

vlfig · 2026-03-20T19:00:31Z

metrics/client.go

+// NoopRPCClientMetrics is a no-op implementation for when metrics are disabled.
+type NoopRPCClientMetrics struct{}
+
+func (NoopRPCClientMetrics) RecordRequest(context.Context, string, time.Duration, error) {}
+
+var _ RPCClientMetrics = NoopRPCClientMetrics{}


I'm not exactly a golang wizz, but is this necessary?

that's compile time interface check, recommended here

publish two basic metrics from the RPC client into Beholder: RPC lat…

a3174e7

…ency, RPC error rate

chatgpt-codex-connector bot reviewed Mar 13, 2026

View reviewed changes

multinode/go.mod Outdated Show resolved Hide resolved

update

24a83d3

guandali requested a review from a team as a code owner March 13, 2026 08:19

product-security-plaid-production bot requested a review from dhaidashenko March 13, 2026 08:20

guandali and others added 8 commits March 16, 2026 14:38

update

2f3fab6

update

b892ff4

revert changes

b5471e0

update

0b3bc02

update

65f6952

update

0e4e902

update

cd5fc94

Merge branch 'main' into lli/rpc-beholder-metric

2925e01

guandali mentioned this pull request Mar 17, 2026

[RPC Metric Part 2] RPC Metrics Integration in Multinode #91

Open

guandali changed the title ~~publish two basic metrics from the RPC client into Beholder: Latency and error rate~~ [RPC Metric Part 1] publish two basic metrics from the RPC client into Beholder: Latency and error rate Mar 17, 2026

guandali changed the title ~~[RPC Metric Part 1] publish two basic metrics from the RPC client into Beholder: Latency and error rate~~ [RPC Metric Part 1] Support two basic metrics in RPC client : Latency and error rate Mar 17, 2026

vlfig requested changes Mar 18, 2026

View reviewed changes

update

7a913aa

guandali requested a review from vlfig March 20, 2026 14:45

vlfig reviewed Mar 20, 2026

View reviewed changes

		@@ -0,0 +1,125 @@
		// RPC client observability using Beholder.


		Create `RPCClientMetrics` with `metrics.NewRPCClientMetrics(metrics.RPCClientMetricsConfig{...})` and pass it as the last argument to `multinode.NewRPCClientBase(...)`. The follow-up interface refactor will make it easier for multinode/chain integrations to supply `env`, `network`, `chain_id`, and `rpc_provider`.

		## Follow-up: multinode integration (PR 2)

		rpcCallLatencyBeholder = "rpc_call_latency"
		rpcCallErrorsTotalBeholder = "rpc_call_errors_total"

Conversation

guandali commented Mar 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Requires Dependencies

Resolves Dependencies

Uh oh!

chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

vlfig left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vlfig left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

guandali commented Mar 13, 2026 •

edited

Loading