Add a new, optional, PID match to the header. #53
Conversation
This is needed because Icinga plans on changing their log format in Icinga/icinga2#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
|
I'm not totally happy with simply renaming the already existing PID field. What about users that rely on that? |
|
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. |
|
We should adhere to https://www.elastic.co/guide/en/ecs/current/index.html . ECS knows 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 |
|
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 What I'd need would be something like a |
This is needed because Icinga plans on changing their log format in Icinga/icinga2#7872
Thanks to @dgeotz for pointing that possible issue out.
We already had a
process.pidin our loglines. This change also renames the already presentprocess.pidtoicinga.pid. Time will tell if this other pid will still be available in loglines.fixes #52