feat: start adding support to cf pages #129
Conversation
vanstinator
force-pushed
the
feat/cf-pages
branch
from
6b0890e to
ecb4583
Compare
|
|
||
| type PageHandlerArgs = Parameters<PagesFunction> | ||
|
|
||
| let cold_start = true |
There was a problem hiding this comment.
We should make this a bit longer to help ensure it doesn't ever conflict with user code (generally, global vars should be avoided in Workers/Functions, but this seems ok.)
e.g. let __otel_cf_is_cold_start = true
There was a problem hiding this comment.
I think this should actually be fine, as it's not exported, so user code can never find it as cold_start.
| ['faas.trigger']: 'http', | ||
| ['faas.coldstart']: cold_start, | ||
| ['faas.invocation_id']: request.request.headers.get('cf-ray') ?? undefined, |
There was a problem hiding this comment.
Could you use semantic attributes import to remain consistent with the rest of the library? Once we update to the latest api, we will be able to tree-shake it to just these three keys being imported.
| } | ||
| cold_start = false | ||
| Object.assign(attributes, gatherRequestAttributes(request.request)) | ||
| Object.assign(attributes, gatherIncomingCfAttributes(request.request)) |
There was a problem hiding this comment.
Could you also assign version metadata, like in
otel-cf-workers/src/instrumentation/fetch.ts
Line 144 in 3bdda1e
I know that version metadata bindings can't be added to Pages projects (looking at you @jahands), and script versions work very differently, but hopefully this will change as they converge more.
| } | ||
|
|
||
| const promise = tracer.startActiveSpan( | ||
| `${request.request.method} ${request.functionPath}`, |
There was a problem hiding this comment.
We recently introduced a new convention for instrumented spans, could you prefix this and the two updateNames to be prefixed with fetchHandler? Again, we could call them functionHandler, but with convergence a consistent name between Workers and Pages will make more sense in my opinion.
|
Hey this would be really useful for a project I am working on. Is this usable as is? Are there plans to merge this? |
Fixes #96
What this PR solves / how to test:
This PR adds support for automatically instrumenting Cloudflare Pages. The code is very similar to the
fetchcode. I'd initially intended to combine the similar bits into a shared core, but as I started to get into those weeds I realized I didn't have a ton of context on the full set of differences between Pages and Workers, and it started to seem like keeping the code paths separate would allow for a more organic growth on the Pages instrumentation.To test this code yourself it's as simple as wrapping a Cloudflare Pages handler in
instrumentPageand passing it a validTraceConfig.