What Is OpenTelemetry?

OpenTelemetry (OTel) is an open-source collection of software tools for instrumenting, generating, collecting, and exporting telemetry data like metrics, logs, and traces for analysis. Modern applications have complex, interconnected software systems that exchange data with multiple internal services and external third parties to fulfill a single user request. Collecting telemetry data, or instrumenting, across diverse systems written in different programming languages and technologies can be challenging. OpenTelemetry is a collaborative effort by tracing solution providers to offer a common ground for instrumentation. Instead of each provider having their own solution, they support the standard format OpenTelemetry defines.

OpenTelemetry supports metrics, logs, traces, and baggage known as Signals. Signals are point-in-time measurements or events through a distributed system.

Metrics

A metric is a cumulative or point-in-time measurement of a running service. Examples of metrics include data throughput rate, request response time, and error number in a given period. A metric is defined by name, kind (type, such as counter or histogram), optional unit, and optional description. Metrics can also be aggregated across a period. Metrics are defined when instrumenting services or applications.

Logs

Logs in OpenTelemetry are a way to standardize timestamped logs across different services and functions, such as existing system logs. The log model allows existing logs to be translated into a standardized format.

Traces

The trace data type is a form of logging that can show the full path of a request through a system across many distributed services. A trace has one or more spans, each a discrete operation or unit of work. Spans are organized in a parent-child acyclical graph within a single trace stemming from one root span.

An example of where a trace could be used is in a password reset operation. A user enters their email address and selects password reset, which then triggers events like:

• Send an email
• Start a timer for the reset expiry period
• Increment a password reset counter to avoid fraud.

The user must click through the email to reset their password. Potential metrics could include the average total time for the task, the average time spent in each operation, daily errors, and the number of password reset limits hit weekly.

Baggage

Baggage is a key-value pair mechanism that annotates this data to all spans across a trace. For instance, in an ecommerce transaction, an order ID might be needed across the trace. If the order ID doesn’t exist within an inventory function when baggage is used on the trace, the span within the inventory function comes with the same attached order ID as from the orders function.

Observability is often mentioned within site reliability engineering (SRE), a field of system management and application monitoring designed to improve application reliability. It refers to the ability to measure and analyze various performance qualities of a product or service from outside the system itself.

Achieving observability requires internal instrumentation and data collection to output quantitative telemetry data. The telemetry data can then be used in tasks like

• Checking whether a given metric meets a service level objective.
• Performing root cause analysis in the case of system problems.
• Determining which system components may require code refactoring or system reconfiguration due to poor performance.

Many tools can be involved in observability, making the process complex and completely different for each application.

Standardization in observability

OpenTelemetry is an open source project from the Cloud Native Computing Foundation (CNCF). It provides a common, standardized observability framework for various tooling, programming languages, infrastructure, and runtimes. With an open, standardized framework, developers and operations teams can quickly and easily create, manage, and export telemetry data, regardless of tooling or infrastructure. Telemetry data is emitted from a service or application and then consumed by an observability backend or tool for further tracking and analysis.

Before OpenTelemetry, developers and operations teams had to purchase expensive, closed-source solutions with proprietary data types or build their own version using custom data collection code. It involved a significant amount of work and investment. Since the convergence of OpenTracing and OpenCensus projects in 2021 into an official OpenTelemetry release, a better solution exists for this complex problem space.

No vendor lock-in

Unlike other telemetry solutions, OpenTelemetry allows organizations full control and ownership of their telemetry data. Proprietary vendors can lock organizations into their solutions to retain customers. OpenTelemetry is open-source and vendor-neutral, allowing individuals and organizations worldwide to use and progress the project without economic or regional barriers.

Highly integrative

OpenTelemetry is designed to integrate with as wide a range of solutions and programming languages as possible, so there is no vendor lock-in to a particular set of requirements or product suites. It has native integration with various tools and platforms, including Grafana, AWS, Splunk, Prometheus, and Jaegar. OpenTelemetry also has application programming interfaces(APIs) and software development kits(SDKs) for Python, C++, PHP, Java, Go, and other programming languages.

Cloud-native

OpenTelemetry is a cloud-native framework designed specifically for distributed cloud infrastructure and tooling.

Cloud-native applications have microservices architecture that decomposes the application into smaller, independent services to perform specific business functions. Containers package up code and all its dependencies so the application runs quickly and reliably from one computing environment to another.

OpenTelemetry’s distributed tracing features track and observe service requests flowing through the distributed systems. You can deploy it alongside application containers, use Kubernetes for orchestration, and utilize cloud services to store and analyze the telemetry data.

Portable

Thanks to its wide range of integrations, OpenTelemetry is also highly portable. You can swap or replace different tools or solutions if and when the business or use case requires it.

OpenTelemetry works in distributed systems by using context propagation. Context propagation allows any type of signal, regardless of service, system, network, or architecture, to be correlated with signals from other places in one object.

Instrumentation

Instrumentation is how and where logs, metrics, and traces are defined. To create and emit these signals, services, and applications must be instrumented in-code or with zero-code customization. Note that OpenTelemetry’s zero-code offerings are currently somewhat limited. After instrumentation, when a service or application runs, it generates telemetry data.

Transport to observability backend

Out of the box, OpenTelemetry uses the OpenTelemetry Protocol (OTLP) to codify and transport telemetry data in client-server systems over gPRC and REST. This can be consumed directly by an appropriate observability backend. There are also options to export telemetry data directly from the instrumented code to various solutions. When more complex systems are involved, an OpenTelemetry collector object can collect telemetry data from multiple sources, which then exports telemetry data to observability tools.

As a leading cloud service provider, AWS runs many of the world’s distributed and containerized applications across its infrastructure. With the proper OpenTelemetry instrumentation and observability tooling, you can accurately monitor these distributed apps to improve user experience and meet expected performance requirements.

AWS Distro for OpenTelemetry is a secure, production-ready, open-source distribution with reliable performance, specifically designed for OpenTelemetry data, instrumentation, and runtimes.

AWS Distro for OpenTelemetry integrates with Amazon Cloudwatch, an AWS monitoring service for cloud resources and the applications that you run on AWS. It can collect and track metrics, monitor log files, and set alarms. Users can collect data, analyze and view custom metrics, create dashboards, identify trends, and set alarms to monitor applications proactively.

AWS Distro for OpenTelemetry also integrates with AWS X-Ray. This fully managed service helps developers analyze and debug distributed microservices applications in production. X-Ray provides an end-to-end view of requests as they travel through your application and shows a map of your application’s underlying components. You can identify and troubleshoot the root cause of performance issues and errors.

Get started with OpenTelemetry on AWS by creating a free account today.