Introduction
This blog post is part of an ongoing series on OpenTelemetry.
This guide is addressed to developers, product managers, and enthusiasts worldwide looking to contribute to the OpenTele...
See more...
Introduction
This blog post is part of an ongoing series on OpenTelemetry.
This guide is addressed to developers, product managers, and enthusiasts worldwide looking to contribute to the OpenTelemetry project.
OpenTelemetry is a vast project with the aim of standardizing and promoting observability best practices around metrics, traces, and logs. OpenTelemetry defines a model to represent metrics, traces, and logs. It defines well-known semantic conventions around metric names, dimensions, units, and properties.
The project implements the common model into a protobuf model. This model generates code in SDKS associated with different languages. The project also implements a collector which is able to integrate with various technologies, receiving or sending data.
The Hero’s Journey
As a hopeful contributor to the OpenTelemetry project, you will want to offer changes to a project such as the collector or a specific SDK.
Track your work with an issue
Your first stop is to check the existing issues on the projects and check if someone has already started working on this. Please create a new issue right away to talk about your work and expose it to the community.
It takes time for the community to gel with new ideas - you should be prepared to talk about your idea and your design. If you require help, you can attend a SIG meeting to discuss your proposal. You can also ask questions on the CNCF slack.
When opening an issue, you will be offered a template to help guide you through the steps of qualifying your issue. If you are proposing a new component, you may need a maintainer to sponsor your addition. If you stop there - that is already helping the project move forward! We thank you for your contribution.
Shift Left Your Work
Devopedia. 2022. "Shift Left." Version 6, February 15. Accessed 2022-06-15. https://devopedia.org/shift-left
The OpenTelemetry project is a bit different from most open source projects as it is not just software - it also defines a specification. As you start working on the project, you will notice that you have to make design choices, such as naming metrics, or making configuration choices and choosing valid defaults. Naming is hard - finding consensus on naming is harder.
As you progress, you should open a new issue under the OpenTelemetry specification repository and tie it to your original issue to provide context to maintainers. The specification contains information about SDK environment variables, semantic conventions, sampling, instrumentation, and data serialization methods.
Please provide a pull request with your changes, and attend one of the OpenTelemetry Specification SIG meetings to discuss them. Once those changes are merged, you have done the hardest part of contributing to OpenTelemetry, and the design choices that you have made will make the next step easy. However, if you are not a developer, this is already a transformative effort. Thank you for your help!
Cultivate the law of Least Surprise
Now armed with a plan and having built consensus around your changes, you are well positioned to implement your changes. A good rule of thumb is to be as least surprising as possible when it’s time to review your code. You should, of course, have great test coverage, and make sure the build passes and that documentation is up to date. You should also prefer small changes instead of a large pull request. It’s much easier to say yes to three small pull requests than a large one. When you open a new pull request against the repository, it will be automatically assigned to a maintainer based on the paths you touch in your pull request. You should leave your pull request as a draft while it is still being developed.
An Example
I took on the task of adding a new metric to host metrics, the number of threads of a running process as exposed to the hostmetrics receiver. First, I looked for an open issue and found that someone had already filed an issue for this use case. Citing this issue, I created a pull request specifically for this new metric. I joined the specification SIG call to discuss the merits of my new addition: 2022-08-09 meeting I also discussed this addition on the ticket. The specification SIG met one more time to discuss this new metric.
Once the specification’s pull request was merged, I could concentrate on the changes to the collector.
I changed the hostmetrics receiver to optionally report thread count. I made sure to add this information to the changelog using a yaml file under the unreleased folder at the root of the repository. With this pull request merged, I could start using this new metric after the next release, 0.59.
— Antoine Toulme, Senior Engineering Manager, Blockchain & DLT