Expose traces and metrics over MauiDevFlow for Sherpa-native observability

[Redth]

Summary

MAUI Sherpa is planning a new in-app Observability surface for the .NET 10 / MAUI diagnostics story. For the first version, we want to use MauiDevFlow as the transport/discovery layer instead of introducing a separate OTLP receiver, external dashboard, or Docker dependency.

This issue requests MauiDevFlow support for traces + metrics endpoints/streams that Sherpa can consume and render natively.

Why MauiDevFlow is the right place for this

MauiDevFlow already solves the hard part that Sherpa would otherwise have to reinvent:

• agent discovery and broker registration
• app connectivity across desktop/device/emulator scenarios
• per-app HTTP endpoints
• live WebSocket streaming patterns
• existing profiler/session concepts

Sherpa already consumes MauiDevFlow for logs, network, sensors, profiling, and app inspection. Reusing that same connection model for observability would give us a much cleaner developer experience than asking Sherpa to become a generic OTLP collector first.

MVP request

For the first version, it is acceptable if this feature requires the target app to include MauiDevFlow support (for example AddMauiDevFlowAgent() / current equivalent).

Please add a stable observability contract that lets a client like Sherpa consume:

• traces
• metrics
• capability/status information
• replay + live streaming
• enough app/resource metadata to filter multiple connected apps/resources cleanly

Important scope decision

For the initial implementation, we want to start with the profiler data MauiDevFlow already has rather than require fully generic OpenTelemetry capture from day one.

That means:

• start with existing profiler spans as the trace-like source
• start with existing live profiler/perf metrics as the metrics source
• consider deeper Activity / Meter capture later if the first slice is too limited

Proposed contract shape

The exact API shape can vary, but Sherpa needs something intentionally supported and versionable.

A possible shape would be:

• GET /api/otel/status
• GET /api/otel/traces
• GET /api/otel/traces/{traceId}
• GET /api/otel/metrics
• WS /ws/otel

Or separate streams such as:

• WS /ws/otel/traces
• WS /ws/otel/metrics

If maintainers would rather extend the existing profiler contract instead of introducing /api/otel/*, that could also work. The main need is a documented, capability-gated contract that downstream tools can rely on.

Trace data expectations

At minimum, the trace side should expose enough information for a Sherpa trace viewer:

• traceId
• spanId
• parentSpanId
• name
• kind
• status
• start/end timestamps or equivalent duration fields
• tags/attributes
• error information
• app/resource metadata for filtering/grouping
• replay/cursor support for incremental reads

This is very close to what the current profiler span model already appears to provide.

Metrics expectations

For v1, metrics can start with the live perf/profiler metrics MauiDevFlow already surfaces or computes, for example:

• FPS
• frame timing / jank indicators
• managed memory
• native memory
• CPU
• GC counts
• thread count
• UI stall counts
• timestamp + app/resource metadata

Sherpa can render these as cards/trends/tables without requiring a full metrics backend.

Sherpa scenarios this unlocks

This work would let Sherpa build:

• a top-level Observability page under Tools
• filtering by connected app/resource
• an observability inspector window with Overview / Traces / Metrics tabs
• a shortcut from the existing App Inspector / DevFlow flow into observability for the selected app
• clear upgrade messaging when an older agent does not advertise observability support

Non-goals for this first cut

This request is not asking MauiDevFlow to:

• become a full generic OTLP collector
• replicate the Aspire Dashboard
• add full log ingestion as part of the first observability slice
• solve all future OpenTelemetry semantics on day one

This is specifically about a DevFlow-first, Sherpa-native traces + metrics experience.

Suggested acceptance criteria

• compatible agents can advertise observability capability
• Sherpa can discover that capability through the existing broker/agent model
• traces can be replayed and streamed live
• metrics can be replayed and streamed/polled live
• multiple connected apps are distinguishable/filterable
• older agents fail gracefully with explicit capability/version absence

Follow-up / future phases

After the first version proves out, future work could consider:

• deeper ActivityListener-based capture
• deeper MeterListener-based capture
• richer OTel-style resource/attribute metadata
• a generic OTLP path for non-DevFlow apps if that becomes important later