Humio Server 1.12.0 LTS (2020-06-09)
Version? | Type? | Release Date? | Availability? | End of Support | Security Updates | Upgrades From? | Config. Changes? |
---|---|---|---|---|---|---|---|
1.12.0 | LTS | 2020-06-09 | Cloud | 2021-06-30 | No | 1.10.0 | No |
Hide file hashes
JAR Checksum | Value |
---|---|
MD5 | 73a3fc77b4b603df3d492a3c8f740cb2 |
SHA1 | 0e70382492ca4a59b3139fad1ee22344f0b257e8 |
SHA256 | dbf34321f44a4e60726a10d67d1a73db7915c94d7e786ad332d5832f34a81c81 |
SHA512 | 4f2840a8b552395735006481107c55567dbbd865025fb0fbfdf5d590938eafb541a780b4065a4ed4419b12e7e894c9a768902ea8f5c21ed7debc3368e6a7e528 |
Export to Bucket, findTimestamp()
,
selfJoin()
, Emergency User Sub-System This
release promotes the 1.11 releases from preview to stable. To
see more details go through the individual 1.11.x release notes
(links in the changelog).
The selfJoin()
query function allows
selecting log lines that share an identifier; for which there
exists (separate) log lines that match a certain filtering
criteria; such as "all log lines with a given userid for which
there exists a successful and an
unsuccessful login".
The findTimestamp()
query function will try
to find and parse timestamps in incoming data. The function
should be used in parsers and support automatic detection of
timestamps. It can be used instead of making regular expressions
specifying where to find the timestamp and parsing it with
parseTimestamp()
. Checkout the
findTimestamp()
for details.
As an alternative to downloading streaming queries directly, Humio can now upload them to an S3 or GCS bucket from which the user can download the data. See Data Storage, Buckets and Archiving.
If there are issues with the identity provider that Humio is configured to use, it might not be possible to log in to Humio. To mitigate this, Humio now provides emergency users that can be created locally within the Humio cluster. See Enabling Emergency Access.
Fluent Bit users might need to change the Fluent Bit configuration. To ensure compatibility with the newest Beats clients, the Elastic Bulk API has been changed to always return the full set of status information for all operations, as it is done in the official Elastic API. This can however cause problems when using Fluent Bit to ingest data into Humio.
Fluent Bit in default configuration uses a small buffer (4KB) for responses from the Elastic Bulk API, which causes problems when enough operations are bulked together. The response will then be larger than the response buffer as it contains the status for each individual operation. Make sure the response buffer is large enough, otherwise Fluent Bit will stop shipping data. See: https://github.com/fluent/fluent-bit/issues/2156 and https://docs.fluentbit.io/manual/pipeline/outputs/elasticsearch
Fixed in this release
Other
Other changes: (see 1.11.1 release notes)
Major changes: (see 1.11.0 release notes)