Logstash 7.12.0 Release Notes
editLogstash 7.12.0 Release Notes
editSecurity update
editCertificate verification with internal monitoring. We fixed a bug in the monitoring pipeline that caused it to pass monitoring data to Elasticsearch with certificate verification disabled. Logstash internal monitoring had been sending monitoring metadata (such as pipeline throughput metrics) to Elasticsearch without verifying the recipient. #12749
For information: CVE-2021-22138.
New features and enhancements
editProgress toward Elastic Common Schema (ECS)
editWe’ve done more work to help ease your transition to Elastic Common Schema (ECS). This release extends ECS work in previous releases. Here’s a recap:
- ECS support in Elasticsearch output plugin (7.9). The elasticsearch output plugin can manage index templates that are compatible with ECS. For more info, see Compatibility with the Elastic Common Schema (ECS).
-
Pipeline level ECS compatibility (7.10). The
pipeline.ecs_compatibility
setting lets users control ECS compatibility for all plugins in a pipeline at once instead of configuring each instance manually. This setting lets users lock in a specific behavior in advance of their next major version upgrade.
ECS compatibility is off-by-default in Logstash 7.x, but will be on-by-default in Logstash 8.0.
ECS-compliant grok patterns
editThe grok filter plugin offers a new set of patterns to make event field names ECS-compliant. (No worries if you’re not ready to transition yet. The complete set of legacy patterns is still available and continues to be the default for Logstash 7.x.)
The ECS pattern set has an equivalent for each pattern in the legacy set, and is a drop-in replacement. Use the ecs_compatibility setting when you’re ready to switch modes.
ECS-compliant beats input
editThe beats input plugin is now ECS-compliant. It adds two fields related to the event: the deprecated host which contains the hostname, and the ip_address containing the remote address of the client’s connection. When ECS compatibility mode is enabled these fields are moved to ECS-compatible namespace.
JDK 15 support
editLogstash introduces support for JDK 15! You need to update settings in
jvm.options
and log4j2.properties
if:
- you are upgrading from Logstash 7.11.x (or earlier) to 7.12 or later, AND
- you are using JDK 15 or later.
Unless both of these conditions apply, you don’t need to adjust settings because of the upgrade. See Using JDK 15 for more information.
Conditional settings for JVM versions
editWe’ve added support for conditional settings and behavior, dependent on the JVM
version. Now you can configure different settings for different JVM versions.
Here is an example from the default jvm.options
file.
Example:
## GC configuration 8-13:-XX:+UseConcMarkSweepGC 8-13:-XX:CMSInitiatingOccupancyFraction=75 8-13:-XX:+UseCMSInitiatingOccupancyOnly
This example sets garbage collection (GC) values for JDK 8-13 only. Those settings don’t apply to JVM 14 and above.
This feature is available for any setting in the jvm.options
file, and aligns
more closely with the Elasticsearch implementation of jvm settings.
Aarch64 (ARM64) support for Linux (beta)
editSupport for 64-bit ARM architectures on Linux is now in beta, with downloadable artifacts and docker images available.
Performance improvements and notable issues fixed
editPipeline loading and monitoring improvements
We’ve made changes to start the webserver that exposes the Logstash metrics API earlier in the startup process. For slow starting pipelines, this would cause error messages to appear in the Logstash logs, and cause delays to the availability of the metrics API. #12571
Windows startup fixes
We’ve fixed an issue where Logstash would crash when attempting to start using the bundled JDK when Logstash was located in a folder where the folder name contained spaces #12585
Plugin releases
editElasticsearch Filter - 3.9.3
Geoip Filter - 6.0.5
Grok Filter - 4.4.0
- Feat: ECS compatibility support. Add (built-in) patterns definitions that are fully Elastic Common Schema compliant. #162
Metrics Filter - 4.0.7
- [DOC] Fixed typo in documentation
Beats Input - 6.1.0
Elasticsearch Input - 4.9.1
Http Input - 3.3.7
- Feat: improved error handling/logging/unwraping #133
Redis Input - 3.6.0
- Remove ruby pipeline dependency. Starting from Logstash 8, Ruby execution engine is not available. All pipelines should use Java pipeline #84
Syslog Input - 3.4.5
- Added support for listening on IPv6 addresses
Tcp Input - 6.0.7
- Fix: reduce error logging (to info level) on connection resets #168
- Refactor: only patch Socket classes once (on first input)
-
Refactor: use a proper log4j logger (in Java to avoid surprises when unwrapping
LogStash::Logging::Logger
)
Udp Input - 3.4.0
Kafka Integration - 10.7.1
- Fix: dropped usage of SHUTDOWN event deprecated since Logstash 5.0 #71
Rabbitmq Integration - 7.2.0
- Remove ruby pipeline dependency. Starting from Logstash 8, Ruby execution engine is not available. All pipelines should use Java pipeline #39
Ecs_compatibility_support Mixin - 1.1.0
-
Support Mixin for ensuring a plugin has an
ecs_compatibility
method that is configurable from anecs_compatibility
option that accepts the literaldisabled
or a v-prefixed integer representing a major ECS version (e.g.,v1
), using the implementation from Logstash core if available.
Cloudwatch Output - 3.0.9
- Fix: dropped usage of SHUTDOWN event deprecated since Logstash 5.0 #18
Elasticsearch Output - 10.8.2
- [DOC] Update links to use shared attributes #985
Lumberjack Output - 3.1.8
- Fix: dropped usage of SHUTDOWN event deprecated since Logstash 5.0 #31
S3 Output - 4.3.3
- [DOC] Update links to use shared attributes #230
Core Patterns - 4.3.0
With 4.3.0 we’re introducing a new set of pattern definitions compliant with Elastic Common Schema (ECS), on numerous places patterns are capturing names prescribed by the schema or use custom namespaces that do not conflict with ECS ones.
Changes are backwards compatible as much as possible and also include improvements to some of the existing patterns.
Besides fields having new names, values for numeric (integer or floating point) types are usually converted to their
numeric representation to ease further event processing (e.g. http.response.status_code
is now stored as an integer).
to leverage the new ECS pattern set in Logstash a grok filter upgrade to version >= 4.4.0 is required.
-
aws
-
in ECS mode we dropped the (incomplete) attempt to capture
rawrequest
fromS3_REQUEST_LINE
-
S3_ACCESS_LOG
will handle up-to-date S3 access-log formats (6 new field captures at the end) Host Id → Signature Version → Cipher Suite → Authentication Type → Host Header → TLS version -
ELB_ACCESS_LOG
will handle optional (-
) in legacy mode -
null values such as
-
or-1
time values (e.g.ELB_ACCESS_LOG
'srequest_processing_time
) are not captured in ECS mode
-
in ECS mode we dropped the (incomplete) attempt to capture
-
bacula
-
Fix: improve matching of
BACULA_HOST
asHOSTNAME
-
Fix: legacy
BACULA_
patterns to handle (optional) spaces -
Fix: handle
BACULA_LOG
Job Id: X prefix as optional - Fix: legacy matching of BACULA fatal error lines
-
Fix: improve matching of
-
bind
-
BIND9
's legacyquerytype
was further split into multiple fields as:dns.question.type
andbind.log.question.flags
-
BIND9
patterns (legacy as well) were adjusted to handle Bind9 >= 9.11 compatibility -
BIND9_QUERYLOGBASE
was introduced for potential re-use
-
-
bro
-
BRO_
patterns are stricter in ECS mode - won’t mistakenly match newer BRO/Zeek formats -
place holders such as
(empty)
tags and-
null values won’t be captured -
each
BRO_
pattern has a newerZEEK_
variant that supports latest Zeek 3.x versions e.g.ZEEK_HTTP
as a replacement forBRO_HTTP
(in ECS mode only), there’s a new file zeek where all of theZEEK_XXX
pattern variants live
-
-
exim
-
introduced
EXIM
(EXIM_MESSAGE_ARRIVAL
) to match message arrival log lines - in ECS mode!
-
introduced
-
firewalls
-
introduced
IPTABLES
pattern which is re-used withinSHOREWALL
andSFW2
-
SHOREWALL
now supports IPv6 addresses (in ECS mode - dueIPTABLES
pattern) -
timestamp
fields will be captured forSHOREWALL
andSFW2
in legacy mode as well -
SHOREWALL
became less strict in containing thekernel:
sub-string -
NETSCREENSESSIONLOG
properly handles optionalsession_id=... reason=...
suffix -
interval
andxlate_type
(legacy) CISCO fields are not captured in ECS mode
-
introduced
-
core (grok-patterns)
-
SYSLOGFACILITY
type casts facility code and priority in ECS mode -
SYSLOGTIMESTAMP
will be captured (fromSYSLOGBASE
) astimestamp
- Fix: e-mail address’s local part to match according to RFC (#273)
-
-
haproxy
- several ECS-ified fields will be type-casted to integer in ECS mode e.g. haproxy.bytes_read
-
fields containing null value (
-
) are no longer captured (e.g. in legacy modecaptured_request_cookie
gets captured even if"-"
)
-
httpd
-
optional fields (e.g.
http.request.referrer
oruser_agent
) are only captured when not null (-
) -
source.port
(clientport
in legacy mode) is considered optional -
dropped raw data (
rawrequest
legacy field) in ECS mode - Fix: HTTPD_ERRORLOG should match when module missing (#299)
-
optional fields (e.g.
-
java
-
JAVASTACKTRACEPART
's matched line number will be converted to an integer -
CATALINALOG
matching was updated to handle Tomcat 7/8/9 logging format -
TOMCATLOG
handles the default Tomcat 7/8/9 logging format -
old (custom) legacy TOMCAT format is handled by the added
TOMCATLEGACY_LOG
-
TOMCATLOG
andTOMCAT_DATESTAMP
still match the legacy format, however this might change at a later point - if you rely on the old format useTOMCATLEGACY_
patterns
-
-
junos
-
integer fields (e.g.
juniper.srx.elapsed_time
) are captured as integer values
-
integer fields (e.g.
-
linux-syslog
-
SYSLOG5424LINE
captures (overwrites) themessage
field instead of using a custom field name -
regardless of the format used, in ECS mode, timestamps are always captured as
timestamp
-
fields such as
log.syslog.facility.code
andprocess.pid
are converted to integers
-
-
mcollective
- mcollective-patterns file was removed, it’s all one mcollective in ECS mode
-
MCOLLECTIVE
'sprocess.pid
(pid
previously) is not type-casted to an integer
-
nagios
-
numeric fields such as
nagios.log.attempt
are converted to integer values in ECS mode
-
numeric fields such as
-
rails
-
request duration times from
RAILS3
log will be converted to floating point values
-
request duration times from
-
squid
-
SQUID3
'sduration
http.responsestatus_code
andbytes
are type-casted to int -
SQUID3
pattern won’t capture null (-)user.name
orsquid.response.content_type
- Fix: allow to parse SQUID log with status 0 (#298)
- Fix: handle optional server address (#298)
- Fix: Java stack trace’s JAVAFILE to better match generated names
- Fix: match Information/INFORMATION in LOGLEVEL #274
- Fix: NAGIOS TIMEPERIOD unknown (from/to) field matching #275
- Fix: HTTPD access log parse failure on missing response #282
-
Fix: UNIXPATH to avoid DoS on long paths with unmatching chars #292
For longer paths, a non matching character towards the end of the path would cause the RegExp engine a long time to abort. With this change we're also explicit about not supporting relative paths (using the `PATH` pattern), these won't be properly matched.
- Feat: allow UNIXPATH to match non-ascii chars #291
-