elastic · leehinman · Jun 24, 2022 · Jun 24, 2022
@@ -1,4 +1,9 @@
 # newer versions go on top
+- version: "1.4.1"
+  changes:
+    - description: Add correct field mapping for event.created
+      type: bugfix
+      link: https://github.com/elastic/integrations/pull/3579
 - version: "1.4.0"
   changes:
     - description: Migration of tile map to map in logs dashboard

@@ -4,6 +4,8 @@
   name: error.message
 - external: ecs
   name: event.category
+- external: ecs
+  name: event.created
 - external: ecs
   name: event.kind
 - external: ecs

@@ -143,6 +143,7 @@ Error logs collects the Apache error logs.
 | ecs.version | ECS version this event conforms to. `ecs.version` is a required field and must exist in all events. When querying across multiple indices -- which may conform to slightly different ECS versions -- this field lets integrations adjust to the schema version of the events. | keyword |
 | error.message | Error message. | match_only_text |
 | event.category | This is one of four ECS Categorization Fields, and indicates the second level in the ECS category hierarchy. `event.category` represents the "big buckets" of ECS categories. For example, filtering on `event.category:process` yields all events relating to process activity. This field is closely related to `event.type`, which is used as a subcategory. This field is an array. This will allow proper categorization of some events that fall in multiple categories. | keyword |
+| event.created | event.created contains the date/time when the event was first read by an agent, or by your pipeline. This field is distinct from @timestamp in that @timestamp typically contain the time extracted from the original event. In most situations, these two timestamps will be slightly different. The difference can be used to calculate the delay between your source generating an event, and the time when your agent first processed it. This can be used to monitor your agent's or pipeline's ability to keep up with your event source. In case the two timestamps are identical, @timestamp should be used. | date |
 | event.dataset | Event dataset | constant_keyword |
 | event.kind | This is one of four ECS Categorization Fields, and indicates the highest level in the ECS category hierarchy. `event.kind` gives high-level information about what type of information the event contains, without being specific to the contents of the event. For example, values of this field distinguish alert events from metric events. The value of this field can be used to inform how these kinds of events should be handled. They may warrant different retention, different access control, it may also help understand whether the data coming in at a regular interval or not. | keyword |
 | event.module | Event module | constant_keyword |

@@ -1,7 +1,7 @@
 format_version: 1.0.0
 name: apache
 title: Apache HTTP Server
-version: 1.4.0
+version: 1.4.1
 license: basic
 description: Collect logs and metrics from Apache servers with Elastic Agent.
 type: integration

@@ -1,4 +1,9 @@
 # newer versions go on top
+- version: "1.2.2"
+  changes:
+    - description: Add correct field mapping for event.created
+      type: bugfix
+      link: https://github.com/elastic/integrations/pull/3579
 - version: "1.2.1"
   changes:
     - description: Update Readme

@@ -2,6 +2,8 @@
   name: ecs.version
 - external: ecs
   name: error.message
+- external: ecs
+  name: event.created
 - external: ecs
   name: tags
 - external: ecs

@@ -43,6 +43,7 @@ The Bitbucket integration collects audit logs from the audit log files or the au
 | data_stream.type | Data stream type. | constant_keyword |
 | ecs.version | ECS version this event conforms to. `ecs.version` is a required field and must exist in all events. When querying across multiple indices -- which may conform to slightly different ECS versions -- this field lets integrations adjust to the schema version of the events. | keyword |
 | error.message | Error message. | match_only_text |
+| event.created | event.created contains the date/time when the event was first read by an agent, or by your pipeline. This field is distinct from @timestamp in that @timestamp typically contain the time extracted from the original event. In most situations, these two timestamps will be slightly different. The difference can be used to calculate the delay between your source generating an event, and the time when your agent first processed it. This can be used to monitor your agent's or pipeline's ability to keep up with your event source. In case the two timestamps are identical, @timestamp should be used. | date |
 | event.dataset | Event dataset | constant_keyword |
 | event.module | Event module | constant_keyword |
 | group.id | Unique identifier for the group on the system/platform. | keyword |

