Add the api value to event.category
#2147
Conversation
schemas/event.yml
Outdated
| @@ -156,6 +156,19 @@ | |||
| normalize: | |||
| - array | |||
| allowed_values: | |||
| - name: api | |||
| description: > | |||
| Events in this category correspond to API events propagated directly | |||
There was a problem hiding this comment.
The event.category field values are designed to be fairly broad, and the term api encompasses a wide range: native, SOAP, RPC, Websocket, REST, etc.
I don't think we should limit its intended usage only to native/system API calls.
There was a problem hiding this comment.
Understood, I'll rephrase
| Events in this category correspond to API events propagated directly | ||
| from the Operating System (Windows, Linux, etc.), from either the native | ||
| API function or system call, or a managed source of events (such as ETW, syslog). | ||
| expected_event_types: |
There was a problem hiding this comment.
Narrowing down this list of expected event.type values is tough. I could see adding others, but it's also far easier to add others later than remove.
Maybe info for APIs that are purely returning information and not taking action or making a state change?
And perhaps also creation/change/deletion for the creating and removing of a resource by way of an API call?
* Adding `api` to `event.category` * better phrasing for description, added a few extra expected types (cherry picked from commit 08237fe)
💚 All backports created successfully
Questions ?Please refer to the Backport tool documentation |
This Pull Request adds a new value for the
event.category:api. Events in this category correspond to API events propagated directly from the Operating System from either the native API function (for instance, OS callbacks from Windows or Linux), system calls, or also managed source of events (such as ETW for instance).Resolves #2138