Distributed Tracing for C++ Applications with OpenTelemetry & Logz.io

Many organizations are moving from monolithic to microservices-based architectures. Microservices allow them to improve their agility and provide features more quickly. Although developing a single microservice is simpler, the complexity of the overall system is much greater. Here, we’ll review how to add distributed tracing to C++ with the OpenTelemetry collector and send to Logz.io.

One of the biggest challenges is finding efficient tools to quickly debug and solve production problems. This is done through logging, distributed tracing, and analyzing various metrics. 

OpenTelemetry is a collection of tools to monitor applications and infrastructure by instrumenting, generating, collecting, and exporting telemetry data. This includes metrics, logs, and traces. 

Check out our OpenTelemetry guide for more.

Typically, this data is streamed to some sort of user interface (UI), where it can be filtered, searched, and monitored from one place. Jaeger is one example of this type of tool. 

The microservices approach promotes using various programming interfaces. While you can find many examples of how to use distributed tracing in high-level programming languages, including C#, Java, Go, and Node.js, many companies use C++ to create highly performant applications. 

To keep the discussion clear, we’ll use an app composed of two microservices that communicate with each other through HTTP. Although we can choose from several different exporters, or make our own, we’re using Logz.io here. 

You can find the repo for the Logz.io OpenTelemetry collectorcode on GitHub

Getting Started 

We’ll start by creating two HTTP services with C++ named service-a and service-b. Both expose the ping endpoints. Additionally, when the ping endpoint of service-a is invoked, it automatically sends a ping to service-b.  

To implement HTTP server and client functionality, we’ll be using the Pistache framework. We can build the framework ourselves, or install it as a dependency in various ways (including CMake build configuration and Pkg-Config). The companion code to this tutorial uses a CMake build configuration to compile Pistache from the source code that we previously cloned from the Git repository (see the common/pistache subfolder). 

The HTTP server-side code looks the same for both services (see service.hpp under the service-a or service-b subfolders). We’ll first set up routes, like this: 

Leave a Reply