Last week, we were very excited to host our first ever SquaredUp Virtual Customer Workshop! We’d received so much positive feedback on the intimate in-person workshop we ran in the UK last month that we wanted to extend the invitation worldwide – by recreating the experience virtually. Using the digital conferencing app Gather Town, we were pleased to welcome 23 SquaredUp customers from 12 countries to our virtual “SquaredUp Town”.
Big news! Microsoft have just dropped Azure Monitor SCOM Managed Instance (SCOM MI), their cloud-based alternative to SCOM. It’s fully Microsoft managed, and so it promises to take the headache out of deploying, scaling, and managing your SCOM Management Groups. Read Microsoft’s announcement blog to learn all about it.
You'll often hear us saying "everyone loves a dashboard", and that's most certainly true, but nobody loves staring at a screen all day waiting for something to happen. Real magic is when your awesome dashboard comes to you, where you need it, when you need it. Over the last few months we've introduced a bunch of powerful features to make "taking action" as simple as possible... Monitors let you define the health of your data so you can see at a glance if something isn't right.
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.
