Accessing log level label from transport

[10xLaCroixDrinker]

Related: Vunovati/pino-opentelemetry-transport#155

In the pino-opentelemetry-transport, I'm using the level label as SeverityText on the log record. Since the log object only has the level number, and the transport doesn't have access to the logger itself to read logger.levels, I'm using the label from pino.levels for SeverityText. This becomes a bit of a problem though for custom levels.

If a user is using any custom levels in their pino configuration, they'll have to pass that same configuration again to the transport in order to be able to use the level label.

Is there a way that I'm missing that exists to access the level label from the transport without having to do this?

[mcollina]

Your assessment is correct. I think passing the custom level information down to the worker thread would be a very nice feature addition, if you'd like to send a PR.

[10xLaCroixDrinker]

@mcollina PRs are open for this now.

• https://github.com/pinojs/thread-stream/pull/145
• https://github.com/pinojs/pino/pull/1930
• https://github.com/pinojs/pino-abstract-transport/pull/90

Most of the changes are in pino-abstract-transport. Looking forward to your feedback.

[mcollina]

I think it would be safer/easier to pass it via workerData. Why did you pass it via postMessage?

[10xLaCroixDrinker]

I passed it via postMessage because the worker is created before the pino instance, so that information isn't available to include in workerData.

[10xLaCroixDrinker]

WorkerData could potentially work for

pino({
  transport: {
    target: '/absolute/path/to/my-transport.mjs'
  }
})

But would not support

pino(pino.transport({
  target: '/absolute/path/to/my-transport.mjs'
})

[10xLaCroixDrinker]

@mcollina what are your thoughts?

Do you want to only support this feature when including the transport on the config? Or am I missing something here that would work for workerData when calling pino.transport() directly?

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.