Feature: opt-in metrics and tracing hooks

[HarshaNalluru]

Description

Optional hooks to emit query latency and counts to a user-provided sink.

Use case

Teams running Moss in production want to observe query latency and volume without vendor lock-in.

Proposed solution

Add opt-in callbacks for query timing and counts that users can wire to their own metrics or tracing, off by default. Moss docs: https://docs.moss.dev/docs/start/what-is-moss Contributing guide: https://github.com/usemoss/moss/blob/main/CONTRIBUTING.md

Alternatives considered

No response

[Adityacrypto-del]

Can you please assign this issue to me.

[Syedowais312]

Hey @HarshaNalluru
looked into this a bit.
The core query engine isn't in this repo (the moss crate is a private crate distributed as prebuilt binaries per the bindings' Cargo.toml), so the hooks would need to live in each SDK's wrapper layer, timing around the native/FFI call rather than instrumenting the engine itself. There's already a precedent for this shape in the mutation APIs OnProgress callbacks in Go (mutation.go), JS (internalMossClient.ts), etc. so I'd mirror that pattern for query().
One thing worth deciding before start: should this be a plain, dependency-free callback (OnQueryMetrics func(QueryMetrics)) that users wire up to whatever they use the OTel, Prometheus, logs or should the SDK bake in OpenTelemetry directly (spans/metrics via the OTel Go SDK)? The Go SDK currently has zero third-party deps, so going the OTel route would add one for every user, even those who don't need it. I'd lean toward the plain callback for that reason, but wanted to check since I've been contributing to otel-collector and can help build the OTel-specific wiring too if that's the direction you'd prefer.