- Winlogbeat Reference: other versions:
- Winlogbeat Overview
- Quick start: installation and configuration
- Set up and run
- Upgrade
- Configure
- Winlogbeat
- General settings
- Project paths
- Output
- Kerberos
- SSL
- Index lifecycle management (ILM)
- Elasticsearch index template
- Kibana endpoint
- Kibana dashboards
- Processors
- Define processors
- add_cloud_metadata
- add_cloudfoundry_metadata
- add_docker_metadata
- add_fields
- add_host_metadata
- add_id
- add_kubernetes_metadata
- add_labels
- add_locale
- add_network_direction
- add_nomad_metadata
- add_observer_metadata
- add_process_metadata
- add_tags
- append
- community_id
- convert
- copy_fields
- decode_base64_field
- decode_duration
- decode_json_fields
- decode_xml
- decode_xml_wineventlog
- decompress_gzip_field
- detect_mime_type
- dissect
- dns
- drop_event
- drop_fields
- extract_array
- fingerprint
- include_fields
- move_fields
- rate_limit
- registered_domain
- rename
- replace
- script
- syslog
- timestamp
- translate_ldap_attribute
- translate_sid
- truncate_fields
- urldecode
- Internal queue
- Logging
- HTTP endpoint
- Instrumentation
- winlogbeat.reference.yml
- How to guides
- Modules
- Exported fields
- Monitor
- Secure
- Troubleshoot
- Get Help
- Debug
- Understand logged metrics
- Common problems
- Dashboard in Kibana is breaking up data fields incorrectly
- Bogus computer_name fields are reported in some events
- Error loading config file
- Found unexpected or unknown characters
- Logstash connection doesn’t work
- Publishing to Logstash fails with "connection reset by peer" message
- @metadata is missing in Logstash
- Not sure whether to use Logstash or Beats
- SSL client fails to connect to Logstash
- Monitoring UI shows fewer Beats than expected
- Dashboard could not locate the index-pattern
- High RSS memory usage due to MADV settings
- Not sure how to read from .evtx files
- Contribute to Beats
Filter and enhance data with processors
editFilter and enhance data with processors
editYou can define processors in your configuration to process events before they are sent to the configured output. The libbeat library provides processors for:
- reducing the number of exported fields
- enhancing events with additional metadata
- performing additional processing and decoding
Each processor receives an event, applies a defined action to the event, and returns the event. If you define a list of processors, they are executed in the order they are defined in the Winlogbeat configuration file.
event -> processor 1 -> event1 -> processor 2 -> event2 ...
It’s recommended to do all drop and renaming of existing fields as the last step in a processor configuration. This is because dropping or renaming fields can remove data necessary for the next processor in the chain, for example dropping the source.ip
field would remove one of the fields necessary for the community_id
processor to function. If it’s necessary to remove, rename or overwrite an existing event field, please make sure it’s done by a corresponding processor (drop_fields
, rename
or add_fields
) placed at the end of the processor list defined in the input configuration.
For example, the following filter configuration drops a few fields that are rarely used (provider_guid
, process_id
, thread_id
, and version
) and one nested field, event_data.ErrorSourceTable
:
processors: - drop_fields: fields: [winlog.provider_guid, winlog.process.pid, winlog.process.thread.id, winlog.version, winlog.event_data.ErrorSourceTable]