cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Introducing built-in Persistent Volume Claim Monitoring for Kubernetes

Alisopp
Dynatrace Guide
Dynatrace Guide

We are happy to announce, that PVC (Persistent Volume Claim) monitoring is becoming a built-in feature of our product. Previously, PVC monitoring was based on custom metric, and hence subject to additional licensing. With this change, PVC monitoring becomes part of your existing license, meaning there won't be any additional charges for using it. Going forward, we will also enable this feature for everyone per default.

I'm already using PVC monitoring today. Is there anything I need to do?

The integrated PVC monitoring will replace the current set of custom metrics with new built-in metrics. The assets provided by Dynatrace for PVC monitoring will be automatically updated by us. Specifically, the built-in anomaly detection for PVCs will automatically utilize the new metrics with version 1.294. For the PVC dashboard, we will deprecate the existing extensions, and ship an updated dashboard, based on the new metrics, as a built-in dashboard of Dynatrace.

If you are using today`s PVC metrics in any custom dashboard, metric event, or SLO, you need to manually migrate these assets by following the guide below.

Prerequisites

Which metrics are affected

The affected metrics are the ones that are written upon enabling the PVC toggle in the monitoring settings of a Kubernetes cluster. Following table shows which metrics are affected and by which metric they are replaced:

 

Deprecated metric key

(Decommission: Dynatrace 1.296)

1. Dynatrace Classic - New metric key

(Kubernetes classic, Dashboards Classic, Data explorer, Metrics, ...)

2. Dynatrace Platform/Grail - New metric key*

(Kubernetes, Dashboards, Notebooks, ...)

New metric name

kubelet_volume_stats_available_bytes

  1. builtin:kubernetes.persistentvolumeclaim.available
  2. dt.kubernetes.persistentvolumeclaim.available

Kubernetes: Volume available bytes

kubelet_volume_stats_capacity_bytes

  1. builtin:kubernetes.persistentvolumeclaim.capacity
  2. dt.kubernetes.persistentvolumeclaim.capacity

Kubernetes: Volume capacity

kubelet_volume_stats_used_bytes

  1. builtin:kubernetes.persistentvolumeclaim.used
  2. dt.kubernetes.persistentvolumeclaim.used

Kubernetes: Volume used bytes

 

Alisopp_0-1714985061585.png

 

* Using the new PVC metrics in the platform requires the new Kubernetes experience.

How to get the new metrics

The new metrics will be written with updating your ActiveGates to version 1.289+. They are written per default, and are independent of the PVC toggle. The PVC toggle only switches writing of the deprecated PVC metrics.

How to successfully migrate to the new metrics

As there is no straight forward migration from an old metric to a new metric, we can't automatically migrate your custom dashboards, custom events for alerting, SLOs, or any other tool that utilizes our API to access these metrics.

To minimize the effort on your side, we offer a web application, called Metric Audit Report, guiding you through this process. So please make sure to update your ActiveGates to 1.289+, when this version becomes available for you and migrate your assets until Dynatrace 1.296 is released.

 

Alisopp_1-1714985061733.png

 

Deprecation: What happens to the old metrics?

They will still be written if the PVC toggle is enabled until Dynatrace 1.296. With Dynatrace 1.296 their decommission is planned. The PVC toggle will be no longer available.

Alisopp_2-1714985061566.png

 

For troubleshooting steps, see the article: Troubleshooting PVC not showing data.

3 REPLIES 3

sivart_89
Advisor

Will the method in which the metrics are being captured, remain the same? In other words, I believe the below is how dynatrace get some of the metrics, will the same endpoint be used?

If there are different endpoints that will be used can you provide one of them please? We have some clusters that are not exposing the pvc metrics in their current state of k8 version, I'm wondering if I will be able to start seeing them come 1.294 cluster version & 1.289 AG

/api/v1/nodes/{k8-node-name}/proxy/metrics

sivart_89_0-1717179239994.png

How we collect the data from Kubernetes remains the same, yes we are still using the node metrics endpoint for pvc.

With not exposing, you mean that the Kubernetes clusters do not provide any kubelet_volume_stats_ (e.g. kubelet_volume_stats_used_bytes) ,metric on these endpoints? Otherwise, please follow this Troubleshooting guide for PVC.

 

Also, the new metrics are already available with cluster version 1.290 and AG 1.289. In cluster version 1.294 we adapt our builtin features to use the new metrics instead of the old ones.

That is correct, the diamanti clusters we have are on an older version of diamanti which puts us on k8 version 1.21. Not entirely sure if it is the k8 version itself being and older version that doesn't expose the metrics or if its entirely due to the diamanti version we are using.

Being the method in collecting the metrics is the same, we won't be able to get these in even in the new way. Nothing at fault from dynatrace, entirely on us as we just haven't moved very quickly with the k8 updates here 😀

Featured Posts