This project is not covered by Drupal’s security advisory policy.

This module sprung up due to the frequency of outages we saw with an unnamed hosting service. Sometimes new projects need more handholding than others and new hosts have different challenges.

Quick overview

This is a customizable liveness probe with:

  • (see README.md for usage and setup)
  • command line wrapper for drush with fail-over liveness event logging capability included
  • liveness_cron implemented
  • invoke liveness check with php command (wrapper for drush with failover)
  • harvest liveness results from multiple environments
  • email notification
  • customizable block (place it with the block system)
  • enable or disable block with "last 3 liveness events (default displays events from last 48 hrs)"
  • sortable and filterable liveness events
  • multiple environments configurable to be probed and merge results
  • display last 3 messages from last X hours where X is configurable (for the block)

Basically the idea is to use the one of our test (aka qa) and dev environments that run Drupal as liveness probes to not only monitor each other but also they will be used to monitor prod.

So if prod is down, we will display a notification (block) in our test (aka qa) and dev Drupal environments indicating this.

There will be three (or more) configurable urls for probing. The production (prod) url will be a configuration field and all probing will be disabled for prod it'self. Probing will be performed and reported on the test and dev. Test and dev will probe each other and also the prod url for liveness. Sends an email about the liveness events OR simply log them and display a SITENAME is down message in a block on the non-prod hosts. Each liveness event will be logged. The list of interested party emails or drupal accounts is configurable.

This functionality is complemented with a drush command which, if the db is down, writes an entry to an availability file with the date of the downage that can be consumed by the module. Should the db come back after a db unavailable occurence those entries from the availability file will be added to the dblog (watchdog) as an entry but only once per timestamp.

The drush command is a complementary offering of this module that can be added to a crontab entry on the host(s) as a complementary part of the solution for when the db is unavailable.

Features

Use your various drupal environments to probe others and your prod environment and report liveness events to interested parties, display a block notifying of liveness events on the other environments.

Liveness block
LIveness events
Configuration page for liveness probe

Post-Installation

Once installed, you will need to configure the hosts involved in the liveness probing and select your configuration options. Then go to the block system, add the liveness probe notification block where you want it.
Set up a crontab entry or equivalent to invoke drupal cron externally.
Then run cron to do first liveness probe.
There is also a drush liveness:check command that is made available, when providing URL and environmental name parameters there'll be less or no db calls made until the check has written its entry.

Additional Requirements

This module requires Drupal core and optionally email capability as well as drush and ideally a crontab entry for cron to be invoked externally from Drupal. There's also a special drush command included that can be invoked at a low level as follows: drush liveness:check https://url-to-check environment-name

N/A

Similar projects

None that I know of (yet)

Supporting this Module

TBD

Community Documentation

README.md

Supporting organizations: 
Provide hosting and development resources

Project information

Releases