Expand description
§tailtriage-controller
tailtriage-controller manages repeated, bounded capture windows for long-lived services.
Use it when you want to turn capture on, collect one generation, turn capture off, and later start a fresh generation without restarting the process.
For in-process analysis/report generation, use tailtriage-analyzer.
For command-line analysis of saved artifacts, use tailtriage-cli.
§When to use this crate
Use tailtriage-controller when you need repeated arm/disarm windows in one process.
Use tailtriage-core for a single explicit build -> capture -> shutdown run.
Use tailtriage when you want the default entry point with controller support enabled by default (or disabled via Cargo features).
§Installation
cargo add tailtriage-controller§Quick start
output("tailtriage-run.json") configures the base artifact path template. Each activation writes a per-generation artifact with -generation-N in the file name (for example, generation 1 writes tailtriage-run-generation-1.json).
use tailtriage_controller::TailtriageController;
fn main() -> Result<(), Box<dyn std::error::Error>> {
let controller = TailtriageController::builder("checkout-service")
.initially_enabled(false)
.output("tailtriage-run.json")
.build()?;
let _generation = controller.enable()?;
let started = controller.begin_request("/checkout");
started.completion.finish_ok();
let _ = controller.disable()?;
Ok(())
}§Mental model
A controller owns a template plus at most one active generation.
enable()creates a fresh generation from the current template.disable()stops new admissions for that generation.- If no captured requests are still in flight, the generation finalizes immediately.
- Otherwise the generation enters closing and finalizes after its already-admitted captured requests drain.
- The next
enable()creates a new generation with a new artifact path.
Requests started while the controller is disabled or closing are inert:
- they preserve request metadata
- they record no capture events
- they never join a later generation
Each activation writes a per-generation artifact whose file name includes -generation-N.
§Minimal TOML example
Use TOML when you want repeatable operational settings, including mode selection.
[controller]
service_name = "checkout-service"
[controller.activation]
mode = "light"
[controller.activation.sink]
type = "local_json"
output_path = "tailtriage-run.json"§Expanded TOML example
[controller]
service_name = "checkout-service"
initially_enabled = false
[controller.activation]
mode = "investigation"
strict_lifecycle = true
[controller.activation.capture_limits_override]
max_requests = 150000
max_stages = 300000
max_queues = 300000
max_inflight_snapshots = 300000
max_runtime_snapshots = 150000
[controller.activation.sink]
type = "local_json"
output_path = "tailtriage-run.json"
[controller.activation.runtime_sampler]
enabled_for_armed_runs = true
mode_override = "investigation"
interval_ms = 250
max_runtime_snapshots = 20000
[controller.activation.run_end_policy]
kind = "auto_seal_on_limits_hit"§Config precedence and reload rules
When TOML is loaded with config_path(...):
service_namefrom TOML overrides the builder value when present.- builder
service_nameis a fallback only when TOML omitsservice_name. initially_enabledfalls back to the builder value when omitted.- activation template settings come from TOML.
- omitted optional activation subfields use TOML contract defaults.
reload_config() updates the template for future generations only.
It does not mutate a generation that is already active.
§Run-end policies
Supported policies:
continue_after_limits_hit(default)auto_seal_on_limits_hit
Behavior:
continue_after_limits_hit: generation stays active after the first truncationauto_seal_on_limits_hit: on the firstlimits_hit, new admissions stop and the generation moves to closing; finalization happens immediately if no captured requests are still in flight, otherwise after they drain
TOML contract:
[controller.activation.run_end_policy]is optional- if that table is present,
kindis required
§Runtime sampler template
The controller can start a Tokio runtime sampler automatically for armed generations.
Important constraints:
- sampler startup still requires an active Tokio runtime
- sampler settings are fixed at activation time
- runtime snapshot retention is still bounded by the resolved core capture limits
§TOML field reference
§[controller]
service_name(optional string): overrides the builder service name when present; must not be emptyinitially_enabled(optional bool): whentrue,build()starts generation1
§[controller.activation]
mode(required string):lightorinvestigationstrict_lifecycle(optional bool, defaultfalse)
§[controller.activation.sink]
type(required string):local_jsonoutput_path(required string forlocal_json): base path template for per-generation files
§[controller.activation.capture_limits_override]
All fields are optional:
max_requestsmax_stagesmax_queuesmax_inflight_snapshotsmax_runtime_snapshots
§[controller.activation.runtime_sampler]
Optional table. Default is disabled.
enabled_for_armed_runsmode_overrideinterval_msmax_runtime_snapshots
§[controller.activation.run_end_policy]
Optional table. If present, kind is required.
kind = "continue_after_limits_hit"kind = "auto_seal_on_limits_hit"
§Important constraints
- at most one generation is active at a time
- active generation settings do not change after activation
- requests remain bound to the generation that admitted them
- controller capture and analysis are separate
- for in-process analysis/report generation, use
tailtriage-analyzer - for command-line analysis of saved artifacts, use
tailtriage-cli
§Related crates
tailtriage: default entry pointtailtriage-core: direct instrumentation lifecycletailtriage-tokio: runtime-pressure samplingtailtriage-axum: Axum request-boundary integrationtailtriage-analyzer: in-process analysis/report generation for completed runstailtriage-cli: command-line analysis of saved run artifacts
Structs§
- Active
Generation State - Metadata for one active generation.
- Controller
Activation Template - One bounded activation template snapshot.
- Controller
Request Completion - Completion token for a request admitted through
TailtriageController. - Controller
Started Request - Result of trying to begin one captured request in a generation.
- Inert
Controller Request Handle - Inert controller request handle metadata stored while disabled/closing.
- Loaded
Controller Config - Parsed controller config loaded from a TOML file.
- Runtime
Sampler Template - Runtime sampler template attached to controller activation settings.
- Tailtriage
Controller - Long-lived live-capture controller for arm/disarm workflows.
- Tailtriage
Controller Builder - Builder for a long-lived
TailtriageController. - Tailtriage
Controller Status - Public status snapshot for reporting controller state.
- Tailtriage
Controller Template - Template configuration that the controller applies to future activations.
Enums§
- Config
Load Error - Errors emitted while loading controller TOML config from disk.
- Controller
Build Error - Errors emitted while building a controller.
- Controller
Inflight Guard - Controller-local in-flight guard wrapper.
- Controller
Queue Timer - Controller-local queue timer wrapper.
- Controller
Request Handle - Instrumentation handle for requests admitted through
TailtriageController. - Controller
Sink Template - Sink/output template used by controller-generated runs.
- Controller
Stage Timer - Controller-local stage timer wrapper.
- Disable
Error - Errors emitted while disarming and finalizing generation artifacts.
- Disable
Outcome - Outcome of calling
TailtriageController::disable. - Enable
Error - Errors emitted when enabling/arming controller capture.
- Generation
State - Current generation state for a controller.
- Reload
Config Error - Errors emitted while reloading controller TOML config.
- Reload
Template Error - Errors emitted while replacing controller activation templates directly.
- RunEnd
Policy - Policy for bounded activation run completion.
- Shutdown
Error - Errors emitted during process shutdown finalization.