rsyslog server

My main use case for rsyslog server is syslogging. A quick, specific example of how I use it for logging is collecting any syslog from a Unix server, including syslogs from firewalls and routers.

The best feature rsyslog server offers is syslog recording. What I appreciate about the syslog recording feature is that it serves as the main and most important feature, recording syslogs and receiving syslogs from TCP or UDP, other UDP servers, and forwarding those logs to even other servers, allowing for daily syslog handling in any direction, TCP, UDP, local, or remote.

rsyslog server has had the usual impact on my organization; it does not matter to me if it is rsyslog server or another syslog server; it is just my preference, and I do not have specific reasons why it became this preference. There has been just personal preference in noticeable differences in reliability, performance, or troubleshooting since I have used rsyslog server compared to others.

rsyslog server can be improved; I wish it did something different or better, specifically regarding BRP.

I have been using rsyslog server for more than five years.

rsyslog server is stable; it is more than stable enough for me.

rsyslog server's scalability is good; it handles growing workloads well for me.

I have never reached out to customer support.

I previously used the old syslog from Debian GNU/Linux before choosing rsyslog server.

I did not purchase rsyslog server through the AWS Marketplace. My experience with pricing, setup cost, and licensing is that I have never licensed rsyslog server, as it is open source, so the question does not make sense.

I have not seen a return on investment; it is just about functionality for me.

I did not evaluate other options before choosing rsyslog server. It was the next choice at hand.

That is all for me regarding features, flexibility, or ease of use. I rate rsyslog server an eight on a scale of one to ten because I am mostly happy, but sometimes it does not work immediately, and I have to work with the logs to figure out what is happening. Regarding rsyslog server's AI capabilities, I think about its governance and security. I do not care for AI in rsyslog server ensuring its accuracy and reliability of output. I have no specific advice for others looking into using rsyslog server other than to follow the usual Google setup and be happy.

Our primary use case for rsyslog server is centralized log collection, long-term retention, and security monitoring. We also use it as an intermediate logging layer before forwarding logs to our CrowdStrike Falcon cloud platform for XDR and MDR analysis.

We built an automated pipeline where firewall devices send logs to rsyslog server, which then processes, stores, and forwards the logs to CrowdStrike Falcon. This helps us detect abnormal firewall activity, suspicious traffic, and security-related events in near real time.

The solution is also valuable for historical investigations because it allows us to retain logs locally for root cause analysis and back-dated event reviews.

rsyslog server has significantly improved our firewall visibility, centralized monitoring, and overall security operations. Before implementing centralized logging, visibility into inbound and outbound firewall activity was limited.

After integrating rsyslog into our environment, we gained better insight into traffic behavior, firewall policy usage, and potential security issues. This helped us improve firewall rules, reduce unnecessary open ports, strengthen outbound connectivity controls, and accelerate troubleshooting and forensic investigations.

The best features of rsyslog server are its support for both UDP and TCP log ingestion, flexible log routing, self-hosting capability, log rotation management, and reliable buffering and forwarding features.

These capabilities are essential in our environment because our firewalls generate a large volume of logs every day. Proper log rotation prevents files from becoming too large and difficult to analyze during investigations.

Another major advantage is the ability to offload buffering, retries, forwarding, and parsing from the firewall itself. This reduces firewall workload while ensuring logs are securely stored and available for future analysis.

One area that could be improved is native support for Docker and Kubernetes container logging. While integration is possible, forwarding container logs into XDR or MDR platforms often requires additional customization.

Simplified cloud-native integrations and easier container log management would make the solution more efficient for modern environments.

I have been using rsyslog server for approximately two and a half years for centralized log collection, retention, and security analysis.

Yes, rsyslog server has been very stable in our environment. It handles large log volumes reliably without major operational issues. Restarting services, rotating logs, and maintaining long-term retention have all been straightforward and dependable.

The scalability of rsyslog server has been excellent in our environment. It handles multiple gigabytes of firewall and infrastructure log data efficiently without performance issues, even as our logging requirements continue to grow.

I have not needed to reach out for customer support concerning rsyslog server

I did not use another centralized logging solution before rsyslog server. We implemented it based on organizational requirements, and it has proven to be reliable and highly effective for our environment.

The initial setup was straightforward in our environment. We configured the firewall devices to forward web filtering, DNS filtering, and application filtering logs to the rsyslog server using the server’s IP address for centralized log ingestion.

On the rsyslog side, we created separate log collection files and routing rules so that firewall logs are stored independently for easier analysis and troubleshooting. We also implemented automated daily log rotation and compression of older log files for long-term retention and future forensic investigations.

No, we handled the deployment and implementation internally without using an external integrator or consultant. The setup and configuration process was manageable with in-house Linux and firewall administration knowledge.

The initial setup was straightforward. We configured the firewall devices to forward web filtering, DNS filtering, and application filtering logs to the rsyslog server.

On the rsyslog side, we created separate log collection files and automated daily log rotation with compression of older logs for future investigations and retention management.

