Storage Node - Disk Space Metric

Stefan Negrea snegrea at redhat.com
Mon Jul 15 21:03:26 UTC 2013



----- Original Message -----
> From: "John Sanda" <jsanda at redhat.com>
> To: rhq-devel at lists.fedorahosted.org
> Sent: Monday, July 15, 2013 11:43:32 AM
> Subject: Re: Storage Node - Disk Space Metric
> 
> >> 
> >> 1) Should we include both metrics? Overall disk space use & data files
> >> disk space used? We could only hope that having the two metrics will make
> >> it easier for users to understand what they are.
> > 
> > I think two metrics is a good idea.  We must have a way to easily alert on
> > a disk space consumption.  The Iteration-3
> > Calculated.PartitionDiskSpaceUsedPercentage metric is useful information:
> > How much of my used disk space is due to my storage node?   But it's
> > mainly useful to help understand if a disk space issue is or is not due to
> > the storage node.  We need the Iteration-3
> > Calculated.PartitionDiskSpaceUsedPercentage metric for alerting on
> > excessive disk space for the storage node partitions. Of course we'd need
> > two names that describe the distinction.  I think both metrics should be
> > on the same resource as they are related.
> 
> 
> I agree that we need two metrics. I do not think that they should be on the
> same resource though because they are not necessarily related. It may not be
> the storage node that is eating up space on the file system. The
> Calculated.PartitionDiskSpaceUsedPercentage metric should go on the File
> System resource type.


I am not sure we can put any of these metrics outside of Storage Node resources because they depend on the data files locations. A *nix installation might have multiple mount points; but we would be interested in alerting only for the mount points that have data files. To create an alert we need to know the mount points for all data files, which is an RHQ Storage Node property only. Data file locations can change over time and we would need to be able to adjust this metric and alert on fly as the RHQ Storage Node configuration evolves. 

Adding alerts to all the partitions is not a good idea either because a mount point like /boot could have a high usage percentage but never contain Cassandra data files. Also, we will not be able to capture alerts in the way we do it today (all alerts from the all the sub-resources of RHQ Storage Nodes).


John, any thoughts on how to address these issues?


Thank you,
Stefan Negrea





More information about the rhq-devel mailing list