Problems logging to php://stdout

[vacri]

Hi folks,

We're running a Directus 8.6.2 container in AWS ECS, with logs being shipped via STDOUT/Docker Logs to AWS Logs. We're using our own container with nginx/php7.3-fpm rather than the official container. I've explicitly turned off env var configuration, as we want to use the multiple API config files feature of v8.

The problem is that application logs are still being written to disk rather than sent to stdout, and I can't figure out why. In my test setup, I only have one config file (api.php) and only one Directus env var (turning off env-based config), and I still can't make it work.

This is what I can see from inside the docker container in the cloud

root@cdb4ea2ac581:/var/www/app# printenv | grep DIRECTUS
DIRECTUS_USE_ENV=0

root@cdb4ea2ac581:/var/www/app# head config/api.php 
<?php
return [

    'env' => 'production',          // production, development, or staging
                                    // Production silences stack traces and error details in API output

    'logger' => [
        //'path' => '../logs',       // Where to save warning and error logs for the API
        'path' => 'php://stdout',
    ],

root@cdb4ea2ac581:/var/www/app# ls -l logs
total 4
-rw-r--r-- 1 www-data www-data 2110 May 27 05:40 error.2020-05-27.log

So despite env var config being disabled and logger.path being set to php://stdout, the errors are still being written to disk (and are not appearing in our central logging).

The documentation is pretty slim on the config file, and I couldn't find much documentation around logging config. If I switch the DIRECTUS_USE_ENV to 1, the container predictably crashes since there are no other Directus env vars.

Is there something I'm not doing right here? Something I've missed?

[benhaynes]

Any thoughts @WoLfulus ?

[WoLfulus]

I'm unsure about this one.

All of the output is going to the log file? Or some of them are going to the stdout stream?

[vacri]

All of the application output is going to the logfile. We have nginx and php-fpm logs going to stdout, which are appearing as expected in docker logs. Also, as far as I'm aware, our devs do not alter any of the Directus core files.

Gist of the files we use to create the image - maybe something will pop out?

Hrm, actually, looking at our base php image, we're missing the required php libs fileinfo and pdo. Curious, we've been running for almost a year on several installs with this setup and not had a problem that exposed this. I'll try again with these deps enabled.

[vacri]

That was red herring, the container has those mods installed, just not as separate php packages (I was just skimming the apt install list in the Dockerfile).

Does anything in the gist pop out as wrong to you?

[vacri]

Came back to this problem and figured it out.

The logger only sets up the stream output if there is a loadable config. I was generating error loglines by going to a bad URL /foo. If I had been doing something under /api/foo, the loglines would have shown up, as my config file is api.php. So we're in the situation where the loglines go to STDOUT if the error happens as part of a project, but to the default logfile location if they're not.

The workflow in the code is

1. set up a default logfile location as log $path
2. load the config
3. if there's logger.path in the config, set the log $path to that
4. test if it's a stream (the default location is not a stream)
5. continue setting up the log handler; party time

If there's no project to indicate which config file to use, then there's no config file to load, so there's no logger.path available, and the system never overrides the default path. The workflow above fails to load a config at step 2) when I generate a logline using a url like /foo, so the logger gets set to the default filesystem location and doesn't stream to STDOUT

This looks like what @WoLfulus might have been getting at with the question about the possible split in log destinations. I'm not quite sure the best way forward - might just change the hardcoded default location.