Migrate system process metricset fields to ECS#10332
Migrate system process metricset fields to ECS#10332jsoriano merged 21 commits intoelastic:masterfrom
Conversation
| "ppid": 40547, | ||
| "state": "running", | ||
| "username": "ruflin" | ||
| "pgid": 2080, |
There was a problem hiding this comment.
It can be weird to find pgid here but the rest of ids in process.*, should we add this to ECS?
There was a problem hiding this comment.
+1. even if it's not in ECS, we can push it under process.*.
@webmat FYI
There was a problem hiding this comment.
To what fields file should I add this field? To the ECS one even if it is not in ECS yet?
There was a problem hiding this comment.
I have added it by now to field.ecs.yml and opened a PR in ECS elastic/ecs#311
5f8dea6 to
81d275d
Compare
|
CI failure not related, reproduced locally and it seems related to latest ES snapshot: |
5490e3a to
95eb36c
Compare
webmat
left a comment
There was a problem hiding this comment.
Mostly commented about the group ID
auditbeat/docs/fields.asciidoc
Outdated
|
|
||
| -- | ||
|
|
||
| *`process.pgid`*:: |
There was a problem hiding this comment.
As proposed in your ECS PR, I would go for process.group.id here (and process.user.id if you have that)
There was a problem hiding this comment.
Actually seeing the full context, I wonder if we shouldn't simply map to the top level fields, like you did for user.name. So:
system.process.username=>user.namesystem.process.pgid=>group.id
And equivalent mappings, if you have user id and group name.
WDYT @ruflin ?
I'd say unless the events can contain more than one user or group, we shouldn't nest them.
There was a problem hiding this comment.
As commented in elastic/ecs#311, the pgid identifies a group of processes, not a group of users. It is a value similar to ppid, I think it belongs to process.
| ], | ||
| "executable": "/usr/bin/dockerd-ce", | ||
| "name": "dockerd", | ||
| "pgid": 2080, |
There was a problem hiding this comment.
And don't forget to leave group ID as text (wherever it ends up)
There was a problem hiding this comment.
By text I meant keyword datatype, here
There was a problem hiding this comment.
I agree that these ids could be keyword, but this is a value of the same kind as pid or ppid and they are defined as long in ECS 🤔
There was a problem hiding this comment.
Gotcha, I was not familiar with pgid. If the semantics are like PID, this can be left as numeric, then.
So recap: I'm good with the field process.pgid, and I'm good with it remaining numeric 👍
| Cwd: exe.Cwd, | ||
| Env: env, | ||
| Pid: pid, | ||
| Ppid: state.Ppid, |
There was a problem hiding this comment.
Ah I see, we also have it as part of the monitoring reporting?
There was a problem hiding this comment.
Yes, I think this is also used for beats monitoring.
|
pgid moved to metricbeat only fields |
webmat
left a comment
There was a problem hiding this comment.
I'm good with the pgid as it is now. I wasn't familiar with the concept.
Noticed that cwd migration is missing an alias in fields.yml and ecs-migration.yml. After that, I think we're good :-)
| ], | ||
| "executable": "/usr/bin/dockerd-ce", | ||
| "name": "dockerd", | ||
| "pgid": 2080, |
There was a problem hiding this comment.
Gotcha, I was not familiar with pgid. If the semantics are like PID, this can be left as numeric, then.
So recap: I'm good with the field process.pgid, and I'm good with it remaining numeric 👍
| type: alias | ||
| path: user.name | ||
| migration: true | ||
| - name: cwd |
There was a problem hiding this comment.
cwd should be migrated to process.working_directory
There was a problem hiding this comment.
Oh, good catch, thanks.
| "process.pid", | ||
| ]: | ||
| assert key in output | ||
| assert key in output, "'%s' not found" % key |
There was a problem hiding this comment.
❤️ more verbose failures ;-)
No description provided.