open-telemetry / open-telemetry/opentelemetry-cpp

Document common usecases and recommended usage

Open
#688 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

do-not-stale documentation
Dominant language
C++
Stars
1.4k
Forks
632
Avg merge
1d 13h
Merged PRs (30d)
75

Description

(came up during OpenTelemetry C++ SIG)

Creating this issue to track the common use-cases that we want to document in more detail. It would be ideal to add this documentation to readthedocs/Getting Started so that these common users can get started quickly without having to fully understand all the build options.

We can start in the roles defined in the specification here https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/glossary.md#user-roles

I've interpreted these roles to map to the use-cases of:

  • Application Owner - I want my application to generate telemetry, I need to use sdk (and possibly install a vendor-specific)
  • Instrumentation Author - Any-one using the api to instrument their application OR library code
  • Library Author - A library that is instrumented using the api but is intended to be used by other applications (or libraries) and may be distributed by itself
  • Plugin Author - Someone (likely a vendor) who uses sdk and provides an SDK plugin that application owners can install

Please add comments for any use-cases that you may be interested in.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the readthedocs Getting Started section and the user roles in the OpenTelemetry specification glossary. Review how the C++ API and SDK are currently explained for application owners, instrumentation authors, library authors, and plugin authors. Done means adding clear guidance for the identified common use cases without requiring readers to understand all build options.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
documentation
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.