We describe our customers' usual use cases for Graylog as one where we use it for event correlation. We take typical IT events, and we also use it for security event correlation as well. So, both security and general IT.

We use Graylog internally in our company.

The features and capabilities of Graylog that we have found most valuable are related to its basis on open search, which was ElasticSearch. We appreciate being able to integrate custom feeds and do custom parsers, and to be able to do some of the correlation on it. That all works effectively.

The Graylog features that have proven to be most beneficial for our data analysis in particular are that we tend to use it as a big data store, so we have the correlation rules that, if something matches under certain conditions, it raises an alarm. We use it for investigating problems and problem management. We throw all the information at it, we have it alerting for certain conditions, but generally we use it for deep diving into issues as needed.

The area in Graylog that needs to be improved or enhanced would be the integrations. It would be useful to have more parsers and filters for different types of systems, which is growing, but we still find many systems that there aren't any, and we have to create our own. Having a library of parsers would help. Mainly, it's about integrations: being able to parse different sources and output to different systems easier.

I have been working with Graylog for about 8 years or so. That is quite a while.

I rate the stability of Graylog as very stable, probably a nine out of ten.

On a scale from 1 to 10, where 10 is the highest level of scalability, I would rate Graylog's scalability as an eight. I think Graylog itself is scalable, but where it needs improvement is around the underlying features of open search, particularly concerning data logs and things. More up-to-date documentation on how to do high ingestion and high search scenarios, including recommendations for configuration and deployment, would be useful.

Regarding technical support for Graylog, I can't comment much because I've not had to use it. Even though we have the enterprise products, we've not needed to use technical support because we've been using Graylog for many years and can fix most problems ourselves. There are some sizing documents online, but they were a few years out of date when we looked a few months back.

Before Graylog, we had a customer running IBM QRadar, which is a big security logging platform. We used other products such as RSyslog, Kiwi Syslog, which is Windows-based, and Syslog-ng, among others.

The decision to switch to Graylog was influenced by my appreciation of its user interface. It separates out the ingestion from the backend. For instance, if Graylog is running and you take the backend down, you don't lose events. In contrast, with RSyslog, if you turn it off, you can't do backend-frontend maintenance, which is an advantage Graylog offers. It also handles clustering nicely, making it easy to scale up quickly.

I would rate my experience with the initial setup of Graylog on a scale of 1 to 10 as probably about a five. If someone has never used Linux before, it would be very difficult, but if you're familiar with Linux and the day-to-day things behind the scenes, it's quite straightforward. The guides online are simple, follow the guide, and you've got a system that works. There could possibly be more around improving the performance, and maybe some more up-to-date calculators on sizing because some of the sizing information we've seen previously are a few years out of date.

For maintenance, we usually need just one or two people. We have a team of three engineers who look after it, and they rotate the maintenance responsibilities every three weeks.

The return on investment or cost savings we have seen since the deployment of Graylog is primarily in time savings, allowing our security team and IT engineers quick access to information, as it all goes to one place. It makes it quite quick to find things, enabling us to retrieve the information needed to respond swiftly.

Evaluating other options before choosing Graylog was somewhat straightforward because we've been using it for some time and are confident with it. Originally, we recommended Graylog to a customer, but they chose QRadar, which is very expensive and didn't scale as effectively. Eventually, we put Graylog next to QRadar because QRadar couldn't keep up.

My impression of the overall visibility of Graylog is good. In the past few years, as it's transitioning from just an open-source product into more of an enterprise solution, they're trying to grow into that area and do more in the API space. I think it will get better, particularly for orchestration pieces. That's probably its weaker area compared to some of the other products such as Microsoft Sentinel or Log Analytics, where they have more hooks into different products. I appreciate that Graylog is moving towards that, and it's quite simple to get it stood up quickly. We have used it during security incidents with customers, and we have spun up a separate Graylog instance to help them with ransomware type issues.

Graylog has supported our compliance and security monitoring activities because, for one of our customers who falls under the NIST 2 regulation due to critical infrastructure, we heavily use it for that side. However, for the rest, we don't tend to use it for compliance really. A lot of that's handled separately, so it's not really an area we do much with Graylog at the moment, but it could be something that we could do more with in the future.

Graylog is not assisting us with our AI-driven data analysis or any operations with AI at the moment, but it could be something that we could do in the future.

Currently, about 10 people are using Graylog in our company.

We have plans to use Graylog more in the future as we deploy more. We run a private cloud for different platforms, and our intention is to have all of those systems folding their events into Graylog.

Overall, I would rate Graylog at about a seven or eight. The only downside is some of the integrations; if it had more integrations, it would be easier to work with other tools. Contextually, they're transitioning from an open-source background to a more enterprise-oriented space, which understandably takes time.

In my opinion, the best use case for Graylog is for backend services due to its excellent real-time updates. It is especially effective with strong type languages, like Java or C++. The streaming of messages happens with the GELF protocol over UDP, making it quite fast. Deploying Graylog into a Docker image where microservices are placed allows for easy log retrieval. Logs from different Docker machines can be combined into one Graylog instance, providing a complete view of backend behavior for both developers and customer support teams.

