Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Setting naming convention for exporter packages #629

Merged
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,7 @@ the release.
## Unreleased

- Remove SpanId from Sampler input.
- Added conventions for naming of exporter packages

## v0.3.0 (02-21-2020)

Expand Down
10 changes: 8 additions & 2 deletions specification/glossary.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,13 @@ Denotes the library that implements the *OpenTelemetry API*.
See [Library Guidelines](library-guidelines.md#sdk-implementation) and
[Library resource semantic conventions](resource/semantic_conventions/README.md#telemetry-sdk)

<a name="instrumented_library"></a>
<a name="telemetry_sdk"></a>
toumorokoshi marked this conversation as resolved.
Show resolved Hide resolved

### Exporter Library

Libraries which are compatible with the [Telemetry SDK](glossary.md#telemetry-sdk) and provide functionality to emit telemetry to consumers.

<a name="exporter_library"></a>

### Instrumented Library

Expand All @@ -37,7 +43,7 @@ Example: `io.opentelemetry.contrib.mongodb`.

Synonyms: *Instrumenting Library*

<a name="name"></a>
<a name="instrumentation_library"></a>

### Tracer Name / Meter Name

Expand Down
6 changes: 6 additions & 0 deletions specification/library-guidelines.md
Original file line number Diff line number Diff line change
Expand Up @@ -83,6 +83,12 @@ Vendors are encouraged to keep protocol-specific exporters as simple as possible

End users should be given the flexibility of making many of the decisions regarding the queuing, retrying, tagging, batching functionality that make the most sense for their application. For example, if an application's telemetry data must be delivered to a remote backend that has no guaranteed availability the end user may choose to use a persistent local queue and an `Exporter` to retry sending on failures. As opposed to that for an application that sends telemetry to a locally running Agent daemon, the end user may prefer to have a simpler exporting configuration without retrying or queueing.

If additional exporters for the sdk are provided as separate libraries, the
toumorokoshi marked this conversation as resolved.
Show resolved Hide resolved
name of the library should be prefixed with opentelemetry, then exporter, using the namespacing conventions of the particular language. For example:

- python: opentelemetry-exporter-jaeger
- javascript: @opentelemetry/exporter-jeager

### Alternative Implementations

The end-user application may decide to take a dependency on alternative implementation.
Expand Down
2 changes: 1 addition & 1 deletion specification/trace/sdk_exporters/zipkin.md
Original file line number Diff line number Diff line change
Expand Up @@ -54,7 +54,7 @@ and Zipkin.

Zipkin service name MUST be set to the value of the
[resource attribute](../../resource/semantic_conventions/README.md):
`service.name`. In Zipkin it is important that the service name is consistent
`service.name`. In Zipkin it is important that the service name is consistent
for all spans in a local root. Otherwise service graph and aggregations would
not work properly. OpenTelemetry doesn't provide this consistency guarantee.
Exporter may chose to override the value for service name based on a local root
Expand Down