forked from ViaQ/elasticsearch-templates
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy path_default_.yml
171 lines (154 loc) · 6.6 KB
/
_default_.yml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
version: 2017.09.06.0
field_defaults:
type: string
doc_values: true
index: not_analyzed
_default_:
type: group
name: "Default"
description: |
The top level fields are common to every application, and may be present in every record.
For the Elasticsearch template, this is what populates the actual mappings
of _default_ in the template's mapping section.
fields:
- name: "@timestamp"
type: date
format: yyyy-MM-dd HH:mm:ss,SSSZ||yyyy-MM-dd'T'HH:mm:ss.SSSSSSZ||yyyy-MM-dd'T'HH:mm:ssZ||dateOptionalTime
example: 2015-01-24T14:06:05.071Z
description: |
UTC value marking when the log payload was created, or when log payload was first collected if the creation time is not known;
this is the log processing pipeline’s “best effort” determination of when the log payload was generated
FYI: the “@” prefix convention to note a field as being reserved for a particular use; in this case, most tools by default look for “@timestamp” with ElasticSearch
fields:
- name: raw
ignore_above: 256
type: string
- name: geoip
description: >
geo-ip of the machine
type: object
object_struct:
dynamic: True
properties:
location:
type: geo_point
- name: hostname
type: string
description: >
FQDN of the entity generating the original payload. This field is a
best effort attempt to derive this context; sometimes the entity
generating it knows it; other times that entity has a restricted
namespace itself, and the collector or normalizer knows that.
- name: ipaddr4
type: ip
description: >
IP address v4 of the source server, can be an array.
fields:
- name: raw
ignore_above: 256
type: string
norms:
enabled: false
- name: ipaddr6
type: string
description: >
IP address v6 of the source server(if available).
- name: level
type: string
example: info
description: |
Logging level as provided by: rsyslog(severitytext property), python's
logging module, etc.
Possible values are as listed here: http://sourceware.org/git/?p=glibc.git;a=blob;f=misc/sys/syslog.h;h=ee01478c4b19a954426a96448577c5a76e6647c0;hb=HEAD#l74 plus `trace` and `unknown`
That is: alert crit debug emerg err info notice trace unknown warning
Note that `trace` isn't in the syslog.h list but many applications use it
`unknown` is only used when the logging system gets a value it doesn't understand
`unknown` is the highest level
`trace` should be considered as higher (more verbose) than `debug`
`error` should be converted to `err`
`panic` should be converted to `emerg`
`warn` should be converted to `warning`
Numeric values from syslog/journal PRIORITY can usually be mapped using the priority values as listed here:
http://sourceware.org/git/?p=glibc.git;a=blob;f=misc/sys/syslog.h;h=ee01478c4b19a954426a96448577c5a76e6647c0;hb=HEAD#l51
That is, 0 -> emerg, 1 -> alert, ..., 7 -> debug, 8 -> trace, 9 -> unknown
Log levels/priorities from other logging systems should be mapped to the nearest match
For example, from python logging: https://docs.python.org/2.7/library/logging.html#logging-levels
CRITICAL -> crit, ERROR -> err, ...., DEBUG -> debug
- name: message
type: string
index: analyzed
doc_values: false
example: TODO
description: >
Typical log entry message, or payload, possibly stripped of metadata
pulled out of it by collector/normalizer, UTF-8 encoded.
norms:
enabled: false
- name: pid
type: string
description: >
This is the process ID of the logging entity, if available.
- name: service
type: string
description: >
Name of the service associated with the logging entity, if available.
For example, syslog's APP-NAME and rsyslog's programname property are
mapped to the service field.
- name: tags
type: string
doc_values: false
index: analyzed
analyzer: whitespace
description: >
Optionally provided operator defined list of tags placed on each log
by the collector or normalizer. The payload can be a string with
whitespace-delimited string tokens, or a JSON list of string tokens.
- name: file
type: string
index: analyzed
doc_values: false
description: >
Optional path to the file containing the log entry local to the
collector
TODO: analyzer for file paths
norms:
enabled: True
fields:
- name: raw
type: string
ignore_above: 256
- name: offset
type: long
description: >
The offset value can represent bytes to the start of the log line in the
file (zero or one based), or log line numbers (zero or one based), so
long as the values are strictly monotonically increasing in the context
of a single log file. They values are allowed to wrap, representing a
new version of the log file (rotation).
- name: namespace_name
type: string
example: my-cool-project-in-lab04
doc_values: false
index: not_analyzed
description: |
format: [a-zA-Z][a-zA-Z0-9-]{0,61}[a-zA-Z0-9]
Associate this record with the namespace with this name.
This value will not be stored. It is only used to associate the
record with the appropriate namespace for access control and
visualization. Normally this value will be given in the tag, but if the
protocol does not support sending a tag, this field can be used.
If this field is present, it will override the
namespace given in the tag or in kubernetes.namespace_name.
The format is the same format used for Kubernetes namespace names.
See also namespace_uuid.
- name: namespace_uuid
type: string
example: 82f13a8e-882a-4344-b103-f0a6f30fd218
description: |
format: [a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}
The uuid associated with the namespace_name.
This value will not be stored. It is only used to associate the
record with the appropriate namespace for access control and
visualization. If this field is present, it will override the
uuid given in kubernetes.namespace_uuid. This will also cause
the Kubernetes metadata lookup to be skipped for this log record.