Both tools (Splunk UF running as a sidecar and Logmink) serve the purpose of forwarding logs for centralized analysis. While Logmink has a narrow focus of just HTTP logs, Splunk is log general and can serve the same purpose.
Splunk is considered more enterprise grade. Logmink focuses only on HTTP logs. But Splunk seems more appropriate here for enterprise environments.
I completely agree with your points. I developed Logmink because tools like Splunk are very costly, are only managed by security teams (not application teams), and can take days to retrieve a single log packet, especially in production environments (or sometimes not at all due to security restrictions).
As an application developer, I needed a straightforward way to check my app logs. We tried other tools like Dynatrace, but they were also expensive. We turned to open-source solutions like Logstash, Prometheus, Filebeat, and Grafana. While these tools are powerful, they require significant effort and expertise to set up. What we needed was a simpler HTTP-based solution for tracing requests across servers, which is why I developed Logmink.
It's interesting that you chose mongodb as a backend. It may be a niche that is overlooked.
Most log aggregation tools are overcomplicated, require A LOT of resources, plus they still rely on storing log term data on S3 assuming that "everyone loves that!". That's not always true.
There are a few tools that try to utilize ClickHouse for a more centralized log storage that works better for small deployments. I found them too limited, or too focused on their enterprise offering (like signoz, which is much more than logs, but lacks some basics that are only in paid versions).
This project my actually be some nice middleground.
Splunk is considered more enterprise grade. Logmink focuses only on HTTP logs. But Splunk seems more appropriate here for enterprise environments.