Programming language: Go
License: MIT License
Tags: Performance    

go-instrument alternatives and similar packages

Based on the "Performance" category.
Alternatively, view go-instrument alternatives based on common mentions on social networks and blogs.

Do you think we are missing an alternative of go-instrument or a related project?

Add another 'Performance' Package


⚡️ go-instrument

Automatically add Trace Spans to Go methods and functions

codecov Go Report Card Go Reference

This tool uses standard Go library to modify AST with instrumentation. Use this in your CI before compilation. It is also possible to track generated code, however comments will be missing. You can add new instrumentations by defining your own Instrumenter and invoking Processor like it is done in main.

  • No dependencies
  • 400 LOC
  • OpenTelemetry (Datadog, NewRelic, etc.)
go install github.com/nikolaydubina/go-instrument@latest
find . -name "*.go" | xargs -I{} go-instrument -app my-service -w -filename {}

Functions and methods with ctx context.Context in arguments

func (s Cat) Name(ctx context.Context) (name string, err error) {

will be instrumented with span

func (s Cat) Name(ctx context.Context) (name string, err error) {
    ctx, span := otel.Trace("my-service").Start(ctx, "Cat.Name")
    defer span.End()
    defer func() {
        if err != nil {
            span.SetStatus(codes.Error, "error")

Example HTTP server go-instrument-example as it appears in Datadog. [](./docs/fib-error.png)



To avoid instrumentation of function add comment anywhere in the file.

//go:instrument -skip=SomeFunc|SomeOtherfunc|privateFunc

func (s Cat) Name(ctx context.Context) (name string, err error) {
  //go:instrument -skip=Name


Functions that have named return err error will get spans with appropriate status and error recorded.

func (s Cat) Walk(ctx context.Context) (err error) {


Comments will be stripped. This fits well if your next step is to compile.

In Development

  • [ ] Dynamic error variable name
  • [ ] Creating error when return is not named
  • [ ] Detection if function is already instrumented
  • [ ] Keep comments
  • [ ] Datadog native instrumenter


It is laborious to add tracing code to every function manually. The code repeats 99% of time. Other languages can either modify code or have wrapper notations that makes even manual tracing much less laborious.

As of 2022-11-06, official Go does not support automatic function traces. https://go.dev/doc/diagnostics

Is there a way to automatically intercept each function call and create traces?

Go doesn’t provide a way to automatically intercept every function call and create trace spans. You need to manually instrument your code to create, end, and annotate spans.

Thus, providing automated version to add Trace Spans annotation.


Go Compiler Inlining

Since we are adding multiple functions calls, it affects Go compiler decisions on inlining. It is expected that Go will less likely inline.

For example, can inline function

$ go build -gcflags="-m -m" ./internal/example 2>&1 | grep OneLine
internal/example/basic.go:80:6: can inline OneLineTypical with cost 62 as: func(context.Context, int) (int, error) { return fib(n), nil }
go-instrument -w -filename internal/example/basic.go

Can not inline after instrumentation

$ go build -gcflags="-m -m" ./internal/example 2>&1 | grep OneLine
internal/example/basic.go:132:6: cannot inline OneLineTypical: unhandled op DEFER

Appendix A: Related Work

Appendix B: Other Languages


Java runtime modifies bytecode of methods on load time that adds instrumentation calls. Pre-defined libraries are instrumented (http, mysql, etc).

✅ Very short single line decorator statement can be used to trace selected methods.


import datadog.trace.api.Trace

public class BackupLedger {
  public void write(List<Transaction> transactions) {
    for (Transaction transaction : transactions) {
      ledger.put(transaction.getId(), transaction);


import io.opentelemetry.instrumentation.annotations.WithSpan;

public class MyClass {
  public void myMethod() {

✅ Automatic instrumentation of all functions is also possible.

Datadog supports wildcard for list of methods to trace.

Environment Variable: DD_TRACE_METHODS
Default: null
Example: package.ClassName[method1,method2,...];AnonymousClass$1[call];package.ClassName[]
List of class/interface and methods to trace. Similar to adding @Trace, but without changing code. Note: The wildcard method support ([
]) does not accommodate constructors, getters, setters, synthetic, toString, equals, hashcode, or finalizer method calls

java -javaagent:/path/to/dd-java-agent.jar -Ddd.service=web-app -Ddd.env=dev -Ddd.trace.methods="*" -jar path/to/application.jar


Python monkeypatching of functions at runtime is used to add instrumentation calls. Pre-defined libraries are instrumented (http, mysql, etc).

✅ Very short single line decorator statement can be used to trace selected methods.


from ddtrace import tracer

class BackupLedger:
    def write(self, transactions):
        for transaction in transactions:
            self.ledger[transaction.id] = transaction


def do_work():
    print("doing some work...")

⚠️ Automatic instrumentation of all functions is also possible via monkeypatching (fidning stable library is pending).


❌ Only manual instrumentation.

Appendix C: Paths Not Taken


With eBPF we can track latency, but we would not be able to assign errors to spans. Some platforms may not have access to eBPF.

Wrapping internal functions

Benefit of wrapping is to keep original code without modifications. However, manual step for switching would still be requied. Given every single function is duplciated and is within same package, code will quickly become messy and hard to maintain by user.

Wrapping exported functions

Typically, packages are failry big and performs lots of logic. Oftencase, business domains are split only in few large packages. Low level packages are already likely to be traced with standard tracing (MySQL, het/http, etc). Thus, it is doubtful how much benefit would be from tracing only exported functions and only on import.

Wrapping exported functions with separate package

This would lead to circular dependency failure, since some even exported functions in original package may be called withing same package. Thus, we would either skip those calls, or fail with circular dependency while trying to wrap those.