@@ -1,7 +1,7 @@
 format_version: 1.0.0
 name: atlassian_bitbucket
 title: Atlassian Bitbucket
-version: 1.2.1
+version: 1.2.2
 license: basic
 description: Collect logs from Atlassian Bitbucket with Elastic Agent.
 type: integration

@@ -1,4 +1,9 @@
 # newer versions go on top
+- version: "1.0.3"
+  changes:
+    - description: Add correct field mapping for event.created
+      type: bugfix
+      link: https://github.com/elastic/integrations/issues/3579
 - version: "1.0.2"
   changes:
     - description: Fix dashboard issues.

@@ -1,5 +1,7 @@
 - external: ecs
   name: ecs.version
+- external: ecs
+  name: event.created
 - external: ecs
   name: event.end
 - external: ecs

@@ -1,5 +1,7 @@
 - external: ecs
   name: ecs.version
+- external: ecs
+  name: event.created
 - external: ecs
   name: event.original
 - external: ecs

@@ -4,6 +4,8 @@
   name: client.user.id
 - external: ecs
   name: ecs.version
+- external: ecs
+  name: event.created
 - external: ecs
   name: event.id
 - external: ecs

@@ -12,6 +12,8 @@
   name: ecs.version
 - external: ecs
   name: event.action
+- external: ecs
+  name: event.created
 - external: ecs
   name: event.id
 - external: ecs

@@ -1,5 +1,7 @@
 - external: ecs
   name: ecs.version
+- external: ecs
+  name: event.created
 - external: ecs
   name: event.kind
 - external: ecs

@@ -138,6 +138,7 @@ An example event for `audit` looks as following:
 | data_stream.namespace | Data stream namespace. | constant_keyword |
 | data_stream.type | Data stream type. | constant_keyword |
 | ecs.version | ECS version this event conforms to. `ecs.version` is a required field and must exist in all events. When querying across multiple indices -- which may conform to slightly different ECS versions -- this field lets integrations adjust to the schema version of the events. | keyword |
+| event.created | event.created contains the date/time when the event was first read by an agent, or by your pipeline. This field is distinct from @timestamp in that @timestamp typically contain the time extracted from the original event. In most situations, these two timestamps will be slightly different. The difference can be used to calculate the delay between your source generating an event, and the time when your agent first processed it. This can be used to monitor your agent's or pipeline's ability to keep up with your event source. In case the two timestamps are identical, @timestamp should be used. | date |
 | event.dataset | Event dataset. | constant_keyword |
 | event.id | Unique ID to describe the event. | keyword |
 | event.module | Event module. | constant_keyword |
@@ -375,6 +376,7 @@ An example event for `alert` looks as following:
 | data_stream.namespace | Data stream namespace. | constant_keyword |
 | data_stream.type | Data stream type. | constant_keyword |
 | ecs.version | ECS version this event conforms to. `ecs.version` is a required field and must exist in all events. When querying across multiple indices -- which may conform to slightly different ECS versions -- this field lets integrations adjust to the schema version of the events. | keyword |
+| event.created | event.created contains the date/time when the event was first read by an agent, or by your pipeline. This field is distinct from @timestamp in that @timestamp typically contain the time extracted from the original event. In most situations, these two timestamps will be slightly different. The difference can be used to calculate the delay between your source generating an event, and the time when your agent first processed it. This can be used to monitor your agent's or pipeline's ability to keep up with your event source. In case the two timestamps are identical, @timestamp should be used. | date |
 | event.dataset | Event dataset. | constant_keyword |
 | event.end | event.end contains the date when the event ended or when the activity was last observed. | date |
 | event.id | Unique ID to describe the event. | keyword |
