chore: setup opentelemetry

[hi-ogawa]

• cf. https://github.com/hi-ogawa/youtube-dl-web-v2/pull/38, https://github.com/hi-ogawa/youtube-dl-web-v2/pull/47

Not really crucial, but just out of curiousity and it would be interesting to see how flexible remix is made to integrate opentelemtry. Of course, I assume some patching, but the point is how elegant patch we can find.

todo

• [ ] trace request handler
  • at least it's possible to do from adapter entrypoint
  • span name based on remix route
• [ ] trace loader
  • at least it's possible from makeLoader utils
  • or maybe we can patch to wrap all loader calls around here? https://github.com/remix-run/remix/blob/ea7ab3adf1cc38a3ee40261f8d40d9b2535455ba/packages/remix-server-runtime/routes.ts#L74
  • probably it's best to wrap these callRouteLoaderRR and callRouteActionRR https://github.com/remix-run/remix/blob/ea7ab3adf1cc38a3ee40261f8d40d9b2535455ba/packages/remix-server-runtime/data.ts#L58-L59
  • or we can wrap these individually handleDataRequestRR/handleResourceRequestRR/handleDocumentRequestRR
  • essentially we want to use route.id as a span name instead of complete url pathname to reduce large cardinality due to dynamic route.
  • note that single page request invoke multiple loaders
• [ ] trace page request
  • differentiate from client loader call?
  • "route id" is not necessary available in HandleDocumentRequestFunction (for example, some random 404 url still calls this handler?)
• [ ] trace trpc call
  • url path encodes trpc routes, so request handler tracing should be enough.
• [ ] trace user code

[hi-ogawa]

Closed by https://github.com/hi-ogawa/ytsub-v3/pull/433