Facebook’s Prineville Data Server Center

Creating PULSE — A developer-friendly server monitoring tool (Part 8)

Matt Kingshott
Jan 9, 2019 · 4 min read

This is part of a weekly development blog series, where I will document the creation of an application from the initial idea through to its deployment on a scalable architecture. Even as an experienced developer, I find these stories to be interesting and I usually pick up a tip or two, so if you’d like to come along, and hopefully benefit in some way, let’s dig in!

NOTICE: Pulse has now launched and is available to use. You can create an account by visiting https://pulse.alphametric.co


Keeping things organized

I was recently discussing Pulse with another developer who runs a number of servers and he mentioned that a critical need for him, and likely many other developers running anything more than a minimal infrastructure, would be the ability to group servers according to some principle.

You might choose to categorise your servers in a number of ways:

  1. Around an application. This would be the case for Pulse itself as most of its components (database, cache, queues) will be assigned their own server.
  2. Around a client. Suppose you’re a web agency and you’ve built a number of apps for a company. These apps might sit on different servers, but they have one thing in common, the same client.
  3. Around a location. If you operate servers in multiple data centres, it might be useful to organise them into groups based upon where their data centre is located e.g. Europe, North America etc.
  4. Around a cycle. You might choose to operate servers for development, testing, staging, and finally, production itself.

Introducing Clusters

Regardless of the reasoning behind how you organise your infrastructure, the means of physically doing so in Pulse is the same. You create a new cluster and then add as many servers to it as you wish.

A test cluster containing four servers

Within the cluster page you can quickly see the overall status of the cluster at the time the page was rendered, as well as add more servers or remove existing ones by clicking the trash can icon on the server cards.

Pulse also features a top level cluster management page allowing at-a-glance insight into the organisation and status of your infrastructure.

The cluster management page

Now, let’s take a look at a couple of the coding steps I took along the way…


Creating the necessary relationships

Compared to the existing feature set of Pulse, adding Clusters into the mix was a fairly straightforward process.

It required two additional database tables, Clusters and Nodes. Nodes is simply a pivot table connecting Clusters to Servers.

Next, I wanted the ability to reach the servers directly from the cluster model and not have to use the intermediate table. Fortunately, I discovered that Laravel provides this functionality with the hasManyThrough relationship:

Connecting a cluster to its servers

The column references can be a little confusing, so I advise checking out the documentation for the hasManyThrough relationship.

Personally, I was surprised that I hadn’t discovered this feature earlier, but I know I’ll use it a lot more going forward. It seems that thinks of everything when it comes Laravel!


Checking for data absence

I’m a huge fan of using Form Requests to handle validation and authorization logic in my applications. My thinking is, that by the time I reach the code in my controller method, I should have taken all the necessary steps to be able to trust whatever user-supplied data I’m working with.

To this end, if I find myself needing additional validation logic, I often prefer to write a custom validation rule / class rather than clutter up my controller with further data checks. Clusters was a perfect example of this.

While Laravel includes a database exists rule, I needed the inverse. I had to know that the record did not exist, so I created it and named it absent.

The absent in database validation rule

All that was left to do, was register the class in my AppServiceProvider and include a key / value in the /resources/lang/en/validation.php

This rule is now used to prevent a user from adding a server to a cluster more than once. In other words, it prevents any duplication.


Wrapping Up

Well, that’s it for this week. Next up, we’ll be taking a look at the API features that Pulse will provide. These allow you to build your own dashboard on top of the logging data collected by Pulse, as well automate the creation of a server monitoring profile / downloading of the associated shell script. This permits you to configure a server entirely through your own code.

All that is coming in next week’s article. In the mean time, be sure to follow me here on Medium, and also on Twitter for more frequent updates.

NOTICE: Pulse has now launched and is available to use. You can create an account by visiting https://pulse.alphametric.co

Thanks, and happy coding!

Matt Kingshott

Written by

Senior developer at @alphametric_co. Generally working with PHP / Laravel / Vue. Open source fanatic.

More From Medium

Also tagged JavaScript

Also tagged Linux

Top on Medium

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade