Improving upon my OpenTelemetry Tracing demo

Nicolas Fränkel - Feb 1 - - Dev Community

Last year, I wrote a post on Open Telemetry Tracing to understand more about the subject. I also created a demo around it, which featured the following components:

  • The Apache APISIX API Gateway
  • A Kotlin/Spring Boot service
  • A Python/Flask service
  • And a Rust/Axum service

I've recently improved the demo to deepen my understanding and want to share my learning.

Using a regular database

In the initial demo, I didn't bother with a regular database. Instead:

  • The Kotlin service used the embedded Java H2 database
  • The Python service used the embedded SQLite
  • The Rust service used hard-coded data in a hash map

I replaced all of them with a regular PostgreSQL database, with a dedicated schema for each.

The OpenTelemetry agent added a new span when connecting to the database on the JVM and in Python. For the JVM, it's automatic when one uses the Java agent. One needs to install the relevant package in Python - see next section.

OpenTelemetry integrations in Python libraries

Python requires you to explicitly add the package that instruments a specific library for OpenTelemetry. For example, the demo uses Flask; hence, we should add the Flask integration package. However, it can become a pretty tedious process.

Yet, once you've installed opentelemetry-distro, you can "sniff" installed packages and install the relevant integration.

pip install opentelemetry-distro

opentelemetry-bootstrap -a install
Enter fullscreen mode Exit fullscreen mode

For the demo, it installs the following:

opentelemetry_instrumentation-0.41b0.dist-info
opentelemetry_instrumentation_aws_lambda-0.41b0.dist-info
opentelemetry_instrumentation_dbapi-0.41b0.dist-info
opentelemetry_instrumentation_flask-0.41b0.dist-info
opentelemetry_instrumentation_grpc-0.41b0.dist-info
opentelemetry_instrumentation_jinja2-0.41b0.dist-info
opentelemetry_instrumentation_logging-0.41b0.dist-info
opentelemetry_instrumentation_requests-0.41b0.dist-info
opentelemetry_instrumentation_sqlalchemy-0.41b0.dist-info
opentelemetry_instrumentation_sqlite3-0.41b0.dist-info
opentelemetry_instrumentation_urllib-0.41b0.dist-info
opentelemetry_instrumentation_urllib3-0.41b0.dist-info
opentelemetry_instrumentation_wsgi-0.41b0.dist-info
Enter fullscreen mode Exit fullscreen mode

The above setup adds a new automated trace for connections.

New automatically created span for database connection

Gunicorn on Flask

Every time I started the Flask service, it showed a warning in red that it shouldn't be used in production. While it's unrelated to OpenTelemetry, and though nobody complained, I was not too fond of it. For this reason, I added a "real" HTTP server. I chose Gunicorn, for no other reason than because my knowledge of the Python ecosystem is still shallow.

The server is a runtime concern. We only need to change the Dockerfile slightly:

RUN pip install gunicorn

ENTRYPOINT ["opentelemetry-instrument", "gunicorn", "-b", "0.0.0.0", "-w", "4", "app:app"]
Enter fullscreen mode Exit fullscreen mode
  • The -b option refers to binding; you can attach to a specific IP. Since I'm running Docker, I don't know the IP, so I bind to any.
  • The -w option specifies the number of workers
  • Finally, the app:app argument sets the module and the application, separated by a colon

Gunicorn usage doesn't impact OpenTelemetry integrations.

Heredocs for the win

You may benefit from this if you write a lot of Dockerfile.

Every Docker layer has a storage cost. Hence, inside a Dockerfile, one tends to avoid unnecessary layers. For example, the two following snippets yield the same results.

RUN pip install pip-tools 
RUN pip-compile
RUN pip install -r requirements.txt
RUN pip install gunicorn
RUN opentelemetry-bootstrap -a install

RUN pip install pip-tools \
  && pip-compile \
  && pip install -r requirements.txt \
  && pip install gunicorn \
  && opentelemetry-bootstrap -a install
Enter fullscreen mode Exit fullscreen mode

The first snippet creates five layers, while the second only one; however, the first is more readable than the second. With heredocs, we can access a more readable syntax that creates a single layer:

RUN <<EOF

  pip install pip-tools 
  pip-compile
  pip install -r requirements.txt
  pip install gunicorn
  opentelemetry-bootstrap -a install

EOF
Enter fullscreen mode Exit fullscreen mode

Heredocs are a great way to have more readable and more optimized Dockerfiles. Try them!

Explicit API call on the JVM

