github-mirrors/kibana
1
0
Fork 0
mirror of https://github.com/elastic/kibana.git synced 2025-04-23 09:19:04 -04:00
Code Issues Projects Releases Packages Wiki Activity

[kbn-data-forge] Adding custom heartbeat like data for MongoDB (#178354)

Browse source 
## Summary

This PR adds heartbeat-like data for MongoDB in the `fake_stack` dataset
so users can express an SLO for that service. This also changes some of
the details in the Nginx data to allow for group-by on the same domain
names to be used in testing SLO alert dependencies.
This commit is contained in:
Chris Cowan 2024-03-25 09:17:58 -06:00 • committed by GitHub
parent 2f5396ca10
commit 2dc44ff6b8
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
48 changed files with 2556 additions and 10 deletions
Download patch file Download diff file Expand all files Collapse all files

2
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/admin_console/lib/events/create_user.ts
View file

@ -67,7 +67,7 @@ export const createUser: EventFunction = (_schedule, timestamp) => {
path,
`https://${ADMIN_CONSOLE}.${domain}`,
userAgent,
`${ADMIN_CONSOLE}.${domain}`,
domain,
`${host}:${port}`,
user.id
),

2
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/admin_console/lib/events/delete_user.ts
View file

@ -65,7 +65,7 @@ export const deleteUser: EventFunction = (_schedule, timestamp) => {
path,
`https://${ADMIN_CONSOLE}.${domain}`,
userAgent,
`${ADMIN_CONSOLE}.${domain}`,
domain,
`${host}:${port}`,
user.id
),

2
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/admin_console/lib/events/edit_user.ts
View file

@ -69,7 +69,7 @@ export const editUser: EventFunction = (_schedule, timestamp) => {
path,
`https://${ADMIN_CONSOLE}.${domain}`,
userAgent,
`${ADMIN_CONSOLE}.${domain}`,
domain,
`${host}:${port}`,
user.id
),

2
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/admin_console/lib/events/list_customers.ts
View file

@ -67,7 +67,7 @@ export const listCustomers: EventFunction = (_schedule, timestamp) => {
path,
`https://${ADMIN_CONSOLE}.${domain}`,
userAgent,
`${ADMIN_CONSOLE}.${domain}`,
domain,
`${host}:${port}`,
user.id
),

2
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/admin_console/lib/events/login.ts
View file

@ -62,7 +62,7 @@ export const login: EventFunction = (_schedule, timestamp) => {
path,
`https://${ADMIN_CONSOLE}.${domain}`,
userAgent,
`${ADMIN_CONSOLE}.${domain}`,
domain,
`${host}:${port}`,
user.id
),

2
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/admin_console/lib/events/login_error.ts
View file

@ -61,7 +61,7 @@ export const loginError: EventFunction = (_schedule, timestamp) => {
path,
`https://${ADMIN_CONSOLE}.${domain}`,
userAgent,
`${ADMIN_CONSOLE}.${domain}`,
domain,
`${host}:${port}`,
user.id
),

2
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/admin_console/lib/events/mongodb_connection_error.ts
View file

@ -77,7 +77,7 @@ export const mongodbConnectionError: EventFunction = (_schedule, timestamp) => {
path,
`https://${ADMIN_CONSOLE}.${domain}`,
userAgent,
`${ADMIN_CONSOLE}.${domain}`,
domain,
`${host}:${port}`,
user.id
),

2
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/admin_console/lib/events/mongodb_proxy_timeout.ts
View file

@ -72,7 +72,7 @@ export const mongodbProxyTimeout: EventFunction = (_schedule, timestamp) => {
path,
`https://${ADMIN_CONSOLE}.${domain}`,
userAgent,
`${ADMIN_CONSOLE}.${domain}`,
domain,
`${host}:${port}`,
user.id
),

2
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/admin_console/lib/events/qa_deployed_to_production.ts
View file

@ -59,7 +59,7 @@ export const qaDeployedToProduction: EventFunction = (_schedule, timestamp) => {
path,
`https://${ADMIN_CONSOLE}.${domain}`,
userAgent,
`${ADMIN_CONSOLE}.${domain}`,
domain,
`${host}:${port}`,
user.id
),

2
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/admin_console/lib/events/view_user.ts
View file

@ -66,7 +66,7 @@ export const viewUsers: EventFunction = (_schedule, timestamp) => {
path,
`https://${ADMIN_CONSOLE}.${domain}`,
userAgent,
`${ADMIN_CONSOLE}.${domain}`,
domain,
`${host}:${port}`,
user.id
),

2
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/common/constants.ts
View file

@ -37,3 +37,5 @@ export const NGINX_PROXY = 'nginx_proxy';
export const NGINX_PROXY_HOSTS = times(5).map(
(n) => `${NGINX_PROXY}.prod.${padStart(`${n + 1}`, 3, '0')}`
);
export const HEARTBEAT = 'heartbeat';

2
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/heartbeat/assets/heartbeat.ndjson Normal file
View file

@ -0,0 +1,2 @@
{"attributes":{"allowHidden":false,"fieldAttrs":"{}","fieldFormatMap":"{}","fields":"[]","name":"Heartbeat","runtimeFieldMap":"{}","sourceFilters":"[]","timeFieldName":"@timestamp","title":"kbn-data-forge-fake_stack.heartbeat-*"},"coreMigrationVersion":"8.8.0","created_at":"2024-02-16T00:12:16.285Z","id":"934c52f7-f9ca-40f3-b2ef-64e068b85c49","managed":false,"references":[],"type":"index-pattern","typeMigrationVersion":"8.0.0","updated_at":"2024-02-16T00:12:16.285Z","version":"WzIxMywxXQ=="}
{"excludedObjects":[],"excludedObjectsCount":0,"exportedCount":1,"missingRefCount":0,"missingReferences":[]}

21
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/heartbeat/ecs/fields/mapping-settings.json Normal file
View file

@ -0,0 +1,21 @@
{
"_meta": {
"version": "1.6.0"
},
"date_detection": false,
"dynamic_templates": [
{
"strings_as_keyword": {
"mapping": {
"type": "keyword",
"ignore_above": 1024,
"fields": {
"text": { "type": "text", "norms" : false }
}
},
"match_mapping_type": "string"
}
}
]
}

16
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/heartbeat/ecs/fields/subset.yml Normal file
View file

@ -0,0 +1,16 @@
---
name: heartbeat
fields:
base:
fields: "*"
log:
fields:
level: {}
logger: {}
event:
fields:
action: {}
outcome: {}
type: {}
url: {}
duration: {}

17
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/heartbeat/ecs/fields/template-settings-legacy.json Normal file
View file

@ -0,0 +1,17 @@
{
"index_patterns": ["kbn-data-forge-fake_stack.heartbeat-*"],
"order": 1,
"settings": {
"index": {
"codec" : "best_compression",
"mapping": {
"total_fields": {
"limit": 2000
}
},
"refresh_interval": "2s"
}
}
}

16
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/heartbeat/ecs/fields/template-settings.json Normal file
View file

@ -0,0 +1,16 @@
{
"index_patterns": ["kbn-data-forge-fake_stack.heartbeat-*"],
"priority": 1,
"template": {
"settings": {
"index": {
"codec" : "best_compression",
"mapping": {
"total_fields": {
"limit": 2000
}
}
}
}
}
}

15
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/heartbeat/ecs/generate.sh Executable file
View file

@ -0,0 +1,15 @@
#!/bin/sh
cd ../../../../../../../../../ecs
NAME=heartbeat
BASE=../kibana/x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/$NAME
ECS=$BASE/ecs
python3 ./scripts/generator.py --ref v8.0.0 \
--subset $ECS/fields/subset.yml \
--out $ECS/ \
--template-settings-legacy $ECS/fields/template-settings-legacy.json \
--template-settings $ECS/fields/template-settings.json \
--mapping-settings $ECS/fields/mapping-settings.json

174
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/heartbeat/ecs/generated/beats/fields.ecs.yml Normal file
View file

@ -0,0 +1,174 @@
# WARNING! Do not edit this file directly, it was generated by the ECS project,
# based on ECS version 8.0.0.
# Please visit https://github.com/elastic/ecs to suggest changes to ECS fields.
- key: ecs
title: ECS
description: ECS Fields.
fields:
- name: '@timestamp'
level: core
required: true
type: date
description: 'Date/time when the event originated.
This is the date/time extracted from the event, typically representing when
the event was generated by the source.
If the event source has no original timestamp, this value is typically populated
by the first time the event was received by the pipeline.
Required field for all events.'
example: '2016-05-23T08:05:34.853Z'
default_field: true
- name: labels
level: core
type: object
object_type: keyword
description: 'Custom key/value pairs.
Can be used to add meta information to events. Should not contain nested objects.
All values are stored as keyword.
Example: `docker` and `k8s` labels.'
example: '{"application": "foo-bar", "env": "production"}'
default_field: true
- name: message
level: core
type: match_only_text
description: 'For log events the message field contains the log message, optimized
for viewing in a log viewer.
For structured logs without an original message field, other fields can be concatenated
to form a human-readable summary of the event.
If multiple messages exist, they can be combined into one message.'
example: Hello World
default_field: true
- name: tags
level: core
type: keyword
ignore_above: 1024
description: List of keywords used to tag each event.
example: '["production", "env2"]'
default_field: true
- name: event
title: Event
group: 2
description: 'The event fields are used for context information about the log
or metric event itself.
A log is defined as an event containing details of something that happened.
Log events must include the time at which the thing happened. Examples of log
events include a process starting on a host, a network packet being sent from
a source to a destination, or a network connection between a client and a server
being initiated or closed. A metric is defined as an event containing one or
more numerical measurements and the time at which the measurement was taken.
Examples of metric events include memory pressure measured on a host and device
temperature. See the `event.kind` definition in this section for additional
details about metric and state events.'
type: group
default_field: true
fields:
- name: action
level: core
type: keyword
ignore_above: 1024
description: '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.'
example: user-password-change
- name: duration
level: core
type: long
format: duration
input_format: nanoseconds
output_format: asMilliseconds
output_precision: 1
description: '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.'
- name: outcome
level: core
type: keyword
ignore_above: 1024
description: 'This is one of four ECS Categorization Fields, and indicates the
lowest level in the ECS category hierarchy.
`event.outcome` simply denotes whether the event represents a success or a
failure from the perspective of the entity that produced the event.
Note that when a single transaction is described in multiple events, each
event may populate different values of `event.outcome`, according to their
perspective.
Also note that in the case of a compound event (a single event that contains
multiple logical events), this field should be populated with the value that
best captures the overall success or failure from the perspective of the event
producer.
Further note that not all events will have an associated outcome. For example,
this field is generally not populated for metric events, events with `event.type:info`,
or any events for which an outcome does not make logical sense.'
example: success
- name: type
level: core
type: keyword
ignore_above: 1024
description: 'This is one of four ECS Categorization Fields, and indicates the
third level in the ECS category hierarchy.
`event.type` represents a categorization "sub-bucket" that, when used along
with the `event.category` field values, enables filtering events down to a
level appropriate for single visualization.
This field is an array. This will allow proper categorization of some events
that fall in multiple event types.'
- name: url
level: extended
type: keyword
ignore_above: 1024
description: 'URL linking to an external system to continue investigation of
this event.
This URL links to another system where in-depth investigation of the specific
occurrence of this event can take place. Alert events, indicated by `event.kind:alert`,
are a common use case for this field.'
example: https://mysystem.example.com/alert/5271dedb-f5b0-4218-87f0-4ac4870a38fe
default_field: false
- name: log
title: Log
group: 2
description: 'Details about the event''s logging mechanism or logging transport.
The log.* fields are typically populated with details about the logging mechanism
used to create and/or transport the event. For example, syslog details belong
under `log.syslog.*`.
The details specific to your event source are typically not logged under `log.*`,
but rather in `event.*` or in other ECS fields.'
type: group
default_field: true
fields:
- name: level
level: core
type: keyword
ignore_above: 1024
description: 'Original log level of the log event.
If the source of the event provides a log level or textual severity, this
is the one that goes in `log.level`. If your source doesn''t specify one,
you may put your event transport''s severity here (e.g. Syslog severity).
Some examples are `warn`, `err`, `i`, `informational`.'
example: error
- name: logger
level: core
type: keyword
ignore_above: 1024
description: The name of the logger inside an application. This is usually the
name of the class which initialized the logger, or can be a custom name.
example: org.elasticsearch.bootstrap.Bootstrap

12
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/heartbeat/ecs/generated/csv/fields.csv Normal file
View file

@ -0,0 +1,12 @@
ECS_Version,Indexed,Field_Set,Field,Type,Level,Normalization,Example,Description
8.0.0,true,base,@timestamp,date,core,,2016-05-23T08:05:34.853Z,Date/time when the event originated.
8.0.0,true,base,labels,object,core,,"{""application"": ""foo-bar"", ""env"": ""production""}",Custom key/value pairs.
8.0.0,true,base,message,match_only_text,core,,Hello World,Log message optimized for viewing in a log viewer.
8.0.0,true,base,tags,keyword,core,array,"[""production"", ""env2""]",List of keywords used to tag each event.
8.0.0,true,event,event.action,keyword,core,,user-password-change,The action captured by the event.
8.0.0,true,event,event.duration,long,core,,,Duration of the event in nanoseconds.
8.0.0,true,event,event.outcome,keyword,core,,success,The outcome of the event. The lowest level categorization field in the hierarchy.
8.0.0,true,event,event.type,keyword,core,array,,Event type. The third categorization field in the hierarchy.
8.0.0,true,event,event.url,keyword,extended,,https://mysystem.example.com/alert/5271dedb-f5b0-4218-87f0-4ac4870a38fe,Event investigation URL
8.0.0,true,log,log.level,keyword,core,,error,Log level of the log event.
8.0.0,true,log,log.logger,keyword,core,,org.elasticsearch.bootstrap.Bootstrap,Name of the logger.
1 ECS_Version Indexed Field_Set Field Type Level Normalization Example Description
2 8.0.0 true base @timestamp date core 2016-05-23T08:05:34.853Z Date/time when the event originated.
3 8.0.0 true base labels object core {"application": "foo-bar", "env": "production"} Custom key/value pairs.
4 8.0.0 true base message match_only_text core Hello World Log message optimized for viewing in a log viewer.
5 8.0.0 true base tags keyword core array ["production", "env2"] List of keywords used to tag each event.
6 8.0.0 true event event.action keyword core user-password-change The action captured by the event.
7 8.0.0 true event event.duration long core Duration of the event in nanoseconds.
8 8.0.0 true event event.outcome keyword core success The outcome of the event. The lowest level categorization field in the hierarchy.
9 8.0.0 true event event.type keyword core array Event type. The third categorization field in the hierarchy.
10 8.0.0 true event event.url keyword extended https://mysystem.example.com/alert/5271dedb-f5b0-4218-87f0-4ac4870a38fe Event investigation URL
11 8.0.0 true log log.level keyword core error Log level of the log event.
12 8.0.0 true log log.logger keyword core org.elasticsearch.bootstrap.Bootstrap Name of the logger.

320
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/heartbeat/ecs/generated/ecs/ecs_flat.yml Normal file
View file

@ -0,0 +1,320 @@
'@timestamp':
dashed_name: timestamp
description: 'Date/time when the event originated.
This is the date/time extracted from the event, typically representing when the
event was generated by the source.
If the event source has no original timestamp, this value is typically populated
by the first time the event was received by the pipeline.
Required field for all events.'
example: '2016-05-23T08:05:34.853Z'
flat_name: '@timestamp'
level: core
name: '@timestamp'
normalize: []
required: true
short: Date/time when the event originated.
type: date
event.action:
dashed_name: event-action
description: '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.'
example: user-password-change
flat_name: event.action
ignore_above: 1024
level: core
name: action
normalize: []
short: The action captured by the event.
type: keyword
event.duration:
dashed_name: event-duration
description: '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.'
flat_name: event.duration
format: duration
input_format: nanoseconds
level: core
name: duration
normalize: []
output_format: asMilliseconds
output_precision: 1
short: Duration of the event in nanoseconds.
type: long
event.outcome:
allowed_values:
- description: Indicates that this event describes a failed result. A common example
is `event.category:file AND event.type:access AND event.outcome:failure` to
indicate that a file access was attempted, but was not successful.
name: failure
- description: Indicates that this event describes a successful result. A common
example is `event.category:file AND event.type:create AND event.outcome:success`
to indicate that a file was successfully created.
name: success
- description: Indicates that this event describes only an attempt for which the
result is unknown from the perspective of the event producer. For example, if
the event contains information only about the request side of a transaction
that results in a response, populating `event.outcome:unknown` in the request
event is appropriate. The unknown value should not be used when an outcome doesn't
make logical sense for the event. In such cases `event.outcome` should not be
populated.
name: unknown
dashed_name: event-outcome
description: 'This is one of four ECS Categorization Fields, and indicates the lowest
level in the ECS category hierarchy.
`event.outcome` simply denotes whether the event represents a success or a failure
from the perspective of the entity that produced the event.
Note that when a single transaction is described in multiple events, each event
may populate different values of `event.outcome`, according to their perspective.
Also note that in the case of a compound event (a single event that contains multiple
logical events), this field should be populated with the value that best captures
the overall success or failure from the perspective of the event producer.
Further note that not all events will have an associated outcome. For example,
this field is generally not populated for metric events, events with `event.type:info`,
or any events for which an outcome does not make logical sense.'
example: success
flat_name: event.outcome
ignore_above: 1024
level: core
name: outcome
normalize: []
short: The outcome of the event. The lowest level categorization field in the hierarchy.
type: keyword
event.type:
allowed_values:
- description: The access event type is used for the subset of events within a category
that indicate that something was accessed. Common examples include `event.category:database
AND event.type:access`, or `event.category:file AND event.type:access`. Note
for file access, both directory listings and file opens should be included in
this subcategory. You can further distinguish access operations using the ECS
`event.action` field.
name: access
- description: 'The admin event type is used for the subset of events within a category
that are related to admin objects. For example, administrative changes within
an IAM framework that do not specifically affect a user or group (e.g., adding
new applications to a federation solution or connecting discrete forests in
Active Directory) would fall into this subcategory. Common example: `event.category:iam
AND event.type:change AND event.type:admin`. You can further distinguish admin
operations using the ECS `event.action` field.'
name: admin
- description: The allowed event type is used for the subset of events within a
category that indicate that something was allowed. Common examples include `event.category:network
AND event.type:connection AND event.type:allowed` (to indicate a network firewall
event for which the firewall disposition was to allow the connection to complete)
and `event.category:intrusion_detection AND event.type:allowed` (to indicate
a network intrusion prevention system event for which the IPS disposition was
to allow the connection to complete). You can further distinguish allowed operations
using the ECS `event.action` field, populating with values of your choosing,
such as "allow", "detect", or "pass".
name: allowed
- description: The change event type is used for the subset of events within a category
that indicate that something has changed. If semantics best describe an event
as modified, then include them in this subcategory. Common examples include
`event.category:process AND event.type:change`, and `event.category:file AND
event.type:change`. You can further distinguish change operations using the
ECS `event.action` field.
name: change
- description: Used primarily with `event.category:network` this value is used for
the subset of network traffic that includes sufficient information for the event
to be included in flow or connection analysis. Events in this subcategory will
contain at least source and destination IP addresses, source and destination
TCP/UDP ports, and will usually contain counts of bytes and/or packets transferred.
Events in this subcategory may contain unidirectional or bidirectional information,
including summary information. Use this subcategory to visualize and analyze
network connections. Flow analysis, including Netflow, IPFIX, and other flow-related
events fit in this subcategory. Note that firewall events from many Next-Generation
Firewall (NGFW) devices will also fit into this subcategory. A common filter
for flow/connection information would be `event.category:network AND event.type:connection
AND event.type:end` (to view or analyze all completed network connections, ignoring
mid-flow reports). You can further distinguish connection events using the ECS
`event.action` field, populating with values of your choosing, such as "timeout",
or "reset".
name: connection
- description: The "creation" event type is used for the subset of events within
a category that indicate that something was created. A common example is `event.category:file
AND event.type:creation`.
name: creation
- description: The deletion event type is used for the subset of events within a
category that indicate that something was deleted. A common example is `event.category:file
AND event.type:deletion` to indicate that a file has been deleted.
name: deletion
- description: The denied event type is used for the subset of events within a category
that indicate that something was denied. Common examples include `event.category:network
AND event.type:denied` (to indicate a network firewall event for which the firewall
disposition was to deny the connection) and `event.category:intrusion_detection
AND event.type:denied` (to indicate a network intrusion prevention system event
for which the IPS disposition was to deny the connection to complete). You can
further distinguish denied operations using the ECS `event.action` field, populating
with values of your choosing, such as "blocked", "dropped", or "quarantined".
name: denied
- description: The end event type is used for the subset of events within a category
that indicate something has ended. A common example is `event.category:process
AND event.type:end`.
name: end
- description: The error event type is used for the subset of events within a category
that indicate or describe an error. A common example is `event.category:database
AND event.type:error`. Note that pipeline errors that occur during the event
ingestion process should not use this `event.type` value. Instead, they should
use `event.kind:pipeline_error`.
name: error
- description: 'The group event type is used for the subset of events within a category
that are related to group objects. Common example: `event.category:iam AND event.type:creation
AND event.type:group`. You can further distinguish group operations using the
ECS `event.action` field.'
name: group
- description: 'The indicator event type is used for the subset of events within
a category that contain details about indicators of compromise (IOCs).
A common example is `event.category:threat AND event.type:indicator`.'
name: indicator
- description: The info event type is used for the subset of events within a category
that indicate that they are purely informational, and don't report a state change,
or any type of action. For example, an initial run of a file integrity monitoring
system (FIM), where an agent reports all files under management, would fall
into the "info" subcategory. Similarly, an event containing a dump of all currently
running processes (as opposed to reporting that a process started/ended) would
fall into the "info" subcategory. An additional common examples is `event.category:intrusion_detection
AND event.type:info`.
name: info
- description: The installation event type is used for the subset of events within
a category that indicate that something was installed. A common example is `event.category:package`
AND `event.type:installation`.
name: installation
- description: The protocol event type is used for the subset of events within a
category that indicate that they contain protocol details or analysis, beyond
simply identifying the protocol. Generally, network events that contain specific
protocol details will fall into this subcategory. A common example is `event.category:network
AND event.type:protocol AND event.type:connection AND event.type:end` (to indicate
that the event is a network connection event sent at the end of a connection
that also includes a protocol detail breakdown). Note that events that only
indicate the name or id of the protocol should not use the protocol value. Further
note that when the protocol subcategory is used, the identified protocol is
populated in the ECS `network.protocol` field.
name: protocol
- description: The start event type is used for the subset of events within a category
that indicate something has started. A common example is `event.category:process
AND event.type:start`.
name: start
- description: 'The user event type is used for the subset of events within a category
that are related to user objects. Common example: `event.category:iam AND event.type:deletion
AND event.type:user`. You can further distinguish user operations using the
ECS `event.action` field.'
name: user
dashed_name: event-type
description: 'This is one of four ECS Categorization Fields, and indicates the third
level in the ECS category hierarchy.
`event.type` represents a categorization "sub-bucket" that, when used along with
the `event.category` field values, enables filtering events down to a level appropriate
for single visualization.
This field is an array. This will allow proper categorization of some events that
fall in multiple event types.'
flat_name: event.type
ignore_above: 1024
level: core
name: type
normalize:
- array
short: Event type. The third categorization field in the hierarchy.
type: keyword
event.url:
dashed_name: event-url
description: 'URL linking to an external system to continue investigation of this
event.
This URL links to another system where in-depth investigation of the specific
occurrence of this event can take place. Alert events, indicated by `event.kind:alert`,
are a common use case for this field.'
example: https://mysystem.example.com/alert/5271dedb-f5b0-4218-87f0-4ac4870a38fe
flat_name: event.url
ignore_above: 1024
level: extended
name: url
normalize: []
short: Event investigation URL
type: keyword
labels:
dashed_name: labels
description: 'Custom key/value pairs.
Can be used to add meta information to events. Should not contain nested objects.
All values are stored as keyword.
Example: `docker` and `k8s` labels.'
example: '{"application": "foo-bar", "env": "production"}'
flat_name: labels
level: core
name: labels
normalize: []
object_type: keyword
short: Custom key/value pairs.
type: object
log.level:
dashed_name: log-level
description: 'Original log level of the log event.
If the source of the event provides a log level or textual severity, this is the
one that goes in `log.level`. If your source doesn''t specify one, you may put
your event transport''s severity here (e.g. Syslog severity).
Some examples are `warn`, `err`, `i`, `informational`.'
example: error
flat_name: log.level
ignore_above: 1024
level: core
name: level
normalize: []
short: Log level of the log event.
type: keyword
log.logger:
dashed_name: log-logger
description: The name of the logger inside an application. This is usually the name
of the class which initialized the logger, or can be a custom name.
example: org.elasticsearch.bootstrap.Bootstrap
flat_name: log.logger
ignore_above: 1024
level: core
name: logger
normalize: []
short: Name of the logger.
type: keyword
message:
dashed_name: message
description: 'For log events the message field contains the log message, optimized
for viewing in a log viewer.
For structured logs without an original message field, other fields can be concatenated
to form a human-readable summary of the event.
If multiple messages exist, they can be combined into one message.'
example: Hello World
flat_name: message
level: core
name: message
normalize: []
short: Log message optimized for viewing in a log viewer.
type: match_only_text
tags:
dashed_name: tags
description: List of keywords used to tag each event.
example: '["production", "env2"]'
flat_name: tags
ignore_above: 1024
level: core
name: tags
normalize:
- array
short: List of keywords used to tag each event.
type: keyword

376
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/heartbeat/ecs/generated/ecs/ecs_nested.yml Normal file
View file

@ -0,0 +1,376 @@
base:
description: The `base` field set contains all fields which are at the root of the
events. These fields are common across all types of events.
fields:
'@timestamp':
dashed_name: timestamp
description: 'Date/time when the event originated.
This is the date/time extracted from the event, typically representing when
the event was generated by the source.
If the event source has no original timestamp, this value is typically populated
by the first time the event was received by the pipeline.
Required field for all events.'
example: '2016-05-23T08:05:34.853Z'
flat_name: '@timestamp'
level: core
name: '@timestamp'
normalize: []
required: true
short: Date/time when the event originated.
type: date
labels:
dashed_name: labels
description: 'Custom key/value pairs.
Can be used to add meta information to events. Should not contain nested objects.
All values are stored as keyword.
Example: `docker` and `k8s` labels.'
example: '{"application": "foo-bar", "env": "production"}'
flat_name: labels
level: core
name: labels
normalize: []
object_type: keyword
short: Custom key/value pairs.
type: object
message:
dashed_name: message
description: 'For log events the message field contains the log message, optimized
for viewing in a log viewer.
For structured logs without an original message field, other fields can be
concatenated to form a human-readable summary of the event.
If multiple messages exist, they can be combined into one message.'
example: Hello World
flat_name: message
level: core
name: message
normalize: []
short: Log message optimized for viewing in a log viewer.
type: match_only_text
tags:
dashed_name: tags
description: List of keywords used to tag each event.
example: '["production", "env2"]'
flat_name: tags
ignore_above: 1024
level: core
name: tags
normalize:
- array
short: List of keywords used to tag each event.
type: keyword
group: 1
name: base
prefix: ''
root: true
short: All fields defined directly at the root of the events.
title: Base
type: group
event:
description: 'The event fields are used for context information about the log or
metric event itself.
A log is defined as an event containing details of something that happened. Log
events must include the time at which the thing happened. Examples of log events
include a process starting on a host, a network packet being sent from a source
to a destination, or a network connection between a client and a server being
initiated or closed. A metric is defined as an event containing one or more numerical
measurements and the time at which the measurement was taken. Examples of metric
events include memory pressure measured on a host and device temperature. See
the `event.kind` definition in this section for additional details about metric
and state events.'
fields:
event.action:
dashed_name: event-action
description: '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.'
example: user-password-change
flat_name: event.action
ignore_above: 1024
level: core
name: action
normalize: []
short: The action captured by the event.
type: keyword
event.duration:
dashed_name: event-duration
description: '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.'
flat_name: event.duration
format: duration
input_format: nanoseconds
level: core
name: duration
normalize: []
output_format: asMilliseconds
output_precision: 1
short: Duration of the event in nanoseconds.
type: long
event.outcome:
allowed_values:
- description: Indicates that this event describes a failed result. A common
example is `event.category:file AND event.type:access AND event.outcome:failure`
to indicate that a file access was attempted, but was not successful.
name: failure
- description: Indicates that this event describes a successful result. A common
example is `event.category:file AND event.type:create AND event.outcome:success`
to indicate that a file was successfully created.
name: success
- description: Indicates that this event describes only an attempt for which
the result is unknown from the perspective of the event producer. For example,
if the event contains information only about the request side of a transaction
that results in a response, populating `event.outcome:unknown` in the request
event is appropriate. The unknown value should not be used when an outcome
doesn't make logical sense for the event. In such cases `event.outcome`
should not be populated.
name: unknown
dashed_name: event-outcome
description: 'This is one of four ECS Categorization Fields, and indicates the
lowest level in the ECS category hierarchy.
`event.outcome` simply denotes whether the event represents a success or a
failure from the perspective of the entity that produced the event.
Note that when a single transaction is described in multiple events, each
event may populate different values of `event.outcome`, according to their
perspective.
Also note that in the case of a compound event (a single event that contains
multiple logical events), this field should be populated with the value that
best captures the overall success or failure from the perspective of the event
producer.
Further note that not all events will have an associated outcome. For example,
this field is generally not populated for metric events, events with `event.type:info`,
or any events for which an outcome does not make logical sense.'
example: success
flat_name: event.outcome
ignore_above: 1024
level: core
name: outcome
normalize: []
short: The outcome of the event. The lowest level categorization field in the
hierarchy.
type: keyword
event.type:
allowed_values:
- description: The access event type is used for the subset of events within
a category that indicate that something was accessed. Common examples include
`event.category:database AND event.type:access`, or `event.category:file
AND event.type:access`. Note for file access, both directory listings and
file opens should be included in this subcategory. You can further distinguish
access operations using the ECS `event.action` field.
name: access
- description: 'The admin event type is used for the subset of events within
a category that are related to admin objects. For example, administrative
changes within an IAM framework that do not specifically affect a user or
group (e.g., adding new applications to a federation solution or connecting
discrete forests in Active Directory) would fall into this subcategory.
Common example: `event.category:iam AND event.type:change AND event.type:admin`.
You can further distinguish admin operations using the ECS `event.action`
field.'
name: admin
- description: The allowed event type is used for the subset of events within
a category that indicate that something was allowed. Common examples include
`event.category:network AND event.type:connection AND event.type:allowed`
(to indicate a network firewall event for which the firewall disposition
was to allow the connection to complete) and `event.category:intrusion_detection
AND event.type:allowed` (to indicate a network intrusion prevention system
event for which the IPS disposition was to allow the connection to complete).
You can further distinguish allowed operations using the ECS `event.action`
field, populating with values of your choosing, such as "allow", "detect",
or "pass".
name: allowed
- description: The change event type is used for the subset of events within
a category that indicate that something has changed. If semantics best describe
an event as modified, then include them in this subcategory. Common examples
include `event.category:process AND event.type:change`, and `event.category:file
AND event.type:change`. You can further distinguish change operations using
the ECS `event.action` field.
name: change
- description: Used primarily with `event.category:network` this value is used
for the subset of network traffic that includes sufficient information for
the event to be included in flow or connection analysis. Events in this
subcategory will contain at least source and destination IP addresses, source
and destination TCP/UDP ports, and will usually contain counts of bytes
and/or packets transferred. Events in this subcategory may contain unidirectional
or bidirectional information, including summary information. Use this subcategory
to visualize and analyze network connections. Flow analysis, including Netflow,
IPFIX, and other flow-related events fit in this subcategory. Note that
firewall events from many Next-Generation Firewall (NGFW) devices will also
fit into this subcategory. A common filter for flow/connection information
would be `event.category:network AND event.type:connection AND event.type:end`
(to view or analyze all completed network connections, ignoring mid-flow
reports). You can further distinguish connection events using the ECS `event.action`
field, populating with values of your choosing, such as "timeout", or "reset".
name: connection
- description: The "creation" event type is used for the subset of events within
a category that indicate that something was created. A common example is
`event.category:file AND event.type:creation`.
name: creation
- description: The deletion event type is used for the subset of events within
a category that indicate that something was deleted. A common example is
`event.category:file AND event.type:deletion` to indicate that a file has
been deleted.
name: deletion
- description: The denied event type is used for the subset of events within
a category that indicate that something was denied. Common examples include
`event.category:network AND event.type:denied` (to indicate a network firewall
event for which the firewall disposition was to deny the connection) and
`event.category:intrusion_detection AND event.type:denied` (to indicate
a network intrusion prevention system event for which the IPS disposition
was to deny the connection to complete). You can further distinguish denied
operations using the ECS `event.action` field, populating with values of
your choosing, such as "blocked", "dropped", or "quarantined".
name: denied
- description: The end event type is used for the subset of events within a
category that indicate something has ended. A common example is `event.category:process
AND event.type:end`.
name: end
- description: The error event type is used for the subset of events within
a category that indicate or describe an error. A common example is `event.category:database
AND event.type:error`. Note that pipeline errors that occur during the event
ingestion process should not use this `event.type` value. Instead, they
should use `event.kind:pipeline_error`.
name: error
- description: 'The group event type is used for the subset of events within
a category that are related to group objects. Common example: `event.category:iam
AND event.type:creation AND event.type:group`. You can further distinguish
group operations using the ECS `event.action` field.'
name: group
- description: 'The indicator event type is used for the subset of events within
a category that contain details about indicators of compromise (IOCs).
A common example is `event.category:threat AND event.type:indicator`.'
name: indicator
- description: The info event type is used for the subset of events within a
category that indicate that they are purely informational, and don't report
a state change, or any type of action. For example, an initial run of a
file integrity monitoring system (FIM), where an agent reports all files
under management, would fall into the "info" subcategory. Similarly, an
event containing a dump of all currently running processes (as opposed to
reporting that a process started/ended) would fall into the "info" subcategory.
An additional common examples is `event.category:intrusion_detection AND
event.type:info`.
name: info
- description: The installation event type is used for the subset of events
within a category that indicate that something was installed. A common example
is `event.category:package` AND `event.type:installation`.
name: installation
- description: The protocol event type is used for the subset of events within
a category that indicate that they contain protocol details or analysis,
beyond simply identifying the protocol. Generally, network events that contain
specific protocol details will fall into this subcategory. A common example
is `event.category:network AND event.type:protocol AND event.type:connection
AND event.type:end` (to indicate that the event is a network connection
event sent at the end of a connection that also includes a protocol detail
breakdown). Note that events that only indicate the name or id of the protocol
should not use the protocol value. Further note that when the protocol subcategory
is used, the identified protocol is populated in the ECS `network.protocol`
field.
name: protocol
- description: The start event type is used for the subset of events within
a category that indicate something has started. A common example is `event.category:process
AND event.type:start`.
name: start
- description: 'The user event type is used for the subset of events within
a category that are related to user objects. Common example: `event.category:iam
AND event.type:deletion AND event.type:user`. You can further distinguish
user operations using the ECS `event.action` field.'
name: user
dashed_name: event-type
description: 'This is one of four ECS Categorization Fields, and indicates the
third level in the ECS category hierarchy.
`event.type` represents a categorization "sub-bucket" that, when used along
with the `event.category` field values, enables filtering events down to a
level appropriate for single visualization.
This field is an array. This will allow proper categorization of some events
that fall in multiple event types.'
flat_name: event.type
ignore_above: 1024
level: core
name: type
normalize:
- array
short: Event type. The third categorization field in the hierarchy.
type: keyword
event.url:
dashed_name: event-url
description: 'URL linking to an external system to continue investigation of
this event.
This URL links to another system where in-depth investigation of the specific
occurrence of this event can take place. Alert events, indicated by `event.kind:alert`,
are a common use case for this field.'
example: https://mysystem.example.com/alert/5271dedb-f5b0-4218-87f0-4ac4870a38fe
flat_name: event.url
ignore_above: 1024
level: extended
name: url
normalize: []
short: Event investigation URL
type: keyword
group: 2
name: event
prefix: event.
short: Fields breaking down the event details.
title: Event
type: group
log:
description: 'Details about the event''s logging mechanism or logging transport.
The log.* fields are typically populated with details about the logging mechanism
used to create and/or transport the event. For example, syslog details belong
under `log.syslog.*`.
The details specific to your event source are typically not logged under `log.*`,
but rather in `event.*` or in other ECS fields.'
fields:
log.level:
dashed_name: log-level
description: 'Original log level of the log event.
If the source of the event provides a log level or textual severity, this
is the one that goes in `log.level`. If your source doesn''t specify one,
you may put your event transport''s severity here (e.g. Syslog severity).
Some examples are `warn`, `err`, `i`, `informational`.'
example: error
flat_name: log.level
ignore_above: 1024
level: core
name: level
normalize: []
short: Log level of the log event.
type: keyword
log.logger:
dashed_name: log-logger
description: The name of the logger inside an application. This is usually the
name of the class which initialized the logger, or can be a custom name.
example: org.elasticsearch.bootstrap.Bootstrap
flat_name: log.logger
ignore_above: 1024
level: core
name: logger
normalize: []
short: Name of the logger.
type: keyword
group: 2
name: log
prefix: log.
short: Details about the event's logging mechanism.
title: Log
type: group

320
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/heartbeat/ecs/generated/ecs/subset/heartbeat/ecs_flat.yml Normal file
View file

@ -0,0 +1,320 @@
'@timestamp':
dashed_name: timestamp
description: 'Date/time when the event originated.
This is the date/time extracted from the event, typically representing when the
event was generated by the source.
If the event source has no original timestamp, this value is typically populated
by the first time the event was received by the pipeline.
Required field for all events.'
example: '2016-05-23T08:05:34.853Z'
flat_name: '@timestamp'
level: core
name: '@timestamp'
normalize: []
required: true
short: Date/time when the event originated.
type: date
event.action:
dashed_name: event-action
description: '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.'
example: user-password-change
flat_name: event.action
ignore_above: 1024
level: core
name: action
normalize: []
short: The action captured by the event.
type: keyword
event.duration:
dashed_name: event-duration
description: '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.'
flat_name: event.duration
format: duration
input_format: nanoseconds
level: core
name: duration
normalize: []
output_format: asMilliseconds
output_precision: 1
short: Duration of the event in nanoseconds.
type: long
event.outcome:
allowed_values:
- description: Indicates that this event describes a failed result. A common example
is `event.category:file AND event.type:access AND event.outcome:failure` to
indicate that a file access was attempted, but was not successful.
name: failure
- description: Indicates that this event describes a successful result. A common
example is `event.category:file AND event.type:create AND event.outcome:success`
to indicate that a file was successfully created.
name: success
- description: Indicates that this event describes only an attempt for which the
result is unknown from the perspective of the event producer. For example, if
the event contains information only about the request side of a transaction
that results in a response, populating `event.outcome:unknown` in the request
event is appropriate. The unknown value should not be used when an outcome doesn't
make logical sense for the event. In such cases `event.outcome` should not be
populated.
name: unknown
dashed_name: event-outcome
description: 'This is one of four ECS Categorization Fields, and indicates the lowest
level in the ECS category hierarchy.
`event.outcome` simply denotes whether the event represents a success or a failure
from the perspective of the entity that produced the event.
Note that when a single transaction is described in multiple events, each event
may populate different values of `event.outcome`, according to their perspective.
Also note that in the case of a compound event (a single event that contains multiple
logical events), this field should be populated with the value that best captures
the overall success or failure from the perspective of the event producer.
Further note that not all events will have an associated outcome. For example,
this field is generally not populated for metric events, events with `event.type:info`,
or any events for which an outcome does not make logical sense.'
example: success
flat_name: event.outcome
ignore_above: 1024
level: core
name: outcome
normalize: []
short: The outcome of the event. The lowest level categorization field in the hierarchy.
type: keyword
event.type:
allowed_values:
- description: The access event type is used for the subset of events within a category
that indicate that something was accessed. Common examples include `event.category:database
AND event.type:access`, or `event.category:file AND event.type:access`. Note
for file access, both directory listings and file opens should be included in
this subcategory. You can further distinguish access operations using the ECS
`event.action` field.
name: access
- description: 'The admin event type is used for the subset of events within a category
that are related to admin objects. For example, administrative changes within
an IAM framework that do not specifically affect a user or group (e.g., adding
new applications to a federation solution or connecting discrete forests in
Active Directory) would fall into this subcategory. Common example: `event.category:iam
AND event.type:change AND event.type:admin`. You can further distinguish admin
operations using the ECS `event.action` field.'
name: admin
- description: The allowed event type is used for the subset of events within a
category that indicate that something was allowed. Common examples include `event.category:network
AND event.type:connection AND event.type:allowed` (to indicate a network firewall
event for which the firewall disposition was to allow the connection to complete)
and `event.category:intrusion_detection AND event.type:allowed` (to indicate
a network intrusion prevention system event for which the IPS disposition was
to allow the connection to complete). You can further distinguish allowed operations
using the ECS `event.action` field, populating with values of your choosing,
such as "allow", "detect", or "pass".
name: allowed
- description: The change event type is used for the subset of events within a category
that indicate that something has changed. If semantics best describe an event
as modified, then include them in this subcategory. Common examples include
`event.category:process AND event.type:change`, and `event.category:file AND
event.type:change`. You can further distinguish change operations using the
ECS `event.action` field.
name: change
- description: Used primarily with `event.category:network` this value is used for
the subset of network traffic that includes sufficient information for the event
to be included in flow or connection analysis. Events in this subcategory will
contain at least source and destination IP addresses, source and destination
TCP/UDP ports, and will usually contain counts of bytes and/or packets transferred.
Events in this subcategory may contain unidirectional or bidirectional information,
including summary information. Use this subcategory to visualize and analyze
network connections. Flow analysis, including Netflow, IPFIX, and other flow-related
events fit in this subcategory. Note that firewall events from many Next-Generation
Firewall (NGFW) devices will also fit into this subcategory. A common filter
for flow/connection information would be `event.category:network AND event.type:connection
AND event.type:end` (to view or analyze all completed network connections, ignoring
mid-flow reports). You can further distinguish connection events using the ECS
`event.action` field, populating with values of your choosing, such as "timeout",
or "reset".
name: connection
- description: The "creation" event type is used for the subset of events within
a category that indicate that something was created. A common example is `event.category:file
AND event.type:creation`.
name: creation
- description: The deletion event type is used for the subset of events within a
category that indicate that something was deleted. A common example is `event.category:file
AND event.type:deletion` to indicate that a file has been deleted.
name: deletion
- description: The denied event type is used for the subset of events within a category
that indicate that something was denied. Common examples include `event.category:network
AND event.type:denied` (to indicate a network firewall event for which the firewall
disposition was to deny the connection) and `event.category:intrusion_detection
AND event.type:denied` (to indicate a network intrusion prevention system event
for which the IPS disposition was to deny the connection to complete). You can
further distinguish denied operations using the ECS `event.action` field, populating
with values of your choosing, such as "blocked", "dropped", or "quarantined".
name: denied
- description: The end event type is used for the subset of events within a category
that indicate something has ended. A common example is `event.category:process
AND event.type:end`.
name: end
- description: The error event type is used for the subset of events within a category
that indicate or describe an error. A common example is `event.category:database
AND event.type:error`. Note that pipeline errors that occur during the event
ingestion process should not use this `event.type` value. Instead, they should
use `event.kind:pipeline_error`.
name: error
- description: 'The group event type is used for the subset of events within a category
that are related to group objects. Common example: `event.category:iam AND event.type:creation
AND event.type:group`. You can further distinguish group operations using the
ECS `event.action` field.'
name: group
- description: 'The indicator event type is used for the subset of events within
a category that contain details about indicators of compromise (IOCs).
A common example is `event.category:threat AND event.type:indicator`.'
name: indicator
- description: The info event type is used for the subset of events within a category
that indicate that they are purely informational, and don't report a state change,
or any type of action. For example, an initial run of a file integrity monitoring
system (FIM), where an agent reports all files under management, would fall
into the "info" subcategory. Similarly, an event containing a dump of all currently
running processes (as opposed to reporting that a process started/ended) would
fall into the "info" subcategory. An additional common examples is `event.category:intrusion_detection
AND event.type:info`.
name: info
- description: The installation event type is used for the subset of events within
a category that indicate that something was installed. A common example is `event.category:package`
AND `event.type:installation`.
name: installation
- description: The protocol event type is used for the subset of events within a
category that indicate that they contain protocol details or analysis, beyond
simply identifying the protocol. Generally, network events that contain specific
protocol details will fall into this subcategory. A common example is `event.category:network
AND event.type:protocol AND event.type:connection AND event.type:end` (to indicate
that the event is a network connection event sent at the end of a connection
that also includes a protocol detail breakdown). Note that events that only
indicate the name or id of the protocol should not use the protocol value. Further
note that when the protocol subcategory is used, the identified protocol is
populated in the ECS `network.protocol` field.
name: protocol
- description: The start event type is used for the subset of events within a category
that indicate something has started. A common example is `event.category:process
AND event.type:start`.
name: start
- description: 'The user event type is used for the subset of events within a category
that are related to user objects. Common example: `event.category:iam AND event.type:deletion
AND event.type:user`. You can further distinguish user operations using the
ECS `event.action` field.'
name: user
dashed_name: event-type
description: 'This is one of four ECS Categorization Fields, and indicates the third
level in the ECS category hierarchy.
`event.type` represents a categorization "sub-bucket" that, when used along with
the `event.category` field values, enables filtering events down to a level appropriate
for single visualization.
This field is an array. This will allow proper categorization of some events that
fall in multiple event types.'
flat_name: event.type
ignore_above: 1024
level: core
name: type
normalize:
- array
short: Event type. The third categorization field in the hierarchy.
type: keyword
event.url:
dashed_name: event-url
description: 'URL linking to an external system to continue investigation of this
event.
This URL links to another system where in-depth investigation of the specific
occurrence of this event can take place. Alert events, indicated by `event.kind:alert`,
are a common use case for this field.'
example: https://mysystem.example.com/alert/5271dedb-f5b0-4218-87f0-4ac4870a38fe
flat_name: event.url
ignore_above: 1024
level: extended
name: url
normalize: []
short: Event investigation URL
type: keyword
labels:
dashed_name: labels
description: 'Custom key/value pairs.
Can be used to add meta information to events. Should not contain nested objects.
All values are stored as keyword.
Example: `docker` and `k8s` labels.'
example: '{"application": "foo-bar", "env": "production"}'
flat_name: labels
level: core
name: labels
normalize: []
object_type: keyword
short: Custom key/value pairs.
type: object
log.level:
dashed_name: log-level
description: 'Original log level of the log event.
If the source of the event provides a log level or textual severity, this is the
one that goes in `log.level`. If your source doesn''t specify one, you may put
your event transport''s severity here (e.g. Syslog severity).
Some examples are `warn`, `err`, `i`, `informational`.'
example: error
flat_name: log.level
ignore_above: 1024
level: core
name: level
normalize: []
short: Log level of the log event.
type: keyword
log.logger:
dashed_name: log-logger
description: The name of the logger inside an application. This is usually the name
of the class which initialized the logger, or can be a custom name.
example: org.elasticsearch.bootstrap.Bootstrap
flat_name: log.logger
ignore_above: 1024
level: core
name: logger
normalize: []
short: Name of the logger.
type: keyword
message:
dashed_name: message
description: 'For log events the message field contains the log message, optimized
for viewing in a log viewer.
For structured logs without an original message field, other fields can be concatenated
to form a human-readable summary of the event.
If multiple messages exist, they can be combined into one message.'
example: Hello World
flat_name: message
level: core
name: message
normalize: []
short: Log message optimized for viewing in a log viewer.
type: match_only_text
tags:
dashed_name: tags
description: List of keywords used to tag each event.
example: '["production", "env2"]'
flat_name: tags
ignore_above: 1024
level: core
name: tags
normalize:
- array
short: List of keywords used to tag each event.
type: keyword

376
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/heartbeat/ecs/generated/ecs/subset/heartbeat/ecs_nested.yml Normal file
View file

@ -0,0 +1,376 @@
base:
description: The `base` field set contains all fields which are at the root of the
events. These fields are common across all types of events.
fields:
'@timestamp':
dashed_name: timestamp
description: 'Date/time when the event originated.
This is the date/time extracted from the event, typically representing when
the event was generated by the source.
If the event source has no original timestamp, this value is typically populated
by the first time the event was received by the pipeline.
Required field for all events.'
example: '2016-05-23T08:05:34.853Z'
flat_name: '@timestamp'
level: core
name: '@timestamp'
normalize: []
required: true
short: Date/time when the event originated.
type: date
labels:
dashed_name: labels
description: 'Custom key/value pairs.
Can be used to add meta information to events. Should not contain nested objects.
All values are stored as keyword.
Example: `docker` and `k8s` labels.'
example: '{"application": "foo-bar", "env": "production"}'
flat_name: labels
level: core
name: labels
normalize: []
object_type: keyword
short: Custom key/value pairs.
type: object
message:
dashed_name: message
description: 'For log events the message field contains the log message, optimized
for viewing in a log viewer.
For structured logs without an original message field, other fields can be
concatenated to form a human-readable summary of the event.
If multiple messages exist, they can be combined into one message.'
example: Hello World
flat_name: message
level: core
name: message
normalize: []
short: Log message optimized for viewing in a log viewer.
type: match_only_text
tags:
dashed_name: tags
description: List of keywords used to tag each event.
example: '["production", "env2"]'
flat_name: tags
ignore_above: 1024
level: core
name: tags
normalize:
- array
short: List of keywords used to tag each event.
type: keyword
group: 1
name: base
prefix: ''
root: true
short: All fields defined directly at the root of the events.
title: Base
type: group
event:
description: 'The event fields are used for context information about the log or
metric event itself.
A log is defined as an event containing details of something that happened. Log
events must include the time at which the thing happened. Examples of log events
include a process starting on a host, a network packet being sent from a source
to a destination, or a network connection between a client and a server being
initiated or closed. A metric is defined as an event containing one or more numerical
measurements and the time at which the measurement was taken. Examples of metric
events include memory pressure measured on a host and device temperature. See
the `event.kind` definition in this section for additional details about metric
and state events.'
fields:
event.action:
dashed_name: event-action
description: '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.'
example: user-password-change
flat_name: event.action
ignore_above: 1024
level: core
name: action
normalize: []
short: The action captured by the event.
type: keyword
event.duration:
dashed_name: event-duration
description: '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.'
flat_name: event.duration
format: duration
input_format: nanoseconds
level: core
name: duration
normalize: []
output_format: asMilliseconds
output_precision: 1
short: Duration of the event in nanoseconds.
type: long
event.outcome:
allowed_values:
- description: Indicates that this event describes a failed result. A common
example is `event.category:file AND event.type:access AND event.outcome:failure`
to indicate that a file access was attempted, but was not successful.
name: failure
- description: Indicates that this event describes a successful result. A common
example is `event.category:file AND event.type:create AND event.outcome:success`
to indicate that a file was successfully created.
name: success
- description: Indicates that this event describes only an attempt for which
the result is unknown from the perspective of the event producer. For example,
if the event contains information only about the request side of a transaction
that results in a response, populating `event.outcome:unknown` in the request
event is appropriate. The unknown value should not be used when an outcome
doesn't make logical sense for the event. In such cases `event.outcome`
should not be populated.
name: unknown
dashed_name: event-outcome
description: 'This is one of four ECS Categorization Fields, and indicates the
lowest level in the ECS category hierarchy.
`event.outcome` simply denotes whether the event represents a success or a
failure from the perspective of the entity that produced the event.
Note that when a single transaction is described in multiple events, each
event may populate different values of `event.outcome`, according to their
perspective.
Also note that in the case of a compound event (a single event that contains
multiple logical events), this field should be populated with the value that
best captures the overall success or failure from the perspective of the event
producer.
Further note that not all events will have an associated outcome. For example,
this field is generally not populated for metric events, events with `event.type:info`,
or any events for which an outcome does not make logical sense.'
example: success
flat_name: event.outcome
ignore_above: 1024
level: core
name: outcome
normalize: []
short: The outcome of the event. The lowest level categorization field in the
hierarchy.
type: keyword
event.type:
allowed_values:
- description: The access event type is used for the subset of events within
a category that indicate that something was accessed. Common examples include
`event.category:database AND event.type:access`, or `event.category:file
AND event.type:access`. Note for file access, both directory listings and
file opens should be included in this subcategory. You can further distinguish
access operations using the ECS `event.action` field.
name: access
- description: 'The admin event type is used for the subset of events within
a category that are related to admin objects. For example, administrative
changes within an IAM framework that do not specifically affect a user or
group (e.g., adding new applications to a federation solution or connecting
discrete forests in Active Directory) would fall into this subcategory.
Common example: `event.category:iam AND event.type:change AND event.type:admin`.
You can further distinguish admin operations using the ECS `event.action`
field.'
name: admin
- description: The allowed event type is used for the subset of events within
a category that indicate that something was allowed. Common examples include
`event.category:network AND event.type:connection AND event.type:allowed`
(to indicate a network firewall event for which the firewall disposition
was to allow the connection to complete) and `event.category:intrusion_detection
AND event.type:allowed` (to indicate a network intrusion prevention system
event for which the IPS disposition was to allow the connection to complete).
You can further distinguish allowed operations using the ECS `event.action`
field, populating with values of your choosing, such as "allow", "detect",
or "pass".
name: allowed
- description: The change event type is used for the subset of events within
a category that indicate that something has changed. If semantics best describe
an event as modified, then include them in this subcategory. Common examples
include `event.category:process AND event.type:change`, and `event.category:file
AND event.type:change`. You can further distinguish change operations using
the ECS `event.action` field.
name: change
- description: Used primarily with `event.category:network` this value is used
for the subset of network traffic that includes sufficient information for
the event to be included in flow or connection analysis. Events in this
subcategory will contain at least source and destination IP addresses, source
and destination TCP/UDP ports, and will usually contain counts of bytes
and/or packets transferred. Events in this subcategory may contain unidirectional
or bidirectional information, including summary information. Use this subcategory
to visualize and analyze network connections. Flow analysis, including Netflow,
IPFIX, and other flow-related events fit in this subcategory. Note that
firewall events from many Next-Generation Firewall (NGFW) devices will also
fit into this subcategory. A common filter for flow/connection information
would be `event.category:network AND event.type:connection AND event.type:end`
(to view or analyze all completed network connections, ignoring mid-flow
reports). You can further distinguish connection events using the ECS `event.action`
field, populating with values of your choosing, such as "timeout", or "reset".
name: connection
- description: The "creation" event type is used for the subset of events within
a category that indicate that something was created. A common example is
`event.category:file AND event.type:creation`.
name: creation
- description: The deletion event type is used for the subset of events within
a category that indicate that something was deleted. A common example is
`event.category:file AND event.type:deletion` to indicate that a file has
been deleted.
name: deletion
- description: The denied event type is used for the subset of events within
a category that indicate that something was denied. Common examples include
`event.category:network AND event.type:denied` (to indicate a network firewall
event for which the firewall disposition was to deny the connection) and
`event.category:intrusion_detection AND event.type:denied` (to indicate
a network intrusion prevention system event for which the IPS disposition
was to deny the connection to complete). You can further distinguish denied
operations using the ECS `event.action` field, populating with values of
your choosing, such as "blocked", "dropped", or "quarantined".
name: denied
- description: The end event type is used for the subset of events within a
category that indicate something has ended. A common example is `event.category:process
AND event.type:end`.
name: end
- description: The error event type is used for the subset of events within
a category that indicate or describe an error. A common example is `event.category:database
AND event.type:error`. Note that pipeline errors that occur during the event
ingestion process should not use this `event.type` value. Instead, they
should use `event.kind:pipeline_error`.
name: error
- description: 'The group event type is used for the subset of events within
a category that are related to group objects. Common example: `event.category:iam
AND event.type:creation AND event.type:group`. You can further distinguish
group operations using the ECS `event.action` field.'
name: group
- description: 'The indicator event type is used for the subset of events within
a category that contain details about indicators of compromise (IOCs).
A common example is `event.category:threat AND event.type:indicator`.'
name: indicator
- description: The info event type is used for the subset of events within a
category that indicate that they are purely informational, and don't report
a state change, or any type of action. For example, an initial run of a
file integrity monitoring system (FIM), where an agent reports all files
under management, would fall into the "info" subcategory. Similarly, an
event containing a dump of all currently running processes (as opposed to
reporting that a process started/ended) would fall into the "info" subcategory.
An additional common examples is `event.category:intrusion_detection AND
event.type:info`.
name: info
- description: The installation event type is used for the subset of events
within a category that indicate that something was installed. A common example
is `event.category:package` AND `event.type:installation`.
name: installation
- description: The protocol event type is used for the subset of events within
a category that indicate that they contain protocol details or analysis,
beyond simply identifying the protocol. Generally, network events that contain
specific protocol details will fall into this subcategory. A common example
is `event.category:network AND event.type:protocol AND event.type:connection
AND event.type:end` (to indicate that the event is a network connection
event sent at the end of a connection that also includes a protocol detail
breakdown). Note that events that only indicate the name or id of the protocol
should not use the protocol value. Further note that when the protocol subcategory
is used, the identified protocol is populated in the ECS `network.protocol`
field.
name: protocol
- description: The start event type is used for the subset of events within
a category that indicate something has started. A common example is `event.category:process
AND event.type:start`.
name: start
- description: 'The user event type is used for the subset of events within
a category that are related to user objects. Common example: `event.category:iam
AND event.type:deletion AND event.type:user`. You can further distinguish
user operations using the ECS `event.action` field.'
name: user
dashed_name: event-type
description: 'This is one of four ECS Categorization Fields, and indicates the
third level in the ECS category hierarchy.
`event.type` represents a categorization "sub-bucket" that, when used along
with the `event.category` field values, enables filtering events down to a
level appropriate for single visualization.
This field is an array. This will allow proper categorization of some events
that fall in multiple event types.'
flat_name: event.type
ignore_above: 1024
level: core
name: type
normalize:
- array
short: Event type. The third categorization field in the hierarchy.
type: keyword
event.url:
dashed_name: event-url
description: 'URL linking to an external system to continue investigation of
this event.
This URL links to another system where in-depth investigation of the specific
occurrence of this event can take place. Alert events, indicated by `event.kind:alert`,
are a common use case for this field.'
example: https://mysystem.example.com/alert/5271dedb-f5b0-4218-87f0-4ac4870a38fe
flat_name: event.url
ignore_above: 1024
level: extended
name: url
normalize: []
short: Event investigation URL
type: keyword
group: 2
name: event
prefix: event.
short: Fields breaking down the event details.
title: Event
type: group
log:
description: 'Details about the event''s logging mechanism or logging transport.
The log.* fields are typically populated with details about the logging mechanism
used to create and/or transport the event. For example, syslog details belong
under `log.syslog.*`.
The details specific to your event source are typically not logged under `log.*`,
but rather in `event.*` or in other ECS fields.'
fields:
log.level:
dashed_name: log-level
description: 'Original log level of the log event.
If the source of the event provides a log level or textual severity, this
is the one that goes in `log.level`. If your source doesn''t specify one,
you may put your event transport''s severity here (e.g. Syslog severity).
Some examples are `warn`, `err`, `i`, `informational`.'
example: error
flat_name: log.level
ignore_above: 1024
level: core
name: level
normalize: []
short: Log level of the log event.
type: keyword
log.logger:
dashed_name: log-logger
description: The name of the logger inside an application. This is usually the
name of the class which initialized the logger, or can be a custom name.
example: org.elasticsearch.bootstrap.Bootstrap
flat_name: log.logger
ignore_above: 1024
level: core
name: logger
normalize: []
short: Name of the logger.
type: keyword
group: 2
name: log
prefix: log.
short: Details about the event's logging mechanism.
title: Log
type: group

144
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/heartbeat/ecs/generated/ecs/subset/nginx_proxy/ecs_flat.yml Normal file
View file

@ -0,0 +1,144 @@
'@timestamp':
dashed_name: timestamp
description: 'Date/time when the event originated.
This is the date/time extracted from the event, typically representing when the
event was generated by the source.
If the event source has no original timestamp, this value is typically populated
by the first time the event was received by the pipeline.
Required field for all events.'
example: '2016-05-23T08:05:34.853Z'
flat_name: '@timestamp'
level: core
name: '@timestamp'
normalize: []
required: true
short: Date/time when the event originated.
type: date
host.name:
dashed_name: host-name
description: 'Name of the host.
It can contain what `hostname` returns on Unix systems, the fully qualified domain
name, or a name specified by the user. The sender decides which value to use.'
flat_name: host.name
ignore_above: 1024
level: core
name: name
normalize: []
short: Name of the host.
type: keyword
http.response.bytes:
dashed_name: http-response-bytes
description: Total size in bytes of the response (body and headers).
example: 1437
flat_name: http.response.bytes
format: bytes
level: extended
name: response.bytes
normalize: []
short: Total size in bytes of the response (body and headers).
type: long
http.response.status_code:
dashed_name: http-response-status-code
description: HTTP response status code.
example: 404
flat_name: http.response.status_code
format: string
level: extended
name: response.status_code
normalize: []
short: HTTP response status code.
type: long
labels:
dashed_name: labels
description: 'Custom key/value pairs.
Can be used to add meta information to events. Should not contain nested objects.
All values are stored as keyword.
Example: `docker` and `k8s` labels.'
example: '{"application": "foo-bar", "env": "production"}'
flat_name: labels
level: core
name: labels
normalize: []
object_type: keyword
short: Custom key/value pairs.
type: object
log.level:
dashed_name: log-level
description: 'Original log level of the log event.
If the source of the event provides a log level or textual severity, this is the
one that goes in `log.level`. If your source doesn''t specify one, you may put
your event transport''s severity here (e.g. Syslog severity).
Some examples are `warn`, `err`, `i`, `informational`.'
example: error
flat_name: log.level
ignore_above: 1024
level: core
name: level
normalize: []
short: Log level of the log event.
type: keyword
log.logger:
dashed_name: log-logger
description: The name of the logger inside an application. This is usually the name
of the class which initialized the logger, or can be a custom name.
example: org.elasticsearch.bootstrap.Bootstrap
flat_name: log.logger
ignore_above: 1024
level: core
name: logger
normalize: []
short: Name of the logger.
type: keyword
message:
dashed_name: message
description: 'For log events the message field contains the log message, optimized
for viewing in a log viewer.
For structured logs without an original message field, other fields can be concatenated
to form a human-readable summary of the event.
If multiple messages exist, they can be combined into one message.'
example: Hello World
flat_name: message
level: core
name: message
normalize: []
short: Log message optimized for viewing in a log viewer.
type: match_only_text
tags:
dashed_name: tags
description: List of keywords used to tag each event.
example: '["production", "env2"]'
flat_name: tags
ignore_above: 1024
level: core
name: tags
normalize:
- array
short: List of keywords used to tag each event.
type: keyword
url.domain:
dashed_name: url-domain
description: 'Domain of the url, such as "www.elastic.co".
In some cases a URL may refer to an IP and/or port directly, without a domain
name. In this case, the IP address would go to the `domain` field.
If the URL contains a literal IPv6 address enclosed by `[` and `]` (IETF RFC 2732),
the `[` and `]` characters should also be captured in the `domain` field.'
example: www.elastic.co
flat_name: url.domain
ignore_above: 1024
level: extended
name: domain
normalize: []
short: Domain of the url.
type: keyword

226
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/heartbeat/ecs/generated/ecs/subset/nginx_proxy/ecs_nested.yml Normal file
View file

@ -0,0 +1,226 @@
base:
description: The `base` field set contains all fields which are at the root of the
events. These fields are common across all types of events.
fields:
'@timestamp':
dashed_name: timestamp
description: 'Date/time when the event originated.
This is the date/time extracted from the event, typically representing when
the event was generated by the source.
If the event source has no original timestamp, this value is typically populated
by the first time the event was received by the pipeline.
Required field for all events.'
example: '2016-05-23T08:05:34.853Z'
flat_name: '@timestamp'
level: core
name: '@timestamp'
normalize: []
required: true
short: Date/time when the event originated.
type: date
labels:
dashed_name: labels
description: 'Custom key/value pairs.
Can be used to add meta information to events. Should not contain nested objects.
All values are stored as keyword.
Example: `docker` and `k8s` labels.'
example: '{"application": "foo-bar", "env": "production"}'
flat_name: labels
level: core
name: labels
normalize: []
object_type: keyword
short: Custom key/value pairs.
type: object
message:
dashed_name: message
description: 'For log events the message field contains the log message, optimized
for viewing in a log viewer.
For structured logs without an original message field, other fields can be
concatenated to form a human-readable summary of the event.
If multiple messages exist, they can be combined into one message.'
example: Hello World
flat_name: message
level: core
name: message
normalize: []
short: Log message optimized for viewing in a log viewer.
type: match_only_text
tags:
dashed_name: tags
description: List of keywords used to tag each event.
example: '["production", "env2"]'
flat_name: tags
ignore_above: 1024
level: core
name: tags
normalize:
- array
short: List of keywords used to tag each event.
type: keyword
group: 1
name: base
prefix: ''
root: true
short: All fields defined directly at the root of the events.
title: Base
type: group
host:
description: 'A host is defined as a general computing instance.
ECS host.* fields should be populated with details about the host on which the
event happened, or from which the measurement was taken. Host types include hardware,
virtual machines, Docker containers, and Kubernetes nodes.'
fields:
host.name:
dashed_name: host-name
description: 'Name of the host.
It can contain what `hostname` returns on Unix systems, the fully qualified
domain name, or a name specified by the user. The sender decides which value
to use.'
flat_name: host.name
ignore_above: 1024
level: core
name: name
normalize: []
short: Name of the host.
type: keyword
group: 2
name: host
nestings:
- host.geo
- host.os
prefix: host.
reused_here:
- full: host.geo
schema_name: geo
short: Fields describing a location.
- full: host.os
schema_name: os
short: OS fields contain information about the operating system.
short: Fields describing the relevant computing instance.
title: Host
type: group
http:
description: Fields related to HTTP activity. Use the `url` field set to store the
url of the request.
fields:
http.response.bytes:
dashed_name: http-response-bytes
description: Total size in bytes of the response (body and headers).
example: 1437
flat_name: http.response.bytes
format: bytes
level: extended
name: response.bytes
normalize: []
short: Total size in bytes of the response (body and headers).
type: long
http.response.status_code:
dashed_name: http-response-status-code
description: HTTP response status code.
example: 404
flat_name: http.response.status_code
format: string
level: extended
name: response.status_code
normalize: []
short: HTTP response status code.
type: long
group: 2
name: http
prefix: http.
short: Fields describing an HTTP request.
title: HTTP
type: group
log:
description: 'Details about the event''s logging mechanism or logging transport.
The log.* fields are typically populated with details about the logging mechanism
used to create and/or transport the event. For example, syslog details belong
under `log.syslog.*`.
The details specific to your event source are typically not logged under `log.*`,
but rather in `event.*` or in other ECS fields.'
fields:
log.level:
dashed_name: log-level
description: 'Original log level of the log event.
If the source of the event provides a log level or textual severity, this
is the one that goes in `log.level`. If your source doesn''t specify one,
you may put your event transport''s severity here (e.g. Syslog severity).
Some examples are `warn`, `err`, `i`, `informational`.'
example: error
flat_name: log.level
ignore_above: 1024
level: core
name: level
normalize: []
short: Log level of the log event.
type: keyword
log.logger:
dashed_name: log-logger
description: The name of the logger inside an application. This is usually the
name of the class which initialized the logger, or can be a custom name.
example: org.elasticsearch.bootstrap.Bootstrap
flat_name: log.logger
ignore_above: 1024
level: core
name: logger
normalize: []
short: Name of the logger.
type: keyword
group: 2
name: log
prefix: log.
short: Details about the event's logging mechanism.
title: Log
type: group
url:
description: URL fields provide support for complete or partial URLs, and supports
the breaking down into scheme, domain, path, and so on.
fields:
url.domain:
dashed_name: url-domain
description: 'Domain of the url, such as "www.elastic.co".
In some cases a URL may refer to an IP and/or port directly, without a domain
name. In this case, the IP address would go to the `domain` field.
If the URL contains a literal IPv6 address enclosed by `[` and `]` (IETF RFC
2732), the `[` and `]` characters should also be captured in the `domain`
field.'
example: www.elastic.co
flat_name: url.domain
ignore_above: 1024
level: extended
name: domain
normalize: []
short: Domain of the url.
type: keyword
group: 2
name: url
prefix: url.
reusable:
expected:
- as: url
at: threat.indicator
full: threat.indicator.url
- as: url
at: threat.enrichments.indicator
beta: Reusing the `url` fields in this location is currently considered beta.
full: threat.enrichments.indicator.url
top_level: true
short: Fields that let you store URLs in various forms.
title: URL
type: group

25
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/heartbeat/ecs/generated/elasticsearch/composable/component/base.json Normal file
View file

@ -0,0 +1,25 @@
{
"_meta": {
"documentation": "https://www.elastic.co/guide/en/ecs/current/ecs-base.html",
"ecs_version": "8.0.0"
},
"template": {
"mappings": {
"properties": {
"@timestamp": {
"type": "date"
},
"labels": {
"type": "object"
},
"message": {
"type": "match_only_text"
},
"tags": {
"ignore_above": 1024,
"type": "keyword"
}
}
}
}
}

35
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/heartbeat/ecs/generated/elasticsearch/composable/component/event.json Normal file
View file

@ -0,0 +1,35 @@
{
"_meta": {
"documentation": "https://www.elastic.co/guide/en/ecs/current/ecs-event.html",
"ecs_version": "8.0.0"
},
"template": {
"mappings": {
"properties": {
"event": {
"properties": {
"action": {
"ignore_above": 1024,
"type": "keyword"
},
"duration": {
"type": "long"
},
"outcome": {
"ignore_above": 1024,
"type": "keyword"
},
"type": {
"ignore_above": 1024,
"type": "keyword"
},
"url": {
"ignore_above": 1024,
"type": "keyword"
}
}
}
}
}
}
}

24
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/heartbeat/ecs/generated/elasticsearch/composable/component/log.json Normal file
View file

@ -0,0 +1,24 @@
{
"_meta": {
"documentation": "https://www.elastic.co/guide/en/ecs/current/ecs-log.html",
"ecs_version": "8.0.0"
},
"template": {
"mappings": {
"properties": {
"log": {
"properties": {
"level": {
"ignore_above": 1024,
"type": "keyword"
},
"logger": {
"ignore_above": 1024,
"type": "keyword"
}
}
}
}
}
}
}

50
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/heartbeat/ecs/generated/elasticsearch/composable/template.json Normal file
View file

@ -0,0 +1,50 @@
{
"_meta": {
"description": "Sample composable template that includes all ECS fields",
"ecs_version": "8.0.0"
},
"composed_of": [
"ecs_8.0.0_base",
"ecs_8.0.0_log",
"ecs_8.0.0_event"
],
"index_patterns": [
"kbn-data-forge-fake_stack.heartbeat-*"
],
"priority": 1,
"template": {
"mappings": {
"_meta": {
"version": "1.6.0"
},
"date_detection": false,
"dynamic_templates": [
{
"strings_as_keyword": {
"mapping": {
"fields": {
"text": {
"norms": false,
"type": "text"
}
},
"ignore_above": 1024,
"type": "keyword"
},
"match_mapping_type": "string"
}
}
]
},
"settings": {
"index": {
"codec": "best_compression",
"mapping": {
"total_fields": {
"limit": 2000
}
}
}
}
}
}

90
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/heartbeat/ecs/generated/elasticsearch/legacy/template.json Normal file
View file

@ -0,0 +1,90 @@
{
"index_patterns": [
"kbn-data-forge-fake_stack.heartbeat-*"
],
"mappings": {
"_meta": {
"version": "1.6.0"
},
"date_detection": false,
"dynamic_templates": [
{
"strings_as_keyword": {
"mapping": {
"fields": {
"text": {
"norms": false,
"type": "text"
}
},
"ignore_above": 1024,
"type": "keyword"
},
"match_mapping_type": "string"
}
}
],
"properties": {
"@timestamp": {
"type": "date"
},
"event": {
"properties": {
"action": {
"ignore_above": 1024,
"type": "keyword"
},
"duration": {
"type": "long"
},
"outcome": {
"ignore_above": 1024,
"type": "keyword"
},
"type": {
"ignore_above": 1024,
"type": "keyword"
},
"url": {
"ignore_above": 1024,
"type": "keyword"
}
}
},
"labels": {
"type": "object"
},
"log": {
"properties": {
"level": {
"ignore_above": 1024,
"type": "keyword"
},
"logger": {
"ignore_above": 1024,
"type": "keyword"
}
}
},
"message": {
"type": "match_only_text"
},
"tags": {
"ignore_above": 1024,
"type": "keyword"
}
}
},
"order": 1,
"settings": {
"index": {
"codec": "best_compression",
"mapping": {
"total_fields": {
"limit": 2000
}
},
"refresh_interval": "2s"
}
}
}

29
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/heartbeat/ecs/index.ts Normal file
View file

@ -0,0 +1,29 @@
/*
* Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one
* or more contributor license agreements. Licensed under the Elastic License
* 2.0; you may not use this file except in compliance with the Elastic License
* 2.0.
*/
import { HEARTBEAT } from '../../common/constants';
import base from './generated/elasticsearch/composable/component/base.json';
import log from './generated/elasticsearch/composable/component/log.json';
import event from './generated/elasticsearch/composable/component/event.json';
import template from './generated/elasticsearch/composable/template.json';
import { IndexTemplateDef } from '../../../../types';
const ECS_VERSION = template._meta.ecs_version;
const components = [
{ name: `${HEARTBEAT}_${ECS_VERSION}_base`, template: base },
{ name: `${HEARTBEAT}_${ECS_VERSION}_log`, template: log },
{ name: `${HEARTBEAT}_${ECS_VERSION}_host`, template: event },
];
export const indexTemplate: IndexTemplateDef = {
namespace: HEARTBEAT,
template: { ...template, composed_of: components.map(({ name }) => name) },
components,
};

16
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/heartbeat/index.ts Normal file
View file

@ -0,0 +1,16 @@
/*
* Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one
* or more contributor license agreements. Licensed under the Elastic License
* 2.0; you may not use this file except in compliance with the Elastic License
* 2.0.
*/
import { GeneratorFunction } from '../../../types';
import { bad } from './lib/events/bad';
import { good } from './lib/events/good';
export const kibanaAssets = `${__dirname}/assets/heartbeat.ndjson`;
export const generateEvent: GeneratorFunction = (_config, schedule, _index, timestamp) => {
return schedule.template === 'bad' ? bad(schedule, timestamp) : good(schedule, timestamp);
};

14
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/heartbeat/lib/events/bad.ts Normal file
View file

@ -0,0 +1,14 @@
/*
* Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one
* or more contributor license agreements. Licensed under the Elastic License
* 2.0; you may not use this file except in compliance with the Elastic License
* 2.0.
*/
import { EventFunction } from '../../../../../types';
import { MONGODB, MONGO_DB_GATEWAY } from '../../../common/constants';
import { createEvent } from './create_event';
export const bad: EventFunction = (_schedule, timestamp) => {
return [createEvent(timestamp, MONGODB, `https://${MONGO_DB_GATEWAY}`, 'failure')];
};

35
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/heartbeat/lib/events/create_event.ts Normal file
View file

@ -0,0 +1,35 @@
/*
* Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one
* or more contributor license agreements. Licensed under the Elastic License
* 2.0; you may not use this file except in compliance with the Elastic License
* 2.0.
*/
import { random } from 'lodash';
import { Moment } from 'moment';
import { HEARTBEAT } from '../../../common/constants';
export function createEvent(
timestamp: Moment,
source: string,
url: string,
outcome: 'success' | 'failure',
highLatency = false
) {
return {
namespace: HEARTBEAT,
'@timestamp': timestamp,
tags: [HEARTBEAT, source],
log: {
level: 'info',
logger: HEARTBEAT,
},
message: `Pinging ${url} resulted in "${outcome}"`,
event: {
action: 'ping',
outcome,
duration: (highLatency ? random(1000, 2000) : random(10, 100)) * 1000,
url,
type: HEARTBEAT,
},
};
}

14
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/heartbeat/lib/events/good.ts Normal file
View file

@ -0,0 +1,14 @@
/*
* Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V. under one
* or more contributor license agreements. Licensed under the Elastic License
* 2.0; you may not use this file except in compliance with the Elastic License
* 2.0.
*/
import { EventFunction } from '../../../../../types';
import { MONGODB, MONGO_DB_GATEWAY } from '../../../common/constants';
import { createEvent } from './create_event';
export const good: EventFunction = (_schedule, timestamp) => {
return [createEvent(timestamp, MONGODB, `https://${MONGO_DB_GATEWAY}`, 'success')];
};

10
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/index.ts
View file

@ -19,18 +19,25 @@ import {
generateEvent as generateNginxProxy,
kibanaAssets as kibanaAssetsNginxProxy,
} from './nginx_proxy';
import {
generateEvent as generateHeartbeat,
kibanaAssets as kibanaAssetsHeartbeat,
} from './heartbeat';
import { GeneratorFunction } from '../../types';
import { indexTemplate as adminConsoleIndexTemplate } from './admin_console/ecs';
import { indexTemplate as messageProcessorIndexTemplate } from './message_processor/ecs';
import { indexTemplate as mongodbIndexTemplate } from './mongodb/ecs';
import { indexTemplate as nginxProxyIndexTemplate } from './nginx_proxy/ecs';
import { indexTemplate as heartbeatIndexTemplate } from './heartbeat/ecs';
export const indexTemplate = [
adminConsoleIndexTemplate,
messageProcessorIndexTemplate,
mongodbIndexTemplate,
nginxProxyIndexTemplate,
heartbeatIndexTemplate,
];
export const kibanaAssets = [
@ -38,6 +45,7 @@ export const kibanaAssets = [
kibanaAssetsMongoDB,
kibanaAssetsMessageProcessor,
kibanaAssetsNginxProxy,
kibanaAssetsHeartbeat,
`${__dirname}/assets/transaction_rates.ndjson`,
];
@ -47,11 +55,13 @@ export const generteEvent: GeneratorFunction = (config, schedule, index, timesta
const mongodbEvents = generateMongoDB(config, schedule, index, timestamp);
const messageProcessorEvents = generateMessageProcessor(config, schedule, index, timestamp);
const nginxProxyEvents = generateNginxProxy(config, schedule, index, timestamp);
const heartbeatEvents = generateHeartbeat(config, schedule, index, timestamp);
return [
...(isArray(adminConsoleEvents) ? adminConsoleEvents : [adminConsoleEvents]),
...(isArray(mongodbEvents) ? mongodbEvents : [mongodbEvents]),
...(isArray(messageProcessorEvents) ? messageProcessorEvents : [messageProcessorEvents]),
...(isArray(nginxProxyEvents) ? nginxProxyEvents : [nginxProxyEvents]),
...(isArray(heartbeatEvents) ? heartbeatEvents : [heartbeatEvents]),
].map((event) => {
const labels = event.labels ?? {};
return { ...event, labels: { ...labels, scenario } };

3
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/nginx_proxy/ecs/fields/subset.yml
View file

@ -7,6 +7,9 @@ fields:
fields:
level: {}
logger: {}
url:
fields:
domain: {}
http:
fields:
response:

21
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/nginx_proxy/ecs/generated/beats/fields.ecs.yml
View file

@ -125,3 +125,24 @@
description: The name of the logger inside an application. This is usually the
name of the class which initialized the logger, or can be a custom name.
example: org.elasticsearch.bootstrap.Bootstrap
- name: url
title: URL
group: 2
description: URL fields provide support for complete or partial URLs, and supports
the breaking down into scheme, domain, path, and so on.
type: group
default_field: true
fields:
- name: domain
level: extended
type: keyword
ignore_above: 1024
description: 'Domain of the url, such as "www.elastic.co".
In some cases a URL may refer to an IP and/or port directly, without a domain
name. In this case, the IP address would go to the `domain` field.
If the URL contains a literal IPv6 address enclosed by `[` and `]` (IETF RFC
2732), the `[` and `]` characters should also be captured in the `domain`
field.'
example: www.elastic.co

1
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/nginx_proxy/ecs/generated/csv/fields.csv
View file

@ -8,3 +8,4 @@ ECS_Version,Indexed,Field_Set,Field,Type,Level,Normalization,Example,Description
8.0.0,true,http,http.response.status_code,long,extended,,404,HTTP response status code.
8.0.0,true,log,log.level,keyword,core,,error,Log level of the log event.
8.0.0,true,log,log.logger,keyword,core,,org.elasticsearch.bootstrap.Bootstrap,Name of the logger.
8.0.0,true,url,url.domain,keyword,extended,,www.elastic.co,Domain of the url.

1 ECS_Version Indexed Field_Set Field Type Level Normalization Example Description
8 8.0.0 true http http.response.status_code long extended 404 HTTP response status code.
9 8.0.0 true log log.level keyword core error Log level of the log event.
10 8.0.0 true log log.logger keyword core org.elasticsearch.bootstrap.Bootstrap Name of the logger.
11 8.0.0 true url url.domain keyword extended www.elastic.co Domain of the url.

17
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/nginx_proxy/ecs/generated/ecs/ecs_flat.yml
View file

@ -125,3 +125,20 @@ tags:
- array
short: List of keywords used to tag each event.
type: keyword
url.domain:
dashed_name: url-domain
description: 'Domain of the url, such as "www.elastic.co".
In some cases a URL may refer to an IP and/or port directly, without a domain
name. In this case, the IP address would go to the `domain` field.
If the URL contains a literal IPv6 address enclosed by `[` and `]` (IETF RFC 2732),
the `[` and `]` characters should also be captured in the `domain` field.'
example: www.elastic.co
flat_name: url.domain
ignore_above: 1024
level: extended
name: domain
normalize: []
short: Domain of the url.
type: keyword

38
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/nginx_proxy/ecs/generated/ecs/ecs_nested.yml
View file

@ -186,3 +186,41 @@ log:
short: Details about the event's logging mechanism.
title: Log
type: group
url:
description: URL fields provide support for complete or partial URLs, and supports
the breaking down into scheme, domain, path, and so on.
fields:
url.domain:
dashed_name: url-domain
description: 'Domain of the url, such as "www.elastic.co".
In some cases a URL may refer to an IP and/or port directly, without a domain
name. In this case, the IP address would go to the `domain` field.
If the URL contains a literal IPv6 address enclosed by `[` and `]` (IETF RFC
2732), the `[` and `]` characters should also be captured in the `domain`
field.'
example: www.elastic.co
flat_name: url.domain
ignore_above: 1024
level: extended
name: domain
normalize: []
short: Domain of the url.
type: keyword
group: 2
name: url
prefix: url.
reusable:
expected:
- as: url
at: threat.indicator
full: threat.indicator.url
- as: url
at: threat.enrichments.indicator
beta: Reusing the `url` fields in this location is currently considered beta.
full: threat.enrichments.indicator.url
top_level: true
short: Fields that let you store URLs in various forms.
title: URL
type: group

17
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/nginx_proxy/ecs/generated/ecs/subset/nginx_proxy/ecs_flat.yml
View file

@ -125,3 +125,20 @@ tags:
- array
short: List of keywords used to tag each event.
type: keyword
url.domain:
dashed_name: url-domain
description: 'Domain of the url, such as "www.elastic.co".
In some cases a URL may refer to an IP and/or port directly, without a domain
name. In this case, the IP address would go to the `domain` field.
If the URL contains a literal IPv6 address enclosed by `[` and `]` (IETF RFC 2732),
the `[` and `]` characters should also be captured in the `domain` field.'
example: www.elastic.co
flat_name: url.domain
ignore_above: 1024
level: extended
name: domain
normalize: []
short: Domain of the url.
type: keyword

38
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/nginx_proxy/ecs/generated/ecs/subset/nginx_proxy/ecs_nested.yml
View file

@ -186,3 +186,41 @@ log:
short: Details about the event's logging mechanism.
title: Log
type: group
url:
description: URL fields provide support for complete or partial URLs, and supports
the breaking down into scheme, domain, path, and so on.
fields:
url.domain:
dashed_name: url-domain
description: 'Domain of the url, such as "www.elastic.co".
In some cases a URL may refer to an IP and/or port directly, without a domain
name. In this case, the IP address would go to the `domain` field.
If the URL contains a literal IPv6 address enclosed by `[` and `]` (IETF RFC
2732), the `[` and `]` characters should also be captured in the `domain`
field.'
example: www.elastic.co
flat_name: url.domain
ignore_above: 1024
level: extended
name: domain
normalize: []
short: Domain of the url.
type: keyword
group: 2
name: url
prefix: url.
reusable:
expected:
- as: url
at: threat.indicator
full: threat.indicator.url
- as: url
at: threat.enrichments.indicator
beta: Reusing the `url` fields in this location is currently considered beta.
full: threat.enrichments.indicator.url
top_level: true
short: Fields that let you store URLs in various forms.
title: URL
type: group

20
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/nginx_proxy/ecs/generated/elasticsearch/composable/component/url.json Normal file
View file

@ -0,0 +1,20 @@
{
"_meta": {
"documentation": "https://www.elastic.co/guide/en/ecs/current/ecs-url.html",
"ecs_version": "8.0.0"
},
"template": {
"mappings": {
"properties": {
"url": {
"properties": {
"domain": {
"ignore_above": 1024,
"type": "keyword"
}
}
}
}
}
}
}

1
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/nginx_proxy/ecs/generated/elasticsearch/composable/template.json
View file

@ -6,6 +6,7 @@
"composed_of": [
"ecs_8.0.0_base",
"ecs_8.0.0_log",
"ecs_8.0.0_url",
"ecs_8.0.0_http",
"ecs_8.0.0_host"
],

8
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/nginx_proxy/ecs/generated/elasticsearch/legacy/template.json
View file

@ -71,6 +71,14 @@
"tags": {
"ignore_above": 1024,
"type": "keyword"
},
"url": {
"properties": {
"domain": {
"ignore_above": 1024,
"type": "keyword"
}
}
}
}
},

1
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/nginx_proxy/lib/events/create_nginx_log.ts
View file

@ -38,6 +38,7 @@ export const createNginxLog = (
log: { level: 'INFO', logger: NGINX_PROXY },
host: { name: host },
http: { response: { status_code: statusCode, bytes } },
url: { domain },
},
];
};

2
x-pack/packages/kbn-data-forge/src/data_sources/fake_stack/nginx_proxy/lib/events/create_upstream_timedout.ts
View file

@ -38,6 +38,8 @@ export const createUpstreamTimeout = (
)}, server: ${domain}, request: "${method} ${path} HTTP/1.1", upstream: "http://${hostWithPort}${path}", host: "${domain}"`,
log: { level: 'ERROR', logger: NGINX_PROXY },
host: { name: host },
http: { response: { status_code: 502, bytes: 0 } },
url: { domain },
},
];
};