@@ -610,6 +612,7 @@ An example event for `endpoint_event` looks as following:
 | dll.path | Full file path of the library. | keyword |
 | ecs.version | ECS version this event conforms to. `ecs.version` is a required field and must exist in all events. When querying across multiple indices -- which may conform to slightly different ECS versions -- this field lets integrations adjust to the schema version of the events. | keyword |
 | event.action | The action captured by the event. This describes the information in the event. It is more specific than `event.category`. Examples are `group-add`, `process-started`, `file-created`. The value is normally defined by the implementer. | keyword |
+| event.created | event.created contains the date/time when the event was first read by an agent, or by your pipeline. This field is distinct from @timestamp in that @timestamp typically contain the time extracted from the original event. In most situations, these two timestamps will be slightly different. The difference can be used to calculate the delay between your source generating an event, and the time when your agent first processed it. This can be used to monitor your agent's or pipeline's ability to keep up with your event source. In case the two timestamps are identical, @timestamp should be used. | date |
 | event.dataset | Event dataset. | constant_keyword |
 | event.id | Unique ID to describe the event. | keyword |
 | event.module | Event module. | constant_keyword |
@@ -849,6 +852,7 @@ An example event for `watchlist_hit` looks as following:
 | data_stream.namespace | Data stream namespace. | constant_keyword |
 | data_stream.type | Data stream type. | constant_keyword |
 | ecs.version | ECS version this event conforms to. `ecs.version` is a required field and must exist in all events. When querying across multiple indices -- which may conform to slightly different ECS versions -- this field lets integrations adjust to the schema version of the events. | keyword |
+| event.created | event.created contains the date/time when the event was first read by an agent, or by your pipeline. This field is distinct from @timestamp in that @timestamp typically contain the time extracted from the original event. In most situations, these two timestamps will be slightly different. The difference can be used to calculate the delay between your source generating an event, and the time when your agent first processed it. This can be used to monitor your agent's or pipeline's ability to keep up with your event source. In case the two timestamps are identical, @timestamp should be used. | date |
 | event.dataset | Event dataset. | constant_keyword |
 | event.kind | This is one of four ECS Categorization Fields, and indicates the highest level in the ECS category hierarchy. `event.kind` gives high-level information about what type of information the event contains, without being specific to the contents of the event. For example, values of this field distinguish alert events from metric events. The value of this field can be used to inform how these kinds of events should be handled. They may warrant different retention, different access control, it may also help understand whether the data coming in at a regular interval or not. | keyword |
 | event.module | Event module. | constant_keyword |
@@ -1013,6 +1017,7 @@ An example event for `asset_vulnerability_summary` looks as following:
 | data_stream.namespace | Data stream namespace. | constant_keyword |
 | data_stream.type | Data stream type. | constant_keyword |
 | ecs.version | ECS version this event conforms to. `ecs.version` is a required field and must exist in all events. When querying across multiple indices -- which may conform to slightly different ECS versions -- this field lets integrations adjust to the schema version of the events. | keyword |
+| event.created | event.created contains the date/time when the event was first read by an agent, or by your pipeline. This field is distinct from @timestamp in that @timestamp typically contain the time extracted from the original event. In most situations, these two timestamps will be slightly different. The difference can be used to calculate the delay between your source generating an event, and the time when your agent first processed it. This can be used to monitor your agent's or pipeline's ability to keep up with your event source. In case the two timestamps are identical, @timestamp should be used. | date |
 | event.dataset | Event dataset | constant_keyword |
 | event.module | Event module | constant_keyword |
 | event.original | Raw text message of entire event. Used to demonstrate log integrity or where the full log message (before splitting it up in multiple parts) may be required, e.g. for reindex. This field is not indexed and doc_values are disabled. It cannot be searched, but it can be retrieved from `_source`. If users wish to override this and index this field, please see `Field data types` in the `Elasticsearch Reference`. | keyword |

