syslog-ng Reviews

In Italy, we have to be compliant with the Garante for privacy. We have to log every login, logout, or login failure made by a system administrator.

We store all syslog data of the infrastructure. All our data centers can send logs over TLS or in plain text, and our syslog server can receive all these servers. We can concentrate all logs on a single machine. If we have to search for an intrusion or if an auditor asks us for a log of an administrator that logged into a machine, we can provide all the information they need.

Our current goal is to be compliant. We chose syslog-ng because it is easy to install, easy to maintain, easy to update, and due to the fact that all data arrive in raw format, we can manipulate it as we want. First and foremost, it was important for us to be compliant with Italian law.

In syslog-ng, we can trace all connections, and most importantly, it supports TLS for ciphering the connection.

I have talked with many organizations, and when they ask me how to use it to be compliant with Italian law, I always recommend syslog-ng.

We currently do not use that feature.

We currently have just an open-source release, not a premium release. My boss has indicated that he wants to buy a premium syslog-ng version next month. I think we can use other features of this tool in the future.

In syslog-ng, I think a GUI would be beneficial. I am unsure if the premium module has a GUI to administer it.

I have been working with syslog-ng for some time.

I knew syslog-ng and we chose to use that.

It is extremely stable.

It is easy to scale and there are no problems with scalability.

We have not used customer service.

Negative

We used rsyslog, which is a default Linux service.

The setup is very easy.

We have three data centers in Italy, and in these three data centers, we have three machines that have syslog-ng installed.

When it comes to parsing, I can parse both structured and unstructured data, though our data are only structured.

Currently, we collect all data we receive as raw data. Each file is stored for each server that sends data.

I rate syslog-ng 10 out of 10.

I use syslog-ng for log processing.

What I appreciate most about syslog-ng is its configuration; its C-style config is much easier to understand, read, and write than other popular solutions such as syslog or rsyslog. It has numerous features and is very performant. This is why I chose syslog-ng, and this is why I am using it.

Syslog-ng is easy to use. By looking at some examples, users can understand right away what it is for. The config is straightforward; it has sources, destinations, and filters between them, and it's self-explanatory. If additional features are needed, the documentation is clear and accessible.

Syslog-ng is highly performant, and I needed to process enormous quantities of logs. I implemented a three-server setup. One server was a storage network with extensive storage running syslog-ng to store the logs, and two servers functioned as syslog proxies. They gathered logs and served as entry points for logs from all hosts in different formats. They would then normalize logs to one format and send them to the storage server. Though not a straightforward setup, with syslog-ng it was quite easy to configure.

Something could potentially be improved, though it works effectively for me. In the early stages, over 10 years ago, syslog-ng was lacking some features, so I created a patch for it. I used a patched version rather than the vanilla version. I attempted to submit a patch to the mainstream, but syslog-ng had a different implementation approach, so it wasn't accepted. A few years later, they implemented what I needed in a slightly different way, but now it satisfies my needs, and I no longer require a patched version.

I have been using syslog-ng for over 10 years.

I never experienced any problems with the stability of syslog-ng. There were no crashes or issues; it is extremely stable.

I never needed to contact the support team. The software functions properly, and I never encountered any trouble with it.

Positive

The initial setup of syslog-ng is straightforward. On any Linux distribution, I simply install syslog-ng from the repository, and that completes the process. It works immediately with a default config that can handle the default use case for logging system logs locally. This provides a solid starting point.

I did use syslog and rsyslog previously, but for this complex setup, we conducted research and chose syslog-ng, which worked perfectly. I never considered alternatives afterward. When cloud computing emerged, I compared syslog-ng to Logstash and Fluentd. Logstash is from Elastic, and Fluentd is used in Google Cloud. Syslog-ng demonstrates much better performance than both alternatives.

I am a user of syslog-ng.

Syslog-ng is open source. I am unsure if they're selling any service currently, but we don't use any service.

I would absolutely recommend syslog-ng to others.

On a scale of 1-10, I rate syslog-ng a 10.

We use it for compliance issues, like law enforcement for the Brazilian government.

For us, the most valuable feature is the use of compound search for searching logs at a specific time, by a specific user, or specific behavior.

There is room for improvement in terms of observability. 

Additionally, a possible new feature could be Kafka integration.

We have experience with this solution. We've been using it here for two or three years.

I would rate the stability a nine out of ten. It has been stable for us.

I would rate the scalability a nine out of ten.

The initial setup is easy. I would rate my experience with the initial setup a nine out of ten, with one being difficult and ten being easy to set up.

The documentation is good.

We use a platform called TN, which is a third-party service that provides syslog-ng for us. It's just for adapting something. The solution is easy to maintain. We have one person for maintenance of the solution.

The pricing is in the middle. I would rate the pricing a six out of ten, with one being expensive and ten being cheap.

It's a good product overall, with no major issues. Overall, I would rate the solution a ten out of ten. 

The primary purpose of the solution is to aggregate and filter logs, which will then be ingested into Splunk.

I normally use custom ports so that I can segregate logs on the Syslog level and avoid polluting Splunk. This allows me to classify and segregate logs without having to use default port 514. Syslog-ng is very helpful for creating configurations for custom ports and adding filters to ignore or drop certain events. It is also useful for log rotations. Syslog is very consistent in delivering data.

