Things to do before proceeding with plugin development

[123liuziming]

For now we have a simple prototype, here is a checklist before we proceed with plugin development:

• Test framework
• CI/CD pipeline
  • Unit Tests and coverage report
  • Integration Test
  • Performance Test
• Examples
• Instrumentation API/Semconv encapsulation
• Document
• Go Routine Local Storage

[Cirilla-zmh]

Is this a right timing that we can define an interactive prototype API so that we could add library instrumentations while building the compile tools?
cc @y1yang0 @RomainMuller

As a instrumentation developer, what I totally need may be:

• The schema for code injection configuration:
  • How to match the version scope of libraries.
  • How to identify target methods and link them to our advice methods.
  • How to add necessary helper methods for linking.
• The method signature schema for advice or proxy:
  • How to access and possibly replace input/output for a method.
  • How to transmit local variables between the start and end methods.
  • How to propagate the trace context among goroutines, even if there are no suitable context carriers.

[pdelewski]

@Cirilla-zmh For me, it's the right time to address these things, as they may also influence some design details. It seems that some points may require an additional pass to provide the user with options, such as:

• How to identify target methods and link them to our advice methods.

Some points are still unclear to me, such as:

• How to transmit local variables between the start and end methods.

What do you mean by "start and methods"?

[Cirilla-zmh]

What do you mean by "start and methods"?

Sorry, maybe it can be called as "before and after methods". Basically if we add advice codes in library-side, it's necessary to define the before and after method and give some mechanisms to transmit the variables between these two methods.

func demoFunc() {
    println("hello")
}

// before demoFunc
func beforeDemoFunc() {
    localVar := "before"
}

// after demoFunc
func afterDemoFunc() {
    // we need to access the localVar here
}

However, it's unnecessary if you want to always add proxy method to replace the origin one like:

opentelemetry-go-compile-instrumentation/internal/instrument.go

Lines 100 to 110 in 16c1475

	func rewriteAst(ast *dst.File, fn *dst.FuncDecl) {
	fmt.Printf("Instrumenting function: %s\n", fn.Name.Name)
	// Insert a call to the trampoline function at the beginning of the function
	callToTrampoline := newFuncCall(TrampolineName)
	fn.Body.List = append([]dst.Stmt{callToTrampoline}, fn.Body.List...)
	// Add the trampoline function to the AST
	ast.Decls = append(ast.Decls, newTrampolineFunc())
	// Add the hook function to the AST
	hook := newHookFunc(HookName)
	ast.Decls = append(ast.Decls, hook)
	}

[ralf0131]

Currently focus on the following items, with minimal efforts:

• CI/CD pipeline @123liuziming @RomainMuller
• Test framework @123liuziming @RomainMuller
• Unit Tests and coverage report @123liuziming @RomainMuller
• Examples
• Document
• Instrumentation API/Semconv encapsulation @123liuziming