Operations | Monitoring | ITSM | DevOps | Cloud

In our Configuring OpenTelemetry in Ruby blog post, we showed how to configure OpenTelemetry in a Ruby on Rails backend. In this post, we’ll cover how to configure OpenTelemetry in the front-end JavaScript in order to measure performance of browser and mobile devices and how to configure distributed tracing to work across the frontend and back end telemetry collection. Let’s dive in!

Ah, I too have wondered about this. TL;DR: The Resource says what program is sending these spans and where it’s running. You can skip it if you define OTEL_SERVICE_NAME in the environment. When I’m setting up tracing (for instance, in a Node.js app), I have to create a Resource object in order to set up the OpenTelemetry SDK: If I don’t define that resource parameter, then tracing will still work. But my spans will show up with aservice.name of unknown_service:node.

The promise of OpenTelemetry is that it can help you avoid vendor lock-in by allowing you to instrument your applications once, then send that data to any backend of your choice. This post shows you exactly how to do that with code samples that configure your application to send telemetry data to both Honeycomb and New Relic.

Written by @thetomzach @ Aspecto. In this guide, you’ll learn what Jaeger tracing is, what distributed tracing is, and how to set it up in your system. We’ll go over Jaeger’s UI and touch on advanced concepts such as sampling and deploying in production. You’ll leave this guide knowing how to create spans with OpenTelemetry and send them to Jaeger tracing for visualization. All that, from scratch.

Ah, good question! TL;DR: store the start time of the span, and then create the span on the new page. Usually, you want to start a span, do some work, and then end the span. The whole span gets sent to your OpenTelemetry collector (and thence to Honeycomb) when you end it. But when a page load happens, that span object is lost. Honeycomb never hears about it becausespan.end()wasn’t called. How can we deal with this? Create the span only on the new page, where you can end it. But!

We’ve talked in previous posts about why we think the concept of exemplars are so valuable: They make it easy to jump from metrics into exactly the right traces, eliminating the needle in the haystack problem. We were enthusiastic enough about the idea that we helped contribute the necessary code changes to bring this functionality to the Prometheus ecosystem.

In this article, we will implement distributed tracing for a nodejs application based on microservices architecture. To implement distributed tracing, we will be using open-source solutions - SigNoz and OpenTelemetry, so you can easily follow the tutorial. In modern microservices-based applications, it is difficult to understand how requests are performing across multiple services, infrastructure, and protocols.

“What is up with the Context in OpenTelemetry? Why do I need to mess with it at all? Why, when I set a span as active, don’t subsequent spans just use it as a parent?” Oh, yikes, yeah. The Context abstraction in OpenTelemetry is hard to understand. Here are several ways it’s tricky.

In this modern era, most companies want to make customers happy using emerging technologies. This is why they utilize multiple types of tools and new technologies to attract customers in their funnel and finally convert them into leads. However, it has some demerits too.