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

add vendors.md doc about what it means to support opentelemetry #594

Merged
merged 5 commits into from
May 21, 2020
Merged
Changes from 1 commit
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
51 changes: 51 additions & 0 deletions specification/vendors.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,51 @@
# Vendors

<details>
<summary>Table of Contents</summary>

* [Abstract](#abstract)
* [What it means to support OpenTelemetry](#what-it-means-to-support-opentelemetry)

</details>

## Abstract

The OpenTelemetry project consists of both a
[specification](https://github.com/open-telemetry/opentelemetry-specification)
for the API, SDK, protocol and semantic conventions, as well as an
implementation of each for a number of languages. The default SDK implementation
is [highly configurable](sdk-configuration.md) and extendable, for example
through [Span Processors](trace/sdk.md#span-processor), to allow for additional
logic needed by particular vendors to be added without having to implement a
custom SDK. By not requiring a custom SDK means for most languages a user will
already find an implementation to use and if not they'll have a well documented
specification to follow for implementing in a new language.

The goal is for users to be able to easily switch between vendors while also
ensuring that any language with an OpenTelemetry SDK implementation is able to
work with any vendor who claims support for OpenTelemetry.

This document will explain what is required of a vendor to be considered to
"Support OpenTelemetry" or "Implements OpenTelemetry".

## What it means to support OpenTelemetry

## Tracing, Metrics and Logging Qualifications
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably having the sections instead as Implements OpenTelemetry and Supports OpenTelemetry (with their respective clarifications and side notes) will be easier for new users to grasp.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, I'll update them.


A vendor can qualify their support for OpenTelemetry with the type of telemetry
they support. For example, a vendor that accepts the OpenTelemetry protocol
exports for metrics only will be listed as "Supports OpenTelemetry Metrics".

### Default SDK and the OpenTelemetry Protocol

"Supports OpenTelemetry" means the vendor must accept the output of the default
SDK through the OpenTelemetry Protocol either directly -- meaning the vendor's
tsloughter marked this conversation as resolved.
Show resolved Hide resolved
endpoint/collector/agent implements the receiver end of the protocol -- or as an
tsloughter marked this conversation as resolved.
Show resolved Hide resolved
exporter that works with the [OpenTelemetry
tsloughter marked this conversation as resolved.
Show resolved Hide resolved
Collector](https://github.com/open-telemetry/opentelemetry-collector/).
tsloughter marked this conversation as resolved.
Show resolved Hide resolved

### Custom SDK

A vendor with a custom SDK implementation will be listed as "Implements
OpenTelemetry". If the custom SDK is optional then the vendor can be listed as
"Supports OpenTelemetry".