How to monitor your Laravel application by services (not by hostnames) – Tutorial

Valerio Barbera

Hi, I’m Valerio, software engineer, founder & CTO at Inspector.

I decided to write this post after responding to a support request from a developer who asked me how he can monitor his Laravel application by services and not by hostnames.

The company is working on a backend API for a mobile app. The APIs are running on a set of AWS EC2 instances managed by an Autoscaling Group.

After a thorough investigation into the reason for this request, here is the solution we found.

What is an autoscaling group?

An Autoscaling Group contains a collection of VM instances that are treated as a logical grouping for the purposes of automatic scaling and management of specific component of your system.

In Laravel is quite easy to separate your application in logical components that runs in different servers, like APIs, background Jobs workers, web app, scheduled tasks (cron), etc, so they can scale in and out indipendently based on their specific workload.

Every established cloud provider allwos you to configure Autoscaling Groups, or you can use other technologies like Kubernetes. The result is the same:

Due to the constant turnover of servers to handle the application load dynamically you could see a bit of mess in your monitoring charts. A lot of trendlines turn on and off continuously, one for each underlying server.

Grouping monitoring data by service name

It may be more clear to use a human friendly service name to represent all your servers inside the same Autoscaling Group.

Since transactions in Inspector are grouped by the hostname, we can use the Inspector library to “artificially” change it just before the transaction is sent out of your application to make your dashboard more clear and understandable.

In the boot method of the AppServiceProvider you can use beforeFlush() to add a callback that simply change the hostname of the transaction, assigning a general service name (rest-api, workers, web-app, etc) instead of the original hostname of the server.

<?php

namespace App\Providers;

use App\Jobs\ExampleJob;
use Illuminate\Support\ServiceProvider;
use Inspector\Laravel\Facades\Inspector;

class AppServiceProvider extends ServiceProvider
{
    /**
     * Register any application services.
     *
     * @return void
     */
    public function register()
    {
        //
    }

    /**
     * Bootstrap any application services.
     *
     * @return void
     */
    public function boot()
    {
        Inspector::beforeFlush(function ($inspector) {
            $inspector->currentTransaction()
                ->host
                // You can get the desired service_name by config, env, etc.
                ->hostname = config('app.service_name')
        });
    }
}

You can control what service name should be used in each part of your system through the deployment process by using environment variables.

The app.service_name configuration property could be setup as below:

<?php

// config/app.php file

return [

    'service_name' => env('INSPECTOR_SERVICE_NAME', 'rest_api'),

];

Along the deployment pipeline you can inject a different “INSPECTOR_SERVICE_NAME” for each autoscaling group.

Your dashboard will chage from this:

Application load by hostnames

To this:

Application load by services

I think it looks more clear, and it is what our customer think too 😃!

The number of servers is no longer visible, but you could gather this information from your cloud console.

Use filters to eliminate noise

Thanks to the transactions filtering it’s even more easy to identify the most heaviest tasks in each Autoscaling Group, so you can optimize their performance and cut the costs due to the high number of tasks perfomed before the Autoscaling Group need to start a new server.

Transactions list

Conclusion

Thanks to its purely software library Inspector could be the right choice for developers that love to stay focused on coding instead of infrastructure management.

You will never have the need to install things at the server level or make complex configuration in your cloud infrastructure to monitor your application in real-time.

Inspector works with a lightweight software library that you can install in your application like any other dependencies. Try the Laravel package, it’s free.

Visit our website for more details: https://inspector.dev/laravel/

Related Posts

How to configure HTTPS in Laravel Homestead

How to enable HTTPS in Laravel Homestead

Hi, I’m Valerio Barbera, software engineer, founder and CTO at Inspector. In this article I’ll show you how to enable HTTPS for your local applications served by Homestead. I met this need because I am working to implement browser notifications for Inspector using Pusher/Beams. But Beams requires that the application be necessarily served over HTTPS.

Laravel cron scheduling and its secrets

Hi, I’m Valerio Barbera, software engineer, founder and CTO at Inspector. Laravel tasks scheduling is one of the most useful features of the framework.The official documentation clearly explains what it is for: In the past, you may have written a cron configuration entry for each task you needed to schedule on your server. However, this

Laravel validation and custom rules in Inspector

Hi, I’m Valerio Barbera, software engineer, founder and CTO at Inspector. Data validation is one of the fundamental features in any application and it is something developers manipulate almost every day. The value a software provides to users is often a function of the quality of data it is able to manage. Laravel ships with

How to build scalable applications

Read the best news, tips and other direct in your inbox