glusterfs inside openshift monitoring about gluster-prometheus HOT 5 CLOSED

Thanks for opening the issue. We are still working on the deployment part and a few other metrics

• Metrics which needs to be collected from the same pod where bricks or gluster process are running.(For example: Process related metrics)
• Metrics which can be collected by running as different pod but should be run on same node where bricks are running(For example: Bricks utilization assuming this separate pod can access the same devices)
• Metrics which can be collected by spawning pod in anywhere in the cluster (Example: Cluster metrics which can be gathered by querying gluster cli or REST apis)

Are there any metrics available to monitor gluster heal status and peer status?

In progress, we will update you once these metrics will be available.

from gluster-prometheus.

Thanks for the update. Cool you have these features in pipe. Let's wait till you have implemented them.

from gluster-prometheus.

@aravindavk Do you see any problems with having a gluster-prometheus container as a part of the gluster pods? This would enable decoupling while also providing the co-location necessary to access the resources for monitoring.

from gluster-prometheus.

@aravindavk Do you see any problems with having a gluster-prometheus container as a part of the gluster pods? This would enable decoupling while also providing the co-location necessary to access the resources for monitoring.

No problems for most of the metrics. But for cluster level metrics, exporting from all nodes/pods results in duplicate data in Prometheus(Unless one exporter in cluster identifies itself as leader and exports cluster data).

We can delegate leader election to kubernetes if we separate the cluster level metrics exporter as separate pod, which can talk to any one glusterd and collect cluster metrics.

from gluster-prometheus.

I'd like to get a solid plan for this (assuming we don't already have it and just need to document it). We need to be opinionated on how this should be configured/deployed w/ GCS.

It sounds like we're going to end up w/ a sidecar for node info and a Deployment/pod for the cluster as a whole. This has implications for the operator, so getting it all written down is important.

(also ref #3)

from gluster-prometheus.