Brownfield

Grafana was already approached. A decade ago someone needed to graph something and did so. Since you can put it in front of whatever data store, it shows up in lots of places.

In recent years, Grafana (the firm) has created Grafana Cloud, gobbled up backends like Mimir, Tempo, and Pyroscope. They’re now presenting as a batteries-included observability solution. Let’s dig into that!

Everyone’s newest report is Claude and the dude is a machine.

We really need to get a sense of what this guy is up to. Testing out ideas. Building really low quality designs. Writing the most boring and awful prose.

But the Claude in my IDE is just the one I can see. While I’m busy watching him, there’s another one picking up tickets and opening PRs. One reviewing all the PRs. One fixing the build when it goes red. I thought I hired a coworker. I staffed a whole department — and every one of them is shoving inputs into the same pipeline I’m on the hook for.

How much is it moving the team forward? The Company? And at what cost?

Observing systems has evolved over the years, and Datadog has been there helping it along. The way agents deliver data to predictable and information-rich dashboards is very nice. There is a lot to be said about being predictable and I don’t think anyone would argue about Datadog being predictable on all fronts, except maybe cost.

In this post, I’m going to use the persona frame from the baseline post and walk the same three people through Datadog.

In a similar way to Honeycomb being “a great way to store and retrieve telemetry”, someone noticed that Snowflake was a great way to store and retrieve telemetry. Observe was born out of that concept, has one datastore with everything poured into it and shaped on the way through. No silos is the whole pitch.

In this post I’m using the persona frame from the baseline post and walking the same three people through Observe.

Each observability tool tends to lead users toward a specific workflow. In the same way that working with computers on Windows or MacOS has very different starting points, Logs, Metrics, and Traces each have several entry points.

I want to dig into the benefits and drawbacks of each default workflow.

There have been a lot of changes over my career, and this one is very much the same as the older ones.

Going from local hardware to cloud hardware. Going from single app to distributed app. Going from waterfall to agile work.

AI will only be more disruptive if people can actually take advantage of it.

The single-user mastodon instance that I created a while back has just been doing its thing for a while. I didn’t add a relay so the only stuff I saw was directly followed users. A couple of weeks ago, I added https://bigrelay.social/inbox to feed some of the hashtags I’m following. This caused some emails to show up from Honeycomb about my usage going way up!

Now that I have a century-old house to manage, I’ve found myself struggling to keep on top of all the things that need doing. Not only that, but knowing which need to be done by when, which require tools or parts, and which are on hold can be tricky. To alleviate these problems, I’ve come up with a plan…

When running other people’s software, there are a variety of ways that one can impact the deployment. Developers typically provide a set of configurations that can be set during deployment. Additional configurations are available once it’s running. These are design choices to decide which levers to provide and how flexible to make them. I wanted my instance to do some stuff that the latest release doesn’t do.

You know how every time any startup deployed software for the 2010s, a news article was posted 6-12 months later about how their files were all stored in a completely unprotected S3 bucket? It’s my turn and it’s a speedrun!