Logstash 8 grok is resolving host.name as host.hostname

Elastic Stack Logstash
1

Hi all, I'm currently working on migrating from Logstash 7.x to logstash 8.x and it's being a bit trippy. We already used ECS so supposedly it should be straight forward, but I'm experiencing some weird errors with grok. The main one is that for some reason, in the grok filters used to assign "[host][name]", instead it assigns "[host][hostname]".

Another weird thing is that if I parse a field "[host][name]" already filled, it will autofill "[host][hostname]" automatically with what I suppose is the docker hostname. I'm guessing this is a thing in Logstash 8, but I haven't found any note regarding that...

Anyway, could somebody help me figure out the problem with the grok filters that no longer do what they are supposed to do?

2

Hello,

What are the inputs, filters you are using?

Logstash will not parse anything per default, but some input/filters may populate fields according to ecs.

Please share an example of your pipeline and the message you are receiving.

3

Are you saying that this autofill of [host][hostname] happens in logstash (i.e. a file or stdout output shows it has happened) or are you saying that the events in elasticsearch show that autofill has occurred? If the latter then I would suggest you also look at any ingest pipelines in elasticsearch that might be transforming the documents.

4

Here's an example:

if [event][dataset] == "system.syslog" {
        grok {
            match => {
                "message" => [
                # type=USER_START msg=audit(1404170401.294:157): user pid=29228 uid=0 auid=0 ses=7972 subj=system_u:system_r:crond_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct="root" exe="/usr/sbin/crond" hostname=? addr=? terminal=cron res=success'
                "type=%{NOTSPACE:[audit][type]} msg=audit\(%{NOTSPACE:[audit][epoch]}\): %{NOTSPACE:[audit][action]} pid=%{NOTSPACE:[process][pid]} uid=%{NOTSPACE:[audit][uid]:int} auid=%{NOTSPACE:[audit][auid]:int} ses=%{NOTSPACE:[audit][ses]:int} subj=%{NOTSPACE:[audit][subject]} msg=%{GREEDYDATA:message}",
                "%{SYSLOGBASE} %{GREEDYDATA:message}",
                "%{SYSLOGBASE2}",
                "%{SYSLOGPAMSESSION}"
                ]
            }
            overwrite => ["message", "[host][name]", "[host][hostname]"]
        }

And this is the event:

Jun 24 04:44:01 host-staging-01.test CROND[7276]: (root) CMD (/opt/test/bin/test-time-tester.py -t 10 -e 300 -s europe.pool.ntp.org)

Also because of some other tests I have, I am already parsing "[host][name] = host.test".

When I run logstash with these bits, I end up getting host.name = host.test and host.hostname = host-staging-01.test

Which shouldn't happen due to the overwrite... But I also have the same issue when I don't initially parse the host.name, it only populates host.hostname.

5

It only happens in logstash, it might be because I'm running tests on the docker version of the logstash-filter-verifier tool, and I'm parsing host variables. But still, I don't experience this problem in logstash 7.x, so I assume it must be something related to ECS.

6

This is because in Logstash 8 ecs compatibility is enabled by default and then all default patterns will parse into ecs fields.

Your [host][hostname] is probably being populated because you are using the SYSLOGBASE pattern, which is defined here.

The ecs compatibility being enabled by default is considered a breaking change and is mentioned here.

7

Right, that's what I thought. But then, how does the same happen here?

if [event][dataset] == "cron" {
        grok {
            match => {
                "message" => [
                "%{CRONLOG}",
                "%{SYSLOGTIMESTAMP:timestamp} %{SYSLOGHOST:[host][name]} %{NOTSPACE:[process][name]}\[%{NOTSPACE: [process][pid]}\]: %{GREEDYDATA:message}"
                ]
            }
            overwrite => ["message", "[host][name]", "[host][hostname]"]
        }
    }

Is it the same reason? Because of the SYSLOGHOST?

8

OOOH, OK so it is the same reason. In this case because of the CRONLOG: logstash-patterns-core/patterns/ecs-v1/linux-syslog at f01f3f34cfab13a28b0822bdba33db41823cb1d8 · logstash-plugins/logstash-patterns-core · GitHub.

Case solved, I guess....