Architecture and System Requirements for OpenTelemetry

Most distributed tracing tools work in a very similar fashion. A small bit of code inside your application is configured to record spans and send those spans to a data pipeline that ultimately stores them for later searching and investigation.
Open Telemetry diagram

The individual tools differ slightly on the exact mechanism and terminology, but at a high level there are typically 5 components:

Components in a Typical OpenTelemetry Tool

The individual tools differ slightly on the exact mechanism and terminology, but at a high level there are typically 5 components:

  • Client: Library running inside your application which sends spans to the collector

  • UI: Web UI for viewing traces

  • Collector: Receives spans from clients and routes to the backend

  • Storage: Stores and retrieves span data

  • API: JSON/REST API for retrieving traces

Components in Aternity APM OpenTelemetry

Using Aternity APM with an OpenTelemetry tool allows you to integrate Aternity APM with an application that has already been instrumented using Zipkin or Jaeger. There are three components that comprise Aternity APM OpenTelemetry tool:

  • Client: Uses Zipkin or Jaeger to instrument your application

  • APM Collector: Collects traces from Client machines

  • Analysis Server: Handles spans' storage and retrieval as well as displays data on the WebUI landing page

APM OpenTelemetry diagram