Put Copilot OpenTelemetry Export Behind an Isolated Collector

GitHub announced enterprise-managed OpenTelemetry export for Copilot activity from VS Code and Copilot CLI on July 8, 2026. The post recommends isolating the receiving collector from the primary observability backend, using dedicated credentials, separate datasets, and defined retention policies. It also advises against pointing developer clients directly at the backend and suggests field budget controls, bounded retries, and central rollback switches.

GitHub announced enterprise-managed OpenTelemetry export for Copilot activity from VS Code and Copilot CLI on July 8, 2026. Primary source: GitHub Changelog, July 8, 2026 https://github.blog/changelog/2026-07-08-enterprise-managed-opentelemetry-export-for-vs-code-and-cli/ . Export availability is only the start. The receiving collector becomes an enterprise ingress point. This is an unexecuted operating plan; signal types, attributes, endpoint requirements, and controls must be checked against current GitHub documentation. php managed clients - private telemetry ingress - dedicated OTel Collector pool - field policy + bounded queue - dedicated backend dataset Do not point every developer client directly at the primary observability backend. Give the collector write-only destination credentials, separate its dataset from production application telemetry, and define retention before rollout. Isolation is not anonymity. Stable user, device, organization, or repository identifiers may still be sensitive. | Category | Initial policy | |---|---| | Product and version | Keep bounded values | | Operation and status | Keep documented enums | | Timing and counts | Keep numeric measures | | Raw prompts or generated code | Drop by default | | File paths and repository URLs | Drop or transform after review | | User identity | Prefer scoped pseudonymous identity | | Free-form errors | Drop raw text; keep reviewed classes | These categories are recommendations, not a description of GitHub's payload. Inspect a restricted canary before naming actual keys. processors: memory limiter: check interval: 1s limit mib: 512 spike limit mib: 128 attributes/field budget: actions: Illustrative keys only; replace after payload review. - key: user.email action: delete - key: file.path action: delete - key: command.arguments action: delete batch: send batch size: 512 timeout: 5s Verify processors against the chosen Collector distribution. A valid startup does not prove that records satisfy policy. Backend outage: block the exporter. Retries must be bounded, queue growth visible, memory capped, and developer work independent of recovery. Forbidden-field injection: send fake values for prohibited fields. They must not reach the destination. Never use an employee's real prompt, path, or email as a fixture. Cardinality burst: generate many synthetic identifiers. Confirm series growth, rate controls, and the ability to disable export centrally. Watch accepted/refused records, exporter failures, queue occupancy, drops, retry age, memory, payload size, attribute count, cardinality, and end-to-end delay. The rollback switch should live in enterprise management, not in a collector that must be repaired before export can stop. If filtering fails, disable export, protect minimal incident evidence, revoke collector credentials if needed, and handle already-exported data under the organization's retention process. OpenTelemetry makes transport interoperable. It does not automatically make telemetry safe, affordable, or independent of developer workflows. Isolation, a small field budget, and rehearsed failure behavior are what make the export operable.