Skip to content

Entity id desc#1

Closed
mjwolf wants to merge 3 commits intomainfrom
entity_id_desc
Closed

Entity id desc#1
mjwolf wants to merge 3 commits intomainfrom
entity_id_desc

Conversation

@mjwolf
Copy link
Copy Markdown
Owner

@mjwolf mjwolf commented Nov 29, 2023

No description provided.

Update the process.entity_id description with recommended generation methods.

These methods will allow entity_id to be generated reproducibly, while being
unique to a process.

If different data source collectors use the recommeded generation method, and
observe events from the same process, they will generate the same entity_id, and
it will be possible to corralate the  events and identify them as belonging to the
same process later.

StartTimeSeconds:: Process start time in UNIX time seconds

StartTimeMilliseconds:: Millisecond precision of process start time
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Windows actually gives us a lot more precision than milliseconds in the form of a FILETIME: https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-getprocesstimes

@intxgo
Copy link
Copy Markdown

intxgo commented Dec 6, 2023

Endpoint's entity_id is already used by users (Kibana and API). Response Actions console list it with processes, then the user can grab any to call kill-process --entity_id

As a reminder it's essential to use ids on Windows where PIDs are reused often.

Therefore the gist of my earlier thought was to make the string more human readable like other cloud providers do, basically some sort of GUID. I guess that before Response Actions, the entity_ids were regarded to be used in code, not by human, so the optical readability of base64 was not taken into account. I'd rather start with unique process information at the front of it, as MachineGUID is constant per Endpoint.

I don't mind documenting it publicly. My original thought was that's not needed, but I can't see any reason not to do it.


A String formatted as: "MachineGUID__PID__StartTimeSeconds__StartTimeMilliseconds"

MachineGUID:: The Windows Machine GUID, which can be read from the Windows registry
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we would ever had a need to know that the entity was generated by an Endpoint receiving it.

Re-order the entity_id fields to have the PID, start time first. To
improve human readability and scanning effeciency, the fields that
change most often are first.

Also redefined Windows entity_id to use existing Windows process fields
that are more likely to be unique for the process.
@mjwolf
Copy link
Copy Markdown
Owner Author

mjwolf commented Dec 7, 2023

Endpoint's entity_id is already used by users (Kibana and API). Response Actions console list it with processes, then the user can grab any to call kill-process --entity_id

As a reminder it's essential to use ids on Windows where PIDs are reused often.

Therefore the gist of my earlier thought was to make the string more human readable like other cloud providers do, basically some sort of GUID. I guess that before Response Actions, the entity_ids were regarded to be used in code, not by human, so the optical readability of base64 was not taken into account. I'd rather start with unique process information at the front of it, as MachineGUID is constant per Endpoint.

I don't mind documenting it publicly. My original thought was that's not needed, but I can't see any reason not to do it.

@intxgo How important do you think it is to keep this human readable? If we change to use fixed-width fields, I think it also makes sense to encode numbers with hex; it would reduce the overall length of the string. But it would also make it a bit less human-readable, as PIDs won't be in the normal decimal format that's used in most places

(I've made the changes to the PR to re-order the fields and change the Windows definition, but I haven't changed to fix-width fields yet)

@intxgo
Copy link
Copy Markdown

intxgo commented Dec 7, 2023

@intxgo How important do you think it is to keep this human readable? If we change to use fixed-width fields, I think it also makes sense to encode numbers with hex; it would reduce the overall length of the string. But it would also make it a bit less human-readable, as PIDs won't be in the normal decimal format that's used in most places

(I've made the changes to the PR to re-order the fields and change the Windows definition, but I haven't changed to fix-width fields yet)

I'd say hex or ascii, but nicely formatted fixed length, is perfectly fine, and the shortest the better. For the purpose of Response Actions console the actual meaning of entity_id content doesn't have to be directly visible, but documenting it in general in ECS is a good idea.

mjwolf added a commit that referenced this pull request Mar 17, 2025
* delete asciidoc files

* add migrated files

* clean up cross-repo links

* add missing ecs and otel pages

* add mapped_pages

* fix external links

* Update makefile to use docs-builder

Signed-off-by: bmorelli25 <brandon.morelli@elastic.co>

* Remove tabs from ecs-code_signature.md

* Remove tabs from ecs-device.md

* Remove remaining beta tabs

* [work in progress] Migrate docs md generator (#1)

* Update docs generator to markdown

* generate fieldset docs

* Update fieldset formatting

* Update fieldset formatting

* Change otel dir

* Update more formatting

* Include usage in docs

* Update otel docs generation

* update template files to fix images, links, tables

* commit updated markdown files

* fix extra pipe

* fix otel docs formatting

* Update fieldset

* update more formatting

* Update unit tests

* More formatting fixes

* fix usage section in fieldset template

* update nested fieldset

* fix syntax issues causing build errors

* only build ext link if it's needed

* commit generated markdown files

---------

Co-authored-by: Colleen McGinnis <colleen.mcginnis@elastic.co>

* Fix lint errors

* clean up spacing

* commit changes to layout

---------

Signed-off-by: bmorelli25 <brandon.morelli@elastic.co>
Co-authored-by: Mike Birnstiehl <114418652+mdbirnstiehl@users.noreply.github.com>
Co-authored-by: bmorelli25 <brandon.morelli@elastic.co>
Co-authored-by: lcawl <lcawley@elastic.co>
Co-authored-by: Michael Wolf <michael.wolf@elastic.co>
@mjwolf mjwolf closed this Apr 22, 2025
mjwolf added a commit that referenced this pull request Apr 22, 2025
* delete asciidoc files

* add migrated files

* clean up cross-repo links

* add missing ecs and otel pages

* add mapped_pages

* fix external links

* Update makefile to use docs-builder

Signed-off-by: bmorelli25 <brandon.morelli@elastic.co>

* Remove tabs from ecs-code_signature.md

* Remove tabs from ecs-device.md

* Remove remaining beta tabs

* [work in progress] Migrate docs md generator (#1)

* Update docs generator to markdown

* generate fieldset docs

* Update fieldset formatting

* Update fieldset formatting

* Change otel dir

* Update more formatting

* Include usage in docs

* Update otel docs generation

* update template files to fix images, links, tables

* commit updated markdown files

* fix extra pipe

* fix otel docs formatting

* Update fieldset

* update more formatting

* Update unit tests

* More formatting fixes

* fix usage section in fieldset template

* update nested fieldset

* fix syntax issues causing build errors

* only build ext link if it's needed

* commit generated markdown files

---------

Co-authored-by: Colleen McGinnis <colleen.mcginnis@elastic.co>

* Fix lint errors

* clean up spacing

* commit changes to layout

---------

Signed-off-by: bmorelli25 <brandon.morelli@elastic.co>
Co-authored-by: Mike Birnstiehl <114418652+mdbirnstiehl@users.noreply.github.com>
Co-authored-by: bmorelli25 <brandon.morelli@elastic.co>
Co-authored-by: lcawl <lcawley@elastic.co>
Co-authored-by: Michael Wolf <michael.wolf@elastic.co>
@mjwolf mjwolf deleted the entity_id_desc branch September 26, 2025 16:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants