Description
Lowest priority in the epic, and blocked on capture rather than on effort.
Both kinds have a confirmed OTel-native producer — azuremonitorreceiver and googlecloudmonitoringreceiver, each documented to emit OTel-format metrics — but neither receiver emitted metric-NAME shape was established by SKT-0007.01, so there is nothing to emit yet. cantfind SK-88 carries the question.
A negative outcome is a legitimate and useful result: if the receivers reproduce the vendor metric names verbatim, this is a transport change rather than an OTel-native form, and both kinds should be downgraded to SCRAPE-ONLY in the verdict record with the evidence. Resolve SK-88 before deciding whether to build anything.
Acceptance Criteria
- #1 SK-88 resolved with evidence and a date
- #2 If the receivers produce a distinct OTel-native name shape, both kinds gain an opt-in lane with families recorded in signals/otlp-metrics.md
- #3 If they do not, signals/otlp-native-verdicts.md is corrected to SCRAPE-ONLY for both with the evidence, and the archtest guard list is extended
Definition of Done
- #1 make gate (build vet test race rw-proto-check spdx-check forbidden-words)
- #2 make blueprint-schema (only if a blueprint field or construct/workload config struct changed)
- #3 DRY_RUN=true go run ./cmd/synthkit -once -dump — inventory diffed against signals/
Implementation Plan
2026-09-05 captured-contract run: implement only owned captured or documented contracts under frozen switches; preserve defaults; root integrates shared changes, verifies safe inventory and exact-SHA CI, and records unconfirmed shapes as capture boundaries.
Implement the two frozen opt-in CSP native lanes in disjoint packages using vendor-sourced names, instruments, units and labels, test first, preserving existing scrape dumps. Root integrates shared hunks, regenerates schema once, validates, reviews the integrated batch, and records family counts. The alternative scrape-only criterion remains not applicable.
Implementation Notes
2026-09-05 retrieval via Context7: azuremonitorreceiver documentation explicitly prefixes scraped names with azure_ and lists azuremonitor.subscription, azuremonitor.subscription_id and azuremonitor.tenant_id resource attributes. Google README only documents metric_name input selection; output naming and resource attributes were not returned, and metadata evidence remains absent. SK-88 is PARTIAL, with a capture boundary stated exactly in cantfind.md. No both-receiver SCRAPE-ONLY verdict or speculative emitter was added.
AC1 remains unchecked: SK-88 is PARTIAL rather than resolved for both receivers. The capture boundary is the authorized terminal outcome for this wave, not completion of the underlying task.
2026-09-06 fallback evidence: current azuremonitorreceiver documentation confirms the exact azure_ metric prefix and the azuremonitor.subscription, azuremonitor.subscription_id, and azuremonitor.tenant_id resource attributes. The Google receiver emitted name and resource envelope remain unresolved, so SK-88 is still partial and no shared CSP verdict or emitter was inferred.
2026-09-06 main-thread resolution of the Google half of SK-88 from upstream source rather than a capture: collector-contrib v0.160.0 googlecloudmonitoringreceiver sets the OTLP metric name to the Cloud Monitoring metric type verbatim, passes unit and description through, puts metric labels on the datapoint unprefixed, sets gcp.resource_type plus bare resource/user/system labels on the resource, and leaves scope empty; GAUGE->Gauge, CUMULATIVE->monotonic cumulative Sum, DELTA->delta Sum, DELTA DISTRIBUTION->delta explicit-bounds Histogram, other DISTRIBUTION kinds dropped. Recorded with file:line in cantfind.md SK-88, signals/otlp-native-verdicts.md and signals/cspgcp.md [slug: cspgcp-otlp-receiver]. Both kinds keep OTEL-NATIVE (different namespace): the receiver forms are distinct from the stackdriver_* and azure_microsoft_* scrape forms, so AC3 does not apply and AC2 is the remaining work. Unparked: the capture boundary is gone; per-family kind/unit/labels for an emitter come from each vendor’s metric list.
2026-09-06: integrated both default-off native lanes at c7fd0225918446e5a65c5a878ec3233f0d81b77f. Azure has 119 descriptor entries and 103 native names; GCP has 115 catalog families and the standalone blueprint emits 113 (the two Cloud SQL PostgreSQL families require a declared PostgreSQL fixture). Family sets, instrument contracts and forward-only name pairings pass. Source references live beside the per-family signals tables. Unconfirmed Azure training and six VNet families, unresolved Vertex and receiver-dropped distributions remain omitted. AC3 is discharged as NOT APPLICABLE by the frozen decision: both receivers have distinct native names; no scrape-only verdict or guard extension was made. just gen ran once; final just check exit 0; explicit safe and native dumps exit 0; local agent-excluded just e2e exit 0. CI 34037668429 success at the full source SHA; publish 34037668503 success. Whole-dump byte identity remains unproven because an unchanged fixed-tick baseline also varies in logs/spans. The complete metric/Loki prefix and existing CSP scrape inventories match; default-off tests pass. No assertion or exemption changed.
Final Summary
2026-09-05: Parked at the exact emitted-contract capture boundary. Azure prefix is documented; Google emitted name/resource shape is unresolved. Obtain receiver output retaining names, instruments, units, scope and attributes before AC2 implementation; AC3 does not apply on current evidence.
2026-09-06: Azure contract evidence improved, but the task remains Parked because the Google half is unresolved. Resume from a retained Google receiver output containing exact names, instruments, units, scope, and attributes.
2026-09-06: SK-88 resolved for both halves (Azure from vendor docs, Google from receiver source at v0.160.0). AC1 checked. Moved to To Do: AC2 (opt-in lanes for csp_azure and csp_gcp from the vendor metric lists) is the remaining implementation work; AC3 does not apply.
Both opt-in CSP native lanes are integrated and verified. AC3 is a conditional alternative resolved as not applicable, not a scrape-only implementation claim. Preserve the recorded full-dump nondeterminism limitation and withheld families.