Syslog-ng has a separate config file in addition to the core configuration.

The filtering has room for improvement. Some standard filters don't fit the use cases with the solution. I would like to have additional filtering methods so I can use two different filters to log methods with the same configuration file.

Using syslog is all for logging, and if the logging can be fine-tuned or improved, or any improvements can be made to the logging level, I think that is the way we should consider exploring new options.

I have been using the solution for five years.

The solution is stable. We haven't seen any problems with syslog unless there is a buffer workflow. This is likely due to a storage issue, but syslog-ng is functioning properly.

Syslog is mainly used for network logs, and it can be configured to support a number of ports for an IP. From a scalability perspective, a front-end load balancer or other third-party elements can be used to route traffic to syslog. However, syslog will always look for the standard log format. If the format is not up to the standard syslog level, the load balancer will add its own IP to the log and forward it to syslog. To ensure integrity, the log should remain the same, without any changes to the server A IP. If there is a change in the login server A, the load balancer will add its own IP or hostname to the log and forward it to syslog. To address this issue, further investigation is needed to enable the product to overcome this scenario.

We have 12 technicians supporting the platform.

If I am an application owner, I need to rely on the infrastructure network team to provide the prerequisite packages for syslog-ng. I suggest that syslog-ng installation is easy, or even the same as syslog. The best improvement that can be made is if someone downloads a syslog package with its dependent packages in one package. This would make it easier to install syslog in one step, rather than having to identify the dependent packages. For example, if I am running a syslog on Linux and I want to install a new syslog package on Linux, I need to look for a dependent package in Fedora or any RPM package versions. I may not know the exact applicable version for the syslog file, so I may need to search on YouTube or Google to identify the dependent packages. If the package for Red Hat Linux syslog includes all the dependent packages for that version, then it should be a one-time deployment or configuration.

I give the solution an eight out of ten.

Depending on the use case, if we need to collect logs locally, then syslog-ng is the right solution. Additionally, the solution is easy to learn. That is the advantage.

I felt that we needed a syslog connector at that moment, so we chose syslog-ng. We then conducted a high-level study to see if we could make syslog-ng work since our syslog uses templates as its framework and syslog-ng uses configuration files. This is how we made the decision to switch solutions.

We use syslog-ng to aggregate all our logs. We were looking for a SIEM solution, so syslog-ng is serving as a temporary replacement.

Syslog-ng has built-in features that we can use to create alerts for a SIEM solution. It isn't a true SIEM solution, but it's sufficient for the time being. 

Syslog-ng isn't a true SIEM solution, and you need some expertise to get it to work in a SIEM use case. 

We have used syslog-ng for at least three years.

We haven't had any outages.

Syslog-ng is scalable enough for our purposes. It can handle log collection from 400-plus hosts, but I think it could do better. 

We use syslog-ng as an open-source platform, so we don't have support. We're relying on our in-house personnel. The solution was pretty self-explanatory, and our people know how to use it. Besides, we've never had problems that would require calling support.

The learning curve was pretty easy, so we didn't need support to tell us how to use it. It was ready to use once we installed it. 

I rate syslog-ng nine out of 10 for ease of setup. It was a cookie-cutter installation. 

Syslog-ng is a free open-source solution.  

I rate syslog-ng 10 out of 10. It's free and easy to use. It has built-in tools that help us index the various logs sent to it. It's a solid log product. If you're looking for a SIEM solution, syslog-ng will work as a stopgap measure at beginning of the project. 

It can also work as an injector for a true SIEM solution. You can send all the logs to syslog-ng and forward all the data to the SIEM solution after you've cleaned up the data and got the pertinent information. It's a good front end for a commercial SIEM solution, which becomes more expensive as you load more data into it. 

I would highly recommend syslog-ng for that use case. However, if you lack the expertise, you might need to go with a cloud-based SIEM instead. You need some in-house expertise or an outside consultant to manage it and set it up. 

We implement solutions for our customers and we utilize syslog-ng to create automation batches and scripts without the need for a user interface.

The ability to extract and store the logs is the most valuable feature of syslog-ng.

There is always the potential for additional integration and protocol extensions.

I am currently using syslog-ng. 

We implement syslog-ng for our customers.

Syslog-ng is open-source.

I give syslog-ng an eight out of ten.

I use syslog-ng to perform enterprise security audits for compliance with data regulations like GDPR in Brazil. 

Syslog-ng provides easy access to all my logs. It helps me show managers and other clients precisely where an incident occurred. I also like it because you can integrate syslog-ng with multiple solutions to allow real-time monitoring. 

It's hard to find people who know how to use syslog-ng. I often find problems with configurations, and solutions aren't integrated correctly with syslog-ng. For example, there might be data with extra decimals, or the collector agents are incorrectly named. It isn't a problem with the solution; it's a lack of professionals.

I have used syslog-ng for about three years.

Syslog-ng is stable. I don't have problems with memory or processing. It can handle a large amount of data.

I rate syslog-ng support eight out of 10.

Positive

We're familiar with syslog-ng, but many people don't know how to manage or configure the solution. About three or four people are typically involved in using or maintaining syslog-ng.  

I rate syslog-ng 10 out of 10.