Simple Server Monitoring with Ping.gg

It really is the world’s most simple server monitoring service

Best of all, Ping.gg is currently free! Ping.gg will ping your server constantly, with an interval of 10 seconds.

Victor, the ping.gg creator, will be releasing all the Go code on GitHub eventually, but will keep the UI/PHP pieces to himself. It sounds like HTTP response checking is also in the works:

There is a ping daemon (Go app) that is listening for a couple of redis pub/sub channels for hosts to start and stop pinging. Each host is handled by a different goroutine. When something goes up or down, it publishes the host in another 2 redis pub/sub channels.

This is what I’ll release as open source, before I do I’d like to refactor it so it’s not tightly couple with redis, but rather have an interface there, so it’s easy to change the redis pub/sub interface with, for example, HTTP calls.

Monitor a Site with Ping.gg

To monitor a site (my.example.com), issue this command:

curl ping.gg/[email protected]/my.example.com

I’ll let Victor explain how it works:

After you provide a hostname or IP and your email address, you’ll be sent an email with 3 generated URLs that you can to click to start, stop and delete your tracking. Every time you server goes down or back online you will receive a notification, which will also include the control URLs. BTW, check your spam folder… you know the drill.

ping.gg-down-email

Every time my.example.com is unreachable, you’ll receive an email at [email protected]. An example email is below.

That’s It

Issuing that curl command is all you need to do. You’ll receive an email after adding a site to monitor asking you to active the monitoring. There’s also a link in that email so you can stop or pause monitoring of a site if you wish.

Ping.gg allows 10 sites to be monitored per email address. Ping.gg considers your server/site to be down when it fails to answer 6 pings in a row.

Hoping that Victor builds this into a full fledged service with account dashboards and all, just because it’s sooo simple. The Terms of Service possibly indicate that a professional service may be available at some point:

As previously stated, this is not a professional service (not now at least) so by using this service you agree to the following:

  1. You use this service at your own risk.
  2. There is no warranty that the service will work properly or at all.
  3. Your alerts might be terminated without notice.
  4. The service can stop operating anytime without notice.

Go ahead and give Ping.gg a try, it’s been very reliable for me and I’ve had no issues with it. Keep the Terms of Service in mind, however.

Moving Servers At Dreamhost

After making this post, I submitted a support ticket to Dreamhost. Justin at Dreamhost replied back with a pretty solid sounding solution:

I did notice a few busy sites on the apaches for 2 of your domains. I started a move to another IP/apache which should complete in a few hours, and we can see if that apache turns out to be more stable. Since the server-status page for the old 2 showed an uptime of about 1 hour, likely the sites were causing that apache instance to time out and need to be restarted, resulting in a bit of downtime. Give it a try for a day and if you still have problems, let me know!

Perfect. Switch my domains over to a new httpd process with less activity. Makes sense. Well, after that was done, not much of an improvement was seen, as you can probably tell.

Today, I received another email from Justin saying he noticed longren.org was still slow to respond. He offered to move me to another server, assuming I was willing to have some downtime. He even asked if there was a time I’d prefer the move to be made. I asked him if 10:00 PST would work, and it did. So, this site is going to be offline for a few hours tonight while it’s being moved to a new server. The actual switch won’t take very long, I’ll just have to wait a few hours for the DNS to start pointing to the new IP.

Hopefully everything will be up and running along nice and smoothly tomorrow morning. Also, Justin at Dreamhost is awesome. He’s been very attentive and always offers possible solutions. Thanks again Justin!

Horrible Repsonse Time

longrenOrgEvenSlowerLongren.org has been really, really slow the last week or so. This site has never been this slow to load, even when I was hosting it out of my house on my cable connection. Granted, I didn’t get the traffic back then that I do now, it still shouldn’t be this slow.

Last time longren.org was being slow as shit, I posted an image of a graph from Site24x7, like I’ve done in this post. The response time in the earlier image is horrible, 4510 ms, but that’s a lot lower than I’m seeing now. As you can see from the image above in this post, the current average response time over the last 7 days is 6614 ms.

This has to be a result of something going on at Dreamhost. I say that because sometimes pages on longren.org will load up in a snap. Most of the time though they take between 15 and 30 seconds to load. Even sending queries to the database is slower than normal. Database queries are usually done being executed within 1 or 2 seconds. Lately, it’s been taking 5 to 9 seconds. Something is definitely up. Perhaps I will submit a support ticket to Dreamhost tomorrow. Yay.

Poor Site Performance

Poor Response TimeTake a look at the photo shown there. I don’t like it, at all. I’ve been using Site24x7 for the last few days to monitor various websites I run. It’s really handy and has brought to my attention a few things I wasn’t expecting. Namely, this site performs very poorly, which I’ve noticed more and more in the last few weeks.

OK, this site, longren.org, is hosted at Dreamhost. The Slackware Blog is of course, hosted at wordpress.com. And the other site in the image, is one for work. The site for work has better “response” times than both longren.org and the Slackware Blog. This took me by surprise because the work site is hosted on a Qwest DSL 1Mbit line.

Poor Response Time ComparisonI have a feeling the poor response time is mostly due to grabbing data from external sources, such as Google and Blogrolling. However, I don’t really include much content from external sources. Perhaps the small number of images causes this site to have much slower response times. The Slackware Blog and the work site are very light on images compared to this site. I never post images in posts at the Slackware Blog.

Anyway, I guess a 4500 millisecond response time isn’t too terrible, it’s about 4.5 seconds. Over the last couple days, the response time has gone down to around 2500 milliseconds, or 2.5 seconds. This site does have a larger amount of data to pull for every page, so I guess increased response times here are to be expected. Maybe I’m just worrying about nothing.