Logging / OpenTelemetry support?

[alpharder]

Thanks for the awesome project.

Are there any plans regarding providing any logging solution or maybe OpenTelemetry support out of the box?

Relying on underlying server logging / OpenTelemetry isn't enough for observability, also for example raw-dogging with let's say Bun.serve doesn't actually have any logging by itself.

This factor might be important when considering adopting orpc by larger companies.

[unnoq]

I don’t have experience with this topic yet, but I definitely want to support it. First, could you share what kind of metrics or things you'd like to track in oRPC - like interceptors, middleware workflows, etc.? Any real examples of how similar solutions (like oRPC) support OpenTelemetry would also be really helpful.

[alpharder]

Could this be added as a middleware ? Otel middleware ?

From what I can tell after reading some of the oRPC source code – not really, if you need some details.

[yacobmole]

Could this be added as a middleware ? Otel middleware ?

From what I can tell after reading some of the oRPC source code – not really, if you need some details.

As oRPC is a library and you use it an adapter you can get a standard instrumentation library for the runtime.

I don't understand why you say not really? I treat oRPC as a set of functions and add tracing as I would any standard function

This is how I have my OpenTelemetry Middleware Setup

export const instrumentedMiddleware = (spanName: string) =>
  orpc.middleware(async ({ next, context }) => {
    const tracer = trace.getTracer("orpc");
    return tracer.startActiveSpan(spanName, (span) => {
      return next({
        context: { ...context, tracer, span } satisfies InstrumentedContext,
      });
    });
  });

and then in the procedure I call span.end(), While not SUPER elegant and I'm sure if I played around with it more I could get a more elegant way.
Open to suggestions.

[Yoshify]

Could this be added as a middleware ? Otel middleware ?

From what I can tell after reading some of the oRPC source code – not really, if you need some details.

As oRPC is a library and you use it an adapter you can get a standard instrumentation library for the runtime.

I don't understand why you say not really? I treat oRPC as a set of functions and add tracing as I would any standard function

This is how I have my OpenTelemetry Middleware Setup

export const instrumentedMiddleware = (spanName: string) =>
  orpc.middleware(async ({ next, context }) => {
    const tracer = trace.getTracer("orpc");
    return tracer.startActiveSpan(spanName, (span) => {
      return next({
        context: { ...context, tracer, span } satisfies InstrumentedContext,
      });
    });
  });

and then in the procedure I call span.end(), While not SUPER elegant and I'm sure if I played around with it more I could get a more elegant way. Open to suggestions.

Could you not do:

export const instrumentedMiddleware = (spanName: string) =>
  orpc.middleware(async ({ next, context }) => {
    const tracer = trace.getTracer("orpc");
    return tracer.startActiveSpan(spanName, (span) => {
      const result = await next({
        context: { ...context, tracer, span } satisfies InstrumentedContext,
      });
      span.end()
      return result;
    });
  });

To avoid having to span.end() in every procedure?

[alpharder]

@yacobmole doesn't this approach provides you with a single, atomic "orpc" span?

[alpharder]

As oRPC is a library and you use it an adapter you can get a standard instrumentation library for the runtime.
I don't understand why you say not really? I treat oRPC as a set of functions and add tracing as I would any standard function

Let me clarify. Once the observability expectations regarding oRPC are very basic, i.e. "going to trace something that's happening @ oRPC" – the code above should work.

However, on the other hand, this code makes no practical sense from observability standpoint, because oRPC middlewares only wrap underlying (previously registered) middlewares and procedure execution code itself, alongside with data validation (and all of this atomically, so you aren't tracing raw, isolated procedure code execution as well).

oRPC has lots of internal processes going on – transforming request into standard request, executing all kinds of interceptors, decoding/encoding data, executing other middlewares, which are left uninstrumented and thus unobserved.

Instrumenting all of this externally via middlewares or interceptors is not achievable with the current state of oRPC codebase, that's why I've created this discussion in the first place.

I treat oRPC as a set of functions and add tracing as I would any standard function

90% of oRPC runtime code is unaffected by tracing @ middleware.

[unnoq]

I'm working on this in next week, this is a big step to improve oRPC reliability.

[bagashiz]

Hey, I'm currently using orpc in a Next.js project and would like to integrate structured logging using pino. Is there an example of how to set up a logging middleware that logs the procedure name/path, execution time, and any other useful metrics?

I tried something like this:

import { o } from ".";

export const logMiddleware = o.middleware(async ({ context, path, next }) => {
  const start = Date.now();
  try {
    return next({ context });
  } catch (e) {
    context.logger.error(e);
  } finally {
    const end = Date.now();
    context.logger.info({ method: "", path, duration: end - start });
  }
});

…but of course, it doesn’t work as expected. Any pointers?

[unnoq]

you're missing this: @bagashiz

-    return next({ context });
+   return await next({ context });

[bagashiz]

oh, my bad, lol. thanks for pointing that out.

what other fields are available on the input parameter of the middleware function?
also, is there a way to access the request method and the response's status code from there?