Distributed systems and microservice architectures can be complicated in terms of networks. When an end user clicks on a website, many web requests go from...
Migrating to the cloud is deeply desirable due to ease of the management, scalability and many other factors, however poor choices in the migration process can lead to increased costs, poor performance and tech debt. Learn about the top 7 cloud migration mistakes and how to avoid them.
Learn how AWS Control Tower can accelerate your cloud foundation by simplifying and automating AWS account creation, governance & management.
Learn about AWS Control Tower's features and capabilities, uses cases where it can maximize value and updates announced at AWS re:Invent 2021.
Distributed systems and microservice architectures can be complicated in terms of networks. When an end user clicks on a website, many web requests go from the client's browser to the web server. On the backend, there are network requests flowing all over the place between microservices, databases, proxies, and more. With the end user clicking around on the website and traffic flowing all over the place to backend systems, it is often difficult for engineers to find out where the bottlenecks are and on which components the requests are spending the most time. For example, a particular request can spend time at the database layer, trying to get all the data, calling a third-party API, or maybe it’s attempting to process business logic within several microservices. To understand this, it’s important to have distributed tracing set up.
As applications become more complex and more services are involved in serving user traffic, it becomes critical to understand how requests traverse services and how each service contributes to overall latency. This is what distributed tracing does. It captures telemetry information of user requests and how long it takes each microservice in the path to return a response.
When a user request comes in, it’s important to create a trace i.e., the representation of the request journey as it moves through all the services of a distributed system. Traces are composed of spans, where each span represents a specific request and response pair involved in serving the user request. The parent span describes the latency as observed by the end-user. Each child span describes how a particular service in the distributed system was called and responded with latency information captured for each.
OpenTelemetry is a framework that provides a collection of APIs, libraries, agents, and tools to capture traces, logs and metrics from an application. OpenTelemetry aims to standardize the way in which telemetry data is collected and sent to different backend platforms. This provides a vendor-neutral path for instrumentation and delivers the flexibility to change the observability backend platform (i.e, to move from New Relic to Datadog or vice versa) without having to instrument the application code again. To be clear, OpenTelemetry does not replace Jaeger or Prometheus, which are observability backends. But the project helps in exporting data to both open-source and commercial backends.
Below are the features that OpenTelemetry provides:
There are multiple components of OpenTelemetry:
At the high level, OpenTelemetry consists of three main pieces:
The purpose of the API is to enable the instrumentation for libraries and application code. The API can be divided into four distinct sections: tracing, meters, shared context and semantic conventions.
The OpenTelemetry SDK is the implementation of the OpenTelemtry API.
The SDK is implemented in the most popular languages like JavaScript, Java, Python, Ruby, Go, .NET, C++, giving developers a broad support for their languages of choice.
The Collector is a standalone service that can ingest metrics and spans from a wide variety of sources, including Zipkin, Jaeger, OpenCensus, and of course, the OpenTelemetry protocol itself. You can configure the collector to do tail-based sampling of those spans. It also enables exporting spans and metrics to a large number of vendor and open-source telemetry systems.
It is important to note that although the OpenTelemetry architecture intends to be a complete telemetry solution out of the box, there are many extension points that allow for customization as needed.
If you do not want to be locked into a vendor contract, OpenTelemetry is a great vendor-neutral solution that supports open standards.
Caylent provides a critical DevOps-as-a-Service function to high-growth companies looking for expert support with Kubernetes, cloud security, cloud infrastructure, and CI/CD pipelines. Our managed and consulting services are a more cost-effective option than hiring in-house, and we scale as your team and company grow. Check out some of the use cases, learn how we work with clients, and read more about our DevOps-as-a-Service offering.
Caylent Team