Graylog Enterprise Reviews

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.

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.

Neutral

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.

We have various environments, including UAT, SIT, Dev, and Production, with automated deployments. We refer to Graylog Enterprise to verify if deployments have completed, check their status if they have failed, and determine what version is currently running.

Some team members from the QA team are unable to see the exact version or the newer version. We use Graylog Enterprise to check if the deployment is done, identify what version has been deployed, and determine on what date the environment was updated.

We provide variables to fit in the relevant section and select the appropriate one, such as the environment and what we need to check. This is the main feature I appreciate about Graylog Enterprise. Whatever we select, such as the database name or environment name, all the information appears, including the date of the last deployment and related details.

Troubleshooting is straightforward with Graylog Enterprise. Whenever we encounter an issue, whether from the QA team or other team members, we use it to troubleshoot the specific problem and implement a fix.

During deployments, we fix issues as quickly as possible using Graylog Enterprise. When team members from the QA team inform us that something is not working or an environment is down, we access Graylog Enterprise to verify if the deployment has been completed and check exactly what version is running.

We receive approximately 15 to 16 daily requests, and we resolve them through Graylog Enterprise.

We have been using Graylog Enterprise for the last two years. Graylog Enterprise is deployed in our organization as a private cloud solution.

There are many other applications in the market that influenced my rating reduction.

My main use case for Graylog Enterprise is to monitor all of the company's requests.

A quick specific example of how I use Graylog Enterprise in my work is that we use it to handle tickets where there is a need to obtain evidence through the requests between systems.

In Graylog Enterprise, I work with all types of data that can travel between the requests of various systems. During a normal day, we handle tickets and need to investigate some requests, and in those cases, we use Graylog Enterprise.

I find all of the features Graylog Enterprise offers to be very interesting and particularly useful.

Graylog Enterprise has impacted my organization very positively.

It helps provide agility during the discovery of evidence for the resolution of problems.

For me, Graylog Enterprise meets my needs satisfactorily.

I don't have anything else I'd like to see changed or enhanced in Graylog Enterprise.

I have been using Graylog Enterprise for one year.

On a scale of 1 to 10, I would rate Graylog Enterprise a 10.

I think this score is appropriate because Graylog Enterprise serves me very well.

My advice for others looking into using Graylog Enterprise is to explore it a lot.

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.

We had two use cases. In the beginning, log centralization was the main thing, and this was the most frequent use of Graylog, but we also tried to use it for analytics. Graylog was maintained by the data lake team, and we were looking for tools that were suitable for analytics. We felt that Graylog looks real-time. It had some graphs and dashboards. So, we had an idea to use it for analytics.  

What I like about Graylog is that it's real-time and you have access to the raw data. So, you ingest it, and you have access to every message and every data item you ingest. You can then build analytics on top of that. You can look at the raw data, and you can do some volumetric estimations, such as how big traffic you have, how many messages of data of a type you have, etc.

We stopped using it for analytics because of its price, and at the moment, we are using it mostly for log centralization. If you use it with high traffic for analytical purposes, as well as for the logs, the infrastructure costs are unbelievable.

Graylog is a great product backed by Elasticsearch as the storage and query engine. It is just an interface on top of Elasticsearch and some Elasticsearch management. The indexes that are kept in Elasticsearch are managed by Graylog software. Elasticsearch is a decent product, but it's very infrastructure-heavy. It requires lots of resources, and if you make a mistake with provisioning, you are likely to not get a cluster back. We had a couple of outages like that, and we hated that. So, we ended up over-provisioning resources just to avoid such situations from happening. If you have a whole team trying to fix the Graylog instance for two days, that's a bit too much. That may be my Norwegian take on it, but the engineering resources are expensive. It's better to just provision the infrastructure.

Overall, the product is great, and the features are just fine, but the infrastructure cost is what is killing it. The infrastructure cost is the main issue. I like the rest. If the infrastructure costs could be lower, it would be fantastic. I'm not sure if they can improve the infrastructure cost with the way Elasticsearch is. If they keep using Elasticsearch, maybe there are some opportunities there, or they can support other backends with cheaper storage. They could have a different backend to replace Elasticsearch or do some tweaks to Elasticsearch to reduce the costs. There could be partial parsing of logs or parsing on demand so that when you write data through Graylog to Elasticsearch, it doesn't need to crunch in every detail requiring that much CPU.

I was a part of the team that was managing a Graylog instance for five years. We were both the maintainers and users of the platform. The last time I checked the Graylog interface was half a year ago. We switched to Loggly for day-to-day activities. Not all the teams in our company did that, but we did. 

It's stable if you do not overload it. If you go over the boundary that it can handle with the existing infrastructure, it becomes a nightmare. Otherwise, it just runs smoothly.

