Subscribe
Share
Share
Embed
Healthcheck is a new Drupal module (that TEN7 developed!) that runs periodic checks on the health of your Drupal site and shows the results in an easy-to-understand dashboard.
This is ONE OF 8 BILLION, a podcast about all of us.
We all have a story, don’t we? We’ve all had successes and failures, joy and disappointment, love and sadness. And yet, we’ve all made it to here… to right now! Our stories are one amongst eight billion others… eight billion other stories, each of them unique, each of them grand in their own way, and each of them a window into the humanity that connects us all. ONE OF 8 BILLION tells the life stories of people from around the world. More at 1of8b.com
ONE OF 8 BILLION is supported by TEN7, a technology studio whose mission is to Make Things That Matter. Online at ten7.com
Hey Everybody!
You’re listening to the TEN7 Podcast,
where we get together every fortnight,
and sometimes more often, to talk about
technology, business and the humans in it.
I am your host Ivan Stegic.
We spend a fair amount of time at
TEN7 building software that makes our
clients and their users lives easier.
In so doing, we end up creating things
for ourselves that make our lives
better, faster and less mundane.
And, we inevitably end up contributing
these things back to Open Source.
You could check out
ten7.com/wegiveback for more info.
on things like Flight Deck and Starbase
and other things we’ve built and
given back and continue to support.
Today, we’re announcing the
beta release of a new Drupal
8 module we call Healthcheck.
And, joining me now is the
principal architect and maintainer
of the module, Tess Flynn.
Hi Tess.
Hello.
We’ve been spending our fair share
of time talking to each other on
the Podcast lately, haven’t we?
It does seem to be a running theme lately.
I’m surprised you’re not
sick of my voice yet.
Not at all.
I have a lot of fun talking to you.
So, another module in
the Drupal 8 ecosystem.
Can you give me a 30,000-foot
view of what Healthcheck is?
I like saying that Healthcheck is a
bit like a doctor for your website.
It sits in the background of
your website and runs periodic
checks on the health of your site.
And, why is the health of
your site so important?
Mostly because we spend so
much time not looking at it.
How often do you actually
look at your own website?
Do you check to make sure
that it’s working correctly?
That you didn’t make some change without
thinking or in desperation, or when you
were in the wrong browser window, thinking
you were looking at a different copy of
your site, and now something is amiss.
How often does that happen?
A lot of organizations, a lot of
people don’t really spend a lot
of time looking at their site.
To them it’s just a thing that works until
there’s a problem, and then once there’s a
problem, we don’t know for how long it has
been a problem, because someone had to go
through the effort to complain about it.
Or, someone internally had to stumble on
it themselves, because who knows how many
users it had affected in the meantime.
I think you’re indirectly answering a
question I was going to ask, which is,
doesn’t Site Audit module already do this?
But, what you’re kind of implying here is
that, Healthcheck does this Healthcheck
of the site, but it does it repeatedly.
Yea, Site Audit is more
of a point checker.
I mean, it’s in the name, Site Audit.
And, when you do an audit, you’re
not going to have an accountant come
in and manage all of your finances.
You’re going to have an auditor come in
and rifle through all of your paperwork
at once, to actually figure out what’s
going on, and then once the audit is
over, they’re gone, they don’t come back.
Unless if you have reason to
request or require another audit.
So, the whole point of Site Audit is to
do a point check, at one point in time.
Healthcheck doesn’t really
have that kind of mentality.
It’s mentality is that it checks
continually, on a regular basis, and it
is meant to constantly monitor your site.
And, unlike Site Audit,
it’s a module, right?
Site Audit is this drush
thing, but Healthcheck isn’t?
That’s correct.
Site Audit 2.x is actually a drush
command, and it is meant to run as a
point check, whenever you run the command.
However, Site Audit 3X is actually
supposed to be a Drupal 8 module.
Now at the time of the recording of
this Podcast, it’s not yet finished.
So, I don’t know where they are with the
development of that, however, it might
be out by the time you listen to this.
So, basically, you go to drupal.org, you
go to the Healthcheck module, it’s for
Drupal 8, you download it, you install
it like you would any other module,
and then you go to the reports page.
Does that sound right?
That’s correct.
And, can you tell me about
the reports that it generates.
I kind of get the, like a very high
level, it gives you thumbs up, thumbs
down, and thumbs somewhat down.
So, things that are good, things that
are bad and things that you should check.
Is that about, right?
No.
See, that’s one thing that is
also different with Healthcheck.
Healthcheck doesn’t really try to
go against an idealistic bottle
of what a Drupal site should be.
Instead, it has kind
of an action modality.
So, each individual check has to
report results on how you should
resolve that problem, or not.
So, is this a critical problem?
Should you drop everything
and immediately go and fix it.
Is this something that you probably
should do something about, but
it’s not literally on fire?
Is this, “well this might be ok, and you
should probably look at it, but we’re
not sure if it’s actually that bad.
It might be good for your site.” Or,
“this is fine, this is perfectly expected.
Don’t worry about it.”
And, who determines that?
Is that something that you
decided right at the beginning
with the rest of the TEN7 team?
Or, is that something that’s configurable?
Those different levels.
So, right now, the checks are
actually kind of hard coded.
I would actually like to someday,
make this a little bit more rules
based, where you could configure
those thresholds individually.
I don’t see why the current
architecture couldn’t do that, but
it’s not in the module right now.
We’re still getting towards that data.
And, what kind of checks
does it support right now?
And, how do those compare to something
like Site Audit, for example?
So, there are a lot of similar checks
between Healthcheck and Site Audit.
We check a lot of best practice things,
like, we check if CSS preprocessing is
on, what’s your caching configuration?
We do a few other things as well.
We check the size of the database, if
there’s, oh geez, there’s so many of
them that I can’t quite remember them
all right now, I’d have to look them up.
So, basically, it does a ton of
things that you’d expect from
a best practices point of view,
a Drupal site should be doing.
And, then, it does that on a schedule,
and I would imagine that’s configurable?
Yep.
The schedule can be configured
to run along certain periods.
I think by default that’s once every 24
hours, but you can actually configure it
to run a Healthcheck on every cron run,
and then whatever period you have cron
configure to, it can run a Healthcheck.
So let’s talk a little bit about how
it knows that there’s a difference,
compared to the check that it did last.
Does it only store the last check?
No.
What it actually does is that, the default
mode of Healthcheck is what I call ad hoc
reports, and what happens is that, out of
the box it doesn’t do any checks in the
background, it doesn’t send notifications,
all it does is provides a report screen
that you could interactively check.
Now, there are ways of
extending that afterwards.
You can actually configure it to run
notifications regularly, in which
case, additional options show up
for how often you want that check
to be run, and how do you want to
be notified of when that occurs.
And what kind of notification
system exists right now?
Right now we have two
different notification
systems built into the module.
We have one for sending email
notifications, and the email format
is actually configurable, so you can
change it to be whatever you want, And
we have one that uses webhooks, and
we’ve tested it with Zapier, I’m not
entirely certain if it will work for other
integration providers, but via Zapier,
you can get to something like Slack.
And that notification system to Zapier
is really a JSON object that gets
posted to a particular endpoint, and
then whatever system you’re using as
that webhook endpoint, can process that
data and do whatever it wants with it.
So, something like Integromat or
Zapier, or any of the other competitors
will likely work with this endpoint.
Ok, so, if I understand this
correctly, Healthcheck is a site
doctor for your Drupal 8 website.
It runs and can run on a schedule, it
keeps a history of all the checks that
it’s done in the past, and it compares
the latest check with the previous one.
It will then alert you either
via email or via webhook as to
if there have been any changes.
Does that sound about right?
About.
It doesn’t really check the
previous one to the next one.
There are mechanisms where if a
critical item is found, it will
run notifications no matter if that
was previously discovered or not.
And there are configurations to run
regular reports and send an entire digest
of all of the findings that have been
found in the last Healthcheck to whatever
notification system you configure it to.
That sounds like a patch request.
If someone’s out there listening,
you can submit your own patches, we
can absolutely add the feature of
being able to check from a previous,
do a comparison from a previous
check, so that you’re only sending
notifications out when something changes.
Although, I’m not sure that
that’s any better than sending
it out every time cron runs.
If you haven’t dealt with an issue,
you probably, especially if it’s
critical, you probably want to be
reminded that something’s going on.
Yea, that’s generally kind of where
it came down with the situation.
It’s not like a phone notification,
where once you see it once,
you don’t want to see it again.
This is an infrastructure notification,
and it’s kind of common practice that you
don’t want those to get deprioritized.
You want to have that priority
regularly refreshed, so that you
know you have to deal with it.
That.
That makes a lot of sense.
So, this is in beta release.
It’s the first beta release for Drupal 8.
So, basically, Healthcheck’s
been written from scratch.
Is that a good thing?
Some people say that it’s never a good
thing to write a thing from scratch.
Honestly, in my perspective on Drupal 8
is, you might as well write from scratch.
And, the reason why is, Drupal 8
is fundamentally a very different
system than Drupal 7, and it is
a false dichotomy to assume that
they’re really the same product.
They’re completely
different in my opinion.
And, if you don’t take the time
to reconceptualize what you’re
doing from 7 to 8, you’re going to
have a bad time eventually if your
module is of any degree complex.
So, let’s talk about the Drupal
8 version of this module.
I want you to mention, and maybe
kind of talk about how the plugin
architecture has been designed.
The idea behind it is that we are going
to release a module here that has a
certain amount of capability to do the
checks that we really wanted to do.
But then, make it possible so that
anyone can write their own checks in
addition to the ones that we’ve written.
Does that sound about
what we were thinking?
Yea.
One of the primary concerns for me, when I
was architecting this module is, I wanted
to make it really, really, really, really,
really easy to write your own checks.
I don’t want to make that a complex,
weird affair, I wanted to make it as
natural as possible, for anybody who is
used to implementing a Drupal 8 plugin.
And, with Healthcheck, we already
provide a base class for the plugin.
We provide all of the documentation,
we provide the plugin types, there
are easily findable examples within
the module that you can pattern it off
of, and really you have to make one
object and one function, and that’s it.
Is there a limitation to the kind
of check you could be writing?
Well, ok.
There are a few things that
do come as a limitation with
the module-centric approach.
One is, if the Drupal environment
is completely non-functional,
this module probably won’t work.
And, that’s going to be a bit
of a limitation for some people.
Also, you can’t run it as part
of your infrastructure hosting.
So, you can’t have this as a command
floating out there as Site Audit
does, where you can configure the
infrastructure to regularly run it
against any directory that you assume
has a Drupal installation somewhere.
With Healthcheck, it’s limitation
is that it is a Drupal module, so it
only knows about your Drupal site,
it doesn’t know about anything else.
How does that affect whether you have
a multi-site installation or not?
So, you can still install Healthcheck
in the module directory, and
have it available for all of
the sites in the multi-site, but
you have to enable it for each.
So the beta release that we’re
announcing today is for Drupal 8.
There’s still a ton of Drupal 7 sites
out there, and I know we’re planning on
providing support for Drupal 7 as well.
Can you speak to how that may be
the same, or might be different
than the Drupal 8 module?
So, I would like to write it as
similarly as possible, with similar
class names, similar interfaces, so
that it works more or less the same.
I would like to use C-tool plugins, but
I also have no experience with C tool
plugins, so I have no idea if this is
a good decision, or even the right one.
But we’re going to find out,
because that’s how things
evolve, and that’s how we learn.
So, I’m looking forward to finding it out.
Are there any other
options to using C tools?
Well, you could write your own plugin
manager toolkit, but it’s like, that’s
a little bit…I’m not looking forward to
that task myself if I was tasked with it.
[laughing]
[laughing] Well, we might have to have
you architect it, and we’ll see who
else we can get to help us do that.
Ok.
So, Drupal 7 version coming soon,
hopefully in the beginning of 2019.
As some of the listeners out there know,
we have a service called TEN7Audit,
which is usually the first step of
onboarding a new client with TEN7.
And typically it’s for a client, for
a site we didn’t build, but might
need Drupal support, and in the
past, we used Site Audit to extract
useful information about the site,
kind of just as a cursory look.
The very first thing we do in a
TEN7Audit is run Site Audit, we get
that initial automated list of things to
check, but now we’re using Healthcheck
as a drop-in replacement for it.
There are obviously things that Site
Audit does that Healthcheck simply
does not, and I guess the question
for you, Tess, is, when is it more
appropriate to use one over the other?
Usually when it comes to running
the individual Site Audit, usually
I’m only concerned with one site,
and so far, I haven’t actually run
across any multi-site installs.
I’ve run across a few domain access module
installs, and also custom implementations
which mimic that kind of behavior, but
not a multi-site qua multi-site, yet.
And even so, it could be run
on it, it would just require
a little bit more effort.
And when it comes to when should you
run Site Audit, well, for the moment
we don’t have a Drupal 7 version of
Healthcheck, so, I would say that anytime
you’re doing Drupal 7 stuff, you should
probably use Site Audit for right now.
Also, if you intend to run this as part of
an infrastructure setup, inside of server
hosting, or containers that regularly
run against your multiple installed
sites such as if your….I know that
Pantheon does this, I know that you could
definitely configure Site Audit to work
with Aegir, that is one possible usage
of it, those are definitely good options
to use Site Audit for versus Healthcheck.
Healthcheck is meant to
check just one Drupal site.
Ok.
We kind of started talking about future
features in my mind there, so, maybe
after the first beta release and the first
stable release, we’ll focus on doing some
Drupal 7 implementation of Healthcheck.
But, maybe a future release, or have
you thought about a future feature
in subsequent releases to enable some
sort of CLI interface for Healthcheck?
Or do you feel like you don’t want
to take the module down that route?
Do you feel like you just want to
continue to have the module be a
module in the classic sense with the
UI and not go down that CLI route?
The problem with the CLI route is once
you go down that path, the question is,
whether or not it’s going to maintain
being a Drupal module, or if it’s
going to be a Drupal orbiting command.
Site Audit really isn’t a Drupal
module, it’s a drush command.
It’s what I would call, a utility,
which is in Drupal’s orbit.
But, Drupal itself doesn’t
need to be functional.
And, when you look at Site Audit
internally that actually explains a lot
of the design decisions that go into
it, why it doesn’t rely as heavily on
internal services provided by Drupal to
do a lot of checks, but Healthcheck does.
So, likely, no CLI coming to
Healthcheck in the future.
Well, we can still add one, it’s just
that it wouldn’t be a pure CLI approach.
It would be an adjacent command
which would allow you to run the
checks, and even get those responses.
I had thought about implementing
that too, as a drush 9 command, and
a Drupal consult command, But at the
moment what you would usually do is,
you would run drush cron and that
would run the Healthcheck for you.
The thing that made me nervous is
when you said, “once you add it,
you won’t be able to take it out,”
and you’ve gone down that path.
So, now I’m a little bit hesitant about
adding the CLI to Drupal 8 Healthcheck.
I kind of like the idea of just running
drush cron and having it run Healthcheck.
I mean that already works.
That’s how I was testing it.
[laughing]
[laughing] So, the other thing that
appeals to me is, this idea that
notifications or reports can be
sent using a webhook, because that
opens the module up to being used
in so many different places as well.
And, the thing that I am looking
forward to is this idea that we could
potentially have a dashboard where we
can see all of the sites that we’re
checking for clients of our own, the
multi-sites, whatever they may be.
All Healthcheck sites in one place, to
see kind of the status across the board.
Do you think that’s a
reasonable expectation?
I would love to write that functionality
because it would allow us to collate a
lot of different reports from Healthcheck,
and then take them into a single
dashboard that we can display using views.
I love that idea.
And then maybe we could start to
service online and other people can
sign up to using it, and we will
become a service provider then.
Anything more you want to say with
this beta release of Healthcheck?
The thing that I really like about
Healthcheck, is that, it is intended
for people who don’t have a comfortable
grasp of the command line environment.
They’re used to modules, they’re use to
working with the Drupal admin Interface,
and Healthcheck really shines there.
It’s meant to be accessed and worked from,
from that interface, and allow you to do
all of your checks from that interface.
And that’s what I really,
really like about it.
And it’s also created by an
incredibly talented amazing,
developer on the TEN7 staff.
Thank you so much for all the work
that you’ve put into it, Tess.
I’m looking forward to getting a stable
release out there soon after the beta,
and maybe you’ll join me again when we
add another major feature to Healthcheck.
Yep, sounds good.
Healthcheck is a Drupal 8
module, available now in
beta at ten7.com/healthcheck.
It’s you’re your site’s
own personal physician.
It’ll periodically run checks on
your site to see if something’s
changed, gone wrong, or been
misconfigured, and it’ll also alert you.
Drupal 8 Healthcheck at
ten7.com/healthcheck.
You’ve been listening to the TEN7 Podcast.
Find us online at ten7.com/podcast.
And if you have a second,
do send us a message.
We love hearing from you.
Our email address is podcast@ten7.com.
Until next time, this is Ivan Stegic.
Thank you for listening.