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

Valerio Barbera
inspector monitoring hostnames

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.

Inspector segments metrics by hostnames. So as the number of underlying hosts increase it could create a bit of clutter in the charts.

Here is the solution.

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 logical group.

We can use the Inspector library to programmatically change the hostname just before the transaction is sent out of your server and set the same for related server. It will make your dashboard more clear and understandable.

inspector server load monitoring

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

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 pass the name of the service that should be used during transaction monitoring by using an environment variable. Environment variables can be set accordingly in your CI/CD pipeline.

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

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. 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

Autofix your Laravel application for free

Inspector is a Code Execution Monitoring tool specifically designed for software developers. You don’t need to install anything on the infrastructure, just install the Laravel package and you are ready to go.

If you are looking for effective automation, and the ability to automatically receive code change proposals to fix application errors try Inspector for free. Register your account.

Or learn more on the website: https://inspector.dev

Related Posts

Laravel Http Client Overview and Monitoring

Laravel HTTP client was introduced starting from version 10 of the framework, and then also made available in all previous versions. It stands out as a powerful tool for making HTTP requests and handling responses from external services. This article will delve into the technical foundations of the Laravel HTTP client, its motivations, and how

Laravel Form Request and Data Validation Tutorial

In this article I will talk about Laravel Form Request to send data from your application frontend to the backend. In web applications, data is usually sent via HTML forms: the data entered by the user into the browser is sent to the server and stored in the database eventually. Laravel makes it extremely simple

Upload File in Laravel

You can upload file in Laravel using its beautiful unified API to interact with many different types of storage systems, from local disk to remote object storage like S3. As many other Laravel components you can interact with the application filesystem through the Storage Facade: Illuminate/Support/Facades/Storage This class allows you to access storage drivers called