It's pretty scalable. We didn't hit any ceiling when scaling it up. You throw hardware at it, and it just performs fine. The only issue is the cost. It's not dependent on how big an instance you have. The problem is that it costs a fortune.

We have about 300 users, but it's not about the users. It's about the traffic we have. Our traffic is pretty big. We have thousands of messages going per second through the Graylog instance. It's not that we have many users making queries concurrently, but still, to have the data ready for querying, Graylog needs to crunch it, process it, and write it to Elasticsearch, and that's what consumes resources most of the time.

We didn't have any issues that we needed to fix in Graylog. It just worked for us. We do use other open-source products and commercial products, and the commercial product support is not always fantastic. For Graylog, we could solve all the issues by searching over the internet and on Stack Overflow. With other products, such as Metabase, which is an open-source business intelligence tool that we use, because half of our company is made of software developers, they can write a patch. We did that a couple of times, but with Graylog specifically, we haven't had a need to introduce any patches. It was just tweaking the config.

We switched to Loggly because of the infrastructure costs of Graylog. Loggly is an all in the cloud commercial offering. Even though Graylog is free and doesn't require any maintenance and we just pay for the infrastructure, surprisingly, Loggly costs less than Graylog. So, we save money with Loggly. That was a big surprise to me.

Graylog is very stable, but Loggly is less stable. Maybe they're trying to cut costs. We have had a couple of outages, and quite often, we had indexing delays. When the data is not available right away, we have to wait for that. With Graylog, with our over-provisioning, we never had these issues, but we use Loggly because it's more efficient money-wise for our volume.

One drawback of Loggly is that they have just a few sites where they can store data. Previously, the site was only in the United States. We couldn't choose anything else. For us, it wasn't a problem because there was some agreement between the European Union or European Economic Area and the United States on data processing, but then this agreement got canceled. So, Loggly introduced one European site. They do have something over here, but we still lack support on the locality of the data because our customers are in Asia, and we want services to be placed closer to them. We want more sites. If Loggly, for example, could be deployed on any AWS instance, such as on Amazon Cloud or Google Cloud, which do have data centers in, for example, Thailand or the Asia Pacific, that would be beneficial. Loggly still doesn't have that. They are developing something, but that's an advantage of Graylog. It can be placed anywhere you have the infrastructure.

There is one particular mode with which we could not agree with Loggly, but there is some progress there. We have high traffic, but we don't want to store the data for long. Loggly suggests 90 days by default. We don't need 90 days because we need to troubleshoot situations that happened today and yesterday. We only need a couple of weeks of data, but we need to process a lot of traffic. Loggly wasn't ready for this type of load. I do understand why Loggly does that. It's not the storage that is most expensive; it's the CPU resources that you need to put into the indexing process when you ingest logs into the system. So, Graylog is more flexible because you still can tweak it to your particular load. You can say that you need just two weeks of high-traffic data, but you would need the infrastructure built specifically for this use case. With Loggly, we spent a year negotiating this mode. We came close, but it's still not ideal.

The other competitors, which we haven't had in production, such as Humio, are promising lower prices. It seems like the next generation of log processing. Graylog is based on Elasticsearch, and it seems that Loggly is also based on Elasticsearch or at least some mutated version of it. Humio seems to be based on something else. They don't have Elasticsearch. So, they don't have this burden of maintenance.

We have top-level engineers, and we didn't have any problems at all, but any random guy could also set it up. It involved the magic of regular Linux commands. It was pretty easy. I would rate it a five out of five in terms of the ease of the setup. It's great.

It's open source and free. They have a paid version, but we never looked into that because we never needed the features of the paid version.

If you have a small amount of traffic or you are a small company, Graylog is just fantastic because it's open source, and it's free. You can run a Graylog instance on pretty modest hardware, but when it comes to large volumes, as we have, it becomes too expensive. 

I'm pretty happy with the features of the product, but I'm not happy with the infrastructure costs. Feature-wise or from the end user perspective, Graylog is just great.

For small enterprises, it's a good start because they tend to use cheaper products, at least until they grow. Graylog is a good fit there because you can pick a very cheap cloud provider and then just install it there. It is pretty cheap. For big companies that are focused on reliability and availability, Graylog either requires over-provisioning or will cost a lot, which is not ideal. There are better solutions out there in the market, but one important point is that Graylog can be placed in your local data center. Some companies are very suspicious of clouds or have some restrictions from authorities or as per their policies and business model. There are countries, for example, Pakistan, where the network is poor, and if you use the closest data center of any cloud provider, that will most likely be Thailand. For these types of setups, Graylog is pretty much the only choice.

Before Humio, I would have rated it a 10 out of 10. It's a great product, but because of its cost, I would rate it a 9 out of 10.

