Skip to content

Commit

Permalink
[qnap_nas] Ensure event.created is correctly mapped (#12288)
Browse files Browse the repository at this point in the history
- Added event.created to ecs field mappings
  • Loading branch information
taylor-swanson authored Jan 9, 2025
1 parent 80d18e9 commit 9f541bb
Show file tree
Hide file tree
Showing 4 changed files with 9 additions and 1 deletion.
5 changes: 5 additions & 0 deletions packages/qnap_nas/changelog.yml
Original file line number Diff line number Diff line change
@@ -1,4 +1,9 @@
# newer versions go on top
- version: "1.20.2"
changes:
- description: Fix mapping of event.created.
type: bugfix
link: https://github.com/elastic/integrations/pull/12288
- version: "1.20.1"
changes:
- description: Use triple-brace Mustache templating when referencing variables in ingest pipelines.
Expand Down
2 changes: 2 additions & 0 deletions packages/qnap_nas/data_stream/log/fields/ecs.yml
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,8 @@
name: error.message
- external: ecs
name: event.action
- external: ecs
name: event.created
- external: ecs
name: event.ingested
- external: ecs
Expand Down
1 change: 1 addition & 0 deletions packages/qnap_nas/docs/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -122,6 +122,7 @@ An example event for `log` looks as following:
| 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.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.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 |
| event.module | Event module | constant_keyword |
Expand Down
2 changes: 1 addition & 1 deletion packages/qnap_nas/manifest.yml
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
name: qnap_nas
title: QNAP NAS
version: "1.20.1"
version: "1.20.2"
description: Collect logs from QNAP NAS devices with Elastic Agent.
type: integration
format_version: "3.0.3"
Expand Down

0 comments on commit 9f541bb

Please sign in to comment.