Below are terms you will hear and see frequently when you learn about and use OpenTelemetry; understanding what each one refers to will help cement your knowledge and enable you to navigate conversations about OpenTelemetry.
The OpenTelemetry API provides a standard way to collect instrumentation data. It is separate from any implementation (see: SDK) and defaults to a no-op provider (“provider” is also referred to as the SDK) if no provider is loaded when an app starts. This means that without the SDK, the API calls simply become no-ops; in other words, an SDK has to be loaded so we can use the API.
The OpenTelemetry SDK provides standard ways to configure what happens, or what we want to do, with the instrumentation data that’s collected by the API. It is the implementation of the API, or how we utilize the API. Generally, resource creation and configuration occurs in the SDK.
The OpenTelemetry semantic conventions describe the standard format for data from common operations. Its power lies in bringing uniformity to data, which allows backends such as New Relic to easily parse and identify relevant information.
The OpenTelemetry specification (or “spec”) provides blueprints for all of the above to bring standardization across all languages. For example, the spec defines a standardized data model for what a trace is, what an exporter should do, and what is required to create a resource, and anyone implementing OpenTelemetry can* expect the behavior to be the same across the different language SDKs they are using.
*Currently, because the OpenTelemetry project is still evolving, actual behavior may vary depending on the level of maturity within each specific language.
The OpenTelemetry Collector is a highly configurable system for processing data that you can implement as part of your observability strategy with OpenTelemetry, as it provides a wide range of configuration options for your data (e.g., sampling and data scrubbing). You don’t need to stand up a Collector to export trace data to New Relic as you can configure an exporter directly in your SDK, but it can be extremely useful in some cases, such as for centralizing configuration, and for removing the need to redeploy your service when you need to add a new exporter. The Collector is where you will build and manage pipelines for the different signals (metrics, logs, traces) being collected from your services.