How to monitor your Laravel application by services not by hostnames
Tags: monitoring, laravel, devops, aws
Published: 2021-11-25 16:10:11

Hi, I'm Valerio, software engineer, founder & CTO at [Inspector](https://www.inspector.dev).

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
<?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:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/b7vcyqadibydbbh1g9hm.png)

To this:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cchxh7ens3933be95eii.png)

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.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4w7srp21eegdxvxw7eg3.png)

## 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](https://github.com/inspector-apm/inspector-laravel).

Visit our website for more details: [https://inspector.dev/laravel/](https://inspector.dev/laravel/)