This is part three in a series where I learn OpenTelemetry (OTEL) from scratch. If you haven't yet seen them yet, part 1 is about setting up auto-instrumented tracing for Node.js and part 2 is where I initially implemented the OTEL collector. Today we are going to begin experimenting with sampling. We need to sample traces because we capture so much data! It would be impractical to process and store it all (in most cases).
In the previous article I covered how to set up auto-instrumented tracing for a Node.js app using OpenTelemetry (OTEL). We then sent the spans directly to the open source tracing tool Jaeger. I recommend you give that a read first before walking through this guide because we're going to re-use the instrumentation we set up last time. Today we're going to take things a step further by introducing the OpenTelemetry Collector.
Recently I caught up with Jamie Allen on Episode 67 of the Slight Reliability podcast to discuss the idea of a single pane of glass (SPOG). Jamie had written an article titled The Single Pain of Glass which coincidentally was what I titled Slight Reliability Episode 10. I thought given our shared use of puns and this topic that it was worth a conversation! So, what is a single pane of glass? Is it an idea with practical application? How does it fit into the world of modern observability?
This month, we were thrilled to welcome SquaredUp customers from all over the world to our in-person workshop in sunny Marlow, UK. It was a wonderful day of learning and sharing ideas, and a unique opportunity for SquaredUp users to meet the people behind the product (us!), network with like-minded customers, and get an exclusive look at the latest product updates. We were excited to showcase our Dashboard Server product roadmap and share our vision for the future of SquaredUp.
The shift from traditional monitoring to observability is widespread, and necessary. It's the way we make sense of increasingly complex and distributed systems. But when we capture all this data at scale... what do we do with it all? If this data itself had inherent value, we’d all be rich. But in the real world data does not provide us value until we can act on what it tells us.
Six months ago I attempted to get OpenTelemetry (OTEL) metrics working in JavaScript, and after a couple of days of getting absolutely no-where, I gave up. But here I am, back for more punishment... but this time I found success! In this article I demonstrate how to instrument a Node.js application for traces using OpenTelemetry and to export the resulting spans to Jaeger. For simplicity, I'm going to export directly to Jaeger (not via the OpenTelemetry Collector).
In the world of performance testing there is a heavy focus on the practice of load testing. This requires building complex automated test suites which simulate load on our services. But load testing is one of the most expensive, complicated, and time consuming activities you can do. It also generates substantial technical debt. Load testing has its time and place, but it's not the only way to measure performance.
How do companies actually use Azure DevOps? What are the use cases? We took a look at how the team at SquaredUp uses Azure DevOps to build their CI/CD pipelines and deploy new features to their SaaS product.
If you take a glance at LinkedIn, Twitter, or any tech-focused social content these days you're bound to see people talking about something called "DORA metrics". So what are DORA metrics? What value do they provide? And how can you get started with them?
DORA metrics, not to be confused with the beloved children’s cartoon character, are a bit trendy at the moment in the world of technology. The DevOps Research and Assessment group (DORA) is run out of Google. They run surveys and do research into what makes organizations successful in the Digital Age. They’re probably most well known for their yearly State of DevOps Reports and the book Accelerate.