We are using the solution to store all the logs from different sources. Also, we use it to monitor the logs for system errors.

The solution's most valuable feature is its new interface. It enhances our cluster's performance as well.

They depleted the legacy alarm callback feature from the current version. They should make it available in the newest version as well. Also, they should include SSO integration in Graylog 5.0's community version, similar to its enterprise version. It would also be beneficial if they added a feature that scales the solution automatically when the load increases.

We have been using the solution for five to six years.

The solution's current version that I am using is stable.

We have 50-60 users of the solution. Its scalability gets complicated when we have to update or edit multiple nodes. It is a very tedious task to add new nodes to the cluster. I rate its scalability a six.

We use Graylog's community support forum. It helps us solve our queries.

The solution's initial setup is easy. The deployment process for the new version takes 10-15 days.

Our in-house technical staff has seven years of experience working with Graylog. With their guidance, we configure and maintain the solution.

The solution's community version works well for a lesser workload. It will help if you opt for the solution's enterprise version if you plan to increase the load.

I recommend the solution to others and rate it as a seven.

I have my own recipe for an infrastructure code where I integrate Fluent Bit with Kubernetes. It scrapes the logs off of all the member nodes of Kubernetes and then it chips that to an input on Graylog. That way, when developers want to troubleshoot an application but don't want to use anything Kubernetes CLI-related, they can jump straight to Graylog. They can type the name and the type of deployment that they're looking for and get all of the logs pulled into one place. Essentially I use this solution to give developers a way to look at all the logs in an aggregated form. It's very helpful.

I also use the solution to extract and quantify data and metrics from the logs. For example, let's say you're running the wallet application and you want to make sure that you are getting the minimum 404's when somebody is trying to make a payment. You can essentially extract the code on Graylog and it will give you a really nice view of how often your wallet times out, or overall performance. If you're looking specifically from a security standpoint, if the application is seeing something that should not be seen, you have a way to log that.

I also use it for building charts and live logging. Also, the pipelines allow you to take a raw log, create something out of it, and transform it into something else, so I use that for streams, presentations, metrics, and health checks from an app runtime standpoint.

Everything stands out as valuable, including the fact that I can quantify and qualify the logs, create pipelines and process the logs in any way I like, and create charts or data maps. One time, I created a geo map based on IP addresses accessing a website. The web server generates logs based on who's accessing the application, and we were able to extract the IPs from the logs and even create a chart on Graylog to map out exactly what countries the requests were coming from. Graylog is amazing. It's a beast.

Graylog needs to improve their authentication. Their AD integration is really bad. When it comes to ACL's, access control lists, where you want to have different group memberships and control who gets access to what, it really could use major improvements. It seems like a beta authentication version that they came up with in a hurry and said, "Hey guys, we've got something going for you. Use it until we think of something later on." I believe their enterprise version has improved some of these features, but I use the open source version.

The second thing would be the way they handle live logging. The fact that Graylog displays logs from the top down is just ridiculous. I've never seen anything that logs this way except for Graylog. I believe this is an issue because they have the selector going in that direction, so it would make sense that they have to implement it that way, but it's definitely not cool. When you're looking at Graylog's live logging, whether it's doing a one-second or five-second pull, you'll notice that new log lines are placed at the top of the screen, not the bottom of the screen. I find this ridiculous because normally when you're looking at logs anywhere, on Linux, even in Windows, you're going to see that the logs are generated at the bottom. That's one thing that Graylog definitely needs to improve. 

Graylog also needs to invest some time to improve the performance and how they handle the maintenance of Elasticsearch.

An added feature I would like to see is the capacity to delegate most of the backend maintenance to the frontend UI. When you have somebody from the service desk working on the solution or somebody who's not a technical person, they could run some of the maintenance stuff directly from the UI.

Another thing is something that I saw in LogDNA, where you could have a color based on log regex. For example, it would color the timestamps next to the log lines orange, make the source of the log purple, and then make the actual log content black. That would be very nice to see in Graylog.

I have been using this solution for about four to five years.

I would give this solution a six out of ten for stability. It has quite a few hiccups. I usually try to avoid them the best I can, but sometimes they just happen and you have to deal with it.

Graylog can scale, but technically, Graylog's scalability mainly depends on Elasticsearch because it uses Elasticsearch as the backend. I would say the question should probably be about how well Elasticsearch can scale. The answer to that would be that it is pretty scalable, but it's not simple. It's not like Kubernetes, where you just add a few extra replicas and you get performance right of the box. It's a bit complex to scale it, but it is scalable.

I would rate the technical support as a four out of five. From an experience standpoint, they're pretty good.

Positive

It really depends. If you're going to slap Graylog into a very small environment and do a standalone instance, it's super easy and straightforward. You have to install Mongo, Elasticsearch, and Graylog and connect them to each other, which is super simple. There are tons of easy tutorials online available to help you do that. 

