We are really pleased to announce that Graylog v2.1 is now GA!
Graylog 2.1.0 introduces many new features such as message decorators and pluggable authentication. We also have made improvements to the product based on your feedback. We want to use this opportunity to truly thank you for helping us reach this milestone!
For those of you that are currently using Graylog Enterprise, we have exciting news that will be released soon. Please check our blog in the next few days to catch the latest updates.
Download Graylog 2.1.0:
- DEB or RPM packages are available in our repositories and our download page. Check our documentation for details.
- Docker image
- OVA / Appliance
- Tarball (manual installation)
users also need to download version 1.1.0
of the enterprise plugins, which are compatible with Graylog 2.1.0.
Now let’s jump in and see these new features!
Message decorators allows you to modify message values on search result pages automatically. A classic example would be to change the numerical severity level of a syslog message (level=4) to a human readable string like level=warning (4).
We are shipping two standard decorators that you can use out of the box:
Syslog severity mapper decorator
This decorator lets you automatically decorate numeric syslog severity level values to a more
legible text representation.
Format string message decorator
The format string message decorator will help you alter the look of your fields. This will allow you to combine several fields into one or make some of your fields more readable.
In addition to a standard decorator, you can also use a message processing pipeline as a message decorator so that every message of the current search result page will run through the pipeline. It is also possible to write your own message decorators using our plugin system.
Decorator configurations are always bound to streams, so you can have standard mutations per
The Graylog Processing Pipeline now comes with a complete simulator user interface that allows you to test your pipeline and rule compositions.
When a test log message is fed into the simulator, you will immediately see the following:
- An overview of what fields were transformed and why
- The resulting, fully processed and parsed log message
- A microsecond resolution trace of the performed actions
Beats support for Collector Sidecar and message input
The Graylog Collector Sidecar now supports Elastic Beats. This means you can control the deployment and configuration of your Beats fleet automatically and template-based from your Graylog Web Interface.
Collector status display in web interface
Collectors can now send their internal status back to Graylog. A status page lists all running collectors for each host. In case of an error, the host is marked with a small red badge to indicate the problem and with a message to get an idea of why the collector is failing. In addition, the user can find general information on the status page like the tags that are configured for the Sidecar or a list of available log files. A real headless administration is now possible with these changes.
SSO & Pluggable authentication
Graylog has always supported the built-in user/password and LDAP authentication methods but this
release finally makes the authentication methods pluggable. The first plugin we released is for Single-Sign-On (SSO).
The SSO plugin supports automatic login and user account creation based on trusted HTTP headers set by an authentication proxy.
*Note that the SSO plugin is not bundled with the release, so you need to download and install it manually if you want to use it. You can find the plugin in the Graylog Marketplace.
Stream rule descriptions and alert condition titles
Stream rules and alert conditions can now be annotated with more information. This is extremely useful when working in a team. A team member can now look at stream rules or alert conditions and receive additional context as to why they were created or what they are intended to do.
Add more flexibility to the network settings
We made some changes in the network settings, in order to make Graylog easier to deploy, especially
when running behind proxies or load balancers. The changes are compatible with the previous
settings, so you should not require any changes when upgrading from 2.0.x to 2.1.x.
Please take into account that we modified the default settings to make the web interface and REST
API to live under the same port. Your Graylog web interface is available now by default in
http://127.0.0.1:9000/, and your Graylog REST API in http://127.0.0.1:9000/api.
Upgrading from Graylog 2.0.x to 2.1.x
The upgrade is a drop-in replacement from v2.0. Please ensure you read the upgrade documentation before start the upgrading process!
For OVA users, please follow these instructions to upgrade your Virtual Machine Appliances.
These are the changes we made since 2.1.0-rc.1. The full Graylog 2.1.0 changelog is available here.
- Actually use the bluebird promise in FetchProvider. Graylog2/graylog2-server#2762
- Audit event cleanup. Graylog2/graylog2-server#2746
- Update documentation links. Graylog2/graylog2-server#2759
- Allow child elements in the search form. Graylog2/graylog2-server#2756
- Make key_prefix configuration optional. Graylog2/graylog2-server#2755, Graylog2/graylog2-server#2757
- Invalidating widget result cache cluster wide when a widget changes. Graylog2/graylog2-server#2732, Graylog2/graylog2-server#2745
- Correct documentation links in 'misc/graylog.conf'. Graylog2/graylog2-server#2747. Thank you @supahgreg!
- Fix web plugin loading on IE 11
Pipeline processor plugin
- Fix page size in function list. Graylog2/graylog-plugin-pipeline-processor#97
We love your feedback
We are really excited about Graylog 2.1.0, and we want to hear what you think about it! There are a variety
of ways to provide feedback, all of which can be found on our Community page.