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

Valerio Barbera

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 in logical components like APIs, bacground 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, 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 (rest-api, workers, web-app, etc) instead 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 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 that are being used to support the workload is not visible, but in theory you might be most interested in getting this information from your cloud console.

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

Transactions list

Conclusion

Thanks to its purely 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.

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

Related Posts

How code-driven monitoring tools can help you deliver successful software products

Hi, I’m Valerio, software engineer, founder & CTO at Inspector. In this article I would like to share my experience with you about why software developers should always prefer code-driven instead of infrastructure-driven monitoring tools.  Understanding their different approaches can help you better organize your team, stay agile and fast during delivery times, and quickly

How to prevent users from registering into your app with insecure passwords

Hi, I’m Valerio, software engineer and CTO at Inspector. About one year ago one of our accounts on an external platform has been hacked. Our credit card was attached to this account so we had to warn the bank to block it. Fortunately, there were no consequences, neither for our bank account, nor for our

Is it better to BUILD an internal monitoring environment, or BUY a prepackaged solution?

“Build vs Buy” Bake-off: Which should you choose? Every case is different, and all of these factors should be considered carefully before making a decision. There are situations where building a solution makes sense, either because you have the time, your requirements aren’t very complex, or if your applications simply don’t have enough load to