gluster_exporter or gluster-prometheus?

[ghost]

is this project replacing https://github.com/ofesseler/gluster_exporter or any relationship? This looks pretty much not maintained however in Prometheus third party integration is the one mentioned: https://prometheus.io/docs/instrumenting/exporters/

I have tested that exporter it seems collecting some metrics that here are not available?

thanks

[amarts]

@labazza thanks for reporting this. We will work with both @ofesseler and prometheus.io to get this fixed!

Also note that, this project has started integrating with https://github.com/gluster/gcs to provide a usable containers with gluster to show how one can consume this! (ref: #45)

Will keep you posted you on this!

[labazza]

@amarts thanks for the reply, i will test this exporter as well it's great to see monitoring around gluster is movig forward. ATM i use glusterd and not glusterd2 and it's deployed on baremetal.

[aravindavk]

@amarts thanks for the reply, i will test this exporter as well it's great to see monitoring around gluster is movig forward. ATM i use glusterd and not glusterd2 and it's deployed on baremetal.

This project is compatible with both glusterd and glusterd2. Please refer README for install and usage details.

[labazza]

Hi @amarts and @aravindavk . I have tested the other project gluster-exporter since a first effort on Grafana + Prometheus alerting was put there. Also we deploy the exporter as rpm so i was following the development of issue #18 . I noticed you started a joint effort under this project : https://github.com/ofesseler/gluster_exporter/issues/40 therefore i will report here the anomalies i have found:

• the extractor requires glusterd to be running
• because of point 1 we cannot have "volume_mounted" "volume_writable" from the clients
• if the extractor is running with default -volumes '_all' the following error: WARN[0010] no Volumes were given. source="main.go:322"
• some metrics listed as implemented in the readme.md are not present either specifying a single volume or using _all: OpErrno, opRet, node_inodes_free , node_inodes_total, volumes_available, brick_available, brick_duration_seconds_total, brick_data_read_bytes_total, brick_data_written_bytes_total, brick_fop_hits_total, brick_fop_latency_avg, brick_fop_latency_min, brick_fop_latency_max
• this metric is listed as pending peerStatus.peer.state

In bold what i think is more important. ATM My knowledge of GO still fairly limited so my apologies for the lack of contribution. I will proceed deploying this extractor and test if the above metrics are already present.

[labazza]

i'm now running gluster-prometheus and will replace the old one. I'm happy to close this issue if you agree to track the following under this project would be great:

• have this project advertised under the prometheus documentation: https://prometheus.io/docs/instrumenting/exporters/
• exporter release versioning and distribution of either tgz or rpm
• client mount side checks as per "volume_mounted" "volume_writable" by running the exporter on the gluster fuse mounts
• volume heal stats thanks!

[amarts]

@labazza this is very valuable update! Yes, sure we will make sure to take care of the above items! Lets keep this issue open for some time till we have the above addressed. (Or at least issues open for individual issues from your list.

• [ ] - have this project advertised under the prometheus documentation: https://prometheus.io/docs/instrumenting/exporters/
• [ ] - exporter release versioning and distribution of either tgz or rpm
• [ ] - client mount side checks as per "volume_mounted" "volume_writable" by running the exporter on the gluster fuse mounts
• [ ] - volume heal stats

[adampl]

Hi all, what's the current status of this issue?

[brian-brazil]

Hi, please see the discussion on https://github.com/prometheus/docs/pull/1315 in relation to listing this on the Prometheus documentation. Basically this exporter should fetch metrics synchronously on scrape, not maintain its own internal scraping intervals with TTLs. See https://prometheus.io/docs/instrumenting/writing_exporters/#scheduling, this would both be more in line with Prometheus best practices and make the code simpler too.