Problem
Forge's Go telemetry runtime can export traces and metrics, and Rustic AI already instruments agent message processing through TelemetryMixin. However, each Forge-supervised Python agent runs as a separate plain rustic_ai.forge.agent_runner process without an OpenTelemetry SDK tracer provider or exporter.
TelemetryMixin intentionally becomes a no-op when no provider has been installed. Passing TRACEPARENT to the child preserves propagation metadata but does not initialize a provider or export spans. As a result, enabling Forge telemetry captures the Go control-plane spans but not the Rustic AI agent-processing and message-sending spans needed by the Studio Observe views.
The former Rustic AI server handled this at the process-host boundary:
- the API server was launched with
opentelemetry-instrument and OTLP environment configuration;
- Ray workers, which were separate processes, initialized a
TracerProvider and OTLPSpanExporter in RayAgentWrapper.
Forge should provide the equivalent process bootstrap for the Python workloads it supervises. It should not duplicate Rustic AI's span instrumentation or require individual agents to configure telemetry.
Relevant code
forge-python/src/rustic_ai/forge/agent_runner.py starts ForgeAgentWrapper without telemetry bootstrap.
forge-go/supervisor/process.go passes TRACEPARENT, but context propagation alone does not install an SDK provider.
- Rustic AI Core's
TelemetryMixin already emits rustic_ai:process_message and rustic_ai:send_message spans when a real provider is present.
Proposed direction
- Define the telemetry environment contract for Forge-supervised Python processes.
- When Forge telemetry is enabled, start Python workloads with equivalent OpenTelemetry bootstrap, such as Python auto-instrumentation, and point them at the selected Forge OTLP collector or external endpoint.
- Include the required SDK/exporter packages in the supervised runtime only as appropriate for the chosen implementation.
- Preserve the existing W3C trace context from the Go control plane through the agent process.
- Set useful resource identity (
service.name) and agent/guild attributes without placing credentials or message bodies in telemetry.
- Flush and shut down providers when an agent exits.
- Keep telemetry disabled/no-op when Forge telemetry is disabled.
Acceptance criteria
- A message sent from Forge's WebSocket gateway produces one connected trace containing both Go control-plane spans and Rustic AI agent processing/sending spans.
- Separate agent processes export to
desktop_sqlite and external_otlp modes.
- Existing Rustic AI
TelemetryMixin instrumentation is reused without changes to individual agent implementations.
- Disabled telemetry adds no exporter activity and does not require a running collector.
- Tests cover propagation, multi-agent traces, clean shutdown, and exporter failure without leaking payloads or credentials.
This is a future observability improvement and does not block guild launch or execution.
Problem
Forge's Go telemetry runtime can export traces and metrics, and Rustic AI already instruments agent message processing through
TelemetryMixin. However, each Forge-supervised Python agent runs as a separate plainrustic_ai.forge.agent_runnerprocess without an OpenTelemetry SDK tracer provider or exporter.TelemetryMixinintentionally becomes a no-op when no provider has been installed. PassingTRACEPARENTto the child preserves propagation metadata but does not initialize a provider or export spans. As a result, enabling Forge telemetry captures the Go control-plane spans but not the Rustic AI agent-processing and message-sending spans needed by the Studio Observe views.The former Rustic AI server handled this at the process-host boundary:
opentelemetry-instrumentand OTLP environment configuration;TracerProviderandOTLPSpanExporterinRayAgentWrapper.Forge should provide the equivalent process bootstrap for the Python workloads it supervises. It should not duplicate Rustic AI's span instrumentation or require individual agents to configure telemetry.
Relevant code
forge-python/src/rustic_ai/forge/agent_runner.pystartsForgeAgentWrapperwithout telemetry bootstrap.forge-go/supervisor/process.gopassesTRACEPARENT, but context propagation alone does not install an SDK provider.TelemetryMixinalready emitsrustic_ai:process_messageandrustic_ai:send_messagespans when a real provider is present.Proposed direction
service.name) and agent/guild attributes without placing credentials or message bodies in telemetry.Acceptance criteria
desktop_sqliteandexternal_otlpmodes.TelemetryMixininstrumentation is reused without changes to individual agent implementations.This is a future observability improvement and does not block guild launch or execution.