Creating a server health monitoring app with Laravel
You will need to have Apache, PHP, Composer, MySQL, and Node installed on your machine.
There are lots of server monitoring solutions out there. Most popular among them are Datadog and New Relic. Some server infrastructure providers such as DigitalOcean also comes with basic server monitoring features such as disk, CPU, and memory. There are also open-source solutions such as Nagios. But more often than not, especially on small projects, a lot of the functionality that these services offer is more than what you need. Aside from that, they’re usually not cheap.
If you’re like me and all you want is some basic functionality such as realtime monitoring of whether specific software on your server is running or not, then creating your own server monitoring app is the way to go.
In this tutorial, we’ll be creating a live server monitoring app with Laravel and Pusher Channels.
Prerequisites
Knowledge of PHP is required to follow this tutorial. You also need to know basic server management for infrastructure providers like DigitalOcean or Linode. Things like generating ssh keys and adding them to your remote server.
Development environment
You need to have Apache, PHP, Composer, MySQL, and Node installed on your machine. The easiest way to follow this tutorial if you don’t already have the development environment is to use either Laravel Homestead or Laravel Valet. If you have a bit more time, you can install Laradock instead. This is the same environment that I’ve used for creating this tutorial.
Out of the box, Laravel Homestead and Laradock will come pre-installed with the required software.
If you opt for Laravel Valet, you also need to install PHP, Composer, MySQL, and Node separately. For the HTTP server, it’s going to use PHP’s built-in server instead of Apache. Just follow their documentation for the instructions.
A remote server to be monitored is also required. Don’t assign a password to the ssh key you generate as the tool that we will be using for logging in remotely to the server doesn’t support logging in with ssh keys that require a password. This tutorial won’t be covering how to add ssh keys to a remote server. But if you’re using a Linux-based server, all you have to do is log in to it and append your local machine’s public ssh key to the ~/.ssh/authorized_keys file in the server.
Lastly, you need to have a Pusher account with an app instance which you can use for testing.
Package versions
The following package versions are used for the app:
- laravel/framework 5.8
- pusher/pusher-php-server 4.0
- spatie/laravel-server-monitor 1.0
You don’t have to use the same versions, but it’s good to know if you encounter any compatibility issues.
App overview
We’ll be building a live server monitor that will constantly check for various server status such as disk space, CPU, and memory. It will also check if the software you’re using to run your server is running or not. The data on the page will automatically be updated at a specific interval.
Here’s what the app will look like:
You can view the code on its GitHub repo.
Bootstrapping the app
Let’s get started by creating a new Laravel project:
composer create-project --prefer-dist laravel/laravel liveservermonitor
This will create a new liveservermonitor folder on your working directory. Navigate inside that and it will serve as the root directory for this project.
Create and add the database config
Log in to the MySQL server and create the database that we will be using to store the status of the servers to be monitored:
mysql -u root -p
CREATE DATABASE server_monitor;
Next, open the .env file and set your database credentials. Replace the values for the one’s which starts with YOUR_:
DB_CONNECTION=mysql
DB_HOST=YOUR_DB_HOST
DB_PORT=3306
DB_DATABASE=server_monitor
DB_USERNAME=YOUR_DB_USERNAME
DB_PASSWORD=YOUR_DB_PASSWORD
Install the backend dependencies
Next, we need to install the libraries we need:
composer require spatie/laravel-server-monitor pusher/pusher-php-server
Here’s a breakdown of what each one does:
- spatie/laravel-server-monitor - for implementing server monitoring features.
- pusher/pusher-php-server - for implementing realtime communication between the backend and the frontend of the app.
Once the libraries are installed, we need to register the service provider for the laravel-server-monitor package. Open the config/app.php file and add the following under the providers array. While you’re there, uncomment the Broadcast service provider as well. This will let us use the event broadcasting feature in Laravel. We use it to broadcast the event for when laravel-server-monitor has finished checking the server status:
'providers' => [
// ...
App\Providers\BroadcastServiceProvider::class, // uncomment this
Spatie\ServerMonitor\ServerMonitorServiceProvider::class, // add this
];
Next, generate the migration files for creating the tables to be used by laravel-server-monitor then run the migrations:
php artisan vendor:publish --provider="Spatie\ServerMonitor\ServerMonitorServiceProvider" --tag="migrations"
php artisan migrate
This will create the hosts table:
And the checks table:
The hosts table stores all the information about the remote servers to be monitored, while the checks table stores the information for the various checks that you’ve added for each of the server (for example, disk space and MySQL).
Lastly, generate the configuration file for the laravel-server-monitor. This will create a config/server-monitor.php file. This is where we can configure the various settings for the library:
php artisan vendor:publish --provider="Spatie\ServerMonitor\ServerMonitorServiceProvider" --tag="config"
Install the frontend dependencies
After installing and configuring the backend dependencies, we can also install the frontend dependencies. First, install the default frontend libraries which Laravel depends on (includes Bootstrap, jQuery, and others):
npm install
Note: This includes a bunch of libraries which we won’t be using. But we won’t really be importing them in any of our scripts so it’s okay even if we don’t remove them from the
package.jsonfile.
Once those are installed, we also need to install our own dependencies:
npm install --save laravel-echo pusher-js visibilityjs
Here’s a break down of what each one does:
- laravel-echo - this will let us configure Pusher channels as a broadcaster. You can also use the pusher-js library directly if you’re sure you won’t be needing to use any other realtime subscription channels in the future. Using Laravel Echo is simply a convenience utility for normalizing the APIs.
- pusher-js - the client-side component of Pusher Channels. Laravel Echo uses it behind the scenes to establish realtime communication between the backend and the frontend.
- visibilityjs - for listening for when the page visibility changes. This acts as a wrapper to the Page Visibility API so it’s easier to use (normalized API across browsers).
Building the app
Now we’re ready to build the app. We’ll first add the custom system checks, then we’ll create a custom notification channel so that the server has a way of notifying us when the system checks finishes running. After that, we’ll work on the frontend side of the app. Then finally, we’ll add the remote servers to be monitored and run the system checks.
First, open the config/server-monitor.php file and inspect the checks array. These are the server checks that are built into laravel-server-monitor. In this tutorial, we won’t be using elasticsearch and memcached because the remote server that I’ll be using for testing doesn’t have it installed. From here, you can uncomment any checks that you don’t need. Though only do that if you’re sure that you won’t be using it in any of the servers you want to add for monitoring. You can actually disable specific checks to a server that’s already being monitored. I’ll show you how later:
// config/server-monitor.php
'checks' => [
'diskspace' => Spatie\ServerMonitor\CheckDefinitions\Diskspace::class,
'elasticsearch' => Spatie\ServerMonitor\CheckDefinitions\Elasticsearch::class,
'memcached' => Spatie\ServerMonitor\CheckDefinitions\Memcached::class,
'mysql' => Spatie\ServerMonitor\CheckDefinitions\MySql::class,
]
Aside from removing unneeded checks, this is also where we can add custom checks for checking if the software you’re using to run the server is running. And that’s exactly what we’ll be doing next. Specifically, we’ll add the following:
- Check if Apache is running
- Check if Beanstalkd is running
- Get the memory usage
- Get the average CPU usage
Checking if Apache is running
First, we’ll add the class for checking if Apache is running. You can do that by creating a SystemChecks folder inside the app directory and inside it create an Apache.php file:
<?php
// app/SystemChecks/Apache.php
namespace App\SystemChecks;
use Spatie\ServerMonitor\CheckDefinitions\CheckDefinition;
use Symfony\Component\Process\Process;
class Apache extends CheckDefinition
{
public $command = 'service apache2 status';
public function resolve(Process $process)
{
if (str_contains($process->getOutput(), 'active (running)')) {
$this->check->succeed('is running');
return;
}
$this->check->fail('is not running');
}
}
From the code above, you can see that we need to import both the Spatie\ServerMonitor\CheckDefinitions\CheckDefinition and Symfony\Component\Process\Process class to create a system check class. The class that you create has to extend the CheckDefinition class.
This requires you to add a public $command and implement the resolve() function. The $command, as the name suggests is the command used for checking the status of the software you want to check. Good thing there’s already a built-in diagnostics tool for Apache, so all we have to do is call it from here:
public $command = 'service apache2 status';
If you execute the same command on the terminal you’ll get an output similar to the following:
Next, inside the resolve() function, we get access to the $process because it’s passed as an argument. From here, all we have to do is check if the output string contains “active (running)”. If you check the terminal output above, it contains that same string in green so we know that the server is running if that’s present in the output. We then call $this->check->succeed('is running') to set the status of the check:
if (str_contains($process->getOutput(), 'active (running)')) {
$this->check->succeed('is running'); // set status
return;
}
Checking if Beanstalkd is running
Create an app/SystemChecks/Beanstalkd.php file and add the following. This does pretty much the same thing as the Apache check. The only difference is the command we’re executing:
<?php
// app/SystemChecks/Beanstalkd.php
namespace App\SystemChecks;
use Spatie\ServerMonitor\CheckDefinitions\CheckDefinition;
use Symfony\Component\Process\Process;
class Beanstalkd extends CheckDefinition
{
public $command = 'service beanstalkd status';
public function resolve(Process $process)
{
if (str_contains($process->getOutput(), 'active (running)')) {
$this->check->succeed('is running');
return;
}
$this->check->fail('is not running');
}
}
Getting average CPU usage
Create an app/SystemChecks/CPUUsage.php file and add the following. This is a bit different from the previous two because even though we’re extending from the CheckDefinition class, we aren’t actually implementing it 100%. We’re setting an empty command because the Symfony Process component which is used by laravel-server-monitor doesn’t seem to be able to handle piping directly with awk (a text processing tool) for the command line). So what we do is execute the command ourselves instead.
Since there’s usually a threshold in which we consider the CPU to be at a normal operating rate, we also need to add a separate config for that inside config/server-monitor.php. That’s what we’re getting when we call config('server-monitor.cpu_usage_threshold'). There are two thresholds: warn and fail. If the current CPU usage percentage is either of those two, we set the check status to whatever it falls into. Otherwise, we assume that the CPU is operating at a normal rate and set the status to succeed:
<?php
// app/SystemChecks/CPUUsage.php
namespace App\SystemChecks;
use Spatie\ServerMonitor\CheckDefinitions\CheckDefinition;
use Symfony\Component\Process\Process;
class CPUUsage extends CheckDefinition
{
public $command = "";
public function resolve(Process $process)
{
$percentage = $this->getCPUUsagePercentage();
$usage = round($percentage, 2);
$message = "usage at {$usage}%";
$thresholds = config('server-monitor.cpu_usage_threshold');
if ($percentage >= $thresholds['fail']) {
$this->check->fail($message);
return;
}
if ($percentage >= $thresholds['warning']) {
$this->check->warn($message);
return;
}
$this->check->succeed($message);
}
// next: add code for getting CPU percentage
}
Here’s the function for getting the CPU percentage. This uses grep to search for lines with the “cpu” text inside the /proc/stat file. After that, we use awk to calculate the usage percentage based on the result we get when we perform arithmetic operations on the second ($2), fourth ($4), and fifth ($5) column of text in that line. Then we simply return the result by using print:
protected function getCPUUsagePercentage(): float
{
$cpu = shell_exec("grep 'cpu ' /proc/stat | awk '{usage=($2+$4)*100/($2+$4+$5)} END {print usage}'");
return (float) $cpu;
}
For reference, here’s what the output of cat /proc/stat looks like. So $2 is 11738, $4 is 18979 and so on:
Note: The function above only returns the average CPU usage since the system booted up. This lets us see whether the system is running under tremendous load for a longer period of time. If you need to get the current CPU usage, you need to use something like the
topcommand.
Getting memory usage
The last system check that we’ll add is the memory usage. Create an app/SystemChecks/MemoryUsage.php file and add the following. This works similarly to the previous one. The only difference is that we’re now directly reading from the file instead of using grep and awk, we’re using PHP’s fopen() function to read the /proc/meminfo file:
<?php
namespace App\SystemChecks;
use Spatie\ServerMonitor\CheckDefinitions\CheckDefinition;
use Symfony\Component\Process\Process;
class MemoryUsage extends CheckDefinition
{
public $command = "";
public function resolve(Process $process)
{
$percentage = $this->getMemoryUsage();
$message = "usage at {$percentage}%";
$thresholds = config('server-monitor.memory_usage_threshold');
if ($percentage >= $thresholds['fail']) {
$this->check->fail($message);
return;
}
if ($percentage >= $thresholds['warning']) {
$this->check->warn($message);
return;
}
$this->check->succeed($message);
}
// next: add code for getting memory percentage usage
}
Here’s the function for getting the current memory usage. This reads from the /proc/meminfo file. This file contains various information about the system memory. We extract all number instances then divide the active memory usage from the total memory to get the memory in use:
protected function getMemoryUsage(): float
{
$fh = fopen('/proc/meminfo', 'r');
$mem = 0;
$all_str = '';
while ($line = fgets($fh)) {
$all_str .= $line;
}
fclose($fh);
preg_match_all('/(\d+)/', $all_str, $pieces);
$used = round($pieces\[0\][6] / $pieces\[0\][0], 2);
return $used;
}
For reference, here’s the output of cat /proc/meminfo. The index count starts at 0, so the sixth value is the one beside “Active” and the first value is the one beside “MemTotal”:
Configure server monitor
Now that we’ve added all the system checks, it’s time to let laravel-server-monitor know of them. To do that, all we have to do is add them to the checks array. Use a short but descriptive name for the keys and set the path to the class as the value:
<?php
// config/server-monitor.php
return [
'checks' => [
'diskspace' => Spatie\ServerMonitor\CheckDefinitions\Diskspace::class,
'elasticsearch' => Spatie\ServerMonitor\CheckDefinitions\Elasticsearch::class,
'memcached' => Spatie\ServerMonitor\CheckDefinitions\Memcached::class,
'mysql' => Spatie\ServerMonitor\CheckDefinitions\MySql::class,
// add these:
'apache' => App\SystemChecks\Apache::class,
'beanstalkd' => App\SystemChecks\Beanstalkd::class,
'cpu' => App\SystemChecks\CPUUsage::class,
'memory' => App\SystemChecks\MemoryUsage::class
],
// ...
];
At this point, we’re not really done yet. We’ve already added the custom checks but we still haven’t added a way for us to get hold of the data in realtime. That’s what we’ll be doing in the next section.
Create Pusher notification channel
The next step is for us to create a custom notification channel. These notification channels automatically get triggered every time the system checks are done executing. By default, laravel-system-monitor uses Slack as a notification channel. We won’t be using it in this tutorial because all we need is realtime monitoring. For that, we will be using Pusher Channels.
// config/server-monitor.php
'notifications' => [
'notifications' => [
Spatie\ServerMonitor\Notifications\Notifications\CheckSucceeded::class => ['slack'], // we need to update this so it doesn't use slack
// ...
]
To create a custom notification channel, create a Channels folder inside the app directory and inside it create a PusherChannelsChannel.php file then add the following:
<?php
// app/Channels/PusherChannelsChannel.php
namespace App\Channels;
use Illuminate\Notifications\Notification;
use Illuminate\Support\Facades\Cache;
use App\Events\FinishedCheck;
class PusherChannelsChannel
{
public function send($notifiable, Notification $notification)
{
if (Cache::get('page_visibility') == 'visible') {
$id = $notification->event->check->id;
$type = $notification->event->check->type;
$status = $notification->event->check->status;
$last_run_message = $notification->event->check->last_run_message;
$host_id = $notification->event->check->host_id;
event(new FinishedCheck([
'id' => 'check-' . $id,
'type' => $type,
'status' => $status,
'last_run_message' => $last_run_message,
'element_class' => numberTextClass($type, $status, $last_run_message),
'last_update' => now()->toDateTimeString(),
'host_id' => 'host-' . $host_id
]));
}
}
}
What the above code does is it first checks whether the app dashboard is currently being viewed by the user (on the foreground). If it is, it dispatches the FinishedCheck event. We’ll create this event shortly, for now, know that it’s the one responsible for triggering the message to be sent to the frontend of the app. The message contains the status of a specific system check.
Finished check event
In order to send messages to the app’s frontend and update its contents without refreshing the whole page, we need to create an event which will broadcast the message using Pusher Channels. You can create the event using artisan:
php artisan make:event FinishedCheck
This creates an app/Events/FinishedCheck.php file which has already the basic boilerplate code for broadcasting events in Laravel. Replace the existing code with the following:
<?php
namespace App\Events;
use Illuminate\Broadcasting\Channel; // for broadcasting to a public Pusher channel
use Illuminate\Foundation\Events\Dispatchable;
use Illuminate\Broadcasting\InteractsWithSockets;
use Illuminate\Contracts\Broadcasting\ShouldBroadcast;
class FinishedCheck implements ShouldBroadcast
{
use Dispatchable, InteractsWithSockets, SerializesModels;
public $message; // the message to be sent to the client side
public function __construct($message)
{
$this->message = $message;
}
public function broadcastAs()
{
return 'finished.check';
}
public function broadcastOn()
{
return new Channel('live-monitor');
}
}
The most important thing in the above code is that the class should implement the ShouldBroadcast class. This lets Laravel know that this is an event class. If you implement that class, you need to supply the broadcastOn() function. Inside it, all you need to do is return a new Channel instance. This accepts the name of the public Pusher channel where you want to broadcast the event.
public function broadcastOn()
{
return new Channel('live-monitor');
}
Next, add the $message as a public property for the class. This will contain the actual message to be sent to the frontend:
public $message;
Lastly, although not required, we’re also setting a broadcastAs() function. This allows us to change the name of the event. By default it will be set to the full path of the class: App\\Events\\FinishedCheck. As you can see, it’s not really that friendly. If you specify the broadcastAs() function, the string that you return from here will be used instead:
public function broadcastAs()
{
return 'finished.check';
}
Add notification channel
Now that we’ve created both the custom notification channel and the event which it dispatches, it’s time to let laravel-server-monitor know of it. Start by importing the PusherChannelsChannel class. Then for each of the items inside the notifications.notifications array, set PusherChannelsChannel::class as an item. This allows us to trigger the event for updating the client-side for each of the available notifications:
<?php
// config/server-monitor.php
use App\Channels\PusherChannelsChannel; // add this
return [
'checks' => [
// ...
],
// ...
'notifications' => [
// update this:
'notifications' => [
Spatie\ServerMonitor\Notifications\Notifications\CheckSucceeded::class => [PusherChannelsChannel::class],
Spatie\ServerMonitor\Notifications\Notifications\CheckRestored::class => [PusherChannelsChannel::class],
Spatie\ServerMonitor\Notifications\Notifications\CheckWarning::class => [PusherChannelsChannel::class],
Spatie\ServerMonitor\Notifications\Notifications\CheckFailed::class => [PusherChannelsChannel::class],
],
// ...
],
// ...
];
While we’re here, you can also add the CPU and memory usage thresholds after the diskspace threshold:
// ...
'diskspace_percentage_threshold' => [
'warning' => 80,
'fail' => 90,
],
// add these
'cpu_usage_threshold' => [
'warning' => 70,
'fail' => 90,
],
'memory_usage_threshold' => [
'warning' => 75,
'fail' => 90,
],
Routes
Now we’re ready to start working on the frontend of the app. Start by replacing the contents of the routes/web.php file with the following. Below, we’re adding two routes: one for handling the request to the home page of the app and the other for handling the POST request for updating the page visibility status:
<?php
Route::get('/', 'MonitorController@index'); // for serving the app dashboard
Route::post('/page-visibility', 'MonitorController@updatePageVisibility'); // for updating the page visibility
Monitor Controller
The next step is to create the MonitorController that we’ve used above. Execute the following command in the terminal to create it:
php artisan make:controller MonitorController
This will generate an app/Controllers/MonitorController.php file with some minimal boilerplate code for a controller. Clear the contents of the file and add the following instead:
<?php
// app/Controllers/MonitorController.php
namespace App\Http\Controllers;
use Illuminate\Http\Request;
use App\Host;
use Illuminate\Support\Facades\Cache;
class MonitorController extends Controller
{
public function index()
{
$hosts = Host::get();
return view('monitor', [
'hosts' => $hosts
]);
}
public function updatePageVisibility()
{
Cache::put('page_visibility', request('state'));
return 'ok';
}
}
In the code above, we’ve imported the Host model but we haven’t created it yet. This model represents the hosts table in the database. We’re using it to get the list of hosts (remote servers) that are monitored.
Host model
The next thing we need to do is create the Host model:
php artisan make:model Host
That will create an app/Host.php file. Replace its contents with the following. Below, we’re adding an Eloquent relationship to the App\Check model. This allows us to get the system checks associated with a specific host:
<?php
// app/Host.php
namespace App;
use Illuminate\Database\Eloquent\Model;
class Host extends Model
{
public function checks()
{
return $this->hasMany('App\Check');
}
}
Check model
Since we’ve already referenced the Check model earlier, we now need to create it:
php artisan make:model Check
That’s all there is to it. We don’t really need to make any modifications to the boilerplate code. But in case it changes in the future, here’s what it looks like:
<?php
// app/Check.php
namespace App;
use Illuminate\Database\Eloquent\Model;
class Check extends Model
{
}
Index page
At this point we’re now ready to add the HTML code. Create a resources/views/monitor.blade.php file and add the following:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="csrf-token" content="{{ csrf_token() }}">
<title>Live Server Monitor</title>
<script src="{{ asset('js/app.js') }}" defer></script>
<link rel="dns-prefetch" href="//fonts.gstatic.com">
<link href="https://fonts.googleapis.com/css?family=Nunito" rel="stylesheet" type="text/css">
<link href="{{ asset('css/app.css') }}" rel="stylesheet">
</head>
<body>
<div id="app">
<header>
<nav class="navbar navbar-expand-md navbar-light navbar-laravel">
<div class="container">
<a class="navbar-brand" href="{{ url('/') }}">Live Server Monitor</a>
</div>
</nav>
</header>
<main class="py-4 container">
<div class="row">
@forelse ($hosts as $host)
<div class="col">
<div class="card" style="width: 18rem;">
<div class="card-body">
<h5 class="card-title">{{ $host->name }}</h5>
<h6 class="card-subtitle mb-2 text-muted" id="host-{{ $host->id }}">Last updated: {{ minValue($host->checks) }}</h6>
@forelse (onlyEnabled($host->checks) as $check)
<ul class="mt-3">
<li id="check-{{ $check->id }}">
{{ $check->type }}: <span class="{{ $check->type }} {{ numberTextClass($check->type, $check->status, $check->last_run_message) }}">{{ $check->last_run_message }}</span>
</li>
</ul>
@empty
<p class="card-text">No checks yet</p>
@endforelse
</div>
</div>
</div>
@empty
<p>No hosts yet</p>
@endforelse
</div>
</main>
</div>
<script src="{{ asset('js/index.js') }}" defer></script>
</body>
</html>
All we’re doing in the above code is looping through all the $hosts that were supplied by the controller. We’re filtering the checks so that it only returns the one’s which are enabled (enabled=1 in the database) using a helper function (onlyEnabled()) which we’ll be creating shortly. We also have a helper function for outputting a specific class based on the status of the system check. For example, if specific software is running, we want to change the text color to green. If not, then we want it to be red. That’s what the numberTextClass() function does.
Helper functions
Create a helpers.php file inside the app directory and add the following:
// app/helpers.php
function textClass($status, $last_message) {
if ($last_message == 'is running') { // change text color based on the last message
return ($status == 'success') ? 'text-success' : 'text-danger';
}
return ($status == 'failed') ? 'text-danger' : '';
}
function onlyEnabled($collection) { // filter the collection to only the one's which are enabled
return $collection->filter(function($item) {
return $item->enabled == 1;
});
}
function minValue($checks) { // used for returning the oldest last_ran_at date
return min(array_column($checks->toArray(), 'last_ran_at'));
}
function numberTextClass($type, $status, $text) { // change text color based on the threshold value
// these maps to the treshold configs in the config/server-monitor.php`
$configs = [
'diskspace' => 'server-monitor.diskspace_percentage_threshold',
'cpu' => 'server-monitor.cpu_usage_threshold',
'memory' => 'server-monitor.memory_usage_threshold'
];
preg_match('/(\d+)/', $text, $pieces); // get all the numbers in the text
if (!empty($pieces)) {
$number = (float) $pieces[0];
$config = config($configs[$type]);
return ($number >= $config['fail']) ? 'text-danger' : (($number >= $config['warning']) ? 'text-warning' : ''); // determine the class to add based on the current percentage value
}
return textClass($status, $text); // for the one's whose value isn't percentage based
}
Since the class we’ve just added needs to be preloaded on every file, we need to update the composer.json file and tell it to autoload the app/helpers.php file:
{
// ...
"extra": {
// ...
},
"autoload": {
// ...
"classmap": [
// ...
],
"files": ["app/helpers.php"] // add this
},
}
Save the changes then execute the following command to reload the files that need to be autoloaded:
composer dump-autoload
Page scripts
At this point, we can now add the JavaScript code for receiving the events from the backend as well as updating the page visibility.
Open the resources/js/bootstrap.js file and uncomment the following lines. This allows us to subscribe to the channel that we’ve broadcasted on in the backend earlier:
// resources/js/bootstrap.js
import Echo from 'laravel-echo'
window.Pusher = require('pusher-js');
window.Echo = new Echo({
broadcaster: 'pusher',
key: process.env.MIX_PUSHER_APP_KEY,
cluster: process.env.MIX_PUSHER_APP_CLUSTER,
encrypted: true
});
Next, create a resources/js/index.js file and add the following code. The most important code here is the one where we subscribe to the live-monitor channel. Note that the period before the event name (finished.check) is not a typo. We need to put that to instruct Laravel Echo not to prepend the application’s namespace to the event. From there, we just destructure the message and use the different properties of the message object to update the element which displays the data that we need to update:
// resources/js/index.js
// set the CSRF token generated in the page as a header value for all AJAX requests
// https://laravel.com/docs/master/csrf
$.ajaxSetup({
headers: {
'X-CSRF-TOKEN': $('meta[name="csrf-token"]').attr('content')
}
});
window.Visibility = require('visibilityjs'); // import the visibility.js library
// subscribe to the live-monitor channel and listen to the finished.check event
window.Echo.channel('live-monitor')
.listen('.finished.check', (e) => {
const { id, type, last_run_message, element_class, last_update, host_id } = e.message; // destructure the event data
$(`#${id} .${type}`)
.text(last_run_message)
.removeClass('text-success text-danger text-warning')
.addClass(element_class);
$(`#${host_id}`).text(`Last update: ${last_update}`);
});
// next: add code for updating page visibility
Next, add the code for listening to page visibility changes. Make a POST request to update the status in the backend. This effectively stops the notifications from happening if the state value becomes equal to hidden:
Visibility.change(function (e, state) {
$.post('/page-visibility', { state }); // hidden or visible
});
Lastly, update the webpack.mix.js file to include the resources/js/index.js file for minification:
mix.js('resources/js/app.js', 'public/js')
.js('resources/js/index.js', 'public/js') // add this
.sass('resources/sass/app.scss', 'public/css');
Once that’s added, you can now process the frontend scripts and styles:
npm run dev
Adding a remote server
laravel-server-monitor comes with an Artisan utility for adding a host. Execute the following on the terminal to add one:
php artisan server-monitor:add-host
Here’s what adding a host will look like:
You can also do this manually through the database by adding a new entry to the hosts table and adding the checks that you want to the checks table. You can even create your own Artisan command to customize it based on your needs.
Here’s what the checks table looks like. If at some point, you want to disable a specific check that you’ve previously added, you can simply set enabled to 0 or delete the row entirely:
Running the app
Before running the app, you first need to update the .env file with your Pusher app instance credentials:
BROADCAST_DRIVER=pusher
QUEUE_CONNECTION=sync
PUSHER_APP_ID=YOUR_PUSHER_APP_ID
PUSHER_APP_KEY=YOUR_PUSHER_APP_KEY
PUSHER_APP_SECRET=YOUR_PUSHER_APP_SECRET
PUSHER_APP_CLUSTER=YOUR_PUSHER_APP_CLUSTER
MIX_PUSHER_APP_KEY="${PUSHER_APP_KEY}"
MIX_PUSHER_APP_CLUSTER="${PUSHER_APP_CLUSTER}"
Once that’s done, access the app on your browser. For me, I used liveservermonitor.loc as the local domain name.
You can manually trigger a system check using the artisan utility provided by laravel-server-monitor:
php artisan server-monitor:run-checks
Do note that you have to uncomment the line which checks for page visibility in the app/Channels/PusherChannelsChannel.php file for it to work. It wouldn’t really trigger the event if the page is not currently in the foreground:
if (Cache::get('page_visibility') == 'visible') {
// ...
}
Running system checks
The ideal way for us to run the checks is to run them at a specific interval. Laravel already comes with Task Scheduling features. This allows us to run the php artisan server-monitor:run-checks command at a specific interval.
Open the app/Console/Kernel.php file and add the following inside the schedule() function. This will automatically run the command every minute:
protected function schedule(Schedule $schedule)
{
$schedule->command('server-monitor:run-checks')->everyMinute(); // add this
}
This makes use of crontab so you’ll have to enable it by adding the following to your cron entry file (crontab -e):
* * * * * cd /path-to-your-project && php artisan schedule:run >> /dev/null 2>&1
At this point, you should now be able to access the app’s dashboard page and the data displayed would refresh every minute.
Conclusion
That’s it! In this tutorial, we’ve built a web app for monitoring the status of your servers in realtime. We’ve used the Laravel Server Monitor package by Spatie to implement most of the functionality. Then we used Pusher Channels to update the server status displayed on the screen in realtime. Lastly, we used the Visibility.js library to check if a user is currently viewing the page where the server status is displayed.
With this knowledge, you’ll now be able to add your own server checks to constantly monitor your servers during times where you expect more traffic than usual. You can also add custom notifications and have the server send you a text message when the CPU usage goes above the threshold that you’ve set.
You can view the full source code of the app on this GitHub repo.
4 September 2019
by Wern Ancheta