Graylog Reviews

Our primary use case of this solution is for logging. Because we have financial systems, we also use it for audit trailing.

I basically run the entire program in our company. Whenever there's an audit, I get the people on board and give them the information they require.

Graylog captures our financial logs and preserves them, mainly for any audit that may come up. The compliance is very good.

What I like most about this solution, is that it caches the log. I also like it's filtration because we have various layers of data that needs to be captured - from flat filing to Windows servers, Linux-based servers and the like. I like the diversity and the number of environments it can cover, including the switches.

I would like to see a date and time in the Graylog Grok patterns so that I can save time when searching for a log. I like how the streams and the search query work, but adding a date and time will allow me to pull out a log in a milli-second.

I am very proud of how very stable the solution is. One time I had an entire node on my VxRail VMware collapse, so I basically restored the template, gave it the same IP address and everything was working again.

We've grown from 500 to 2,000 independent devices on this solution, and it captures them all. We even plan to increase our usage. So, yes, the program is scalable.

There hasn't been a need for me to call support, because I only went through the forums and hundreds of pages of manuals to get to understand it. 

The initial setup was really complex because I did it myself. I had no support and I didn't understand the whole ecosystem. The first deployment took about a month because I had to figure out exactly what I'm capturing, and how to query it afterwards. I also had to manage the clientele, client installations, and the like. After a month or so I had an overall view of everything.

I am responsible for the deployment and maintenance of Graylog. I've even done smaller setups and deployments for other people. 

I use the free version of Graylog.

In the next version I would perhaps like to see less overlapping in in the interface. Some users feel that it is still very rigid and boxy. Pretty old school. So a more user-friendly interface with less overlapping in the structures would be great. I rate this solution 9.5 out of 10.

Logs were previously stored in various database tables. Log consumers were required to write SQL for retrieval, then correlate/join disparate sources by hand. Since most logging fields were not indexed, the retrieval process was painfully slow.

Real-time UDP/GELF logging and full text-based searching. Since UDP is a stateless, connectionless protocol, it simplifies error handling for the log sender/producer in the event that Graylog is not available. UDP is also a fast and lightweight protocol, perfect for sending large volumes of logs with minimal overhead. Storing logs in Elasticsearch means log retrieval is extremely fast, and full text search is available by default. Additionally, Graylog has support via plugins for Slack-based alerts. These have been wonderful for notifying us when exceptional log messages are encountered.

• Backup and restore functionally for migrating instances.
• Dashboard and search analytics (i.e., more complex visualizations and the ability to execute custom Elasticsearch queries would be great).
• More flexible alert conditions

No issues.

No issues.

I would rate them as a two out of 10. You are on your own without an enterprise license.

No previous solution.

Our setup was not straightforward. We opted to create a Docker swarm instance, hosting three Graylog nodes, Nginx for SSL/TLS offloading, and three MongoDB nodes (in a replica set). Then, we installed a three node Elasticsearch cluster on RHEL 7 virtual machines. The majority of the configuration was done through Docker compose.

You get a lot out-of-the-box with the non-enterprise version, so give it a try first.

All the other solutions were in-house proposals.

Thoroughly read the Graylog documentation and consider Enterprise support if you have atypical needs or setup requirements.

Use for log aggregation, alerting, and monitoring in a container environment

• Searching errors
• Alerting through Slack and OpsGenie using their plugins.

We run a containerized microservices environment. Being able to set up streams and search for errors and anomalies across hundreds of containers is why a log aggregation platform like Graylog is valuable to us. 

Allowing us to set up alerts and integrate with platforms we already use, such as Slack and OpsGenie to alert users of these errors proactively, is also a very useful feature. 

Elasticsearch recommendations for tuning could be better. Graylog doesn't have direct support for running the system inside of Kubernetes, so it can be challenging to fill in the gaps and set up containers in a way that is both performant and stable.

