From 8e46c2f9b6fe7d7e5d9bf979b74c72878084388e Mon Sep 17 00:00:00 2001 From: Marc Guasch Date: Mon, 28 Jun 2021 11:26:47 +0200 Subject: [PATCH 1/2] Make netflow package GA with v1.0.0 --- packages/netflow/changelog.yml | 5 +++++ packages/netflow/data_stream/log/manifest.yml | 1 - packages/netflow/manifest.yml | 6 +++--- 3 files changed, 8 insertions(+), 4 deletions(-) diff --git a/packages/netflow/changelog.yml b/packages/netflow/changelog.yml index 3b4eba8f585d..68b03a9739f3 100644 --- a/packages/netflow/changelog.yml +++ b/packages/netflow/changelog.yml @@ -1,4 +1,9 @@ # newer versions go on top +- version: "1.0.0" + changes: + - description: make GA + type: enhancement + link: https://github.com/elastic/integrations/pull/1218 - version: "0.4.1" changes: - description: Use `wildcard` field type for the relevant ECS fields. diff --git a/packages/netflow/data_stream/log/manifest.yml b/packages/netflow/data_stream/log/manifest.yml index f8512d49839a..bf706ae5c5b8 100644 --- a/packages/netflow/data_stream/log/manifest.yml +++ b/packages/netflow/data_stream/log/manifest.yml @@ -1,5 +1,4 @@ title: NetFlow logs -release: experimental type: logs streams: - input: netflow diff --git a/packages/netflow/manifest.yml b/packages/netflow/manifest.yml index 9106c7ad53a9..2a260a332158 100644 --- a/packages/netflow/manifest.yml +++ b/packages/netflow/manifest.yml @@ -1,16 +1,16 @@ format_version: 1.0.0 name: netflow title: NetFlow -version: 0.4.1 +version: 1.0.0 license: basic description: NetFlow Integration type: integration categories: - network - security -release: experimental +release: ga conditions: - kibana.version: "^7.9.0" + kibana.version: "^7.14.0" policy_templates: - name: netflow title: NetFlow logs From 994063fecf473deeb1145ed63b8edb691e946a0a Mon Sep 17 00:00:00 2001 From: Marc Guasch Date: Tue, 29 Jun 2021 15:20:39 +0200 Subject: [PATCH 2/2] Set event.module and event.dataset --- packages/netflow/changelog.yml | 3 +++ .../data_stream/log/fields/base-fields.yml | 8 ++++++++ .../netflow/data_stream/log/fields/ecs.yml | 18 ------------------ packages/netflow/docs/README.md | 4 ++-- 4 files changed, 13 insertions(+), 20 deletions(-) diff --git a/packages/netflow/changelog.yml b/packages/netflow/changelog.yml index 68b03a9739f3..f201174ed3fd 100644 --- a/packages/netflow/changelog.yml +++ b/packages/netflow/changelog.yml @@ -4,6 +4,9 @@ - description: make GA type: enhancement link: https://github.com/elastic/integrations/pull/1218 + - description: Set "event.module" and "event.dataset" + type: enhancement + link: https://github.com/elastic/integrations/pull/1218 - version: "0.4.1" changes: - description: Use `wildcard` field type for the relevant ECS fields. diff --git a/packages/netflow/data_stream/log/fields/base-fields.yml b/packages/netflow/data_stream/log/fields/base-fields.yml index 7c798f4534ca..12d5ac2a456b 100644 --- a/packages/netflow/data_stream/log/fields/base-fields.yml +++ b/packages/netflow/data_stream/log/fields/base-fields.yml @@ -7,6 +7,14 @@ - name: data_stream.namespace type: constant_keyword description: Data stream namespace. +- name: event.module + type: constant_keyword + description: Event module + value: netflow +- name: event.dataset + type: constant_keyword + description: Event dataset + value: netflow.log - name: '@timestamp' type: date description: Event timestamp. diff --git a/packages/netflow/data_stream/log/fields/ecs.yml b/packages/netflow/data_stream/log/fields/ecs.yml index d3ed51ed6d48..81d7c5488d19 100644 --- a/packages/netflow/data_stream/log/fields/ecs.yml +++ b/packages/netflow/data_stream/log/fields/ecs.yml @@ -813,16 +813,6 @@ 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.' - - name: dataset - level: core - type: keyword - ignore_above: 1024 - description: '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.' - example: apache.access - name: duration level: core type: long @@ -857,14 +847,6 @@ This gives information about what type of information the event contains, without being specific to the contents of the event. Examples are `event`, `state`, `alarm`. Warning: In future versions of ECS, we plan to provide a list of acceptable values for this field, please use with caution.' example: state - - name: module - level: core - type: keyword - ignore_above: 1024 - description: 'Name of the module this data is coming from. - - If your monitoring agent supports the concept of modules or plugins to process events of a given source (e.g. Apache logs), `event.module` should contain the name of this module.' - example: apache - name: original level: core type: keyword diff --git a/packages/netflow/docs/README.md b/packages/netflow/docs/README.md index 5bb951c5af2b..0fe095759db8 100644 --- a/packages/netflow/docs/README.md +++ b/packages/netflow/docs/README.md @@ -135,14 +135,14 @@ The `log` dataset collects netflow logs. | event.category | Event category. This contains high-level information about the contents of the event. It is more generic than `event.action`, in the sense that typically a category contains multiple actions. Warning: In future versions of ECS, we plan to provide a list of acceptable values for this field, please use with caution. | keyword | | event.code | Identification code for this event, if one exists. Some event sources use event codes to identify messages unambiguously, regardless of message language or wording adjustments over time. An example of this is the Windows Event ID. | 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 | 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.dataset | Event dataset | constant_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.end | event.end contains the date when the event ended or when the activity was last observed. | date | | event.hash | Hash (perhaps logstash fingerprint) of raw field to be able to demonstrate log integrity. | keyword | | event.id | Unique ID to describe the event. | keyword | | event.ingested | Timestamp when an event arrived in the central data store. | date | | event.kind | The kind of the event. This gives information about what type of information the event contains, without being specific to the contents of the event. Examples are `event`, `state`, `alarm`. Warning: In future versions of ECS, we plan to provide a list of acceptable values for this field, please use with caution. | keyword | -| event.module | Name of the module this data is coming from. If your monitoring agent supports the concept of modules or plugins to process events of a given source (e.g. Apache logs), `event.module` should contain the name of this module. | keyword | +| event.module | Event module | constant_keyword | | event.original | Raw text message of entire event. Used to demonstrate log integrity. This field is not indexed and doc_values are disabled. It cannot be searched, but it can be retrieved from `_source`. | keyword | | event.outcome | The outcome of the event. If the event describes an action, this fields contains the outcome of that action. Examples outcomes are `success` and `failure`. Warning: In future versions of ECS, we plan to provide a list of acceptable values for this field, please use with caution. | keyword | | event.provider | Source of the event. Event transports such as Syslog or the Windows Event Log typically mention the source of an event. It can be the name of the software that generated the event (e.g. Sysmon, httpd), or of a subsystem of the operating system (kernel, Microsoft-Windows-Security-Auditing). | keyword |