Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
But that doesn't mean it is necessarily easy to do.
Part of the problem is that messages can come in FAST... and the data has to be read and stored at least as fast as it comes in. This introduces a problem with the database - which doesn't do well with bursts of high traffic input.
I would suggest first start trying process records from rsyslog written to disk, then add them to the database. This allows you to use the disk file as LARGE cache of input that will catch the data. If you use a method similar to "tail -f", you will be able to read and process the data as fast as you can (and even catch up to rsyslog production) without loosing the data.
When this works, you can even add the ability to periodically direct rsyslog to start a new file, the data base process can then finish the current one, start processing the new one. And the old file could be either archived (at first), and then deleted, thus making the used disk space available for for messages.
If you can ALWAYS keep up with the data (even to the point of implementing your own caching file if necessary) you can modify the rsyslog configuration to pass the data to your process instead of writing it to disk...
Your suggestion is very helpful for me . But it will more helpful if you give any document or any suggested link so that I can follow your guideline for implementing the rsyslog server .
Your suggestion is very helpful for me . But it will more helpful if you give any document or any suggested link so that I can follow your guideline for implementing the rsyslog server .
Your suggestion is very helpful for me . But it will more helpful if you give any document or any suggested link so that I can follow your guideline for implementing the rsyslog server .
You have been here ELEVEN YEARS now....you should know the LQ Rules about not using text-speak. You should also be aware of the "Question Guidelines"...asking people to look things up for you, and send you links is fairly rude. You need to show SOME effort of your own.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.