Many a times developers use simple monitoring solutions like Uptime Robot or Pingdom to ping servers to check if they are working fine. But when supplying urls to monitoring services, we need to make sure that they are indeed the right url to for the job.
Most developers supply a generic root url to check if things are fine.
Expect to hit the url every n seconds
If the url does very heavy work and has lots of database calls, there are chances that the monitoring system can burden the server. Performing expensive operations is not really required for monitoring systems. They can even bring down the server.
Does this check every system in the stack?
May a times the front page might just be served from the cache without connecting to the database. So expecting an alert email for a database downtime with a simple monitor might just not work.
What should you really check?
Check if all the components of your stack are working fine.
Most applications have a database. Check if database connections are working.
Some applications have a caching layer. Check if you cache is reachable.
This would translate to the following code:
class HeartBeat class SystemsError < StandardError ; end def run raise SystemsError unless check_db && check_cache end private def check_db User.where('id > 1').exists? end def check_cache Rails.cache.write('heartbeat', DateTime.current) && Rails.cache.read('heartbeat') end end
You can use this model in a controller and mount it in your app at
/appbeat or any url of your wish!
class HeartbeatController < ActionController::Metal def index self.response_body = HeartBeat.new.run end end
Get stories like the directly to your inbox.
Subscribe to our Newsletter
Tips and tricks, news about tech tools, recent blog entries and exclusive email only stories once every two weeks