[LogstashFormatter] ECS support

[rneuter]

👋

I was wondering if Elastic Common Schema will be supported in the future.

For example, in the ECS, the host field should be an object but is set as a scalar string in the LogstashFormatter.

Since version 8 of the ELK stack, ECS is enabled by default on a new installation causing ingestion errors:

Log sent to Logstash from a classic Symfony / Monolog:

{
    "@timestamp": "2022-11-01T15:12:00.252242+00:00",
    "@version": 1,
    "host": "7f50b1b63228",
    "message": "Authenticator successful!",
    "type": "app",
    "channel": "security",
    "level": "INFO",
    "monolog_level": 200,
    "context": {
        "token": {
            "Lexik\\Bundle\\JWTAuthenticationBundle\\Security\\Authenticator\\Token\\JWTPostAuthenticationToken": "JWTPostAuthenticationToken(user=\"x.com\", authenticated=true, roles=\"ROLE_USER\")"
        },
        "authenticator": "Lexik\\Bundle\\JWTAuthenticationBundle\\Security\\Authenticator\\JWTAuthenticator"
    }
}

Logstash response:

{
    "error": {
        "type": "mapper_parsing_exception",
        "reason": "object mapping for [host] tried to parse field [host] as object, but found a concrete value"
    }
}

Support of ECS will bring breaking changes but definitely avoid extra setup time on new installations, which should increase time after time.

I'm not sure of how many fields are concerned but from what I see maybe it's only the host field.

Let me know if you are interested about feedback or to discuss on this!

[Seldaek]

I guess this could be a configurable flag on LogstashFormatter so one can enable ECS support, and maybe a deprecation warning if not enabled so people are nudged to migrate slowly and in monolog 4 we can enable by default?

[Seldaek]

In any case PR welcome, I don't have access to an ECS stack so rather have someone knowledgeable do this.

[vivere-dally]

I think renaming to hostname instead of host would be sufficent