We ran into problems with Elasticsearch throwing a circuit-breaking exception due to field data size being too large. It turned out that the heap size directly impacted this size in a high-throughput environment, causing unexplained instability in Graylog. We were able to troubleshoot on the Elasticsearch size, but we should have been able to reference some minimum requirements for Graylog to know that our settings weren't sufficient.

Otherwise, the documentation is great and there are a lot of options for configuration. Since container orchestration systems are popular and Graylog fits the niche well, perhaps they could officially support running in docker containers on Kubernetes as a StatefulSet as a use case. That way, the declarative nature of Kubernetes config files would document their best-case deployment scenario.

Yes, with Elasticsearch.

No issues with scalability.

Never used.

Splunk, Logstash, and Elasticsearch.

Set up in Kubernetes; not complex once the configuration is right.

We use the free version.

Splunk, Logstash, and Elasticsearch.

Make sure your Elasticsearch cluster is sized right, memory-wise.

It is used as a log manager/SIEM. It provides visibility into the infrastructure and security related events.

The most valuable part is an open source. The build is stable and requires little maintenance, even compared to some extremely expensive products.

There are places which could be improved:

• Stream alerts
• Dashboards
• Parsing.

Some places were already improved in 2.4 with the threat intelligence add-on.

Over six months, I had two similar issues where searches were performed on field "messages". It exhausted all the memory of the ES node causing an ES crash and a Graylog halt.

We have scaled from a single machine installation (a VM with a Graylog + ES + MongoDB) to (2 Graylog + 2 ES + 3 MongoDB). This was done smoothly with a minimal impact on logging.

I have only used the community support (forum), but Graylog developers are quick to respond and assist with issues.

Splunk: The price was the factor for the switch.

The initial setup is straightforward.

Step-by-step installation walk-through is provided by the Graylog team.

If you want something that works and do not have the money for Splunk or QRadar, take Graylog.

ELK was another option. However, Graylog appeared to be more robust and had less limitations at the time.

Just go ahead with the product. 

This had increased productivity for the dev and support teams, because we are directly notifying them. Now, they have to come to dev for every issue. 

The Stream Alert feature is a highlight of this. As for similar products, there are separate integrations, but Graylog ships this with the build.

There should be some user groups and an auto sign-in feature.

No issues.

Not yet.

We are not using any technical support.

No.

It was pretty straightforward.

None, as we are not using an enterprise solution.

We had evaluated ELK Stack, but found Graylog more useful for our use case.

I will say that if you are using this, then explore all the features. You will find this like a swiss army knife.

The product does all the things it must do very well. It can be used for investigating logs as well as a dashboard to see the current amount of errors in the environment.

• Logging aggregation and querying. We have multiple applications, therefore it is no longer feasible to check logs from our file system per each application.
• When adopting microservices architecture, centralized logging is a must have.

It has sped up the investigation of incidents.

The alerting system could be more flexible. It does not allow for definition of different thresholds and alert types of the same streams. It allows different alert types and thresholds for the same stream.

E.g., if we have a single stream of errors, I would like to send each error to the ticketing system: A mail if there are less than 1 errors per second and an SMS if greater than 10 errors received per second.

One year.

No issues.

No issues.

Not applicable.

No.

It was straightforward.

Yes, Elastic Stack.

Send all logs to Graylog instead of just your errors. This will make it easier to investigate problems.

The core of the product is to aggregate log collection.

The ability to write custom alerts is key to information security and compliance. Also, I love the improvements I can make on dashboard widgets. 

Application event messaging, or logging, until I show an organization the result of seeing the application in real time. Then, I can mentor the importance of a good log event message. To have proper context, logging is more than exception logging, it is positive and negative logging. Once you show what can be done with a proper logging message, the entire application can become more robust. The ability to make an extractor out of a non-standard stream of strings, which allows for you to index on a plethora of fields, and you gain some insights that you may have missed. 

Graylog brings life to the application execution.

The collectors and using sidecar made my life easier from earlier versions. Unfortunately, I have been pulled away from the product, beyond setting up new inputs, defining the alerts. I am currently trying to leverage the API and Graylog Extended Log Format (GELF), and some of the underlying tech of Elasticsearch as well, for downstream consumers and our AI consumers.

