Prometheus compatible metrics

[jcpunk]

It would be nice if the pod had a prometheus compatible metrics endpoint (with optional ServiceMonitor from helm).

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[jcpunk]

I'm still interested in this

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[jcpunk]

/remove-lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[jcpunk]

/remove-lifecycle stale

[Starttoaster]

This could be cool, but what metrics would you like to see exported?

[jcpunk]

Perhaps the volumes under management by this tool and any free space per source? Plus the standard CPU/RAM?

[Starttoaster]

Perhaps the volumes under management by this tool and any free space per source? Plus the standard CPU/RAM?

🤔
This provisioner doesn't currently know or even respect the free space available on the NFS server, so I'm not sure how that would be accomplished.

CPU/RAM sounds more like node_exporter's job than a metrics exporter built into this, to be honest.

Care to give more thoughts for either of those ideas? I'm not a maintainer here to be clear, but I own/maintain a fork of this repository. And was intrigued by the idea of adding metrics to it. I'm just not sure what metrics would really be appropriate for it. For what it's worth, I believe used space in a persistent volume is handled by kubelet's builtin metrics exporter (which is built into kubernetes installations.) And for CPU/RAM metrics of the NFS server, I think you would probably be better suited installing node_exporter on your NFS server. For CPU/RAM metrics of this provisioner, you're actually looking at using CAdvisor's metrics exporter (also built into kubernetes.)

[jcpunk]

I was thinking CPU/RAM usage of the nfs-subdir-external-provisioner process itself.

Maybe how many volumes were created by the provisioner?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[Starttoaster]

I was thinking CPU/RAM usage of the nfs-subdir-external-provisioner process itself.

This is probably better off being a metric from CAdvisor or kube-state-metrics.

Maybe how many volumes were created by the provisioner?

This metric wouldn't really be valuable to me, personally. It doesn't really tell me anything important about the state of my NFS server. Because number of volumes does not give a sense for disk usage of the NFS server. And for that metric even, I'd probably rather install node_exporter on the NFS server.

Do you actually have an intended use for these metrics already? This strikes me as potentially a nice thing to think about with no identified use case so far though.

[jcpunk]

I don't have a great handle on what would be useful. I mostly just like observational metrics.