[Art Studio] Observability follow-ups (C#/infra): register dropped ActivitySources + per-stack Deployment name #458

New Issue

2026-07-08T01:59:19Z

spikerj commented

2026-07-08 01:59:19 +00:00

Follow-ups split out of #457 (whose P2+P3 backend slice shipped in spikersoft-backend PR #182). These two are C#/infra and decision-gated; each needs a go-ahead before turning on.

Note: the third item originally listed here — art_pipe worker.py OTLP consumer spans for true C#↔Python traces — is a duplicate of the existing #430 (under epic #428, with #431 covering the Python→Seq log side). The C# side already injects _traceparent via WorkerTraceContext.Inject, and #182's artpipe.worker.execute span measures the subprocess from the .NET side; #430 is what lights up the model steps inside Python. Tracking that work there, not here.

P4 — register dropped ActivitySources

SpikerSoft.MessageBus and SpikerSoft.Api create ActivitySources that aren't added to the tracer, so those spans never export. Registering them lights up API-turn and bus-publish spans in Jaeger, but increases global span volume — decision: confirm we want the extra cardinality/cost (and pick a sample ratio) before turning them on.

P5 — per-stack `Deployment__Name`

Give each ArtPipe stack file a distinct Deployment__Name so DeploymentName in Seq/traces differentiates stacks, not just ServiceName/MachineName. Small change across the per-stage/per-model stack files in spikersoft-infrastructure. Mostly cosmetic given MachineName already identifies the container — low priority.

Parent: ProArt Art Studio epic #346 / trace-correlation epic #428. Conventions: telemetry-correlation rule.

Follow-ups split out of #457 (whose P2+P3 backend slice shipped in spikersoft-backend PR #182). These two are C#/infra and decision-gated; each needs a go-ahead before turning on. > **Note:** the third item originally listed here — art_pipe `worker.py` OTLP consumer spans for true C#↔Python traces — is a **duplicate of the existing #430** (under epic **#428**, with #431 covering the Python→Seq log side). The C# side already injects `_traceparent` via `WorkerTraceContext.Inject`, and #182's `artpipe.worker.execute` span measures the subprocess from the .NET side; #430 is what lights up the model steps *inside* Python. Tracking that work there, not here. ## P4 — register dropped ActivitySources `SpikerSoft.MessageBus` and `SpikerSoft.Api` create `ActivitySource`s that aren't added to the tracer, so those spans never export. Registering them lights up API-turn and bus-publish spans in Jaeger, but increases global span volume — **decision:** confirm we want the extra cardinality/cost (and pick a sample ratio) before turning them on. ## P5 — per-stack `Deployment__Name` Give each ArtPipe stack file a distinct `Deployment__Name` so `DeploymentName` in Seq/traces differentiates stacks, not just `ServiceName`/`MachineName`. Small change across the per-stage/per-model stack files in **`spikersoft-infrastructure`**. Mostly cosmetic given `MachineName` already identifies the container — low priority. Parent: ProArt Art Studio epic #346 / trace-correlation epic #428. Conventions: `telemetry-correlation` rule.

spikerj referenced this issue

2026-07-08 01:59:28 +00:00

[Art Studio] End-to-end observability for the new ArtPipe worker stage actions (Jaeger spans + correlated Seq logs) #457

spikerj changed title from ~~[Art Studio] Observability follow-ups: art_pipe worker.py OTLP spans (C#↔Python) + ActivitySource registration + per-stack Deployment name~~ to [Art Studio] Observability follow-ups (C#/infra): register dropped ActivitySources + per-stack Deployment name

2026-07-08 02:01:47 +00:00

spikerj commented

2026-07-11 23:26:30 +00:00

Resolved: P4 (register dropped ActivitySources) in spikersoft-backend PR #187 (merged — behind an opt-in gate with source-scoped sample ratio, satisfying the decision gate), P5 (per-stack Deployment__Name) in spikersoft-infrastructure PR #13 (merged). The third item was re-homed to #430 per the ticket note. Closing.