Logging to sinks other than `console`

[eropple]

With my devops hat on, getting plaintext logs sent to console is really itchy; my normal environments all use Pino (or, for older ones, Bunyan) in order to emit structured logs, and so EdgeDB's method of logging will actually break my ingest into services like Datadog.

My suggestion would (to avoid breaking compat) be to do something like changing logging from boolean to boolean | LoggingAdapter of some flavor. Because EdgeDB manages its own connection pool, I'm struggling with a great way to provide additional context to each connection's logger (being able to provide a request ID to every query being executed inside a given HTTP handler, for example), but my strong S1 is that that'd do a lot for maintenance load.

If there's interest and we can adequately scope it, I'd be interested in taking a crack at this.

[colinhacks]

I think this is a great idea. @1st1 any thoughts?

I like the logging: boolean | LoggingAdapter approach. Do you have a proposal for that interface? Super simple option:

interface LoggingAdapter {
  log(...args: unknown[]): void;
  warn(...args: unknown[]): void;
  error(...args: unknown[]): void;
}

Though this doesn't provide an affordance for customizing logging on a per-connection basis. Connections are generally quite short-lived so not sure if that's really a pattern we want to encourage. It's a bit of a leak in the "client" abstraction.

[eropple]

FYI - have not forgotten about this but I've just gotten bounced around on different projects. I'm still interested in this and in EdgeDB more generally, but only so many hours in the day, etc.

As far as a LoggingAdapter concept, my S1 is "make it work best with Pino/Bunyan out of the box"; at least in my neck of the woods, that's The Standard For Structured Logging, which is where I think you get the most benefit out of this. It's essentially similar to the interface you wrote above (though I'd go info rather than log, but that isn't compatible with console then - hard to say. But the key thing there becomes standardizing on the first arg being a Record<string, any> and the second being a human-readable textual string.

And that makes sense re: the client/connection pool, but from the perspective of an application and application framework developer, what I really want is to be able to bind metadata to the logging for a query. For example, the last time I was elbow deep in TypeORM, the client provider gizmo replaced the logger in a child so as to be able to pass the HTTP request ID and log queries, etc. with that. (Expecting users to pass a req-id with every query isn't super friendly/realistic, after all.)