-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Add the ability to set custom fields #1092
Conversation
66b1dd0
to
87e1371
Compare
@@ -57,11 +57,11 @@ type ProspectorConfig struct { | |||
} | |||
|
|||
type HarvesterConfig struct { | |||
common.EventMetadata `config:",inline"` // Fields and tags to add to events. |
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 on approaching this directly with an eventMetadata object. That makes it easy to extend it later with other fields.
LGTM. Even though fields has its issue, as far as a I know we haven't found a better option yet and people got used to call it fields, so I would stay with it. What happens if inside a prospector |
Great work! LGTM |
we still need tags, if we got fields? |
Optional fields that you can specify to add additional information to the | ||
output. For example, you might add fields that you can use for filtering log | ||
data. Fields can be scalar values, arrays, dictionaries, or any nested | ||
combination of these. All scalar values will be interpreted as strings. By |
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.
All scalar values will be interpreted as strings
This is not true anymore. Types are currently preserved.
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.
I removed this sentence from the docs. I didn't see your comment prior to asking you the question on Slack.
@urso About tags vs fields: I was thinking the same first but I get the feeling people use them differently. I would keep both if it doesn't add much complexity. |
|
87e1371
to
4b9e118
Compare
We could do away with tags since you could implement them with fields. But you couldn't merge the "global" and "local" |
The prospector fields will be added to the root of the document and the shipper fields will be under the
This should be fixed now. It was due to scalars not being converted to strings under ucfg. The docs have been updated to reflect this change in behavior and the test fixed. |
@andrewkroh Interesting about the fields_under_root. I like it. |
LGTM. @andrewkroh Can you rebase? |
} | ||
*ms = cleanUpInterfaceMap(result) | ||
|
||
// Add fields and override. |
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.
@andrewkroh Seems like the old comment disappeared. The main reason I was thinking about logging is for debugging reason in case we get the info that some fields disappear. Lets leave it out for now and discuss it in case we hit such a case.
Add the ability to set tags in Filebeat prospector config Add the ability to set tags and fields in Winlogbeat event log config Update docs to remove wording about all scalars being changed to strings. Closes elastic#726
4b9e118
to
1043c19
Compare
It's rebased. Jenkins is failing because of a docker problem. |
Add the ability to set custom fields
Any change of back-porting this to the current topbeat and packetbeat releases? i don't want to upgrade live servers with nightly builds, but i need this custom fields to be able to proper filter things on kibana. |
This feature will be included in the upcoming |
I amended my previous comment. I was thinking of environment variable replacement (which is in 1.2). The custom fields feature is in 5.0. |
Great work, Thanks! |
Every Beat has support for fields, fields_under_root, and tags. And most support setting them at the module level too. Checkout the documentation for Metricbeat: |
Yes but this fields are static right? You define them at the metricbeat.yml if I'm not mistaken. Is there a way to make them variable according to another field pulled from a module? For instance vsphere.virtualmachine.name ? Thank you! |
These fields are static. You could mutate the event in Logstash. |
@andrewkroh the documentation for adding tags isnt for 7.4 version anywhere. There are too many older versions of addings tags/fields and could you please tell how it is in 7.4 version? Will it be something like this- This would be the way to tag each log file with its own tag and then in logstash create an index for this tag? Thanks, I have looked at discussion forum for ES but all are for older versions. |
The documentation for |
thank you so much, but has it been updated for logstash as well? From the add_field example, will index be formed in logstash too? For something like this- |
This pull request implements the feature requested in #726.
Changes Affecting All Beats
fields
andfields_under_root
as options availableunder the
shipper
configuration. These settings are analogous to settingscurrently available in Filebeat.
fields
defined in the prospectorconfiguration take precedence over fields define in the
shipper
configuration.
Changes Affecting Filebeat
tags
for each prospector. These tags willbe appended to the list of tags specified in the
shipper
configuration.fields
are not longer automatically converted to strings.Changes Affecting Winlogbeat
tags
,fields
, andfields_under_root
as optionsfor each event log.
Examples
Topbeat
Filebeat
Winlogbeat
See the test cases for more examples.
Open Questions
fields
? (same as it's called in Filebeat)