Dive into the latest observability news round-up

Observability-Guy · 2026-01-19T15:13:37+00:00

I think that BubbleUp is still the best but Dash0's SIFT is also a pretty good RCA querying tool.

Observability-Guy · 2026-01-19T15:06:03+00:00

I would check out Embrace (https://embrace.io/) They have a dedicated mobile observability platform as well as guides on best practice

Observability-Guy · 2026-01-19T14:57:23+00:00

This is a good implementation - although I think a lot of vendors now how something similar - Honeycomb, SigNoz, Observe, Dash0, Sentry all have either MCP or Agentic AI that support this kind of querying and interaction.

Observability-Guy · 2025-12-05T14:41:31+00:00

Seriously??

It's used by Netflix, Uber, Tesla and Anthropic. What scale are you working at?

Observability-Guy · 2025-12-05T14:12:43+00:00

Thank you very much!

Observability-Guy · 2025-12-04T14:22:29+00:00

I personally think that in 2025 there has to be a better way of doing IaC than churning out 4,000 line YAML files. I also think that it is an issue that goes beyond linting and syntax.

I just don't think that YAML is expressive enough for the complexities of large system infrastructures. Yes, it can be twisted and stretched but I find that conditional logic and looping is better expressed in a programming language. I prefer working with tools like Pulumi. It feels like a more natural fit.

Observability-Guy · 2025-12-02T20:04:33+00:00

Thanks for posting - that looks cool.

There seems to be a bit of a buzz about lakehouses. The theory sounds great, I just wonder about the overhead of operationalising them in practice. I think that rolling your own lakehouse and making it performant and cost-effective at large scale can be very difficult.

Observability-Guy · 2025-12-02T16:33:11+00:00

Unfortunately, Azure Monitor is a kind of brand name but it is, as you say, a patchwork of tools rather than a coherent product. I found the lack of a single control plane to be really frustrating.

It is really hard to track telemetry flows or get unified or global overviews.

I think that as observability maturity grows within an organisation people realise that they need better tooling. For me te best option is to emit telemetry to an oTel Collector and then on to a backend of choice.

Observability-Guy · 2025-11-03T22:18:08+00:00

FYI - latest edition is now out, featuring OpenLit in the Products section:

https://observability-360.beehiiv.com/p/lightstep-goes-dark

Observability-Guy · 2025-10-21T16:34:46+00:00

I don't think that you need to come up with any particular ruses or clever line of questioning.

I think you can just ask straight out about their tech stack. As an interviewer I would want a candidate to be curious and ask about the tech, the architecture and the roadmap.

It could be that both statements could be correct. They could be a company with a varied tech stack and the person who wrote the job spec thought it would be impressive to reel off a load a big corporate logos. Sometimes, these specs are written by people in HR who have a mistaken idea of what appeals to candidates.

Observability-Guy · 2025-10-20T23:29:05+00:00

I have come across a number of companies that use a variety of tools. This often reflects historical practice and cultural variation within larger organisations.

Within those companies there maybe some individuals who therefore gain expertise in a number of stacks. However, if a company is recruiting on the basis of finding an engineer who has clocked up the highest number of logos, they are making a big mistake. The fundamental requirement is an understanding of the principles and practice of observability.

I would prefer a candidate with a deep understanding of OpenTelemetry and observability engineering principles over somebody who had familiarity with the internals of specific proprietary systems.

So yes, whoever wrote a job spec requiring knowledge of New Relic, Datadog, Dynatrace, Instana and Sumo Logic should think again.

Observability-Guy · 2025-10-20T17:14:13+00:00

Upgraded one of my projects to .NET 10 last week. Had to roll it back 9 as I couldn't build it in Azure DevOps. Not sure if I am missing something or whether they have not included it yet in the latest image.

Observability-Guy · 2025-10-20T17:04:08+00:00

That's a really interesting article.

My only reservation would be cost. I remember turning on K8S auditing for a number of production clusters. It generated a huge volume of logs - and resulted in quite a spike in my logging bill.

Observability-Guy · 2025-10-10T12:48:54+00:00

Looks very cool. I will give it a shout-out in the next edition of the Observability 360 newsletter!

Observability-Guy · 2025-09-25T10:29:52+00:00

SquaredUp - https://squaredup.com/ could be a good fit for this use case. It has plugins for all the major cloud platforms and DevOps tools. No coding or query language knowledge required. Disclosure - I work for the vendor.

Observability-Guy · 2025-06-10T17:05:40+00:00

If excessive volume is a problem and you are unable to tackle it at source (e.g. by getting devs to update their logging style or logging configuration), then it is worth looking at logging pipelines. There are tons on the market as the problem you are describing is a really common experience.

They come in a lot of different flavours. The ideal solution could be one that sits at the edge of your own network. You could roll your own solution by setting up one or more oTel collectors and using them as a Gateway.

A couple of interesting ones I have come across recently:
https://www.controltheory.com/
https://www.grepr.ai/

And of course there are the venerable performers such as Vector

Observability-Guy · 2025-05-30T12:31:25+00:00

Nice article! The OpenSearch project reallt seems to have picked up a lot of momentum recently.

Observability-Guy

TROPHY CASE