[flyte2] Instrument the runs service DB repository layer with Prometheus metrics

[pingsutw]

Part of #7445. Depends on #7446 (the /metrics endpoint + Scope must exist first).

Summary

Add Prometheus metrics to the runs service database repository layer so we can observe DB call volume, error rates, and latency per operation.

Background

The repository implementations live in runs/repository/impl/ (e.g. task.go, trigger.go, and the run repo). These wrap GORM/DB calls and currently emit no metrics — there is no visibility into how often each query runs, how long it takes, or how often it fails.

What to do

1. Thread the metrics Scope (from [flyte2] Add /metrics endpoint and initialize metrics Scope in the app framework #7446, available via app.SetupContext.Scope) into the repository constructor(s). runs/setup.go calls repository.NewRepository(sc.DB, cfg.Database) and impl.NewProjectRepo(sc.DB) — extend these (or wrap the repo) to accept a promutils.Scope.

2. For each DB operation (create/get/list/update/delete), record:

   • call count (labeled by operation name)
   • error count (labeled by operation name)
   • latency (a Prometheus timer / stopwatch)

   A small helper that wraps a DB call with start := time.Now(); defer timer.Stop() + counter increments keeps this DRY.

Acceptance criteria

• /metrics exposes per-operation DB call count, error count, and latency for the runs repository.
• Metrics are created once (no duplicate-registration panics) using a dedicated sub-scope, e.g. scope.NewSubScope("db").
• Unit tests assert that a repository operation increments the expected counter / records latency.

Pointers

• runs/repository/impl/ — repository implementations to instrument.
• runs/repository/repository.go (the NewRepository constructor) and runs/setup.go:40 where it's called.
• flytestdlib/promutils/scope.go — Scope helpers (MustNewCounter, MustNewStopWatch, NewSubScope).

Notes for contributors

• Keep label cardinality low: label by operation name, never by row IDs / project / user values.
• This can be done independently of [flyte2] Add gRPC/Connect RPC metrics interceptor to the runs service #7447 (RPC interceptors); both consume the same Scope.

[runllm]

To instrument the runs service DB repository layer with Prometheus metrics, thread a promutils.Scope into the repository constructors, then use MustNewCounter for call/error counts and MustNewStopWatch for latency, labeling by operation name. Use a dedicated sub-scope (e.g., scope.NewSubScope("db")) to avoid metric name collisions and ensure metrics are registered only once. Wrap each DB operation (create/get/list/update/delete) to increment counters and record latency, following patterns in flytestdlib/promutils/scope.go and existing gormimpl metrics.

Unit tests should verify that repository operations increment the correct counters and record latency. Avoid high-cardinality labels; only label by operation name, not by row/project/user. For reference, see how metrics are set up and used in flyteadmin/pkg/repositories/gormimpl/metrics.go and scope.go.

Would you like a sample code snippet for the helper or more detail on metric registration?

Sources:

• flyteadmin/pkg/repositories/gormimpl/metrics.go
• flytestdlib/promutils/scope.go

---

This is an AI-generated response and your feedback is appreciated! Please leave a 👍 if this is helpful and 👎 if it is not.

Mention @RunLLM to ask follow-up questions. See runllm.com for more!