Dynatrace

I love the OpenPipeline implementation that allows us to modify retention on logs, metrics, and traces. I love the power of DQL centralizing all of the data on Dynatrace into a single query language that can be cross-correlated with trace headers and correlation ID's. I love the simplicity of the Dynatrace Operator and how it instruments entire namespaces with code-level visibility just with a couple of helm commands and some simple yaml configuration.

DQL - unifying data with the ability to pull in a large amount of context has been extremely helpful.

- New Rums On The Grails DEM Experience offers several new data points that are valuable to our application teams. - We are starting to map custom user journeys as business flows, which will allow us to leverage the tool(s) to more effectively track impact. - Tracking user frustrations and errors allows us to make improvements and populate app scorecards

BizEvent logs are segregated from the rest of the platform data, meaning we can't easily correlate business events to traces and logs, even if the W3C trace context headers are present in the bizevent table. Dynatrace makes it hard to rollout to a large group or company since I can't easily validate user permissions and scopes by spoofing a specific user to ensure they only have the access they need. Instrumenting .NET 8 Azure Functions with OpenTelemetry running in isolated workloads proved impossible for our company, and we found the documentation lacking in regards to doing so. This was such an issue that we had to pivot entirely to utilizing ASP.NET Core API instead of Azure Functions SDK for our application to be properly monitored by Dynatrace.

There was virtually no guidance on best practices. It felt like when asked about how to best do things, we were either given very specific answers (like which buttons to click to do a thing) or a general you're doing great, whatever way you are doing it is right!. Things like critical features like segregating data via buckets to ensure faster query response time with reduced cost was never highlighted until we explicitly asked about it. This was AFTER asking for best practices guidance.

- Better reporting in the platform around issues within it (when session replay breaks, what is the impact and cause) - There are so many tables to pull from when using DQL that it makes it difficult to tie data together and provide a holistic view - Being able to automate the creation of user journeys native in the platform would make the process much easier (not having to use the MCP)