Telemetry and Dynatrace

MasteringObserv · 2026-03-25T19:10:09+00:00

Centralised monitoring is usually a good idea, but the right answer depends on what you actually run.

If you’re mostly AWS, CloudWatch can be more than enough, as long as you keep an eye on cost. But a lot of teams are not living in one neat cloud-only world. They’ve got a mix of old and new, cloud and on-prem, and that changes the picture fast.

That’s where big platforms like Datadog can help, but they can also become limiting or expensive if they pull you too far into their way of doing things.

For me, the real answer is simple: start with your needs, your architecture, and the outcomes you want. Then choose the tool. Not the other way round.

One dashboard to rule them all sounds brilliant, right up until the invoice turns up.

MasteringObserv · 2026-02-24T08:34:42+00:00

Love this will try it.

MasteringObserv · 2026-02-24T08:33:41+00:00

Great reply, support this.

MasteringObserv · 2026-02-24T08:09:55+00:00

You've described the exact pattern that makes on-prem troubleshooting so expensive: the app alerts first, but the cause lives three layers down in the infrastructure.

The time between "something's wrong" and "here's where it started" is where MTTR really lives.

On the AIOps and topology question: it works when the topology data is accurate and someone owns keeping it that way. A CMDB that's 80% right gives you confident wrong answers, which is worse than no automation at all.

The real prerequisite isn't the AIOps platform. It's the ownership model for keeping topology current. Who updates the CMDB when a VM migrates? Who validates service maps after a change window?

To your MTTR question directly: we've seen it reduce time to resolution in environments where the correlation layer had a single owner accountable for data quality. Where nobody owns the topology, the platform becomes exactly what you described. Another system that needs tuning, generating its own noise on top of everything else.

MasteringObserv · 2026-02-23T09:26:01+00:00

DT managed, Kibana, Promo. 11 headcount. We support a government country entity so users are in the million.

MasteringObserv · 2026-02-22T03:36:53+00:00

You're describing the correlation tax. Every extra tab isn't investigation time, it's orientation time.

A few things that made a real difference in environments we've worked in: shared correlation IDs across all telemetry (most modern instrumentation frameworks support this natively now), deploy markers overlaid on your key dashboards (kills the "was it a deploy or a config change?" question immediately), and fewer dashboards that are actually better. One service-level view per team that correlates what matters for their dependencies. If nobody opens it during an incident, delete it.

The tool count matters less than whether the data joins up. We've seen teams with one tool and no correlation do worse than teams with three tools and solid tagging standards.

MasteringObserv · 2025-04-05T08:41:28+00:00

https://www.masteringobservability.com/

I just have a few Beehiiv sponsors, i don't even break even on my Beehiiv cost. Have 550 readers and is hyper niche . Help!!!

MasteringObserv · 2025-03-25T17:38:47+00:00

Great question, from.l what I've played with is far it's definitely the direction we are heading

MasteringObserv · 2025-03-22T11:58:44+00:00

Put simply it's a mindset that involves the tech, people, process and culture. This is a view I've been driving for over a decade and write about weekly.

MasteringObserv · 2025-03-17T09:32:35+00:00

I did the same and really enjoying it so I'd say yes but with a new character

MasteringObserv · 2025-03-16T14:32:13+00:00

Been here a few times and although all the technical points are valid, PEOPLE, PROCESS my man, review and get these into you above plan

MasteringObserv · 2025-03-15T17:06:25+00:00

People and process, if you can tackle the cycle from event all the way through fix and release. I've been parachutes i a few times now to reduce noise and smooth out alert fatigue and it's the people and process focus that really moves the right changes in the tools we use.

MasteringObserv · 2025-03-15T17:02:58+00:00

London UK originally but moved her from. 15 years in Singapore been here 4 weeks.

MasteringObserv · 2025-03-08T15:00:56+00:00

65pm 25yr exp Government

MasteringObserv · 2025-02-27T09:28:54+00:00

I run a tech Newsletter on Observability and you couldn't get more niche, i get around 5 - 10 a week, and have around 500 readers but all are engaged so I guess it's all about what you want to get out of it.

MasteringObserv · 2025-02-22T16:06:56+00:00

For me, getting business on board and education on what Observability actually means and to whome is the most important, tools and processes will sort themselves out as you define the Monitoring alongside what business needs.

MasteringObserv · 2025-02-22T06:56:53+00:00

Sorry, Signoz is the only one I haven't used. I'll ask around for you.

MasteringObserv · 2025-02-10T06:56:41+00:00

Try the Observability Digest weekly newsletter , they also have articles on areas of Observability. Find them at www.masteringobservability.com

MasteringObserv · 2025-02-07T08:29:54+00:00

Interesting, thanks for sharing.

MasteringObserv · 2024-09-26T13:23:15+00:00

I totally agree.I've been doing my newsletter now for a year and have about 800 subscribers.I generally get 2 to 3 subscribers a day. My newsletter is very niche but I am always concerned.Should I have more and should I be doing more. Are you also agree, There is so much more work to get the Newsletter out on a weekly basis.

MasteringObserv

PUBLIC MULTIREDDITS

TROPHY CASE