feat: start adding support to cf pages

[vanstinator]

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 fetch code. 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 instrumentPage and passing it a valid TraceConfig.

[jahands]

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

[DaniFoldi]

I think this should actually be fine, as it's not exported, so user code can never find it as cold_start.

[DaniFoldi]

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.

[DaniFoldi]

Could you also assign version metadata, like in

otel-cf-workers/src/instrumentation/fetch.ts

Line 144 in 3bdda1e

Object.assign(attributes, versionAttributes(env))

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.

[DaniFoldi]

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.

[shmuli9]

Hey this would be really useful for a project I am working on. Is this usable as is? Are there plans to merge this?

[jfsiii]

@DaniFoldi @jahands @evanderkoogh This feature is badly needed/wanted. Can let us know about any blockers to merging this PR? We're nearing 1 year since it was opened.

I'm happy to open a new PR for this and address feedback if that helps.

[DaniFoldi]

Hey, I hate to bring bad news, but from my side, I don't actually have merge perms on the repo, and with my team we've created a different otel library (not opensource, as it relies on other internal libs, unfortunately) so I haven't really worked on my fork in a while.

[vanstinator]

I'm no longer with the company I was with back when I opened this, and I don't have a cf-pages project of my own to play with. So I'm afraid I won't be able to take this one over the finish line myself.

[jfsiii]

@evanderkoogh Now that the core-logic-refactor has landed can you take a look at adapting this to the new approach, or explaining how to adapt it?

Anecdotally, this PR has worked well for me in instrumenting two Pages sites

[evanderkoogh]

Hey @jfsiii. I am currently looking into fixing RPC style communication. As that is one of the last things that is not working in currently supported modules.

But this PR should be relatively straightforward to put into the core-logic-refactor. You basically export an object that exposes some methods with specific details on how to instrument. You can see an example at:

otel-cf-workers/src/instrumentation/fetch.ts

Lines 133 to 157 in 289a7cd

	export const fetchInstrumentation: HandlerInstrumentation<IncomingRequest, OrPromise<Response>> = {
	getInitialSpanInfo: (request) => {
	const spanContext = getParentContextFromRequest(request)
	const attributes = {
	['faas.trigger']: 'http',
	['faas.invocation_id']: request.headers.get('cf-ray') ?? undefined,
	}
	Object.assign(attributes, gatherRequestAttributes(request))
	Object.assign(attributes, gatherIncomingCfAttributes(request))
	const method = request.method.toUpperCase()
	return {
	name: `fetchHandler ${method}`,
	options: {
	attributes,
	kind: SpanKind.SERVER,
	},
	context: spanContext,
	}
	},
	getAttributesFromResult: (response) => {
	return gatherResponseAttributes(response)
	},
	executionSucces: updateSpanNameOnRoute,
	executionFailed: updateSpanNameOnRoute,
	}

Then it is probably doing something extremely similar to

otel-cf-workers/src/instrumentation/fetch.ts

Lines 133 to 157 in 289a7cd

	export const fetchInstrumentation: HandlerInstrumentation<IncomingRequest, OrPromise<Response>> = {
	getInitialSpanInfo: (request) => {
	const spanContext = getParentContextFromRequest(request)
	const attributes = {
	['faas.trigger']: 'http',
	['faas.invocation_id']: request.headers.get('cf-ray') ?? undefined,
	}
	Object.assign(attributes, gatherRequestAttributes(request))
	Object.assign(attributes, gatherIncomingCfAttributes(request))
	const method = request.method.toUpperCase()
	return {
	name: `fetchHandler ${method}`,
	options: {
	attributes,
	kind: SpanKind.SERVER,
	},
	context: spanContext,
	}
	},
	getAttributesFromResult: (response) => {
	return gatherResponseAttributes(response)
	},
	executionSucces: updateSpanNameOnRoute,
	executionFailed: updateSpanNameOnRoute,
	}

to get an instrumentPage function that can take a Page object..

Pages is probably the next thing on my agenda after the RPC thing, but the RPC thing isn't going to be super trivial unfortunately :(

[jfsiii]

@evanderkoogh Thanks! Let me know if I can help build/test RPC. We use it extensively in our project and I'm desperate to get OTEL tracing for it.

[evanderkoogh]

What would be amazing @jfsiii, is if you could create some concise examples of either or both RPC and Pages projects in the example directory. And with the RPC one to include endpoints that use a variety of types of arguments to pass back and forth. One primitive, multiple primitives, object, functions, arrays etc..

[jfsiii]

@evanderkoogh I'm mid-sprint right now, but I can probably do that next week