[Azure] azure.eventhub: use ecs definition of the event.dataset field (…

…#9554)

* azure.eventhub: use ecs definition of the event.dataset field

Signed-off-by: Tetiana Kravchenko <[email protected]>

* Update changelog.yml

---------

Signed-off-by: Tetiana Kravchenko <[email protected]>

packages/azure/changelog.yml

@@ -1,3 +1,8 @@
+- version: "1.11.0"
+  changes:
+    - description: Use ecs definition of the 'event.dataset' field for eventhub
+      type: enhancement
+      link: https://github.com/elastic/integrations/pull/9554
 - version: "1.10.0"
   changes:
     - description: Add Microsoft Graph Activity Logs

packages/azure/data_stream/eventhub/fields/base-fields.yml

@@ -14,7 +14,3 @@
   type: constant_keyword
   description: Event module
   value: azure
-- name: event.dataset
-  type: constant_keyword
-  description: Event dataset
-  value: azure.eventhub

packages/azure/data_stream/eventhub/fields/ecs.yml

@@ -44,6 +44,8 @@
   external: ecs
 - name: event.type
   external: ecs
+- external: ecs
+  name: event.dataset
 - name: file.mime_type
   external: ecs
 - name: file.size

packages/azure/docs/eventhub.md

@@ -191,7 +191,7 @@ An example event for `eventhub` looks as following:
 | 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.dataset | Name of the dataset. If an event source publishes more than one type of log or events (e.g. access log, error log), the dataset is used to specify which one the event comes from. It's recommended but not required to start the dataset name with the module name, followed by a dot, then the dataset name. | keyword |
 | event.duration | Duration of the event in nanoseconds. If event.start and event.end are known this value should be the difference between the end and start time. | long |
 | 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 |

packages/azure/manifest.yml

@@ -1,6 +1,6 @@
 name: azure
 title: Azure Logs
-version: 1.10.0
+version: 1.11.0
 description: This Elastic integration collects logs from Azure
 type: integration
 icons: