The Go Instrumnentation special interest group (SIG) meets regularly. See the OpenTelemetry community repo for information on this and other language SIGs.
See the public meeting notes for a summary description of past meetings. To request edit access, join the meeting or get in touch on Slack.
It is important to note what this project is and is not intended to achieve. This helps focus development to these intended areas and defines clear functional boundaries for the project.
This project aims to provide auto-instrumentation functionality for Go applications using eBPF and other process-external technologies. It conforms to OpenTelemetry standards and strives to be compatible with that ecosystem.
This project is expected to be wrapped into some runnable executable that will
further extend the functionality and ergonomics of the project. The auto/cli
package is an example of a wrapping executable and is not apart of this scope.
- Process discovery: This project does not discover nor manage process
auto-instrumentation life-cycles. It is expected that this is done external
to the
autopackage and the results are passed to any createdInstrumentation. - Multi-language auto-instrumentation: This project is focused on instrumentation for the Golang programming language.
- Host instrumentation: This project does not focus on instrumentation for the host or platform running processes.
Update using either make or the GitHub workflow1.
# Optionally, export a version constraint to use.
$ export LIBBPF_VERSION="< 1.5, >= 1.4.7"
$ make synclibbpf
Building requires Linux with kernel 4.4 or higher. In addition, use the latest versions of the following components:
clanggccgolibbpf-devllvmmake
Build the Go Automatic Instrumnentation binary by running:
make build
Alternatively, you can create a Linux Docker container:
make docker-build.
Questions, bug reports, and feature requests can all be submitted as issues to this repository.
Note
We are currently not accepting PRs to add new instrumentation probes. A new [instrumentation probe API] is being designed. To avoid excessive churn and development burden, we will not be accepting new instrumentation probes until that API is completed.
Please do open an issue to track your request for new instrumentation. We would like to know what we are missing and how you plan to use it.
Everyone is welcome to contribute code to opentelemetry-go-instrumentation via
GitHub pull requests (PRs).
To create a new PR, fork the project in GitHub and clone the upstream repo:
go get -d go.opentelemetry.io/auto(This may print some warning about "build constraints exclude all Go files", just ignore it.)
This will put the project in ${GOPATH}/src/go.opentelemetry.io/auto. You
can alternatively use git directly with:
git clone https://github.com/open-telemetry/opentelemetry-go-instrumentation(Note that git clone is not using the go.opentelemetry.io/auto name -
that name is a kind of a redirector to GitHub that go get can
understand, but git does not.)
This would put the project in the opentelemetry-go-instrumentation directory in
current working directory.
Enter the newly created directory and add your fork as a new remote:
git remote add <YOUR_FORK> [email protected]:<YOUR_GITHUB_USERNAME>/opentelemetry-go-instrumentationCheck out a new branch, make modifications, run linters and tests, update
CHANGELOG.md, and push the branch to your fork:
git checkout -b <YOUR_BRANCH_NAME>
# edit files
# update changelog
make precommit
git add -p
git commit
git push <YOUR_FORK> <YOUR_BRANCH_NAME>Additionally, there is a codespell target that checks for common
typos in the code. It is not run by default, but you can run it
manually with make codespell. It will set up a virtual environment
in venv and install codespell there.
Open a pull request against the main opentelemetry-go-instrumentation repo. Be sure to add the pull
request ID to the entry you added to CHANGELOG.md.
- If the PR is not ready for review, please put
[WIP]in the title, tag it aswork-in-progress, or mark it asdraft. - Make sure CLA is signed and CI is clear.
A PR is considered ready to merge when:
-
It has received at least one qualified approval1.
For complex or sensitive PRs maintainers may require more than one qualified approval.
-
All feedback has been addressed.
- All PR comments and suggestions are resolved.
- All GitHub Pull Request reviews with a status of "Request changes" have been addressed. Another review by the objecting reviewer with a different status can be submitted to clear the original review, or the review can be dismissed by a Maintainer when the issues from the original review have been addressed.
- Any comments or reviews that cannot be resolved between the PR author and reviewers can be submitted to the community Approvers and Maintainers during the weekly SIG meeting. If consensus is reached among the Approvers and Maintainers during the SIG meeting the objections to the PR may be dismissed or resolved or the PR closed by a Maintainer.
- Any substantive changes to the PR require existing Approval reviews be cleared unless the approver explicitly states that their approval persists across changes. This includes changes resulting from other feedback. Approvers and Maintainers can help in clearing reviews and they should be consulted if there are any questions.
-
The PR branch is up to date with the base branch it is merging into.
- To ensure this does not block the PR, it should be configured to allow maintainers to update it.
-
All required GitHub workflows have succeeded.
-
Urgent fix can take exception as long as it has been actively communicated among Maintainers.
Any Maintainer can merge the PR once the above criteria have been met.
- Nikola Grcevski, Grafana Labs
- Robert Pająk, Splunk
- Eden Federman, Odigos
- Mike Dame, Odigos
- Ron Federman, Odigos
- Tyler Yahn, Splunk
- Dinesh Gurumurthy, DataDog
- Mike Goldsmith, Honeycomb
- Przemyslaw Delewski, Quesma
See the community membership document in OpenTelemetry community repo.