However, if you want to set up a highly scalable cluster, things will get a little bit complex. It's still very manageable, but it's definitely complex.

It took me about 30 minutes to deploy Graylog. 

There is an open source version and an enterprise version. The authentication is bad in the open source version, but I believe they have improved that in the enterprise version. 

I wouldn't recommend the enterprise version, but as an open source solution, it is solid and works really well.

My advice to people considering this solution is to first determine where they can use it. The server sizing depends on the amount of logs generated and where you get the logs from. For example, it it a Kubernetes cluster with a lot of things on it, or just a bunch of VMs, or just a couple of VMs? What's the size of that? Based off of this, you would then decide the server sizing and how big your Elasticsearch needs to be and how scalable it needs to be. Graylog is like ELK Stack. It's very, very resource hungry.

I would rate this solution as a seven out of ten. 

We have one SIEM tool to integrate the log source for other containers and user-related logs. Those logs were integrated into Graylog. When required those logs Graylog gets sent to a SIEM tool. 

The best feature of Graylog is the Elasticsearch integration. We can integrate and we can run filters, such as an event of interest, and those logs we can send to any SIEM tool or as an analytic. Additionally, there are clear and well-documented implementation instructions on their website to follow if needed.

Graylog could improve the process of creating rules. We have to create them manually by doing parses and applying them. Other SIEM solutions have basic rules and you can create and get more events of interest.

I have been using Graylog for approximately three years.

Graylog is a stable solution. However, while using some microservices it may go down.

Graylog

We have approximately 40 to 45 people using the solution in my company. There are three different teams using it, such as developers and testing teams. The teams use the solution on a daily basis.

We are working in India, and sometimes it takes a while to receive a response from the support. However, the solutions they provide are can do them. Their support is good.

I rate the support from Graylog a four out of five.

Positive

I have previously used Logstash. The main difference between Graylog and Logstash is in Logstash it takes a longer time for searching logs.

We had some struggles with the initial setup of Graylog. However, after using the support it works fine.

I rate the initial setup of Graylog a four out of five.

We use the support from the Graylog team for the implementation of the solution.

Graylog is a free open-source solution. The free version has a capacity limitation of 2 GB daily, if you want to go above this you have to purchase a license.

I rate Graylog a seven out of ten.

I used this solution for bug tracking, checking to see if an application was running correctly or not.

I was working at a big comparison platform in Germany and was part of a  financial services department where we built multibanking applications. I know that in other departments they used different logging tools like TeamCity, so this was not something that was used companywide. There were probably about 50 developers using it, from app developers to Java/Python backend developers and the data science team. The extent of log messages and verbosity was varying from team to team.

One of the most valuable features is that you are able to do a very detailed search through the log messages in the overview. You are also able to attach a lot of details into your log messages. 

When it came to integrating the solution with Java, it was quite easy. My colleagues used Graylog for some dashboards to show how many bugs there were per day or the overall performance of the applications. For the developers it's not super important, but it was quite a good way for the project manager to see that everything was all right.

With Python, there was a problem where it was harder to attach extra information using the basic logging package. We had to build our own custom adapter for this to append that information to the log message. For Python developers, it would be great if Graylog could provide a better Python package in order to make it easier to use for the Python community.

I used this solution for about two years. 

This solution is definitely stable. 

This solution was definitely scalable to our needs. 

I would say the initial setup is quite straightforward, but it's pretty straightforward for any kind of logging tool out there. The difference is in how you integrate it into the project, but I don't think there's much of a difference between all of the tools, at least from my perspective. 

I used Graylog until a few months ago, and I'm currently using Sentry. With Sentry it is quite easy to filter, for example, errors for a specific project just by clicking a drop down. On Graylog, we had to perform active filtering through the search bar. The filtering process was a bit different. I wouldn't say they differ too much, but Sentry also allows me to do some bug tracking and mark them like, "Okay, now I have to review this," or "This has been resolved", which is not something I would ask for in a log tool, but it's available.

I would say that it's definitely worth looking into the extensive search and filtering functionality of Graylog in order to make the most out of it. I would also suggest having a look into the dashboard view functionalities for doing some kind of quick performance overview on the application set. I think the coolest feature of Graylog if you're a developer is that you are able to really narrow down or to specify the search.

For TeamCity, for example, there is specific query language and you can build dashboards and queries there as well, but this feature was kind of limited when I was using it. Even though it was available, I didn't like the feature overly much. I know that there are other similar tools available, but I enjoy using Graylog the most.

I would rate this solution as an eight out of ten because the integration with Python isn't perfect, but if that's fixed in the future, I would say it would be a nine or ten.