feat(sdk-logs,sdk-trace-base,sdk-metrics): add configuration for console.dir depth in ConsoleSpanExporter, ConsoleMetricExporter, and ConsoleLogRecordExporter

[btomaj]

Which problem is this PR solving?

This PR makes console.dir depth configurable in ConsoleSpanExporter, ConsoleMetricExporter, and ConsoleLogRecordExporter to resolve problem using with Cloudflare (excessive depth), and Semantic Conventions for Generative AI (insufficient depth).

Fixes #5800

Short description of the changes

1. An optional options parameter is added to the constructors of ConsoleSpanExporter and ConsoleLogRecordExporter.
2. An optional depth property is added to the options parameter of the constructors of ConsoleSpanExporter, ConsoleMetricExporter, and ConsoleLogRecordExporter that controls the depth setting of console.dir().

Type of change

• New feature (non-breaking change which adds functionality)

NB: ConsoleSpanExporter, ConsoleMetricExporter, and ConsoleLogRecordExporter are not well documented, only used in examples, so there was no existing documentation to update.

How Has This Been Tested?

• packages/opentelemetry-sdk-trace-base/test/common/export/ConsoleSpanExporter.test.ts
• packages/sdk-metrics/test/export/ConsoleMetricExporter.test.ts
• experimental/packages/sdk-logs/test/common/export/ConsoleLogRecordExporter.test.ts

Checklist:

• Followed the style guidelines of this project
• Unit tests have been added
• Documentation has been updated

[cjihrig]

It's worth noting a few things:

• There are other console.dir() flags besides depth. If this were to be added, it would feel incomplete to only support depth.
• Avoid using console.dir in ConsoleSpanExporter for Cloudflare Worker compatibility #5800 and the related workerd issue seem to imply that console.dir() doesn't work at all in Workers, independent of depth. If that's the case, this will not fix that issue.

[btomaj]

• There are other console.dir() flags besides depth. If this were to be added, it would feel incomplete to only support depth.

I agree, and I also don't think depth is a very good name. I would have changed the default to null instead of adding it as an option, but I didn't know why it had been set to 3 (instead of the default of 2 when the option is undefined), so it seemed safest to me to declare it as a configurable option. Why has the default been set to 3, and is setting the default to null an option?

• Avoid using console.dir in ConsoleSpanExporter for Cloudflare Worker compatibility #5800 and the related workerd issue seem to imply that console.dir() doesn't work at all in Workers, independent of depth. If that's the case, this will not fix that issue.

On a second reading, I see that you are right. I misunderstood the conversation. Would something like this be a better change?

import { inspect } from 'node:util';

console.log(inspect(obj, { depth: null, colors: true }));

[cjihrig]

I agree, and I also don't think depth is a very good name.

depth is a fine name, and matches the actual parameter name used by console.dir(). I was just pointing out that there are other parameters that probably make sense to include if this were to land.

Would something like this be a better change?

In Node, that general approach would likely be fine because that's how console.dir() is actually implemented in Node, so that should solve the Cloudflare use case (although this really should be fixed on their side). I'm unsure about any implications for the browser though. You'll probably need an OTel maintainer to weigh in on that. You also still have the issue of whether or not to make the inspect() options configurable.