Severity: 🟡 · Criterion: K11 (Observability) · Phase: P6 · Status (review): 🆕
File(s): src/DockerUpdateGuard.Telemetry/TelemetryActivityNames.cs:13,28,33,38,43; src/DockerUpdateGuard.Telemetry/TelemetryTagNames.cs:33,38,43; spans in use: src/DockerUpdateGuard/Docker/DockerInstanceClient.cs:953, src/DockerUpdateGuard/DockerHub/DockerHubClient.cs:506,566,714; cross-reference metrics src/DockerUpdateGuard/ApplicationTelemetry.cs:111-127
Finding
Of the seven declared TelemetryActivityNames, only two are ever
started as a custom span: DockerHubRequest (DockerHubClient.cs:506,566,714) and
DockerEngineRequest (DockerInstanceClient.cs:953). A repo-wide search confirms zero
usages for ScanRun (scan.run), CveProviderRequest, PortainerRequest,
PortainerAction and PersistenceOperation. Thus there is no parent span for the
central scan lifecycle: the orchestrators do record metrics
(ApplicationTelemetry.RecordScanRun), but open no scan.run activity under
which the DockerHub/Engine child spans and a scan's DB work could be correlated.
The security-critical Portainer action path (stop/kill/restart) and the
CVE provider calls also have no spans — despite reserved names. In parallel, the
tag constants ActionType, ErrorClass and ScanId (TelemetryTagNames.cs:33,38,43)
are set nowhere. (Auto-instrumentation for ASP.NET Core/HttpClient is active via
AddAspNetCoreInstrumentation/AddHttpClientInstrumentation; Portainer actions
are additionally logged via PortainerClientLogging — the loss concerns traces, not logs.)
Impact
Without a scan.run root span, scans cannot be traced end-to-end; the
existing child spans hang uncorrelated under the ASP.NET/background context. For an
observability-centric tool, a noticeable gap in the trace coverage of critical paths
(K11 guiding question), especially for the destructive Portainer path.
Recommendation
In the three orchestrators, wrap the scan run in a scan.run span (ActivityKind.Internal/
Server) (with ScanId/ScanType/ResultStatus tags) and instrument the
Portainer actions with PortainerAction spans (incl. ActionType); otherwise
remove the unused constants (cf. F-041).
Auto-generated from the repository code review. Source of truth: docs/review/findings.md → F-040 (P6), branch review/review-analysis-plan.
Severity: 🟡 · Criterion: K11 (Observability) · Phase: P6 · Status (review): 🆕
File(s):
src/DockerUpdateGuard.Telemetry/TelemetryActivityNames.cs:13,28,33,38,43;src/DockerUpdateGuard.Telemetry/TelemetryTagNames.cs:33,38,43; spans in use:src/DockerUpdateGuard/Docker/DockerInstanceClient.cs:953,src/DockerUpdateGuard/DockerHub/DockerHubClient.cs:506,566,714; cross-reference metricssrc/DockerUpdateGuard/ApplicationTelemetry.cs:111-127Finding
Of the seven declared
TelemetryActivityNames, only two are everstarted as a custom span:
DockerHubRequest(DockerHubClient.cs:506,566,714) andDockerEngineRequest(DockerInstanceClient.cs:953). A repo-wide search confirms zerousages for
ScanRun(scan.run),CveProviderRequest,PortainerRequest,PortainerActionandPersistenceOperation. Thus there is no parent span for thecentral scan lifecycle: the orchestrators do record metrics
(
ApplicationTelemetry.RecordScanRun), but open noscan.runactivity underwhich the DockerHub/Engine child spans and a scan's DB work could be correlated.
The security-critical Portainer action path (stop/kill/restart) and the
CVE provider calls also have no spans — despite reserved names. In parallel, the
tag constants
ActionType,ErrorClassandScanId(TelemetryTagNames.cs:33,38,43)are set nowhere. (Auto-instrumentation for ASP.NET Core/HttpClient is active via
AddAspNetCoreInstrumentation/AddHttpClientInstrumentation; Portainer actionsare additionally logged via
PortainerClientLogging— the loss concerns traces, not logs.)Impact
Without a
scan.runroot span, scans cannot be traced end-to-end; theexisting child spans hang uncorrelated under the ASP.NET/background context. For an
observability-centric tool, a noticeable gap in the trace coverage of critical paths
(K11 guiding question), especially for the destructive Portainer path.
Recommendation
In the three orchestrators, wrap the scan run in a
scan.runspan (ActivityKind.Internal/Server) (withScanId/ScanType/ResultStatustags) and instrument thePortainer actions with
PortainerActionspans (incl.ActionType); otherwiseremove the unused constants (cf. F-041).
Auto-generated from the repository code review. Source of truth:
docs/review/findings.md→ F-040 (P6), branchreview/review-analysis-plan.