Observability

sigMAX exposes runtime behavior through logs, metric events, trace events and deployment monitoring. These signals help diagnose requests and resource use; agreements separately record evidence about generated artifacts and validation.

The distinction between Core and Pro is deployment and execution isolation. The inspected implementation does not justify treating all metrics or traces as exclusive to Pro.

Runtime Signals

The Rust primitive layer provides bounded instrumentation for generated handlers.

Logs

Simple messages and structured events with typed fields.

Metrics

Counter deltas, gauge values and histogram observations.

Traces

Span begin/end events, attributes, events and errors.

Request context

Request identifiers, trace context, route information and deadline state.

These primitives emit Rust tracing events in the current implementation. A metric primitive is not, by itself, a Prometheus scrape endpoint. A trace event does not establish a complete OpenTelemetry or Zipkin export pipeline.

The host bounds event counts, fields and text sizes. Business modules use these primitives instead of writing directly to collector clients.

Deployment Monitoring

The development topology includes the following managed services:

Service	Observed role
cAdvisor	Collects container resource metrics.
VictoriaMetrics	Scrapes cAdvisor every 10 seconds; the current topology uses a persistent volume and 30-day retention.
Zipkin	Provides a tracing service for configured integrations; the current topology uses in-memory storage.
Studio monitoring UI	Shows CPU usage, working-set memory, received/transmitted network traffic and deployment state.

Monitoring is a selectable project extent with a WireGuard dependency. Studio also proxies monitoring queries through its interface; the registry dependency does not make every query a VPN request. See Networking and identity for service exposure. Zipkin’s in-memory configuration does not preserve traces across service restarts.

Container logs are available through the engine and Studio’s log views. The actual collector, retention and export configuration determines which signals are stored and correlated. Grafana or Loki should not be assumed to be bundled from the existence of logs or metrics primitives.

What To Inspect

Failed request

Correlate the route, component, request identifier and deployed artifact version. Check input validation, denied capabilities, binding failures, fuel exhaustion, execution timeout and output rendering errors.

Busy runtime

Inspect pool concurrency, waiting requests, instance replacement and container resources. performance and safer have different instance-refill costs, as described in the Rust runtime lifecycle.

A healthy container or a successful /healthz response does not establish business correctness. Use contract-specific API scenarios and their recorded validation evidence for that question.

Pro Execution Visibility

The Pro architecture adds Kubernetes, KubeVirt and COS2000 to the execution path. Its operational view needs to relate a host request to the VM executor and the artifact it ran.

COS2000 implements its own Prometheus-compatible metrics endpoint on the management interface. A dedicated collector identity can read metrics without receiving the controller’s management role. The executor exposes invocation results, fuel and memory use, instance behavior and engine diagnostics. These are executor signals, separate from the container metrics collected by cAdvisor.

Scrape each executor’s identity directly when attributing VM metrics. A single load-balanced endpoint can hide which executor produced a sample. The COS2000 page also describes its local diagnostic screens and service interfaces.

The inspected Rust runtime repository does not contain the complete Pro deployment or telemetry bridge. End-to-end correlation, VM lifecycle events and executor failures must be verified against the actual Pro integration before they are advertised as available features.

Signals And Agreements

Operational question	Relevant evidence
What happened during a request?	Correlated logs and trace events.
Where are resources being consumed?	Container or VM monitoring and measured execution behavior.
Which code was generated and validated?	Binary and component agreements, digests and reports.
Did the specified behavior pass?	Recorded API scenarios and their validation results.

The implementation references are runtime/src/primitives.rs, studio/apps/topology/src/monitoring.ts and the monitoring service lifecycle in studio/apps/topology/src/docker.ts.