cc @kubernetes/sig-instrumentation-feature-requests @kubernetes/sig-storage-feature-requests
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
@brancz commented on this pull request.
In contributors/design-proposals/storage-metrics.md:
> + +// PVReference contains enough information to locate the referenced PV. +type PodReference struct { + Name string `json:"name"` + UID string `json:"uid"` +} + +``` +### Register the VolumeStats metrics to Prometheus + +The following metrics could be registered to Prometheus + + +| Metric name | Metric type | Labels/tags | +|-------------|-------------|-------------| +| volume_stats_capacityBytes | Gauge | namespace=\<persistentvolumeclaim-namespace\> <br/> persistentvolumeclaim=\<persistentvolumeclaim-name\> <br/> persistentvolume=\<persistentvolume-name\> |
mixed snake and camel case
In contributors/design-proposals/storage-metrics.md:
> +``` +// VolumeStats contains data about Volume filesystem usage. +type VolumeStats struct { + // Reference to the measured PVC. + PVCRef PVCReference `json:"podRef"` + // Reference to the measured PV. + PVRef PVReference `json:"podRef"` + // Embedded FsStats + FsStats + // Name is the name given to the Volume + // +optional + Name string `json:"name,omitempty"` +} + +// PVCReference contains enough information to locate the referenced PVC. +type PodReference struct {
Comment says PVCReference, struct name is PodReference
In contributors/design-proposals/storage-metrics.md:
> + // Embedded FsStats + FsStats + // Name is the name given to the Volume + // +optional + Name string `json:"name,omitempty"` +} + +// PVCReference contains enough information to locate the referenced PVC. +type PodReference struct { + Name string `json:"name"` + Namespace string `json:"namespace"` + UID string `json:"uid"` +} + +// PVReference contains enough information to locate the referenced PV. +type PodReference struct {
comment says PVReference, struct name is PodReference
@jingxu97 pushed 1 commit.
—
You are receiving this because you are subscribed to this thread.
View it on GitHub or mute the thread.
@zhangxiaoyu-zidif commented on this pull request.
In contributors/design-proposals/storage-metrics.md:
> + - In 1.7, an alpha feature is added to isolation emptyDir volume usage and container’s overlay in local storage. User can set a sizeLimit for Pod EmptyDir Volume and eviction manager will take action if the emptyDir volume usage exceeds the configured size. Similarly, user can set request/limit on container’s overlay and eviction manager can take actions based on the monitoring data and the limits. + - There is also a proposal targeting for 1.8 [volume resize proposal](https://github.com/kubernetes/community/pull/657) to dynamically resize the volume (network attached) if the disk resource is insufficient. It requires a monitoring pipeline to dynamically check the the disk usage for each volume (represented by PVC) + +### Current Monitoring Options + +There are a number of monitoring options supported by Kubernetes + - Resource Metrics API (Alpha feature in progress [Resource Metrics API](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-metrics-api.md) + - Collect metrics in Heapster. (metrics has to exposed by Kubelet in Summary API) + - Export metrics through StackDriver + - Kubectl Command (kubectl top, kubectl describe) + +All the storage metrics mentioned in Background are collected by Kubelet Summary API so that it could be integrated with the above monitoring system. However, pod volume metrics is provided in PodStat object’s VolumeStat and VolumeStat only has volume name specified in pod specification. There is no direct way of checking volume usage information by PVC name, which is more preferable by users. + + +## Goals +The gola of this proposal is to expose storage usage metrics to users for monitoring their storage systems.
Is this feature on pod-level ?
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
@jingxu97 commented on this pull request.
I think the metric is per volume. Could you explain what you mean by "pod-level"?
Is this ready for review? I still can see [WIP]
tag in the first line of the doc.
@surajssd commented on this pull request.
In contributors/design-proposals/storage-metrics.md:
> + - In 1.7, an alpha feature is added to isolation emptyDir volume usage and container’s overlay in local storage. User can set a sizeLimit for Pod EmptyDir Volume and eviction manager will take action if the emptyDir volume usage exceeds the configured size. Similarly, user can set request/limit on container’s overlay and eviction manager can take actions based on the monitoring data and the limits. + - There is also a proposal targeting for 1.8 [volume resize proposal](https://github.com/kubernetes/community/pull/657) to dynamically resize the volume (network attached) if the disk resource is insufficient. It requires a monitoring pipeline to dynamically check the the disk usage for each volume (represented by PVC) + +### Current Monitoring Options + +There are a number of monitoring options supported by Kubernetes + - Resource Metrics API (Alpha feature in progress [Resource Metrics API](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-metrics-api.md) + - Collect metrics in Heapster. (metrics has to exposed by Kubelet in Summary API) + - Export metrics through StackDriver + - Kubectl Command (kubectl top, kubectl describe) + +All the storage metrics mentioned in Background are collected by Kubelet Summary API so that it could be integrated with the above monitoring system. However, pod volume metrics is provided in PodStat object’s VolumeStat and VolumeStat only has volume name specified in pod specification. There is no direct way of checking volume usage information by PVC name, which is more preferable by users. + + +## Goals +The gola of this proposal is to expose storage usage metrics to users for monitoring their storage systems.
spell: s/gola/goal/
@derekwaynecarr commented on this pull request.
In contributors/design-proposals/storage-metrics.md:
> + - Kubectl Command (kubectl top, kubectl describe) + +All the storage metrics mentioned in Background are collected by Kubelet Summary API so that it could be integrated with the above monitoring system. However, pod volume metrics is provided in PodStat object’s VolumeStat and VolumeStat only has volume name specified in pod specification. There is no direct way of checking volume usage information by PVC name, which is more preferable by users. + + +## Goals +The gola of this proposal is to expose storage usage metrics to users for monitoring their storage systems. + +## Proposal + +This proposal has three parts, the first part is trying to address the issue of adding volume usage information indexed by PVC and PV name in Kubelet Summary API. The second part is to register the volume metrics to . The third part is to add more storage metrics to Heapster. + + +### volume usage information indexed by PVC/PV in Kubelet Summary API + +The basic idea is to cache PVC and the volume information in kubelet volume manager which is similar to caching the pod and volume information. In Summary API, In Summary API, we could add PVC and PV references into VolumeStats which is included in PodStats.
nit: double "In Summary API"
@jingxu97 pushed 1 commit.
—
You are receiving this because you are subscribed to this thread.
View it on GitHub or mute the thread.
@kmova commented on this pull request.
In contributors/design-proposals/storage-metrics.md:
> + - Kubectl Command (kubectl top, kubectl describe) + +All the storage metrics mentioned in Background are collected by Kubelet Summary API so that it could be integrated with the above monitoring system. However, pod volume metrics is provided in PodStat object’s VolumeStat and VolumeStat only has volume name specified in pod specification. There is no direct way of checking volume usage information by PVC name, which is more preferable by users. + + +## Goals +The gola of this proposal is to expose storage usage metrics to users for monitoring their storage systems. + +## Proposal + +This proposal has three parts, the first part is trying to address the issue of adding volume usage information indexed by PVC and PV name in Kubelet Summary API. The second part is to register the volume metrics to . The third part is to add more storage metrics to Heapster. + + +### volume usage information indexed by PVC/PV in Kubelet Summary API + +The basic idea is to cache PVC and the volume information in kubelet volume manager which is similar to caching the pod and volume information. In Summary API, In Summary API, we could add PVC and PV references into VolumeStats which is included in PodStats.
nit: incomplete sentence? "The second part is to register the volume metrics to ."
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
This PR hasn't been active in 61 days. It will be closed in 28 days (Dec 16, 2017).
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten
.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen
.
Mark the issue as fresh with /remove-lifecycle rotten
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close
Closed #855.
Status?
Was it done?
👍 I'd like to view how much of a persistent volume is in use and don't know of a way.
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.