For improvements or features to add, I would like to see a default dashboard widget that shows the topology of the clusters defined for the graylog install.
For instance, I have three Elasticsearch nodes and three MongoDB. I would like to see a visual representation of their status. 

Additionally, maybe it does exist (I have not looked), but I would like to see percent filled of the current index. 

I love the product. I have used it at three different employment points in my career. I first used Graylog seven years ago, and have provisioned and configured it into production three times over that period.

I have had two gaps in my use over the seven years, so using the current version has been super.

I do have a multinode deployment, with only one Graylog node. As we rely more on Graylog permanently and consume more of its collected data, I will transition to a Graylog HA installation, as and when we come to require it without outage. We are moving more to IoT, and those streams will be mandated to not have any gaps. They will be responders to events that can't have any outages. 

No scaling issues that I have seen with the three nodes of MongoDB and the three nodes of Elasticsearch. I will transition to have HA, load balancers, and buffering/queues as we move forward. I see things have changed in the latest version, or current -1 that I am using right now. I see durability is defined, I just need to reach out and implement it. 

I have not had to use technical support. 

I have always used Graylog2. Initially, I may have looked at Logstash and Loggly, but once it was off and running, I embraced the Graylog way of things. 

This was the first multi-node installation that I laid out. It seems to be running, and I did not find it overly complicated. I have Apache distributed big data experience, and have used Cloudera within that scope. Having Linux expertise, Apache, Tomcat, REST, and Java experiences may have reduce the complexity. 

I am not fully aware of their licensing model. I should take a look at the details, as I am using a community edition. I have not looked at the enterprise offering from Graylog.

I reviewed Logstash and Loggly. 

Start with the defaults. Do not be afraid to start over. Having a test or sandbox to work with to figure out how to create streams, extractors, and inputs is a good way to go. Recommend interacting with MongoDB and Elasticsearch from the command line, if you have the time; nothing deep. Knowing the underlying CLI's may help you if you need to understand how or why something may not line up correctly.

I would consider myself Graylog2's number one fan or at least a big advocate of the utility of this product. Step one in any application inception should begin with application messaging, and couple that with Graylog2, and you will cover many bases of insight and compliance right out of the gate. 

We are using only a few parts of its functionality. Its most valuable functions for us are:

• Log collection
• Quick string search in central storage
• Message forwarding through the in-built module
• Message filters. 

We need all these function to fulfill law requirements for cyber security.

We use this system as a central log collector with the possibility to search through the archive backward for specific string definitions.

The biggest problem is the collector application, as we wanted to avoid using Graylog Collector Sidecar due to its architecture. It requires connection outside our network during build from source, so we decided instead to use the obsolete Graylog Collector, which is working fine and in an easy way. It would be great, if that component would get back into the development process. But it is nothing that I could even complain about, as our company is not paying for support.

Solution was build on the 10th of January 2017, so for nearly a year.

The only issue we had was during the Java patch. Graylog's search DB was not able to start up after the upgrade to Java 9, so we returned back to v.8. With that only exception, we have any issues with application or its components.

We never attempted to scale the environment, as its sizing is defined in the planning phase and it fitted us later perfectly.

We never contacted technical support, so I cannot answer this.

There were no solution before Graylog. It was built as new project.

We did not had any experience with Graylog or its components before this project. We had luck in planning phase, the environment was sized properly to its purpose. 

As Graylog also needs other applications/DB's to run, implementation of each component was a separate challenge, as we are not using the default configuration.

I cannot answer this question. Having paid official support is wise for projects.

Yes, we were thinking about the Logstash family, but due to similar issues with the building codes as in the Graylog Collector Sidecar case, we decided for Graylog.

Do not give up. Look forward and good luck. The worst phase was the planning one, so I would offer this advice: Don't underestimate anything. 

Graylog is worth the given effort.