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

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.

Otherwise logs might not show up in Kibana until hours later, in my case after 2 hours since I am gmt+2

Before: 2020-09-01T19:43:37.000000Z After: 2020-09-01T19:43:37.000000+02:00

Fixes out of date links in the readme and links to the new Elastic.co documentation.

For https://github.com/elastic/ecs-logging-php/issues/20.

~This PR is currently blocked by https://github.com/elastic/docs/pull/2055.~

What

Update docs with the contributing guideline. Add release guideline. Enable release automation when a tag release is created with the format d+.\d+.\d+ Release automation:

• will create a release in github matching the tag.
• will create a changelog using the gren app, filtering only the Pull Requests with certain labels:
  • "Breaking changes" category for all the PRs with the breaking label.
  • "Bug fixes" category for all the PRs with the bug or fix labels.
  • "Features" category for all the PRs with the enhancement, feature or feat labels.

Actions

• [x] Validate scripts locally

How to run locally

$ GITHUB_TOKEN=${GREN_GITHUB_TOKEN} TAG_NAME=1.0.2 make -f .ci/Makefile release

Output

Getting gren config from local file /app/.ci/.grenrc.js

🤖  - Generate release notes:
===================================
✔ Releases found: 3
✔ Tags found: 1.0.2
✔ Pull Requests found: 13
✔ 1.0.2 has been successfully created!
See the results here: https://github.com/elastic/ecs-logging-php/releases/tag/1.0.2

Tests

What does this PR do?

Use https://github.com/elastic/apm-pipeline-library/blob/master/vars/obltGitHubComments.txt

Why is it important?

Avoid hardcoded strings and easy to normalise the GitHub comments in all the oblt projects

You can also see in the GitHub comment that there is a specific section for some of those GitHub comments called 🤖 GitHub comments

• [x] Fixed incorrect use of log.origin for error (log.origin should refer to location of log statement not where error was thrown)
• [x] Added support for 'extra' info. This allows to support Monolog processors such as TagProcessor.
• [x] Added support for log.origin. This allows to support Monolog IntrospectionProcessor.

To do

• [x] Move docs to asciidoc https://github.com/elastic/ecs-logging-php/pull/18
• [x] Open PR in elastic/docs to add to the build https://github.com/elastic/docs/pull/2055
• [x] Open infra ticket to add the elasticsearch/ci docs check to this repo (see link in timeline below)
• [x] Add the elasticsearch/ci docs webhook to the repo
• [x] Remove content from readme and link to published docs https://github.com/elastic/ecs-logging-php/pull/21
• [x] Link to new docs from ecs-logging https://github.com/elastic/ecs-logging/pull/53

• Moved ElasticCommonSchemaFormatter from Elastic\Monolog\v2\Formatter back to Elastic\Monolog\Formatter
  • To keep backward compatible with already released elastic/ecs-logging 1.0.1
  • For more seamless future support of both Monolog v1 and v2
• To make output compatible with the latest ECS logging spec
  • Extracted log.level from log
  • Reordered fields
  • Added ecs.version

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

I guess, we might need to fix the shared library to ensure the env variable is passed otherwise:

18:06:28  + python -
18:06:28  + curl https://pre-commit.com/install-local.py
18:06:28    % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
18:06:28                                   Dload  Upload   Total   Spent    Left  Speed
18:06:28  
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100  2590  100  2590    0     0  11511      0 --:--:-- --:--:-- --:--:-- 11511
18:06:28  Traceback (most recent call last):
18:06:28    File "<stdin>", line 103, in <module>
18:06:28    File "<stdin>", line 64, in main
18:06:28    File "/usr/lib/python2.7/UserDict.py", line 40, in __getitem__
18:06:28      raise KeyError(key)
18:06:28  KeyError: u'HOME'

Summary

Migrate Jenkinsfile to GH Actions Workflow

Tasks

• [ ] Migrate Jenkinsfile
• [ ] Delete Jenkins Job config
• [ ] Delete Jenkins Job
• [ ] Update sheet

This update fixes an issue working with monolog 2.5 and above, where the IntrospectionProcessor added a callType field to its output. Since the ElasticCommonSchemaFormatter does not know about this field, it gets added as a top level key instead of within log.origin even when $useLogOriginFromContext is set. This can be demonstrated by simply checking out the main branch of this repo and running composer install && composer test.

This fixes the issue by adding callType to the list of known origin keys and also uses it (if available, so will still work with monolog < 2.5) within the log.origin.function field. E.g. MyClass::myFunction or MyClass->myFunction.

As a minor additional change it also marks compatibility with psr/log 2.x and 3.x.

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.

Now is ECS_VERSION is const, but I need to set version 1.5.0, easiest way is via constructor like this. My version is backward compatible.

Usage in Laravel:

class EcsFormatter
{
    public function __invoke($logger)
    {
        foreach ($logger->getHandlers() as $handler) {
            $handler->setFormatter(new ElasticCommonSchemaFormatter([], '1.5.0'));
        }
    }
}

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