The Top 5 (Wrong) Reasons You Don’t Monitor Your VPS
I’ve been using virtual private servers for more than a decade, on and off, and only now have I come to realize the importance of VPS monitoring.
This change in mindset should be much of a surprise to those who read the Serverwise blog with any regularity. I haven’t been shy about being a bad, VPS-killing “sysadmin”, but I’m always looking for places to learn.
Enter this very blog. Beginning on or just before August 10, the page generation time for
single.php templates in our WordPress installation had jumped three-fold. Generating a page like this one went from roughly 400ms to nearly 1,200ms.
Get THE BEST DEALS IN CLOUD HOSTING from Los Angeles!Grab a huge 32GB RAM & 320GB of SSD storage for just $109/year!
Given that a blink of the eye takes about 100ms, it’s a significant increase. We went from a slow blink to a legitimate microsleep. Plus, Google is starting to hammer SEO ranks for sites with slow load speeds.
I spent time diving into our WordPress templates to resolve the issue. Based on Git commits, I hadn’t edited the
single.php template for a least a month prior to increase, so I was able to rule it out as the culprit.
I did make two changes on August 10, which were to add some Mailchimp subscribe forms and a
latest post area on the footer to match what we have on our homepage. I removed those and saw generation times improve to a degree, but not return to the 400ms or less level.
The culprit was, in the end, too many plugins, each of which wanted to make a handful of database calls. I removed many unnecessary plugins and made some tough choices about eliminating generally-unused features on this blog in favor of speed. I also ended up dumping dozens of extraneous database calls throughout our templates—why bother using functions like
home_url when I know precisely what those static values will be?
As soon as I deployed these changes, our numbers improved significantly. Our web server now generates a
single.php template in just over 300ms—lower than it had been when this investigation began.
I don’t want this to come off as an attempt at one of those technical postmortems wherein some incredibly smart engineer explains how they fixed an enormously complex issue with their code or infrastructure. I’m just relaying an anecdote for the rest of us.
Without monitoring, we wouldn’t have noticed this issue in the first place. We probably would have ended up spending dozens of ours scratching our heads at downward trending SEO numbers. And, perhaps more importantly, we made our blog’s experience a little better for anyone we’re lucky enough to have read it.
Now that I better understand the value in VPS monitoring, I thought this was an opportune moment to look back into why I hadn’t before. Which excuses had I told myself? What reasons had I heard from others?
“It’s just for personal use.” “I don’t host any websites on it.” “Even if the website crashes, no one looks at it anyway.” “I”m just self-hosting an RSS reader and a few other unimportant things.”
We often don’t realize that we’ve placed sentimental value on something until that object comes under some risk.
I didn’t realize I cared about the carabiner on which I kept my keys—the one I had bought at a gift shop in the North Carolina mountains during a spring break trip with thirty other diehard cyclists, a trip that included both a 120-mile ride and a bout with flu my mother still insists was swine flu—until the security detail at a music venue insisted I couldn’t enter unless I threw it away.
You might not realize how much the contents of your VPS matter to you until you can’t access them. Better you know about it early and carve out time to make the fix rather than finding yourself flailing when you need it the most.
Even if you’ve never experienced a catastrophic crash before, it’s important to remember that the health of a VPS is much more than a binary
is not running. Much the same way your health is more than
The past is a decent indicator of the present, but not when you throw computing into the mix. There are too many variables to possibly keep track of.
I had never had someone hack into my desktop computer before, until it happened. When I started using Linux at around 15, I tended to use
asdf as my user’s password. Why bother with something more complicated for a desktop computer? I hadn’t experienced any problems until I brought my desktop with me to my freshman dorm room and connected to the intraweb.
Oh, we did relish in the joy of that intraweb. We all shared our folders of pirated music. We filled our hard drives with
.avi rips of trending movies we didn’t bother seeing in theaters. We played near-pingless LAN games with friends down the hall.
All this intraweb joy also created attack vectors we weren’t aware of. I never considered that someone might use
ssh to log into my desktop computer. Their scripted attack probably didn’t need long before trying
Cue me spending the next day cleaning things up, mourning over all the pirated music I’d lost, and formatting my system to reinstall Arch Linux. All because I thought, “No one’s ever hacked into my desktop before.”
On occasion, I tell an embarrassing story about a VPS I had long ago, before I realized how easily script kiddies and bots could infiltrate those with, let’s say, a less-than-ideal password security policy.
I logged in after a long break from any development projects and found a cryptocurrency miner running as a Docker container, happily eating up all my spare resources. And then some. I was lucky the provider hadn’t shut my VPS down for using far too many CPU cycles or inadvertently participating in a crypto botnet.
So, yes, your VPS provider (or your own customer) just might let you know that things aren’t working correctly. The trouble is, at that point, the window to make a proper fix might have already closed.
Sure you do! I have more important things to do than writing this very post. My 10-month-old daughter is sitting on the floor next to me (don’t worry, her mom is here too), and while I’d love to dedicate my day to help her master the art of crawling, I also need to get this done.
Most of our lives are more important than a terminal, a VPS, the internet, a computer. Most of our lives are more important than our jobs, our business, the demand to make money.
But, if any of the above three (wrong) reasons ring true to you, there’s a sliver of proof that your VPS or its contents are important to you, at least to a degree.
Alas, my least favorite reason of all. The entire point of the Serverwise blog is to teach you how, or at least give you the confidence that you can.
I started off by installing NetData into my existing self-hosted stack. NetData isn’t perfect for all monitoring needs, but it’s highly configurable and customizable for your needs. You can add more charts, customize alarms, or get deep insights into your Apache/Nginx logs.
And, more than a year ago, I put together a list of some excellent (and free!) alternatives to NewRelic that you can install on your VPS as well.
We have some more monitoring content on the horizon—so stay tuned for that. Until then, let’s try not to kill any more of our servers.
A post-script thank-you to Joel on Software for his headline inspiration.