@@ -1,7 +1,7 @@
 format_version: 1.0.0
 name: carbon_black_cloud
 title: VMware Carbon Black Cloud
-version: 1.0.2
+version: 1.0.3
 license: basic
 description: Collect logs from VMWare Carbon Black Cloud with Elastic Agent.
 type: integration

@@ -1,4 +1,9 @@
 # newer versions go on top
+- version: "1.0.2"
+  changes:
+    - description: Add correct field mapping for event.created
+      type: bugfix
+      link: https://github.com/elastic/integrations/pull/3579
 - version: "1.0.1"
   changes:
     - description: Update readme

@@ -8,6 +8,8 @@
   external: ecs
 - name: event.category
   external: ecs
+- name: event.created
+  external: ecs
 - name: event.id
   external: ecs
 - name: event.ingested

@@ -25,6 +25,7 @@ To use this integration, you must be an organization owner, and you must use an
 | error.message | Error message. | match_only_text |
 | event.action | The action captured by the event. This describes the information in the event. It is more specific than `event.category`. Examples are `group-add`, `process-started`, `file-created`. The value is normally defined by the implementer. | keyword |
 | event.category | This is one of four ECS Categorization Fields, and indicates the second level in the ECS category hierarchy. `event.category` represents the "big buckets" of ECS categories. For example, filtering on `event.category:process` yields all events relating to process activity. This field is closely related to `event.type`, which is used as a subcategory. This field is an array. This will allow proper categorization of some events that fall in multiple categories. | keyword |
+| event.created | event.created contains the date/time when the event was first read by an agent, or by your pipeline. This field is distinct from @timestamp in that @timestamp typically contain the time extracted from the original event. In most situations, these two timestamps will be slightly different. The difference can be used to calculate the delay between your source generating an event, and the time when your agent first processed it. This can be used to monitor your agent's or pipeline's ability to keep up with your event source. In case the two timestamps are identical, @timestamp should be used. | date |
 | event.dataset | Event dataset | constant_keyword |
 | event.id | Unique ID to describe the event. | keyword |
 | event.ingested | Timestamp when an event arrived in the central data store. This is different from `@timestamp`, which is when the event originally occurred.  It's also different from `event.created`, which is meant to capture the first time an agent saw the event. In normal conditions, assuming no tampering, the timestamps should chronologically look like this: `@timestamp` \< `event.created` \< `event.ingested`. | date |

@@ -1,6 +1,6 @@
 name: github
 title: GitHub
-version: 1.0.1
+version: 1.0.2
 release: ga
 description: Collect events from GitHub with Elastic Agent.
 type: integration

@@ -1,3 +1,8 @@
+- version: "1.2.4"
+  changes:
+    - description: Add correct field mapping for event.created
+      type: bugfix
+      link: https://github.com/elastic/integrations/pull/3579
 - version: "1.2.3"
   changes:
     - description: Fixes oauth2 config rendering

@@ -1,4 +1,6 @@
 - name: ecs.version
   external: ecs
+- name: event.created
+  external: ecs
 - name: message
   external: ecs
@@ -3,7 +3,7 @@ name: httpjson
 title: Custom HTTPJSON Input
 description: Collect custom data from REST API's with Elastic Agent.
 type: integration
-version: 1.2.3
+version: 1.2.4
 release: ga
 conditions:
   kibana.version: "^7.16.0 || ^8.0.0"

@@ -1,4 +1,9 @@
 # newer versions go on top
+- version: "1.2.1"
+  changes:
+    - description: Add correct field mapping for event.created
+      type: bugfix
+      link: https://github.com/elastic/integrations/pull/3579
 - version: "1.2.0"
   changes:
     - description: Update to ECS 8.2

@@ -1,3 +1,5 @@
+- name: event.created
+  external: ecs
 - name: event.original
   external: ecs
 - name: tags

@@ -1,3 +1,5 @@
+- name: event.created
+  external: ecs
 - name: event.original
   external: ecs
 - name: tags