[Donation proposal]: otel-desktop-viewer

[CtrlSpice]

Description

The otel-desktop-viewer is a CLI tool for receiving OpenTelemetry traces while working on your local machine that helps you visualize and explore your trace data without needing to send it on to a telemetry vendor. Additionally, it can be used as an exporter in the OpenTelemetry Collector to assist with visualization of telemetry.

Benefits to the OpenTelemetry community

The otel-desktop-viewer offers an easy way for users to visualize their telemetry without requiring additional setup of backends or learning other tools. It's useful for debugging, and decreased the barrier of entry for junior developers and those new to the field.

This component can be quite beneficial when demo'ing the OpenTelemetry Demo app.

Reasons for donation

Otel-desktop-viewer was put together as a personal/learning project, but turned out to be well liked in the community. It would be great to see it extended beyond the MVP stage, and receive more contributions and adoption in the OpenTelemetry community.

Repository

https://github.com/CtrlSpice/otel-desktop-viewer

Existing usage

Unclear. The tool appears to have a few users and ~100ish GitHub stars. It is recommended in the documentation of at least one company (Heroku), and in the setup documentation of otel-cli (https://github.com/equinix-labs/otel-cli).

Maintenance

The original contributors to the repository will continue to be involved in the project and make improvements as time permits.

Licenses

Apache 2.0

Trademarks

None!

Other notes

No response

[codeboten]

I'd love to see this live in its own repo in the OpenTelemetry org, happy to help move this forward!

[MikeGoldsmith]

Agree, this looks great. Thanks for the work @CtrlSpice ❤️

[tedsuo]

I've been wanting something like this for a while. Thank you!

[yurishkuro]

From a brief glance, I don't see how this is different from running Jaeger all-in-one, which is also a single binary but has a lot more functionality. If it's missing some features you want, why not contribute there instead of splintering the ecosystem?

[jmorrell]

From a brief glance, I don't see how this is different from running Jaeger all-in-one, which is also a single binary but has a lot more functionality.

I can take a stab at highlighting some of the differences.

• It doesn't require docker, or any knowledge of containers which can be a large barrier to entry for less experienced engineers.
• It's very lightweight. This project bundles it into a CLI, but it would be a good candidate for ex: shipping it along with a VS Code extension.
• It's conceptually simpler with no long-term storage. The UI is centered around a "show me the last data that I sent" workflow, which is very helpful when working on instrumenting your application locally. Sometimes less is more.
• It's written as an OpenTelemetry Collector exporter, and so could conceivably work with any existing receivers and processors and serve as a developer tool there.

why not contribute there instead of splintering the ecosystem?

In a future where OpenTelemetry gets built into everything, we will need lots of tools for people at all levels to visualize what it is their system is emitting. There is a lot of need for meeting users wherever they are with as few barriers as possible: IDE extensions, native apps, CLI tools, etc. I don't see any one UI being sufficient to serve everyone's needs.

[yurishkuro]

It doesn't require docker, or any knowledge of containers which can be a large barrier to entry for less experienced engineers.

Neither does Jaeger, you can download a binary from GH releases, which is actually a more user-friendly way for non-Go users of OpenTelemetry than doing go install

It's conceptually simpler with no long-term storage.

Jaeger all-in-one does not require external storage

It's written as an OpenTelemetry Collector exporter

Is it intended to be a standard part of collector distro and serve web UI directly from collector binary, similar to z-pages?

I do not disagree with the overall intention of having telemetry & collector debugging tools, but this needs a design proposal and some agreed upon strategy. This tool does not meet this goal in the current form.

[CtrlSpice]

Hi there!

This is a lot to unpack, so I apologize in advance for the wall of text.

From a brief glance, I don't see how this is different from running Jaeger all-in-one, which is also a single binary but has a lot more functionality.

Great question! I feel that the primary intended usecase for these tools was different enough that it warranted a separate implementation. While Jaeger all-in-one is geared towards debugging instrumented systems in a local environment, I wanted a simpler tool specifically focused on debugging and visualizing trace data during the instrumentation process, with a UI streamlined toward that end.

Why not contribute there instead of splintering the ecosystem?

I am a little bit confused by the wording here, but I will try my best to provide some clarity. As I mentioned above, otel-desktop-viewer is not designed to do what Jaeger all-in-one does - it is not an alternate or competing standard. If anything, it fills the niche currently occupied by adding a logging exporter to your project, and squinting at your terminal really hard. As such, I felt it would be a useful addition to enhance the tooling available within the ecosystem, and help make OpenTelemetry more accessible to early-career developers, as well as those who are new to the domain, rather than splintering it.

You can download a binary from GH releases, which is actually a more user-friendly way for non-Go users of OpenTelemetry than doing go install

Oh no, this is absolutely my bad. I forgot to update the README. otel-desktop-viewer is available through go install, as a binary, and through homebrew.

Is it intended to be a standard part of collector distro and serve web UI directly from collector binary, similar to z-pages?

If I am reading z-pages correctly, then pulling desktopexporter into your own collector is conceptually similar and certainly an option if it suits your workflow, though I admit z-pages is a bit before my time so my knowledge is incomplete.

This tool does not meet this goal in the current form.

Agreed! As mentioned in my donation proposal, this tool is very much in its MVP stage. To be very clear: I wrote it as a personal/learning project, and never expected it to receive so much love and support from the community. My motivation for donating it now is to enable community involvement in standardizing the design, contributing to the next stage of the project (support for metric and logs), and generally allowing it to grow beyond the scope I can achieve as one person/developer.

I hope this clears up any misunderstandings, and of course let me know if I can address any further concerns! :)

[austinlparker]

I attempted to capture some of the overall goals/objectives around a telemetry viewer experience in OTEP 230 - would welcome comments over there.

[trask]

Closing in favor of open-telemetry/oteps#230 which is where ongoing discussions are occurring