Yes, the goal is that it should be usable in production as well. The limitation it will probably have compared to ELK/Splunk is that since there's only a single recipient node and it uses SQLite for storage, the upper limit to how quickly it can ingest logs will probably be lower compared to ELK/Splunk. So Logsuck may not ever be suitable for large deployments that are logging huge amounts for sustained periods of time.
I haven't really tested what the limits are yet so unfortunately I can't put a concrete number on it, but my vision is that Logsuck should at the very least work for a small-medium sized company with "normal" logging needs.
The current state is that it's got quite a few bugs and is lacking many features you would expect from an ELK/Splunk alternative but the basic concept is working. If what you need is a GUI for grepping across logs spread out on multiple servers it can be used for that today, but it's not doing much beyond that yet.
I haven't really tested what the limits are yet so unfortunately I can't put a concrete number on it, but my vision is that Logsuck should at the very least work for a small-medium sized company with "normal" logging needs.
The current state is that it's got quite a few bugs and is lacking many features you would expect from an ELK/Splunk alternative but the basic concept is working. If what you need is a GUI for grepping across logs spread out on multiple servers it can be used for that today, but it's not doing much beyond that yet.