In the initial demo, I showed two approaches:

  • The first using auto-instrumentation, which requires no additional action
  • The second using manual instrumentation, with Spring annotations

I wanted to demo an explicit call with the API in the improved version. The use-case is analytics and uses a message queue: I get the trace data from the HTTP call and create a message with such data so the subscriber can use it as a parent.

First, we need to add the OpenTelemetry API dependency to the project. We inherit the version from the Spring Boot Starter parent POM:

<dependency>
    <groupId>io.opentelemetry</groupId>
    <artifactId>opentelemetry-api</artifactId>
</dependency>
Enter fullscreen mode Exit fullscreen mode

At this point, we can access the API. OpenTelemetry offers a static method to get an instance:

val otel = GlobalOpenTelemetry.get()
Enter fullscreen mode Exit fullscreen mode

At runtime, the agent will work its magic to return the instance. Here's a simplified class diagram focused on tracing:

OpenTelemetry Tracing API

In turn, the flow goes something like this:

val otel = GlobalOpenTelemetry.get()                                   //1
val tracer = otel.tracerBuilder("ch.frankel.catalog").build()          //2
val span = tracer.spanBuilder("AnalyticsFilter.filter")                //3
                 .setParent(Context.current())                         //4
                 .startSpan()                                          //5
// Do something here
span.end()                                                             //6
Enter fullscreen mode Exit fullscreen mode
  1. Get the underlying OpenTelemetry
  2. Get the tracer builder and "build" the tracer
  3. Get the span builder
  4. Add the span to the whole chain
  5. Start the span
  6. End the span; after this step, send the data to the OpenTelemetry endpoint configured

Adding a message queue

When I did the talk based on the post, attendees frequently asked whether OpenTelemetry would work with messages such as MQ or Kafka. While I thought it was the case in theory, I wanted to make sure of it: I added a message queue in the demo under the pretense of analytics.

The Kotlin service will publish a message to an MQTT topic on each request. A NodeJS service will subscribe to the topic.

Attaching OpenTelemetry data to the message

So far, OpenTelemetry automatically reads the context to find out the trace ID and the parent span ID. Whatever the approach, auto-instrumentation or manual, annotations-based or explicit, the library takes care of it. I didn't find any existing similar automation for messaging; we need to code our way in. The gist of OpenTelemetry is the traceparent HTTP header. We need to read it and send it along with the message.

First, let's add MQTT API to the project.

<dependency>
    <groupId>org.eclipse.paho</groupId>
    <artifactId>org.eclipse.paho.mqttv5.client</artifactId>
    <version>1.2.5</version>
</dependency>
Enter fullscreen mode Exit fullscreen mode

Interestingly enough, the API doesn't allow access to the traceparent directly. However, we can reconstruct it via the SpanContext class.

I'm using MQTT v5 for my message broker. Note that the v5 allows for metadata attached to the message; when using v3, the message itself needs to wrap them.

val spanContext = span.spanContext                                                //1
val message = MqttMessage().apply {

  properties = MqttProperties().apply {
    val traceparent = "00-${spanContext.traceId}-${spanContext.spanId}-${spanContext.traceFlags}" //2
    userProperties = listOf(UserProperty("traceparent", traceparent))             //3
  }
  qos = options.qos
  isRetained = options.retained

  val hostAddress = req.remoteAddress().map { it.address.hostAddress }.getOrNull()
  payload = Json.encodeToString(Payload(req.path(), hostAddress)).toByteArray()   //4
}
val client = MqttClient(mqtt.serverUri, mqtt.clientId)                            //5
client.publish(mqtt.options, message)                                             //6
Enter fullscreen mode Exit fullscreen mode
  1. Get the span context
  2. Construct the traceparent from the span context, according to the W3C Trace Context specification
  3. Set the message metadata
  4. Set the message body
  5. Create the client
  6. Publish the message

Getting OpenTelemetry data from the message

The subscriber is a new component based on NodeJS.

First, we configure the app to use the OpenTelemetry trace exporter:

const sdk = new NodeSDK({
  resource: new Resource({[SemanticResourceAttributes.SERVICE_NAME]: 'analytics'}),
  traceExporter: new OTLPTraceExporter({
    url: `${collectorUri}/v1/traces`
  })
})

sdk.start()
Enter fullscreen mode Exit fullscreen mode

The next step is to read the metadata, recreate the context from the traceparent, and create a span.

