Update examples and only use Console Exporters

[JamieDanielson]

Note: This issue is being updated and repurposed for further rework on the examples.

Review examples in examples directory and make updates

• update package dependencies
• use only console exporters (remove jaeger, zipkin, and otlp)
• use separate file for setting up otel (otel.js, telemetry.js, etc)

Add a comment for which example you are working on so others don't.

• bunyan
• connect
• dns
• express
• fastify
• graphql
• grpc-census-prop
• hapi
• host-metrics
• ioredis
• koa
• memcached
• meta-node
• mongodb
• mysql
• network
• react-load
• redis
• restify
• router
• web

[sp6370]

Hey 👋🏽 !
I am working on the express example.

[xonev]

Hi there, I'll work on the web example.

[dsvanlani]

I took mongodb actually

[trentm]

@JamieDanielson Having looked at a couple of the examples, I don't know if the "use only console exporters" will be that helpful for users:

• examples/express results in a trace with a lot of spans: client calls server, server calls itself, a number of middleware spans. With the ConsoleSpanExporter this would result in a multi-hundred line dump of output.
• examples/web involves generating spans in a web app. Viewing data dumped to the console won't be so obviously visible to the user playing with the examples.

At least for some of the examples I'm leaning towards settling on a slightly preferred app we run in Docker for visualization. Currently that preference would likely be Jaeger v2 (supports direct OTLP). However, I'm hedging a bit because it doesn't support metrics and logs -- actually it might support metrics, not sure.

A possible demo option might be MS's Aspire Dashboard.
See this comment in the #otel-genai-instrumentation channel https://cloud-native.slack.com/archives/C06KR7ARS3X/p1731995684491229
The need is higher for GenAI instrumentation work because the GenAI semconv uses log events commonly now.

Anyway, sorry to add some complexity here.
My inclination for now is to bias towards:

• use Console exporters where the demo output is small
• use Jaeger for more complex trace examples
• decide case-by-case for other examples where the above options kinda suck

We can discuss/do other options on a separate issue.

[JamieDanielson]

Currently that preference would likely be Jaeger v2 (supports direct OTLP). However, I'm hedging a bit because it doesn't support metrics and logs -- actually it might support metrics, not sure.

Yeah, I generally lean toward Jaeger v2 as well, but hesitate for the same reasons. It looks like it supports OpenMetrics for metrics (not OpenTelemetry) and no logs. Is it confusing to view tracing in Jaeger, with logs and metrics in the console? It seems like that may be the way to go...