Proposal: Add Web UI for code exploration, hook generation, and debugging

[pdelewski]

This proposal suggests adding a web-based UI component to reduce friction when working with compile-time instrumentation. The UI would provide interactive code exploration, automatic hook generation, and debugging capabilities for instrumented applications.

Motivation

Compile-time instrumentation using AOP techniques introduces an abstraction layer that can be challenging to work with:

• Hidden complexity: The final instrumented code differs from the source code, making it hard to understand what actually runs
• Manual hook creation: Writing hook definitions requires understanding function signatures, package paths, and the instrumentation API
• Debugging difficulty: When issues occur, developers need to inspect the modified code in Go's WORK directory
• Discovery problem: Finding which functions to instrument in large codebases is tedious

Currently, users must:

1. Manually browse source files to find functions
2. Hand-write YAML/DSL rules with correct package paths and signatures
3. Run builds and hope the instrumentation works
4. Debug issues by manually inspecting temporary build artifacts

Proposed Solution

A web-based UI that provides multiple views into the codebase and build process:

1. Code Exploration Views

View	Description
Functions	List all functions in the project with signatures
Static Call Graph	Visualize function call relationships
Packages	Browse packages involved in compilation
Files	Navigate source files with syntax highlighting
WORK Directory	Inspect instrumented files in their final form

2. Hook Generation

• Select functions via checkboxes in the Functions view
• Click "Generate Hooks" to auto-create hook boilerplate
• Generated code includes:
  • Proper package paths
  • Correct function signatures
  • Before/After hook templates with timing measurement

3. Build & Run Integration

• Compile: Select hook files and build with instrumentation
• Run: Execute instrumented binaries directly from the UI
• View Output: See console output with tracing information

4. Debugging Support

• Step through instrumented code with breakpoints
• Inspect the final modified source files
• Verify hook injection points
• Compare original vs instrumented code

Benefits

Problem	UI Solution
Finding functions to instrument	Functions view with search/filter
Writing correct hook definitions	Auto-generation with proper signatures
Understanding call flow	Static call graph visualization
Debugging instrumented code	WORK directory inspection + debugger
Verifying instrumentation	Side-by-side original vs modified view

Integration with Existing Tooling

The UI would be a standalone component that:

• Works with the existing -toolexec based instrumentation
• Reads the same YAML/Go DSL rule files
• Can be used independently or alongside IDE plugins
• Potentially shareable with other instrumentation projects

Reference Implementation

A working implementation exists in https://github.com/pdelewski/go-build-interceptor with:

• Full source at ui/ directory
• Cross-platform support (Linux, macOS, Windows)
• Monaco editor integration with Go LSP
• Debugging via delve integration

Screenshots:

https://github.com/pdelewski/go-build-interceptor/blob/main/docs/images/ui-screenshot.png

Workflow Demo:

https://github.com/pdelewski/go-build-interceptor/blob/main/docs/images/go-build-interceptor.gif

Next Steps

1. Evaluate UI codebase for integration
2. Adapt UI to work with existing otel-go-instrumentation build system

Open Questions

• Should this be part of the main repo or a separate companion project?

[y1yang0]

Great proposal. I wonder if this could be an otelc inspector subcommand or something else.

Regarding its location:

• In this repo: We could offer deep integration, like auto-generating Go hook prototypes, making development and debugging much easier.
• As a companion project: It would probably need a more general, language-agnostic scope to get approval from the OTel committers for a new repository (I'm guessing).

[brightzheng100]

I wonder if this could be an otelc inspector subcommand or something else.

otelc inspector subcommand can be a great idea -- think MCP Inspector?

As I just started looking at this project, some key points may pop up to a typical newcomer like me:

1. What will be generated, and why?
2. Is the instrumentation accurate enough for production, so that the key telemetry data (e.g. metrics, traces, logs) can be generated properly?
3. How if I want to enhance something on top of the generated instrumentation? What will be the practical way to avoid potential conflicts between generated code and custom code?
4. Maybe more

So, such a visual tool can be helpful, and now it's about the scope and how such a tool can add the proper value to the ecosystem.

[kakkoyun]

I love this ❤️ And the demo was impressive! 💯 Let's have this in this repo!