feat: Unique connection tracking

[kwasniew]

About the changes

Enhancing request timing metrics with connection id (think instance id but guaranteed to be unique and handled internally by us).

Details:

• I checked how appName was added in the first place: fix: add appName to http response time metrics #2117. Same tradeoffs apply here
• connection id is implemented here: feat: client identification headers unleash-client-node#690
• This is behind a flag to opt-into tracking and also it can be disabled with the killswitch for appName
• We have a new x-unleash-appname header that replaces unleash-appname but not all SDKs use it so we check both with preference given to the x-header
• I'm not using a new x-unleash-sdk header here to keep the metrics data as small as possible for now with the ability to track unique clients

Important:

• connection id has higher cardinality than the app name. We have as many unique connection ids as client pods AND frontend api instances (that's why I want this to be opt-in only for the time of debugging)

Important files

Discussion points

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

2 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
unleash-docs	⬜️ Ignored (Inspect)	Visit Preview		Jan 8, 2025 0:08am
unleash-monorepo-frontend	⬜️ Ignored (Inspect)	Visit Preview		Jan 8, 2025 0:08am

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

OpenSSF Scorecard

Package	Version	Score	Details

Scanned Files

[chriswk]

I want to say yes here, but adding another label with more than one possible value is starting to make me worry about cardinality. I see you've pointed it out, since it's only set to the empty string as long as it's disabled I'm a +1