Diagnostics need a non-PII department id on traces for the multi-department resident portal. What OpenTelemetry mechanism fits?

Diagnostics for a multi-department resident portal should carry a non-PII department id via OpenTelemetry attributes or baggage so traces can be filtered and attributed by department without exposing personal data. Attributes annotate spans for query/filter; baggage propagates key-value context across process boundaries for consistent departmental tagging on child spans. Parks versus housing versus courts traffic can then be sliced in Azure Monitor while resident names, addresses, and government identifiers stay out of telemetry—matching municipal privacy expectations.

Putting full resident names and street addresses into every span attribute fails privacy: traces and logs become PII stores with broad operator access and longer retention than necessary. Avoiding any attributes so traces cannot be filtered by department fails the diagnostic goal—ops cannot isolate a offending department’s portal path during an incident. Encoding Social Security numbers in baggage for ‘richer’ debugging fails catastrophically: SSNs are highly sensitive PII/SPI and must not travel in distributed tracing context.

Exam caveat: baggage is propagated more widely than local span attributes—never place secrets or PII in baggage because downstream services will inherit it. Prefer stable opaque department codes over free-text department names if names can still identify sensitive workloads. Sampling and export backends inherit whatever you put in attributes, so minimize cardinality and sensitivity.

Operational check: emit a non-PII department id on portal traces, query Application Insights filtered by that attribute for a single department, confirm resident name/address/SSN fields are absent from span attributes and baggage, and verify cross-service child spans still carry the department id when baggage propagation is intended.