Skip to content

Add optional Runtime history and Dashboard durable time ranges #38

Description

@sam2tom

Goal

Add optional durable Runtime resource history for the Core Web Dashboard without changing current-snapshot execution ownership or making a telemetry backend mandatory for Sessions.

This follows the current-snapshot/API/Web work in #30 and Phase 4 of contracts/agents-api/runtime-observability-design.md.

Operator outcome

  • Select a durable time range such as 1h, 6h, or 24h in Runtime monitoring.
  • See CPU utilization, memory usage/limit, compute uptime boundaries, and observation coverage from an explicitly labeled history source.
  • Keep browser-local live samples visually and semantically distinct when no history backend is configured.
  • Preserve exact tenant, Session, Environment, and Runtime-incarnation attribution.

Proposed delivery slices

4A. Optional telemetry export

  • Add an internal provider-neutral exporter seam after a validated current observation is produced.
  • Export cumulative CPU seconds, CPU capacity, memory usage/limit, sample result, and sample duration using the instrument names documented in the design.
  • Keep export asynchronous/bounded so backend failure never fails Session execution or the current observation read.
  • Avoid high-cardinality global Prometheus labels. If Session or Runtime identity is exported, require an operator backend and tenant-isolated resource attributes suitable for authorized queries.
  • No provider-native IDs, labels, paths, errors, or credentials.

4B. History query adapter and public Core extension

  • Define a separate runtimehistory read interface; do not overload runtimeobs.Service or current observation routes.
  • Resolve tenant and Session authorization in Core before querying the backend.
  • Define range, step/downsampling, maximum points/series, whole-request deadline, and response byte limits.
  • Fence series by provider-neutral Runtime incarnation so replacement/restart produces a gap rather than a false continuous line.
  • Return explicit unsupported, unavailable, and partial/coverage metadata; never coerce missing samples to zero.
  • Generate the OpenAPI extension and consume it only through packages/agents-client.

4C. Web durable ranges

  • Add advertised durable ranges only when the history capability is configured.
  • Keep Live as the existing browser-local bounded window and reset it on reload/navigation as today.
  • Label the selected source and freshness. Never merge durable and ephemeral points without an explicit boundary.
  • Preserve the current 2x2 CPU, memory, uptime, and token chart layout; token history remains sourced from canonical Session/Turn usage or a separately authorized history contract, not Runtime telemetry duplication.
  • Retain accessible tabular summaries for latest value and missing points.

Boundaries

  • No PostgreSQL time-series table or product database dependency.
  • No lifecycle action, idle inference, suspension, restart, or allocation mutation.
  • No Kubernetes, E2B, or self-hosted source implementation in this issue.
  • No billing or cost data in Core Web.
  • No browser access to OTLP/Prometheus credentials or direct backend queries.
  • Current snapshot API remains available and correct when history is absent or unhealthy.

Acceptance

  • Core starts and all execution/current-observation workflows pass with history fully disabled.
  • Export/backend outages do not change execution, allocation, observation status, or API latency beyond the configured bounded handoff.
  • Cross-tenant history reads are impossible and tested.
  • Restart/allocation replacement/counter regression creates a gap; no synthetic interpolation or zero fill.
  • Query budgets and retention limits are enforced in service and client tests.
  • Core Web clearly distinguishes Live browser memory from durable backend ranges.
  • Architecture, operator configuration, generated contract, coverage ledger, tests, and deployment acceptance are updated.

Open implementation decision

Qualify one operator backend and transport before implementation. Prefer OTLP-compatible export plus a tenant-authorized query adapter, but record the chosen backend's identity model, retention, downsampling, and query API before adding dependencies.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions