Forem: Jonas Siewertsen

Laravel logging: Show correct severity levels on the Google Cloud Platform

Jonas Siewertsen — Sun, 05 Feb 2023 20:00:00 +0000

Let's get right to the point: If you're running a containerized Laravel application on the Google Cloud platform, you can use stderr as your log channel. See on GitHub.

That does work, but every log entry will be shown with the same severity level. Depending on your setup, all log entries will either be shown as default or error.
All the information is there, but you can't filter for severity levels, which is not what you want and makes it hard to spot important error messages or does make it harder to monitor them.

See the example below. Can you spot errors or critical logs?

Why not the official PHP Google logging Package?

The Official PHP Package from Google does work and will ensure severity levels are set correctly.

That package does send all logs via HTTP, which is a little less unstable than logging via stderr on Unix systems.

The package can also send your logs via gRPC, but to enable gRPC support, you need to install the gRPC extension through PECL.

Don't get me wrong: it's a great package, but we wanted to keep dependencies as low as possible.

Why are all logs shown with the same severity level?

This topic is more complex, as there might be different reasons, depending on your setup.

In the end, Google Cloud can't interpret the severity levels correctly. To fix that, we can send plain JSON via stderr or stdout and Google Cloud Logging will parse that information.

An example payload that Google can work with

{
  "severity": "ERROR",
  "message": "There was an error in the application."
}

You can read more about it in the Google Docs.

How to normalize all logs into JSON?

Laravel (and many other frameworks) use the Monolog Package for logging by default. Using their formatter does everything you need!

Monolog is your friend

Instead of only sending the error message, we'll send the logs as JSON with some extra information so the Google Cloud Logging can parse your information correctly.

Logs before formatting.

Enable the correct formatter from Monolog.

Monolog offers a GoogleCloudLoggingFormatter by default. Let's enable it in the config.

The default stderr settings inside config/logging.php:

'stderr' => [
    'driver' => 'monolog',
    'level' => env('LOG_LEVEL', 'debug'),
    'handler' => StreamHandler::class,
    'formatter' => env('LOG_STDERR_FORMATTER'),
    'with' => [
        'stream' => 'php://stderr',
    ],
],

Define the Monolog formatter:

'stderr' => [
    'driver' => 'monolog',
    'level' => env('LOG_LEVEL', 'debug'),
    'handler' => StreamHandler::class,
    'formatter' => \Monolog\Formatter\GoogleCloudLoggingFormatter::class,
    'with' => [
        'stream' => 'php://stderr',
    ],
],

That's it. You can also set it via the env variable if you prefer that.

LOG_STDERR_FORMATTER=\Monolog\Formatter\GoogleCloudLoggingFormatter::class

Write your own and custom formatter.

The GoogleCloudLoggingFormatter has been added in the Monolog versions 2.8.0 and 3.2.0.

If your version is older than that or you need to customize it, you can write your own custom formatter.

Your custom formatter might look like this (See here)

<?php

namespace App\Support;

use DateTimeInterface;

class GoogleCloudLoggingFormatter extends \Monolog\Formatter\JsonFormatter
{
    public function format(array $record): string
    {
        // Re-key level for GCP logging
        $record['severity'] = $record['level_name'];
        $record['timestamp'] = $record['datetime']->format(DateTimeInterface::RFC3339_EXTENDED);

        // Remove keys that are not used by GCP
        unset($record['level'], $record['level_name'], $record['datetime']);

        return parent::format($record);
    }
}

As a last step, you need to define that class inside config/logging.php.

'stderr' => [
    'driver' => 'monolog',
    'level' => env('LOG_LEVEL', 'debug'),
    'handler' => StreamHandler::class,
    'formatter' => \App\Support\GoogleCloudLoggingFormatter::class,
    'with' => [
        'stream' => 'php://stderr',
    ],
],

This is what correct formatted logs look like

Isn't that beautiful? Even without further dependencies besides Monolog.

Credits

Photo by Etienne Girardet on Unsplash

Published at https://jonassiewertsen.com/blog/laravel-logging-show-correct-severity-levels-on-the-google-cloud-platform

Why to use »npm ci« instead of »npm install«

Jonas Siewertsen — Wed, 28 Apr 2021 15:02:14 +0000

We had some problems with our pipelines/actions lately, which could easily be resolved by using npm ci instead of npm install.

The short version

Use npm install to update and install your dependencies.
Use npm ci to only install your dependencies.

Always use npm ci in your pipelines/actions, never npm install.

Don’t compare it with composer

Personally, I do have a strong PHP background and am using composer as PHP’s Package dependency manager on a daily basis.

One of the first things you would learn about composer, is the difference between the install and update command:
composer update will read your composer.json, update all dependencies, write those in your composer.lock file and install them afterwards.

In case you only want to install your packages as locked in your composer.lock file, use composer install instead. This will ensure, that your production environment uses the same dependency versions.

That does make sense, right? This is what we want to use in our pipelines or actions (depending which kind of CI/CD you are using). This does make sure to not auto-update dependencies when deploying. Maybe some updated ones might break something.

Let’s transfer this knowledge to npm

Do we agree, that we want to update dependencies locally, lock those dependencies in our lock-file and only want to install those dependencies as we did lock them?

This does avoid any auto-update which might break something in you application. That’s the exact reason, composer install is being widely used in all production pipelines that I have seen.

`npm install` does work in a different way than `composer install`

This is the key element to understand! Those commands are not the same. Let me explain:

Unlike composer install, npm install will update your dependencies before installing. This isn’t logical at all when you have a PHP background, but it’s important to understand and you need to deal with it.

Running npm install or npm update are nearly the same and will update your package-lock.json, which is what you want to avoid in production.

If you want the same functionality as composer install, use npm ci.

Use `npm ci` if you don’t want to update

npm ci will parse your package-lock.json, won’t do any updates and install those packages.

This is exactly the same as using composer install in the PHP world.

Please update your Pipeline or Actions

If you do use any kind of Pipelines or Actions, make sure to use npm ci, to avoid any problems.

This will avoid merge conflicts. Just in case: Yes, you should version control your package-lock.json file, so every developer working with your project will use the same dependencies as you do and as your production environment does.

Besides this and other occurring problems, it will make your pipelines and actions faster, as npm ci will be finished in less time than install.

I hope this was helpful.

Cover image by https://unsplash.com/@romanenko29061983