I recently shared a train journey with a gentleman who demonstrated the importance of an automated monitoring tool, by missing breakfast. No, really...
So, you’ve gone “cloud native” … you’re running apps in containers, you’re scheduling them with Kubernetes, and now you’re trying to figure out what the heck is going on. It’s the third time in a month where your customers are seeing two minutes of error pages — and then it’s just fixed. That’s plenty long enough for them to complain on Twitter, and besides that, it’s just embarrassing.
This post is Part 1 of a 2-part series about Monitoring Ephemeral Infrastructure. Part 2 will detail how Circonus uses these features to monitor our API services backed by ephemeral GCP infrastructure.
I started using the Open Source (OSS) version of InfluxDB v2.0 very early on in the Alpha releases. Even in the early releases, I was very enamored with the way things were shaping up. But as you know, I do a lot of IoT builds, and use InfluxDB for all of it, so there were a few things I needed it to do that it just didn’t, yet. One of the things I have all my IoT Demos do is to write out alerts to an MQTT broker.
There is no doubt that distributed tracing is critical for microservices observability. Supporting that claim is monitoring guru, Cindy Sridharan, who recently wrote that “there is no other observability signal that is pregnant with data more rich, causal and contextual than that carried by a trace”. But often practitioners end up with hundreds of thousands of traces and most of them are for normal behavior scenario and hence aren’t interesting.