client.on('message', (aTopic, payload, packet) => {
  if (aTopic === topic) {

    console.log('Received new message')

    const data = JSON.parse(payload.toString())

    const userProperties = {}
    if (packet.properties['userProperties']) {                                  //1
      const props = packet.properties['userProperties']
      for (const key of Object.keys(props)) {
        userProperties[key] = props[key]
      }
    }

    const activeContext = propagation.extract(context.active(), userProperties) //2
    const tracer = trace.getTracer('analytics')
    const span = tracer.startSpan(                                              //3
      'Read message',
      {attributes: {path: data['path'], clientIp: data['clientIp']}},
      activeContext,
    )
    span.end()                                                                  //4
  }
})
Enter fullscreen mode Exit fullscreen mode
  1. Read the metadata
  2. Recreate the context from the traceparent
  3. Create the span
  4. End the span

For the record, I tried to migrate to TypeScript, but when I did, I didn't receive the message. Help or hints very welcome!

Apache APISIX for messaging

Though it's not common knowledge, Apache APISIX can proxy HTTP calls as well as UDP and TCP messages. It only offers a few plugins at the moment, but it will add more in the future. An OpenTelemetry one will surely be part of it. In the meantime, let's prepare for it.

The first step is to configure Apache APISIX to allow both HTTP and TCP:

apisix:
  proxy_mode: http&stream                                                       #1
  stream_proxy:
    tcp:
      - addr: 9100                                                              #2
        tls: false
Enter fullscreen mode Exit fullscreen mode
  1. Configure APISIX for both modes
  2. Set the TCP port

The next step is to configure TCP routing:

upstreams:
  - id: 4
    nodes:
      "mosquitto:1883": 1                                                       #1


stream_routes:                                                                  #2
  - id: 1
    upstream_id: 4
    plugins:
      mqtt-proxy:                                                               #3
        protocol_name: MQTT
        protocol_level: 5                                                       #4
Enter fullscreen mode Exit fullscreen mode
  1. Define the MQTT queue as the upstream
  2. Define the "streaming" route. APISIX defines everything that's not HTTP as streaming
  3. Use the MQTT proxy. Note APISIX offers a Kafka-based one
  4. Address the MQTT version. For version above 3, it should be 5

Finally, we can replace the MQTT URLs in the Docker Compose file with APISIX URLs.

Conclusion

I've described several items I added to improve my OpenTelemetry demo in this post. While most are indeed related to OpenTelemetry, some of them aren't. I may add another component in another different stack, a front-end.

The complete source code for this post can be found on GitHub:

GitHub logo nfrankel / opentelemetry-tracing

Demo for end-to-end tracing via OpenTelemetry

Originally published at A Java Geek on January 28th, 2024

Image
Install a NATS server on Debian/Ubuntu

nats, microservices, eventdriven, tutorial
Image
BMI Calculator

mobile, softwaredevelopment
Image
7 Things About Accident Lawyers Baton Rouge You'll Kick Yourself For Not Knowing
Image
SHARD Format – A New Take on Minecraft Region Data

gamedev, algorithms, kotlin, minecraft
Image
¿Cómo funciona Comparator en Java?

java, programming, spanish
Image
Bagaimana Langkah Pasang Taruhan Online Yang Betul
Image
Cisza w Domu: Jak Wyciszyć Mieszkanie i Osiągnąć Spokój
Image
System Design 01 - Data Storage: Pick Your Poison Wisely

systemdesign, database, choice
Image
Who Should Run Tests? On the Future of QA

qa, testing, microservices, devops
Image
Memutuskan Agen Judi Online Yang Memberikan dukungan Dengan Bermacam Type Fitur
Image
sistem negosiasi slots online yang umum dipakai
Image
Deep Exploration of Reinforcement Learning in Fine-Tuning Language Models: RLHF, PPO, and DPO

ai, figma, machinelearning, development
Image
This Week's Top Stories About Baltimore Accident Lawyers
Image
Browse Healthcare.gov Marketplace Plans with a Corticon.js Dynamic Form

corticon, tutorial, showdev, nocode
Image
Jak Wyciszyć Swoje Ściany i Stworzyć Cichą Przystań w Domu
Image
Walking around Promotions: How in order to Make Your Campervan Event Unforgettable!
Image
Lambda function with GraalVM Native Image - Part 4 Measuring cold and warm starts using different Lambda memory settings

java, aws, serverless, graalvm
Image
Cara Pasang Taruhan Judi Online Sangat Gampang
Image
What Injury Lawsuits Experts Want You To Know
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .