Fly.io converts Docker images to fast-booting VMs and runs them globally. Fly.io supports Laravel! Check us out.
Deploying an app to production may at the first few hours leave a sense of blindness on the state of our application. Questions like—Is every request going through smoothly? Will the servers suddenly run out of resource during some data crunching process?—run rampant like plaque in the back of our minds.
Often, we don’t get any indicator of frightening app-mishaps until we just do. Yikes!
Laravel Pulse is one of the Laravel ecosystem’s exciting new rollouts. It delivers a customizable dashboard of cards providing vital insights on application, queue, and server resource usage, as well as minute details on bottlenecks and exceptions.
Today, we’ll setup Laravel Pulse’s
servers card in order to monitor and display resource usage of the Fly Machines running our Laravel app, and thankfully get visuals we can use to anticipate possible resource-mishaps event. Let’s get to it!
Before anything else, we need our Laravel app deployed to a production environment. That can be quickly arranged by deploying it on Fly.io. This Laravel app should be connected to either a MySQL or Postgres database, as those are the only databases currently supported by Laravel Pulse.
Today we’re focusing on setting up our production application to use Pulse’s
servers card feature. This means the Pulse package should also be installed into our app, with its configurable files made available( config, view, migration ) and its tables set up by publishing its assets and running the database migrations.
Finally, its viewPulse authorization gate should be defined so the route to the pulse dashboard,
/pulse, is accessible even in production. Our definition of this gate would determine whether or not a logged-in user can view the Pulse dashboard.
With all the above are properly accommodated, we should be able to access our Pulse dashboard:
Focusing on the Servers Card
That’s a bunch of cards above! But we only need one today, and that’s Pulse’s servers card. Pulse allows us to customize its dashboard thanks to its publishable view asset. Go ahead and revise it to only include our servers card:
<livewire:pulse.servers cols="full" />
Here’s how our dashboard should finally look like:
Aha! And now, our dashboard’s looking pretty desolate. But, that’s only natural. There’s no data yet for the
servers card to display. We have to first capture entries for this card.
Before capturing data for our card to display, let’s take a detour and look into what this servers card is, and, why should we even care. To do this, we’ll start off at the architecture our Laravel application was deployed in.
See, a Laravel app deployed in Fly.io runs on Fly Machines—Firecracker VMs bootable-stoppable in sub-second speeds. They are fast to spin up, fast to tear down, and can even stop themselves when our app isn’t being used, so we can save the costs of those Machines when they aren’t needed. In fact, we can configure our application to spin up its own Machines with the Machines API, but, that’s a story for another day.
By default, when launching a Laravel app( any app really! ) in Fly.io, two Fly Machines are automatically created and allocated for the app. This is convenient: we have a second Fly Machine as backup and a partner to the first. It can receive requests just like the first one, effectively sharing requests and processing burdens with the first one, and, ultimately, acting as fallback in case the first suddenly becomes unavailable.
Now, how do these two Fly Machines tie back to the
Pulse servers card? We have two Fly Machines running our app, we’d like to get a quick glimpse of each Machine’s resource usage, because how would we know whether one or, even both, are consuming too much memory, CPU power, or running out of storage?
This is exactly where Pulse’s servers card comes into play—to monitor and display Fly Machine resource usage!
Capturing Resource Usage with
Now that we’ve got the “why” setup, it’s time to finalize our setup by capturing data entries for the card.
To capture entries, all we have to do is run
php artisan pulse:check on each Machine running our app( remember, we have two! ) and our resource usage shall be good for recording. Once started, the
pulse:check command perpetually runs and periodically dispatches a SharedBeat event.
The recorder for the
servers card reacts to this event and records memory and CPU usage, and available storage.
pulse:check on a Laravel Fly App
pulse:check command runs perpetually once triggered, we only need to configure our Fly Machines to each trigger it once.
Setting that up is quite easy. See, during the time our app was initialized by Fly.io for deployment ( courtesy of
fly launch ), a Dockerfile was auto-generated. This Dockerfile is used to setup the Fly Machine(s) that run our Laravel app.
This Dockerfile makes use of
supervisor to run our app’s server. Thanks to this, we can use supervisor to handle running our
pulse:check command as well. Simply create a new supervisor config file in the
.fly directory generated by Fly.io, and configure it to run the
/* .fly/pulse-worker.conf */
command=php /var/www/html/artisan pulse:check
Afterwards, update the autogenerated Dockerfile to copy this configuration into the
/etc/supervisor/conf.d directory of our to-be Fly Machine:
/* OTHER PARTS OF DOCKERFILE HERE... */
+ # Setup CRON to update databases
+ COPY etc/pulse-worker.conf /etc/supervisor/conf.d/pulse-worker.conf
With those changes, push the changes to our Laravel Fly App by running
fly deploy. Then behold, finally, a card to display resource usage of Fly Machines running our Laravel App:
Since we have two Fly Machines running our Laravel app, two rows are present above. Notice the first column, these are the IDs of the Fly Machines running our app( each is the name retrieved by
pulse:check from each machine ). The next three columns respectively display the CPU, Memory, and Storage allocations consumed by each Machine during the most recent run of the
In just a few steps, we now have our very own Pulse dashboard, customized to display resource usage of our Fly Machines. All we needed to set up was running the
pulse:check command through a supervisor config file, revise the Dockerfile auto-generated by Fly to include this config file to the configs supervisord would run in the Fly Machines running our app. And just with that, we’ve set up Pulse to capture resource usage for each Fly Machine running our Laravel app!