The alerts are a spectacular feature, and usually the first warning I get that something is going on, so I usually set them quite low. Even 2% CPU for me over the course of two hours suggests something is amiss, such as my cache being broken and pages being served dynamically.

Traffic, however, has extremely ungranular control, and entering 0.5 Mbps, for example, will round up to 1Mbps upon reload of the alerts page. 1Mbps is way too high to be of any use to me, as I can actually go over quota on a 360 account sustaining just 650 kbps for the month.

Please consider either letting us specify this in kbps or allowing non-integer entries into incoming and outgoing traffic.

Floating point megabits sounds good to me; I agree with your concern. In fact, 1mbps is also larger than the quote of a 540 account.

Which is why there's the transfer quota percentage alert...

-Chris

I understand, but that lets you know something is going on about 20 days in, rather than 2 hours into a problem. The other alerts are instantaneously meaningful, and I guess that's such a great feature I've already gotten used to it. Two hours of high CPU and you get an alert. Two hours of disk thrashing and you get an alert. My concern isn't actually quota; I just used that as an example. My concern is the mechanism exists now to warn me that something unusual is happening within two hours for IO and CPU, but not traffic.

I think Lucent makes a good point. Having limits that are too loose negate the benefit of the alert. Obviously you don't want them too tight because you will be overwhelmed by alerts. But in many cases when you receive an alert you know exactly why it happened and can ignore it. I see this as a potential application of statistical process control.

You could have the alert manager implement SPC to automatically set alert limits based on a users historical usage as seen by the hourly checks. This can be as simple as computing the mean and standard deviation of the usage over a period of time. The control limit might first be set after X hours of usage and be updated periodically after that. It would be a moving average so that it would move as overall usage trended up or down. For something like the monthly bandwidth, the limits could be left as a handcoded limit.

I think with a little tweaking of parameters like how many standard deviations to use for the control limit and the number of samples in the rolling average/std dev calculation, you could have a fairly reliable well tuned alert system. Of course, you might also allow for users to elect handsetting their limits, overriding the SPC limits. Or have the user select from a few options from loose to tight (for example loose being 4 std deviations and tight being 2.5 standard deviations) to adjust for their tolerance for alerts.

This not only benefits the user in promptly identifying out of the ordinary situations that need attention, it might benefit linode and the fellow users on that system in having unnecessary resource waste addressed promptly (even if that waste does not exceed that users account limits) because it leaves more resources available to the community for burst access for intended (not accidental) resource usage.

Maybe this is overkill, but I thought I'd throw that out there mostly because I think it would be a cool application of SPC...