Support multiple span processors

[plantfansam]

This PR attempts to close #42. Not sure if you want this upstream @evanderkoogh, but I wanted to prove to myself it could be done, so here it is! Some demo code:

import { instrument, ResolveConfigFn } from '@microlabs/otel-cf-workers'
import { trace, Span, Context } from '@opentelemetry/api'
import { ConsoleSpanExporter, ReadableSpan, SpanProcessor } from '@opentelemetry/sdk-trace-base'

class LoggingSpanProcessor implements SpanProcessor {
	onStart(span: Span, _parentContext: Context): void {
		console.log(`startspan:${span.spanContext().spanId}`)
	}

	onEnd(span: ReadableSpan): void {
		console.log(`endspan:${span.spanContext().spanId}`)
	}

	forceFlush(): Promise<void> {
		return Promise.resolve()
	}

	shutdown(): Promise<void> {
		return Promise.resolve()
	}
}

const ResolveTraceConfigFn: ResolveConfigFn = () => {
	return {
		exporter: new ConsoleSpanExporter,
		service: { name: 'greetings' },
		spanProcessors: [new LoggingSpanProcessor]
	}
}

const handler = {
	async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
		await fetch('https://cloudflare.com')
		const greeting = "G'day World"
		trace.getActiveSpan()?.setAttribute('greeting', greeting)
		ctx.waitUntil(fetch('https://workers.dev'))
		return new Response(`${greeting}!`)
	},
}

export default instrument(handler, ResolveTraceConfigFn)

[evanderkoogh]

As we talked about on the call, I have certainly no objections to being able to use different SpanProcessors, but do you think there is a reason to have multiple SpanProcessors? Would you not either use the default one, or a different one?

[plantfansam]

That's such a good question, and it sent me back down the spec rabbit hole. Re-reading the spec, I think that the key line is:

Each processor registered on TracerProvider is a start of pipeline that consist of span processor and optional exporter. SDK MUST allow to end each pipeline with individual exporter.

I think this means that a single OpenTelemetry SDK can e.g. export to different endpoints by registering multiple processor -> exporter couplets.

[evanderkoogh]

I fail to see the reason why you would want to have a different SpanProcessor for every Exporter?

[plantfansam]

Yeah, to be honest, I have a hard time understanding the spec's perspective on this, and there seems to have been a lot of discussion on the topic (e.g. https://github.com/open-telemetry/opentelemetry-specification/pull/338/files) . I (very weakly) believe that multiple processors for each exporter would provide a more on-spec way of achieving this. See, e.g., having a zPages processor and a Batch Span processor that gets to an exporter in this example.

My specific use case for this library doesn't involve two export paths, just monkeying with the spans a bit when they start and end.