<div dir="ltr">I've found histograms to be pretty useful in figuring out patterns during sizable time deltas... and anomaly detection there can highlight stuff you might want to check out ( ie raise the alert condition on that device ).<div><br></div><div>example of a histogram i did many many moons ago to track disk sizes from our nagios plugin that did dynamic disk free analytics.  I don't have any of the animated GIFs I made that showed fluctuations over days... but that was great from a human visual sense.</div><div><br></div><div>I suppose this could be further automated and refined, I've not been focused here anymore though.</div><div><br></div><div>-Matt</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 15, 2015 at 3:08 PM, George Shuklin <span dir="ltr"><<a href="mailto:george.shuklin@gmail.com" target="_blank">george.shuklin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 01/15/2015 06:43 PM, Jesse Keating wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We have a need to better manage the various openstack capacities across our numerous clouds. We want to be able to detect when capacity of one system or another is approaching the point where it would be a good idea to arrange to increase that capacity. Be it volume space, VCPU capability, object storage space, etc...<br>
<br>
What systems are you folks using to monitor and react to such things?<br>
<br>
</blockquote>
<br></span>
In our case we are using standard metrics (ganglia) and monitoring (shinken). I have thoughts about 'capacity planing', but the problem is that you cannot separate payload from wasted resources. For example, when snapshot is created, it eats space on compute (for some configuration) beyond flavor limits. If instance boots, _base is used too (and if instance is booting from big snapshot, it use more space in _base, than in /instances). CPU can be heavily used by many host-internal processes, and memory is shared with management software (which can be greedy too). IO can be overspend on snapshots/booting.<br>
<br>
So we are using cumulative graphs for free space, cpu usage, memory usage. It does not cover flavor/aggregate/pinning-to-<u></u>host-by-metadata cases, but overall give some feeling about available free resources.<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.<u></u>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-operators</a><br>
</div></div></blockquote></div><br></div>