-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce datasources in package to configure inputs and streams #212
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
This file was deleted.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -8,18 +8,26 @@ type: logs | |
# The ingest pipeline which should be used. | ||
ingest_pipeline: default | ||
|
||
vars: | ||
- name: paths | ||
# Should we define this as array? How will the UI best make sense of it? | ||
type: textarea | ||
default: | ||
- /var/log/nginx/access.log* | ||
# I suggest to use ECS fields for this config options here: https://github.com/elastic/ecs/blob/master/schemas/os.yml | ||
# This would need to be based on a predefined definition on what can be filtered on | ||
os.darwin: | ||
- /usr/local/var/log/nginx/access.log* | ||
os.windows: | ||
- c:/programdata/nginx/logs/*access.log* | ||
# List of supported inputs | ||
inputs: | ||
- type: log | ||
vars: | ||
- name: paths | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Similar to my previous comment, it would be great to have There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Added. |
||
required: true | ||
# Should we define this as array? How will the UI best make sense of it? | ||
description: Paths to the nginx access log file. | ||
type: text | ||
multi: true | ||
default: | ||
- /var/log/nginx/access.log* | ||
# I suggest to use ECS fields for this config options here: https://github.com/elastic/ecs/blob/master/schemas/os.yml | ||
# This would need to be based on a predefined definition on what can be filtered on | ||
os.darwin: | ||
default: | ||
- /usr/local/var/log/nginx/access.log* | ||
os.windows: | ||
default: | ||
- c:/programdata/nginx/logs/*access.log* | ||
|
||
requirements: | ||
elasticsearch.processors: | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,23 @@ | ||
|
||
# The selected input has to be passed to the stream config when processed. | ||
|
||
{{#if input == log}} | ||
input: log | ||
|
||
{{#each paths}} | ||
paths: "{{this}}" | ||
{{/each}} | ||
exclude_files: [".gz$"] | ||
|
||
processors: | ||
- add_locale: ~ | ||
{{/if}} | ||
|
||
|
||
# This is an example stream config on how multiple inputs could be supported | ||
|
||
{{#if input == syslog}} | ||
input: syslog | ||
|
||
# TODO: would need some more config options | ||
{{/if}} |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,11 +1,29 @@ | ||
title: Nginx Error Logs | ||
type: logs | ||
ingest_pipeline: pipeline | ||
vars: | ||
- name: paths | ||
default: | ||
- /var/log/nginx/error.log* | ||
os.darwin: | ||
- /usr/local/var/log/nginx/error.log* | ||
os.windows: | ||
- c:/programdata/nginx/logs/error.log* | ||
|
||
|
||
# This is an example that multiple inputs are supported by one dataset | ||
inputs: | ||
- type: log | ||
vars: | ||
- name: paths | ||
required: true | ||
default: | ||
- /var/log/nginx/error.log* | ||
|
||
# TODO: The exact definition of os specific paths still needs to be defined | ||
os.darwin: | ||
- /usr/local/var/log/nginx/error.log* | ||
os.windows: | ||
- c:/programdata/nginx/logs/error.log* | ||
|
||
- type: syslog | ||
vars: | ||
# Are udp and tcp syslog input two different inputs? | ||
- name: protocol.udp.host | ||
required: true | ||
default: | ||
- "localhost:9000" | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -12,3 +12,50 @@ requirement: | |
versions: ">7.1.0 <7.6.0" | ||
elasticsearch: | ||
versions: ">7.0.1" | ||
|
||
datasources: | ||
- | ||
# Do we need a name for the data source? | ||
name: nginx | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think name would be useful to populate the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You mean prefixing the id? Because the id needs to be unique. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yep, I meant prefixing |
||
|
||
# List of inputs this datasource supports | ||
inputs: | ||
- | ||
# An id can be given, in case the type used here is not unique | ||
# This is for selection in the stream | ||
# id: nginx | ||
type: nginx/metrics | ||
descrition: Collecting metrics for nginx. | ||
|
||
# Common configuration options for this input | ||
vars: | ||
- name: hosts | ||
description: Nginx hosts | ||
default: | ||
["http://127.0.0.1"] | ||
# All the config options that are required should be shown in the UI | ||
required: true | ||
Comment on lines
+32
to
+37
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wold like to see type: text
multi: true There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Agree. Adding. |
||
multi: true | ||
type: text | ||
- name: period | ||
description: "Collection period. Valid values: 10s, 5m, 2h" | ||
default: "10s" | ||
Comment on lines
+40
to
+42
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Add There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. +1 for a duration type, we used integer priviously and it was not that great. :) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like duration if that works for the UI. |
||
type: duration | ||
- name: username | ||
type: text | ||
- name: password | ||
# This is the html input type? | ||
type: password | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we need to decide all possible values for
In the case of password vars, I would use There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like the above proposed types. I was thinking of password instead of text to not have to show clear text passwords directly on the screen when users put them in. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. BTW: If we have these predefined values for type we can also validate it already on the package side to make sure nothing odd shows up in the package itself. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For the URL types we have to be careful when we do this and we do it, in some modules we do use compound scheme (not sure if this is the exact term?) Like "http+npipe://./pipe/custom" see https://github.com/elastic/beats/blob/d75261469b5c2e675d7d331b86bfc8599d797ddc/metricbeat/mb/parse/url_test.go for a few examples. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see url support as a stretch goal. In case of doubt we can always fall back to just string. Lets keep it simple for now. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We can add granular text types (duration, url, etc) but it doesn't mean that we need to do validation right now. Validation can be added later on from all fronts (UI, agent, package) once we align on rules. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Also ++ on keeping password type. This give the UI information to decide when to show clear text inputs and when to obfuscate. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As soon as we started the UI implementation and are happy with the format, we should open a PR here with the exact specs. |
||
|
||
- | ||
type: logs | ||
description: Collect nginx logs. | ||
|
||
# Common configuration options for this input | ||
vars: | ||
|
||
- | ||
type: syslog | ||
|
||
# Common configuration options for this input | ||
vars: |
This file was deleted.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,6 @@ | ||
input: metrics/system | ||
enabled: false # default true | ||
metricset: cpu | ||
period: 10s | ||
dataset: system.cpu | ||
metrics: ["percentages", "normalized_percentages"] |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -5,4 +5,5 @@ release: beta | |
# Needs to describe the type of this input | ||
type: metrics | ||
|
||
|
||
inputs: | ||
- type: metrics/system |
This file was deleted.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,4 @@ | ||
inputy: metric/system | ||
enabled: true | ||
metricsets: | ||
- load |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -5,4 +5,5 @@ release: beta | |
# Needs to describe the type of this input | ||
type: metrics | ||
|
||
|
||
inputs: | ||
- type: system/metrics |
This file was deleted.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,4 @@ | ||
input: metric/system | ||
enabled: true | ||
metricsets: | ||
- memory |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -5,4 +5,6 @@ release: beta | |
# Needs to describe the type of this input | ||
type: metrics | ||
|
||
inputs: | ||
- type: system/metrics | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hbharding suggested today that it would be great to have descriptions in the UI. Could we add
description
prop for every input, under itstype
? I think these descriptions should only be a sentence or two, max. Not sure how we will localize these though..There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1. Added it. But did not add it here but on the package level where the overall inputs are defined. As a single input is shown for multiple datasets, I guess it makes more sense there.