OTLP telemetry exporter

[maxdml]

This PR updates the telemetry subsystem to support 1) formatting log entries to OTLP and 2) export logs/traces to configurable OTLP backends.

For instance, with a service that accepts both traces and logs (like the OTel collector), the DBOS SDK can be configure to export both signals to this service:

telemetry:
    OTLPExporters:
        - tracesEndpoint: 'http://localhost:4318/v1/traces'
        - logsEndpoint: 'http://localhost:4318/v1/logs'

Note this setup works out of the box with Jaeger and the OTel collector (see screenshots bellow.)
Also note opentelemetry-js logs API is experimental, so I fixed the version we use to 0.41.2

Details

• Use a wrapper around the Winston logger everywhere.
• The wrapper adds a new OTLP transport to the wrapped winston logger if it detects configured exporters
• This transport simply formats an OTel LogRecord and push it to our collector
• Massively simplify our typing by only using opentelemetry LogRecord and Span

Others

• Metadata are injected to all Winston transports and the transport logic decides whether to include them or not

Thoughts

• There exists a neater way to integrate the active span context to each OTLP log records, which we can consider in the future. Talk to me for details or see PR comments about having a context manager
• The Winston folks are actively working on an OTLP transport/exporter themselves, see here and there. In the future we might want to use it.

Tests

☑️ Unit tests: ideally we would be able to intercept outgoing HTTP requests and expect the payload to conform our expectations. This seems to be quite some work so pushing that for later.

✅ Tested with DBOS cloud integration tests.

✅ Logs w/o metadata:

✅ Logs w/ metadata:

✅ Logs & traces exported to a local OTel collector

✅ Traces exported to a local Jaeger:

[maxdml]

This fix a bug where the metadata would be missing if provided from the parentCtx

[kraftp]

Is this what Winston does by default when it receives non-string input? What were we doing before?

[maxdml]

Here's the set of inputs Winston accepts for its log methods:

 interface LeveledLogMethod {
      (message: string, callback: LogCallback): Logger;
      (message: string, meta: any, callback: LogCallback): Logger;
      (message: string, ...meta: any[]): Logger;
      (message: any): Logger;
      (infoObject: object): Logger;
    }

We have always been using either (message: string, ...meta: any[]): Logger; or (message: any): Logger;

[kraftp]

What does this do in practice? Does it print the original stack trace?

[maxdml]

Yes we just improves the message

[chuck-dbos]

Compared to the original code (not the first PR), it seems it improves the message vs allowing the logger to make the same improvement?

[maxdml]

What would allow the logger to make the same improvement mean here? (The idea is to keep the logger interface simple and as close as Winston as possible, i.e., for errors, you can pass an error object, a string message or a JSON.stringify-able object)

[kraftp]

Do we have to change the configuration file at all to support this new one-exporter, two-endpoint structure?

[maxdml]

Nope, the current way of loading the configuration supports this change transparently.

[maxdml]

Sorry if I wasn't clear: the update to the configuration types is done here

[chuck-dbos]

I suppose we wouldn't catch errors thrown from stringify (for circular references, etc.)?

[maxdml]

The contract would be that we ask users to give use objects that can be JSON.stringify-ed. Under the hood, Winston seems to be more flexible, but it is also really complicated..