----- Original Message -----
From: "John Sanda" <jsanda(a)redhat.com>
To: rhq-devel(a)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