At this moment we are using a custom implementation of this library which was not production ready at that point.

To make things easy there we just moved array keys from the "extra" field of monolog to the root level if the first key matches the ecs schema. This is of course not an ideal situation.

I now notice we have added some types in this lib. Isnt it better if we just fully type the full ecs schema?

So this means we create a class for each root type of the schema where people can easily inject it as well. The types would be fully optional where imo you never want to restrict what you log too much (only the how).

Is this the way to go? If yes i do not mind giving it a shot so we can have a proper way to log in a valid schema format.

PHP message: PHP Notice: Undefined property: Elastic\\Monolog\\Formatter\\ElasticCommonSchemaFormatter::$maxNormalizeDepth in /var/www/vendor/elastic/ecs-logging/src/Elastic/Monolog/Formatter/ElasticCommonSchemaFormatter.php on line 60

PHP 7.4.18 (cli) (built: May 3 2021 12:02:44) ( NTS ) Copyright (c) The PHP Group Zend Engine v3.4.0, Copyright (c) Zend Technologies with Zend OPcache v7.4.18, Copyright (c), by Zend Technologies

Hi,

The composer require elastic/ecs-logging command generates this:

Using version ^1.0 for elastic/ecs-logging
./composer.json has been updated
Running composer update elastic/ecs-logging
Loading composer repositories with package information
Updating dependencies                                 
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - elastic/ecs-logging[1.0.0, ..., 1.0.2] require php ^7.2 -> your php version (8.0.9) does not satisfy that requirement.
    - elastic/ecs-logging 1.0.3 requires psr/log ^1.0.1 -> found psr/log[1.0.1, ..., 1.1.4] but the package is fixed to 2.0.0 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
    - Root composer.json requires elastic/ecs-logging ^1.0 -> satisfiable by elastic/ecs-logging[1.0.0, 1.0.1, 1.0.2, 1.0.3].

Can you update the psr/log dependency in composer.json to "psr/log": "^1.1 || ^2.0" ?

Regards,
Csongor.

I'm not sure how these files could be missing, but I've tried both in my main project and a default empty composer init project, and once installed, the only actual file present under src is src/Elastic/Monolog/Formatter/ElasticCommonSchemaFormatter.php.

src/Elastic/Types does not exist.

Reproduction:

mkdir emptyproject && cd emptyproject
composer init
[... hit enter to accept all defaults ...]
composer require elastic/ecs-logging
ls -la vendor/elastic/ecs-logging/src/Elastic/Monolog # exists
ls -la vendor/elastic/ecs-logging/src/Elastic/Types # does not exist

Do you get the same result?

@philkra how are we going to handle multiple versions of frameworks? Since i see you included them in the dev deps. But installing multiple majors there will be a problem.

How will we handle that? I guess we should mock them instead instead of putting them as dev dependency isnt it?

The readme lists support for monolog v2 but the latest version on packagist (elastic/ecs-logging) is an older version (1.0.1) that is not synced up with the instructions in this repo.

Maybe release an alpha/beta so its less confusing? right now it's not clear you will have to pull the repo using "dev-master'

Would be nice if we could use ECS with Monolog\Handler\ElasticsearchHandler to send the logs directly to elastic search

Unfortunately it now throws with Uncaught InvalidArgumentException: ElasticsearchHandler is only compatible with ElasticsearchFormatter.

Hi guys , would you please point some working examples for this library ?
Is it possible to post resulting json into elastic search api ? how to do ?
Is there a method list ? how can I add my custom fields ?

Thanks!!!

Hey there! 👋 Please correct me if I'm mistaken, but I noticed this package is marked as being a provider of psr/log-implementation (PSR-3), but it does not appear to implement the interface anywhere. It shouldn't be marked as a provider of a PSR implementation if it does not provide said implementation. 😄

Remove the dots (.) of the each key in the labels field as ES is storing the values as nested in such scenarios, but that would violate the mapping schema. Hence, we need to flatten the keys by replacing each . with a _.

Could you add support for PHP 8?

$ composer require elastic/ecs-logging 
                                                                                                                           
[InvalidArgumentException]                                                                                                 
Package elastic/ecs-logging has a PHP requirement incompatible with your PHP version, PHP extensions and Composer version 

$ php -v
PHP 8.0.3 (cli) (built: Mar  5 2021 07:54:30) ( NTS )

$ composer -V
Composer version 2.0.12 2021-04-01 10:14:59

Hi,
I'm curious. Reading through source code to figure out why data that I am inserting via processors (e.g. MonoLog WebProcessor) is not being displayed by your formatter, I see that you are completely ignoring the extras array member of the Monolog record structure, and instead relying on data being in the context member of the record. This appears to be somewhat counter-intuitive to the way that Monolog normally works.

Is this purposeful, or just an unhandled scenario at the present time?

use \Codeception\Test\Unit as UnitTest;
use Elastic\Monolog\Formatter\ElasticCommonSchemaFormatter;
use Monolog\Handler\TestHandler;
use Monolog\Logger;
use Monolog\Processor\WebProcessor;

class ECSFormatterTest extends UnitTest
{
    /**
     * Logger
     */
    protected $sut;
    /**
     * @var TestHandler
     */
    protected $handler;

    public function testECSFormatIsSupported()
    {
        $this->sut->error('Test Message', ['func' => __FUNCTION__]);
        $record = $this->handler->getRecords()[0]['formatted'];
        var_dump($record);exit;
    }

    protected function setUp(): void
    {
        $this->handler = new TestHandler();
        $formatter = new ElasticCommonSchemaFormatter();
        $this->handler->setFormatter($formatter);
        //mock a web server
        $serverData = [
            'REQUEST_URI' => '/test',
            'REMOTE_ADDR' => '127.0.0.1',
            'REQUEST_METHOD' => 'GET',
            'SERVER_NAME' => 'zinc.test',
            'HTTP_REFERER' => 'http://zinc.test',
        ];
        $this->sut = new Logger('test', [$this->handler], [new WebProcessor($serverData)]);

    }
}

At the very least I would expect the data that gets injected into extras to get into the output format labels node, as the func item does in the above test snippet. Ideally I would see 'REMOTE_ADDR' being injected to source.ip in the output.

To do

• Move docs to asciidoc #18
• Open PR in elastic/docs to add to the build elastic/docs#2055
• Open infra ticket to add the elasticsearch/ci docs check to this repo (see link in timeline below)
• Add the elasticsearch/ci docs webhook to the repo
• Remove content from readme and link to published docs #21
• Link to new docs from ecs-logging elastic/ecs-logging#53