Our experience with pricing and setup has been very positive because rsyslog is open-source and highly flexible. The deployment and maintenance costs were minimal compared to commercial logging platforms.

Before choosing rsyslog server, we evaluated Datadog. However, we preferred rsyslog because it provided a cost-effective and flexible self-hosted solution for centralized log collection and investigation without depending heavily on third-party licensing costs.

I would rate rsyslog server 10 out of 10 for centralized logging, log forwarding, and long-term forensic analysis.

For organizations considering rsyslog server, I highly recommend it because it is stable, scalable, lightweight, and highly effective for firewall and infrastructure log management.

The main purpose of rsyslog server is collecting logs from network devices and storing them on a server for monitoring.

The best feature of rsyslog server is easy configuration, which includes straightforward setup and quick monitoring of the logs.

The easy configuration and quick monitoring of rsyslog server help me in my day-to-day work as it saves my time and makes my troubleshooting easier. Once I configure the details in rsyslog.conf and restart rsyslog server, I can quickly access the information, which is very useful for troubleshooting purposes.

Based on my understanding, there are no pain points or negative aspects regarding rsyslog server; all aspects are positive.

I have been using rsyslog server for more than six years.

rsyslog server is stable.

The scalability of rsyslog server is good, as I can perform housekeeping and delete old log files that are generated and stored.

I have not faced any issues with customer support and have not raised any support requests.

I have not used any different solution for monitoring these network device logs; I am using only rsyslog server.

I manually configured the rsyslog.conf on a server, and there is no licensing for rsyslog server. Splunk, in contrast, uses licensing based on daily data ingestion volume, which relates to the indexing count of the logs in Splunk.

I have not evaluated any other options, as rsyslog server is the only solution I use for monitoring logs from network devices.

My advice for others looking into using rsyslog server is that it is easy to use and configure. Once the network device parameters are configured in rsyslog.conf, I can easily monitor the log files, which are useful for troubleshooting purposes. I would rate this product a 9 out of 10.

My main use case for rsyslog server is resending logs to my log server from other servers, and I am redirecting logs from regular servers to one log server.

For resending logs using rsyslog server, I configure one server and enable it on the Ubuntu machine to which I redirect all servers' logs. I enable UDP and TCP for the logs in a firewall, and then on end machines such as servers, I go to rsyslog and enable it. After that, I configure the IPs from the client machine, meaning the server machine, to rsyslog server.

I use rsyslog server exclusively for this purpose.

In my opinion, the best features rsyslog server offers include the ability to send enormous logs from client OS to server devices, which I can fix with scripts. I can easily identify the host machine and what kind of logs it contains, whether it is an application log or operation log, and it sorts them based on how I write the script, allowing it to redirect and resend the logs.

These features make my day-to-day work easier and more efficient because whenever I find any failure or boot problems in a client machine, I can easily identify the issue. I can go to the log machine and check what kind of problem it is, whether it is a web server crash or a main server crash, and based on the logs and messages, I can easily identify and troubleshoot the issues. Furthermore, I can monitor and audit the logs as well, including SSH logins, and track who last logged in and who is currently logged in on the machines, as well as easily track any failed login attempts in case of suspicious activities.

rsyslog server has positively impacted my organization by providing centralized logging for our machines. I implemented it for the servers, database, application servers, and some network devices as well. I get day-to-day logs, which I can monitor easily and audit those devices, impacting our day-to-day productivity.

Currently, I use rsyslog server, but I think some features could be improved by going through other SIEM tools or IBM tools. I am using Splunk for this purpose; I have installed a Splunk agent in the client application, which allows me to redirect the same functionality I need in my daily operations.

I have been using rsyslog server for more than a year.

rsyslog server is stable in my experience.

Regarding scalability, rsyslog server can handle increased loads or more devices easily.

Customer support for rsyslog server has not been needed since I maintain everything myself. If anything happens, I am responsible for finding and fixing the issues; therefore, there is no need to reach out for customer service.

I did not previously use a different solution before rsyslog server; I have always been using rsyslog.

I have seen zero return on investment with rsyslog server as it is an open-source tool. I just download it and do scripting for the kind of logs I want, and it is very easy to configure without any associated costs.

I am not getting any pricing, setup cost, or licensing related to rsyslog server; I am just using it as is.

Before choosing rsyslog server, I evaluated options such as Splunk and some SIEM tools such as Graylog or IBM QRadar, but those were licensed. I cannot use them without going through enterprise purchases, which are financially prohibitive.

I can share specific outcomes regarding rsyslog server, as it has saved me time and improved my ability to respond to issues. Recently, I encountered a problem where my SSH server was down automatically, which caused some users to be unable to log in. From that log, I checked and found critical bugs in SSH, allowing me to troubleshoot the issue within a short amount of time.

My advice for others looking into using rsyslog server is that if someone wants to set up a local environment with a budget-friendly approach, they should choose rsyslog server. If they have ten to fifteen machines in their cloud or private cloud, they can use rsyslog server without issues, making it easier to improve their daily productivity. I would rate this product nine out of ten.