Graylog is valuable because it bridges technical knowledge to non-technical teams, presenting complex backend processes in a simple timeline. It boosts the knowledge of sales and customer support teams by allowing them to see the backend operations without needing to read the code. Its API is flexible for visualization, and its powerful search engine efficiently handles large volumes of log data. Moreover, its stability, fast search capabilities, and compatibility with languages like ANSI SQL enhance its utility in IT infrastructure.

An improvement I would suggest is in Graylog's user interface, such as allowing for font size adjustments. A potential enhancement could be the integration with Ollama to run large language models locally, maintaining high privacy standards.

I have been using Graylog for three years.

Deploying Graylog required about one week of preparation to evaluate the best setup, especially regarding Docker integration and the computing power requirements for scalability.

Graylog is very stable and capable of handling millions of messages without sudden shutdowns or service interruptions.

Deploying on the cloud for Graylog is advisable due to its need for scalability under varying message loads. Graylog offers the capability to withstand large volumes of data, adapting to fluctuating inflows.

I never personally reached out to Graylog technical support. I mostly relied on documentation to address my needs, which was adequate for my purposes.

I used my own logging service, Elasticsearch, and OpenSearch before transitioning to Graylog. OpenSearch was not as intuitive and had a steeper learning curve compared to Graylog.

The initial setup of Graylog was straightforward, provided the codebase was prepared for logging. The documentation, although not visually appealing, was informative and helpful.

I am not familiar with the pricing details of Graylog, as I was not responsible for that aspect. It was determined that we didn't need an enterprise plan, which is more suited for clients with less programming capabilities.

I evaluated Datadog among other solutions, but its pricing model deterred me since I preferred a solution like Graylog, which allowed testing without initial payment.

I would recommend Graylog for its stability, API capabilities, and fast search engine. However, it's not ideal for developers lacking in setting up comprehensive logging in their codebase. I rate Graylog an eight out of ten.

I mostly use it for log management, log aggregation, and visualization. In my case, I am researching how to basically integrate cyber threat intelligence into open-source team systems.

Graylog is very handy. It has data adapters and lookup tables that utilize HTTP calls to APIs. I can enrich data by automating HTTP calls to a MISP instance, for example, or other threat feeds. This is basically the brunt of the work. Otherwise, normalization and parsing of logs from different sources are involved.

I would say log enrichment via these data adapters and lookup tables is valuable, especially the caching ability since Graylog doesn't always have to make API calls for every single instance if it is enriching the same value. That is very handy and makes it scalable.

When it comes to configuring the processing pipeline, writing the rules can be very tedious, especially since the documentation isn't extensive on how the functions provided for these rules work. Parsing depends heavily on regular expressions, which makes the process somewhat tedious.

I have been using it for a year and a half.

I haven't deployed it in a cluster, so I can't properly evaluate how scalable it is. However, since it allows for cluster redundant setups, I imagine it is theoretically pretty scalable. It is very resource-intensive. We have tried it on a single node, but in a setting where a network has thirty different clients doing search queries for insane amounts of logs, it was very slow and inefficient, even with sixteen gigabytes of RAM for that server.

Until now, I have only used the open-source version. I haven't used Graylog Security or Enterprise, so I'm not sure if there is technical support for the open-source version.

Usually, if I have issues that require troubleshooting, I consult the Graylog Community. Sometimes there are solutions on the forum.

Configuring the SSL certificates usually takes a lot of time because I have to add the certificate to the Java keystore in a very specific format. Otherwise, it doesn't get recognized. It is not very convenient. That took me about one week to figure out.

I am the person responsible for that.

Graylog is a purpose-driven tool, so we don't really use it in our company. Rather, we usually deploy it for our clients. Some clients wanted it for managing logs for forensic analysis or compliance reasons, and some wanted it as a security option.

Some clients abandoned it. Even though it is customizable, it doesn't offer much functionality out of the box. It requires a fair amount of effort and expertise to function. Maybe if there were prebuilt dashboards or processing, like Wazuh, it could be adopted on a higher scale.

Overall, my rating for this product is seven out of ten.

As a bank, we use the product to collect logs from various sources, including applications, our website, and mobile applications.

Since it's a free tool, I don't have much to say. Troubleshooting is important to me. The initial setup is complex. I hope to see improvements in Graylog for more interactivity, user-friendliness, and creating alerts.

I have been using this solution for the past three years, and my current version is v5.1.

The solution is stable.

The product is scalable. Currently, three individuals, myself included, use the solution in our company. We plan to increase the usage in the future.

There is no customer service and support available for the free version of the solution.

We have tested IBM QRadar and now use it. First of all, the key factor is the pricing. I saw that IBM QRadar has an interactive dashboard, providing valuable insights to people. Additionally, I've seen that IBM QRadar has an agent that simplifies installations across various platforms without requiring intricate configurations. Also, IBM QRadar has automatic reporting.

The initial setup was complex. The deployment process involved server configuration, setting up alerts, and configuring the system. When upgrading from version 4.2 to 5.1, the configuration took some time.

We are using the free version of the product. However, the paid version is expensive.

Overall, I rate the product a six out of ten.