A Better Way to Monitor Your Laravel Services

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

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

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

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.

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.

You can separate your application into logical components like APIs, background workers, web app, scheduled tasks (cron), etc, so they can scale in and out independently based on their specific workload.

Every established cloud provider allows 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, one for each underlying server.

Grouping Monitoring Data by Service Name

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

Using the beforeFlush() method, you can group your monitoring data by services (API, workers, web app, etc) instead of by hostnames:

<?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')??'rest-api'
        });
    }
}

Your dashboard will change from this:

to this:

I think it looks clearer, and this is what our customer think too 😃!

The number of servers that are being used to support the workload is not visible, but in theory you might be more interested in getting this information from your cloud console.

Inspector can help you optimize the total number of tasks performed before a new server is needed in the Autoscaling Group, and thanks to the transactions filtering you can also immediately identify the heaviest tasks in each Autoscaling Group.

Conclusion

Thanks to its software library Inspector is perfect for developers that need to stay focused on code execution monitoring instead of infrastructure management.

Thanks to Inspector, 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. In case of Laravel you can use our Laravel package.

First Published here