topic H.A.N.T.Y. - OS Service Monitoring Edition in Open Q&A

H.A.N.T.Y. - OS Service Monitoring Edition

jeffrey_cather — Mon, 06 May 2024 12:10:08 GMT

H.A.N.T.Y. - Has Anyone Noticed This Yet?

This is a discussion of findings while investigating the migration from Classic OS Service Monitoring to the New OS Service Monitoring.

I will go first.

The metric names (Keys in a Key:Value pair) have changed between Classic and New.

Examples:

Classic - builtin:host.osService.availability

New - builtin:osservice.availability

Impact:

All things that are dependent upon specific metrics will have to be adjusted.
This includes, but is not limited to, dashboards & Anomaly Detection Metric Events.

Discussion Points:

1) Are any of you in the process of moving from Classic to New?
2) How are you making the changes that affect dashboards?
a) We have thousands of dashboards and some portion of those will be affected
b) Are you informing your users of the change and how to update or are you doing this programmatically?

Thanks,

Cole Cather

Re: H.A.N.T.Y. - OS Service Monitoring Edition

PierreGutierrez — Fri, 26 Apr 2024 15:56:21 GMT

Hi @jeffrey_cather
Exist several scenarios where Dynatrace updates its metrics (similar to the case you mention), and they are normally notified in Dynatrace release note.
https://docs.dynatrace.com/docs/whats-new

1) Are any of you in the process of moving from Classic to New?
Yes, it happened to us when they updated their metrics for Kubernetes.

2) How are you making the changes that affect dashboards?
a) We have thousands of dashboards and some portion of those will be affected
The way we take

Massively identify all the dashboards that have the old metric implemented (in your example: builtin:host.osService.availability) extracting that information through Dynatrace API, to have the exact amount of impact.
We prioritize those dashboards, those that have the most use.
Plan the date and groups of changes to be made.
Make manual changes.

Another solution that you could try is to make massive changes with Monaco, downloading all the affected Dashboards, applying the change at the code level and uploading the dashboards to dynatrace again.

b) Are you informing your users of the change and how to update or are you doing this programmatically?

In our tests, the metrics did not provide differences or anomalies, which is why we decided not to inform the end user.

I don't see much reason in bothering the end user.

I hope it's helpful 💪

Re: H.A.N.T.Y. - OS Service Monitoring Edition

jeffrey_cather — Thu, 23 May 2024 11:45:43 GMT

I am not sure why this was marked as a solution. It was meant to be a discussion and to bring light to a situation that keeps happening as Dynatrace continues to change the product.

I had wanted to make people aware that with every change there is a possibility that the underlying Metric Names can change and that this can affect what people create as dashboards, queries, Metric Events, etc.

I also want Dynatrace to take ownership of the fact that there is a follow-on effect of those changes and to try to limit the amount of times that they make these changes occur. This might take developing naming conventions that won't require changing the metric names as the product advances.

Please don't stiffle the discussion by marking this as "Solved". It is meant to be a discussion not one just person's viewpoint.

Thanks,

Cole Cather