New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
You can't have a quality VPS if you've got someone hammering the disk.
So back to the topic before it gets derailed completely
do a cron iostat and then send to yourself via email?
Apparently you can do this with Munin
More than once I've heard people complain about Munin causing abnormally high disk I/O - so I'm not sure whether that is the best option here :P
@joepie91: Munin nodes don't use a lot of resources, but the graphing system itself does... hence our Munin installation runs on a 'utility' server
Munin is a major resource hog for the few seconds it is running (and if multiple VPSs on the same node keep the default cron setup it will look something like this).
As for the argument of how this was handled, there is a very simple solution that other providers might want to take note of when handling resource abuse... DO NOT SUSPEND! Simple as that. When we find a resource abuser we turn off the VPS and in the ticket we tell them they can power it back on via SolusVM and fix the problem at their convenience instead of waiting for us.
Here's the standard message we use for resource abuse (we include appropriate details afterwards):
Remember that quality I was talking about? There it is
@Kujoe: That's a good idea. Does it really work, or do you end up suspending users anyway?
agree.. except if they're abuse our network (read: ddos)
You know something, you make a lot of good suggestions, not these alone, but overall, over many previous posts as well, but you are making them to the wrong segment of th industry, these are lowendboxes after all. But you seem ok with spending money on development/monitoring/hardware or whatever your crusade of the day is, that is just not realistic many times at this budget level.
If you abuse my nodes, I will suspend you, actually I do not even suspend anyone for resource abuse, I identify the abuse, open a ticket to the user with details, and stop their VPS, telling them in the ticket when they have time, they can simply visit solus and restart their VPS. We all may not share the same time schedule, so they can get to it when they have time, and I've left them a way to do that so I can go sleep too. Now if they simply restart their VPS and do nothing, they get suspended.
But the point has been made, and you seem to not accept if you are abusing resources all your neighbors should suck it up til you are good and ready to deal with the problem. Put the shoe on the other foot, some abuser is telling you to suck it up, they will rectify your poor performance when they are good and ready, have a tall cool glass of stfu while waiting.
Suspending/stopping the abuse is the better solution, and if you can't see it, you need to look within some.
I use Observium.
It can generate iops graph. This graph is from one my server.
Unlike Munin, Observium doesn't regenerate graphs at certain interval. This reduces load on the host server.
Today I will agree with @taipres n_n
So, how you monitor the IOPS stuff? Anything in terminal? Some file in /proc maybe? I don't want to install bloated stuff :P
What package were they using to see how much IOPS he was using?
Does it only generate graphs when they're requested, then? Or something else?
Yes, graphs are generated whenever user wants to view them.
I also like it's user interface. However I can't comment on it's extensibility.
Yea I don't understand why 'graphs' would be generated every X mins... sounds like waste of resources... all you need to do is have the data sitting there waiting to be graphed when person comes in to see it.
Munin creates static html pages and thus it needs to regenerate those images at every x minutes in order to keep that page updated. It needs to regenerate (No of Server) times (No of Service Monitored) times (No of graphs per service, e.g. Daily, Weekly, Monthly, etc) graphs to keep those static pages updated.
There was only one user who insisted that our TOS wasn't valid and would run whatever they wanted but after 2 warnings they realized we weren't playing around. The rest learned their lesson after being shutdown (although some didn't know what SolusVM was so they had no idea how to turn it back on).
We have an automated system for that sort of stuff.
+1. We use Observium and Munin for our node monitoring (Observium primarily for network, munin for the pretty graphs on our website).
Just because you offer cheaper plans doesn't mean you shouldn't give all your customers a certain level of professionalism and common curiosity. I'm not fighting the guy getting suspended if he was degrading the server intentionally or untentionally to the point where it was affecting other users, no my issue was with how it was handled. If you can suspend a user then you can warn a user too...it's the very least you can do, send off an email letting them know why and what they need to do to get it back up. @KuJoe's method of letting them unsuspend themselves is brilliant because that's less work he has to do, and all can be automated, plus it treats the customer in a professional way. Where as treating customers like dirt and not answering their tickets for 2 days while they have no access to the service they payed is not ok. If you or whoever dislike being a host, then either fake it, or pursue something else, but don't take it out on customers, because things could always be a lot worse. You could be working at walmart or something making barely anything, and have to put up customers face to face all day being rude and having 0 appreciation for what you do. Looking down on you because they think them having a better job, makes them better than you, which isn't true regardless, but i've read guys with phd's are working at taco bell right now. So anytime I get frustrated with business related things, I remember that, and you should too.