Add a new, optional, PID match to the header.

[widhalmt]

This is needed because Icinga plans on changing their log format in https://github.com/Icinga/icinga2/pull/7872

Thanks to @dgeotz for pointing that possible issue out.

We already had a process.pid in our loglines. This change also renames the already present process.pid to icinga.pid. Time will tell if this other pid will still be available in loglines.

fixes #52

[widhalmt]

I'm not totally happy with simply renaming the already existing PID field. What about users that rely on that?

[dgoetz]

How about keeping it to process.pid and having the new one as parent_process.pid? Advantage would be full backwards compatibility and alignment with naming on the linux system itself with pid and ppid (or nearly as process and the p in pid is redundant ;-)). But would this be technically correct in all cases?

Or instead of parent_process using icinga_process for the new one as this would be more clear? Also not 100% sure about.

[widhalmt]

We should adhere to https://www.elastic.co/guide/en/ecs/current/index.html .

ECS knows process.ppid which seems to be the right choice here: https://www.elastic.co/guide/en/ecs/current/ecs-process.html

Thanks @dgoetz for the idea. I'll change it.

About the redundancy in the naming: The docs say that ECS will keep well known names like hostname and pid even when they are already part of the parent field. So there's host.hostname as well which usually is just a copy of host.name.

[widhalmt]

While starting the change, I started to realize, that we should have a name for that field that works for all loglines of Icinga 2. If I understand you correctly, @dgoetz , the new field should be called process.ppid when the logline includes another process.pid but should stay as process.pid when there's no other process.pid in the line.

What I'd need would be something like a process.child_pid to denote the PID of the process started by Icinga. :-)