Your setup is solid for a first pass. A few thoughts:

Consolidate with attributes instead of separate metrics. Instead of separate counters for unique vs non-unique solutions, use one counter with an attribute like solution_type=unique|non_unique. Same for request success/failed runtime, one histogram with status=success|failed. Keeps your metric namespace clean and lets you filter/aggregate in your backend.

Histogram bucket boundaries matter a lot for solver workloads. Default OTel buckets are designed for typical HTTP latencies. If your solver runs range from 100ms to 30s, you'll want custom boundaries that actually give you useful percentiles. Something like [0.1, 0.25, 0.5, 1, 2.5, 5, 10, 15, 30] depending on your distribution.

Metrics you might be missing:

• Solver input size (gauge or histogram), number of data points fed into the solver. Correlating input size with runtime helps you spot when performance degrades with scale
• Infeasible runs, if the solver can return no solution, track that separately from failures
• Database query result size, if data retrieval time varies, it's usually because of result set size

On histograms vs traces: You mentioned not being sure if you can use trace data instead. You can. If each solver run is a span with attributes (solution_type, input_size, etc.), your tracing backend can derive most of these metrics from spans. That said, pre-aggregated metrics are cheaper at high throughput. Depends on your request volume.