|
| 1 | +--- |
| 2 | +title: |
| 3 | + Alibaba, Datadog, and Quesma Join Forces on Go Compile-Time Instrumentation |
| 4 | +linkTitle: Go Compile-Time Instrumentation |
| 5 | +date: 2025-01-24 |
| 6 | +author: OpenTelemetry Governance Committee |
| 7 | +issue: https://github.com/open-telemetry/community/issues/2509 |
| 8 | +sig: Governance Committee |
| 9 | +cSpell:ignore: instrgen quesma toolexec |
| 10 | +--- |
| 11 | + |
| 12 | +Standards are only useful if they're widely adopted, and adoption is only |
| 13 | +effective if the available tooling facilitates it. I imagine |
| 14 | +[SI units](https://en.wikipedia.org/wiki/International_System_of_Units) would |
| 15 | +not have been too popular when they were introduced if you had to build your own |
| 16 | +scales to weigh things in Kilograms! |
| 17 | + |
| 18 | +If you use [OpenTelemetry in Go](/docs/languages/go/), you'll be familiar with |
| 19 | +the challenges of configuring instrumentation libraries to automatically |
| 20 | +generate telemetry from well-known open source components. Due to the compiled |
| 21 | +nature of the language, you currently have two options[^1]: |
| 22 | + |
| 23 | +- Use a separate binary that analyzes your Go process and attaches eBPF programs |
| 24 | + to hooks in your application — see |
| 25 | + [opentelemetry-go-instrumentation](https://github.com/open-telemetry/opentelemetry-go-instrumentation/). |
| 26 | +- Manually configure instrumentation libraries in your code, for example see |
| 27 | + [Instrument the HTTP server](/docs/languages/go/getting-started/#instrument-the-http-server). |
| 28 | + |
| 29 | +For different reasons, it is possible that none of those options is viable, or |
| 30 | +optimal, in your environment. However, things are about to change! |
| 31 | + |
| 32 | +## Industry collaboration at the heart of open standards |
| 33 | + |
| 34 | +Over the past few months, OpenTelemetry has received not one, but two donation |
| 35 | +proposals from industry leaders to provide a solution to the problem described |
| 36 | +above, and enable the use of zero-code, vendor-neutral, compile-time |
| 37 | +instrumentation in Go applications. These are: |
| 38 | + |
| 39 | +- Alibaba's |
| 40 | + [donation proposal](https://github.com/open-telemetry/community/issues/2344) |
| 41 | + of |
| 42 | + [opentelemetry-go-auto-instrumentation](https://github.com/alibaba/opentelemetry-go-auto-instrumentation) |
| 43 | +- Datadog's |
| 44 | + [donation proposal](https://github.com/open-telemetry/community/issues/2497) |
| 45 | + of [Orchestrion](https://github.com/datadog/orchestrion) |
| 46 | + |
| 47 | +We are very grateful to Alibaba and Datadog for these donation proposals. This |
| 48 | +continues to demonstrate the convergence of the wider industry towards the |
| 49 | +standards defined by OpenTelemetry. |
| 50 | + |
| 51 | +Compile-time instrumentation leverages the standard Go toolchain’s `-toolexec` |
| 52 | +mechanism to re-write Go source code before it is passed to the Go compiler, |
| 53 | +adding instrumentation in all relevant places (including dependencies as well as |
| 54 | +the Go standard library). |
| 55 | + |
| 56 | +The most exciting part of this announcement is that it won't be Alibaba's or |
| 57 | +Datadog's solution that "wins". In the true spirit of open source collaboration, |
| 58 | +these two organizations have decided to join forces and commit the necessary |
| 59 | +resources to bootstrap a new |
| 60 | +[Go Compile-Time Instrumentation SIG](https://github.com/open-telemetry/community/blob/main/projects/go-compile-instrumentation.md), |
| 61 | +with the intention of providing a unified, vendor-neutral approach that picks |
| 62 | +the best aspects of each solution and benefits the community as a whole. They |
| 63 | +will be supported with further contributions from Quesma, bringing in experience |
| 64 | +on |
| 65 | +[instrgen](https://github.com/open-telemetry/opentelemetry-go-contrib/blob/dafdad14b7858c7f491c8cb72e4bc7deaf9378e3/instrgen/README.md), |
| 66 | +OpenTelemetry's initial experimental approach to provide Go compile-time |
| 67 | +instrumentation based on `-toolexec` and which will be superseded as part of the |
| 68 | +initial efforts of this SIG. |
| 69 | + |
| 70 | +In the longer term, this SIG will focus on: |
| 71 | + |
| 72 | +- Developing compiler plugins or enhancements that inject instrumentation code |
| 73 | + automatically, ensuring minimal runtime performance overhead and compatibility |
| 74 | + with existing Go projects. |
| 75 | +- Providing standardized instrumentation patterns aligned with OpenTelemetry and |
| 76 | + other monitoring frameworks. |
| 77 | + |
| 78 | +If you are interested in contributing, or you simply want to find out more, |
| 79 | +here's some useful information about the SIG: |
| 80 | + |
| 81 | +- GitHub repository: |
| 82 | + [opentelemetry-go-compile-instrumentation](https://github.com/open-telemetry/opentelemetry-go-compile-instrumentation) |
| 83 | +- CNCF Slack: |
| 84 | + [#otel-go-compt-instr-sig](https://cloud-native.slack.com/archives/C088D8GSSSF) |
| 85 | +- Meetings: Every other Thursday UTC: 08:00 – 09:00 (subscribe to |
| 86 | + [this Google Group](https://groups.google.com/a/opentelemetry.io/g/calendar-go) |
| 87 | + for calendar invites, or read more about |
| 88 | + [our community calendar](https://github.com/open-telemetry/community/?tab=readme-ov-file#calendar)) |
| 89 | + |
| 90 | +We look forward to seeing this new SIG in operation, and cannot wait for the |
| 91 | +fruits of this awesome collaboration! |
| 92 | + |
| 93 | +[^1]: |
| 94 | + Unless you want to "build your own scales", or the OTel equivalent, which is |
| 95 | + manually instrumenting third-party libraries. |
0 commit comments