Skip to content

Define exact terminal accounting and causal provenance beyond sampled task resources #454

Description

@schickling-assistant

Problem

A bounded periodic collector can attribute managed-task CPU, memory, and process history through st2's existing per-task cgroup scopes. That deliberately provides sampled, not exact, accounting: it can miss the final scrape interval and tasks shorter than the interval. It also cannot answer causal questions such as which process modified a file or opened a connection.

The first resource-observation increment should stay simple. The more exact contract needs a separate decision because it changes st2 lifecycle and durable-state responsibilities.

Design boundary

Investigate these layers independently:

  1. Exact terminal resource accounting: capture final cpu.stat and memory.peak when the task cgroup becomes empty, before systemd collects it. Define incarnation identity, idempotent terminal records, crash recovery, and bounded retention.
  2. Lifecycle event contract: consider an st2-owned typed start/terminal event feed while an external collector continues to own periodic sampling and metrics.
  3. Broader causal provenance: keep kernel process/file/network collection outside st2. st2 should supply stable managed-task identity and its actual execution-scope binding; a separate collector can join that with kernel evidence.

Do not infer stable identity from the transient systemd unit name. Scope names are intentionally incarnation-unique and their escaped task fragment is lossy. Do not turn st2 into a Prometheus server or provenance database without evidence that the external collector boundary is insufficient.

Decision needed

Establish which consumers require exact per-incarnation totals or causal provenance, then choose the smallest contract that satisfies those queries. Preserve sampled resource history as the default low-complexity path.

Related: #208 covers resource envelopes, limits, and leases. This issue covers observation fidelity and provenance, not admission or containment.

Posted on behalf of @schickling
field value
agent_identity mbp2025.direct.omp.5tek2r48
session mbp2025.5tek2r48
agent_persona generalist
agent_supervisor unavailable
agent_tool OMP
agent_tool_version 18.0.11
agent_runtime OMP 18.0.11
tooling_profile dotfiles@4cc7b25

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

    area:execExec backend and process-group management · Set: manualarea:identityAgent, session, run, and launch-generation identity · Set: manualarea:telemetryOpenTelemetry and observability instrumentation · Set: manualorigin:agentFiled or primarily produced by an AI agent · Set: manualstate:open-design-questionUnresolved design choice requiring explicit alignment before implementation · Set: manualtype:featureNew user-visible or system capability · Set: manual

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions