Description of problem: We would like to collect gluster related metrics from each node to help diagnose issues/performance better Some metrics that are likely to be interesting - Brick -- capacity utilization -- IO stats -- entries to be healed -- number of connections - Gluster process - CPU utilization - Number of bricks and status - Status of gluster processes Version-Release number of selected component (if applicable): How reproducible: NA
Sean, could you add to this?
Are all these metrics collected by the Tendrl plugin
- Brick -- capacity utilization -- Yes available in tendrl collectd plugin -- IO stats -- Yes available in tendrl collectd plugin -- entries to be healed -- Yes available in tendrl collectd plugin -- number of connections -- Yes available in tendrl collectd plugin - Gluster process - CPU utilization No process wise cpu consumption monitored currently. We have net cpu utilization consumed by various categories like system processes, user processes etc... - Number of bricks and status -- Yes available in tendrl collectd plugin - Status of gluster processes -- Not available currently Additionally the detailed list of metrics that tendrl currently has can be found at: https://github.com/Tendrl/documentation/wiki/Metrics
IIUC the link specifies the collectd plugins that will also report gluster stats. I did not see a "tendrl collectd plugin" that requires installation and configuration on collectd side. Is that correct?
Configuration tool(Copied to /usr/bin/ and used like a linux command): https://github.com/Tendrl/node-agent/blob/master/tendrl/node_agent/monitoring/collectd/commands/tendrl_monitoring_config_manager.py Configuration templates: https://github.com/Tendrl/node-agent/tree/master/tendrl/node_agent/monitoring/collectd/templates/gluster Plugins: https://github.com/Tendrl/node-agent/tree/master/tendrl/node_agent/monitoring/collectd/collectors/gluster Please let me know if you need more info..
we decided to make separate repository for gluster-collectd plugin. we rasied bz to create repository under gluster.org. The upstream version of collectd is based on C language and we have gluster plugin based on python. to maintain the plugin in better way we decided to have seperate repository and package it. once the repository is created, we will ship the rpms to fedora and centos and will have ansible playbook to install it.
(In reply to Venkata R Edara from comment #9) > we decided to make separate repository for gluster-collectd plugin. we > rasied bz to create repository under gluster.org. The upstream version of > collectd is based on C language and we have gluster plugin based on python. > to maintain the plugin in better way we decided to have seperate repository > and package it. > > once the repository is created, we will ship the rpms to fedora and centos > and will have ansible playbook to install it. I don't think it should be in a different ansible playbook. If its available in u/s and d/s we can add it to the ovirt-engine-metrics repo.
(In reply to Shirly Radco from comment #10) > (In reply to Venkata R Edara from comment #9) > > we decided to make separate repository for gluster-collectd plugin. we > > rasied bz to create repository under gluster.org. The upstream version of > > collectd is based on C language and we have gluster plugin based on python. > > to maintain the plugin in better way we decided to have seperate repository > > and package it. > > > > once the repository is created, we will ship the rpms to fedora and centos > > and will have ansible playbook to install it. > > I don't think it should be in a different ansible playbook. > If its available in u/s and d/s we can add it to the ovirt-engine-metrics > repo. Sure. the playbook wont be in different repo. we can add it to ovirt-engine-metrics repo. we will notify once the playbook is ready.
Hi, Any updates?
The playbooks are ready. we are shipping 2 packages. gluster-collectd plugin which is to be installed on ovirt nodes where gluster is installed. one more package is choose-master which uses ovirt sdk api to choose ovirt nodes which are up and chooses one node to get volume metrics. on ovirt engine, install this rpm https://copr-be.cloud.fedoraproject.org/results/redara/gluster-collectd/fedora-27-x86_64/00798077-choose-master/choose-master-1.0.0-1.fc27.noarch.rpm on ovirt nodes install rpm https://copr-be.cloud.fedoraproject.org/results/redara/gluster-collectd/fedora-27-x86_64/00795761-gluster-collectd/gluster-collectd-1.0.0-1.fc27.noarch.rpm playbook: https://github.com/gluster/gluster-collectd/pull/2 we will add more documentation on how to use playbook.
This bug has not been marked as blocker for oVirt 4.3.0. Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.
Unlikely that this is going to be integrated. Deferring this