NOTE: Graylog has made many updates to the application since this release. We encourage you to update to the latest version and take advantage of the large number of new features and functionality.
We are happy to announce that Graylog v2.5 is now available. This release includes several new features, including support for Elasticsearch 6.x, along with numerous bug fixes.
NEW FEATURES
ELASTICSEARCH 6.X SUPPORT
Graylog v2.5 supports Elasticsearch 6.x. Our benchmarks have shown that Graylog 2.5 requires 25-30% less storage space compared to previous versions.
The upgrade to Elasticsearch 6 is very easy if you are already on Elasticsearch 5 and you don’t have any Graylog indices that were created by an older version of Elasticsearch.
If this command returns no index names, you can upgrade from Elasticsearch 5 to 6 without additional manual steps required:
$ http :9200/_settings | jq ‘[ path(.[] |
select(.settings.index.version.created < “5000000”))[] ]’
(this example uses jq and httpie)
We will follow up with a guide that describes how to upgrade indices that require re-indexing later this week. Please wait for this guide and do not upgrade to Elasticsearch 6 yet if the command above does return index names.
Note that Graylog v2.5 also still supports Elasticsearch 5 and an upgrade is strongly recommended to prepare you for Graylog 3.0, but not mandatory.
Graylog Enterprise customers can contact our support team with any questions related to the upgrade and we’ll be happy to assist.
ALERTING IMPROVEMENTS
Before this release, all alert conditions applied to all messages in a stream. The problem with that was that you had to create another stream for each subset of messages you wanted to alert on.
For example, if you had a stream called “Windows EventLogs” and you wanted to trigger an alert whenever a message with Event ID 1102 (The audit log was cleared) came in, you’d have to create a new stream “Windows EventLogs: Audit Log Cleared” and then add a message count condition on that stream.
Graylog v2.5 introduces a new Query parameter for all alert conditions that lets you specify a search query to narrow down the alert result set. You can now add the alert condition to your global EventLog stream and specify a query like “event_id:1102”. The query language is the same as for all other searches so you can use range operators and wildcards, and also chain parts of the query with AND and OR operators.
NEW LOOKUP TABLE ADAPTER: DNS
Our lookup tables already included useful adapters to enrich data in log messages with more data found in CSV files on disk, threat intelligence lists, or WHOIS databases.
With this release, we are adding a new lookup table adapter that lets you to perform forward or reverse DNS lookups. You can take an IP address or domain name from a log message, look it up using the new adapter, and then add the result back to the original log message. This capability is very useful for, for example, enriching any network traffic logs with more information about the involved hosts.
You can find the documentation here.
THROTTLING SUPPORT FOR AWS FLOWLOGS INPUT
The Graylog journal is a part of the graylog-server process that effectively queues messages on disk when data can’t be processed due to planned maintenance, temporary overloading, or an outage of underlying infrastructure.
Graylog message input can support “throttling” of data if the server is able to temporarily stop reading from a source. The graylog-server process enters a throttled state when messages are appended to the journal faster than they are processed. See this page in the docs for more info.
Sources that are pushing messages into Graylog via a simple network connection do not usually support throttling (a request to stop sending data for a while). Some sources like Kafka or AMQP do support this though and our inputs are handling this accordingly.
With this release, we are introducing throttling support for our AWS Flow Logs and AWS Logs inputs. Messages are now left on the AWS Kinesis stream and are not read into the Graylog journal when the server is in a throttled state. This allows for better load balancing of all AWS Flow Logs inputs across your Graylog cluster and also reduces unnecessary journal contention. The messages really belong on Kinesis when we can’t read them fast enough and that’s where we leave them now.
You can find the documentation here.
CHANGELOG
You can find the complete changelog here.
DOWNLOAD NOW
Download Graylog v2.5 here.
Please report bugs and any other issues in our GitHub issue tracker.
COMING SOON: GRAYLOG V3.0!
Graylog v3.0 is coming in February 2019!
Stay in touch to find out more about the release:
* Graylog v3.0 Sneak Peek Webinar
* Follow us on Twitter – @graylog2
* Follow us on LinkedIn
* Follow us on Facebook
