syslog-ng VS qryn

Syslog-ng can feed splunk directly via HEC without having to use heavy forwarders. Earlier you had to hand configure it via the http () destination, v4.2 added this via a separate destination driver. https://github.com/syslog-ng/syslog-ng/releases/tag/syslog-ng-4.2.0

ports: syslog-ng 4.1.1[6]

Syslog-ng seems a bit weird about open/close source. They have a github but it seems like all the documentation is seemingly all over the place & it's not obvious to find what the limitations of open source version are.

What we do internally is use [syslog-ng](https://github.com/syslog-ng/syslog-ng) to read the journald socket and push to a remote and into Kafka. I think journald works well as a structured logging tool, but it's certainly deficient in other ways

We're using syslog-ng in my apprenticeship, it works just fine, interfacing with a in-prem Prometheus/Elasticsearch

[12] https://github.com/syslog-ng/syslog-ng/releases/tag/syslog-ng-3.31.1

Thanks for mentioning qryn! We are a non-corporate alternative and feature full ingestion compatibility with DataDog (including Cloudflare emitters, etc), Loki, Prometheus, Tempo, Elastic & others for both on-prem (https://qryn.dev) and Cloud (https://qryn.cloud) deployments, without the killer price tag.

Note: in qryn s3/r2 are as close to /dev/null as it gets!

qryn and vector get along very well! We use it all the time for testing and developing qryn and qryn.cloud and most of our users love it! But we're just as compatible with Loki/LogQL, Influx protocol for metrics and logs, Elastic Bulk, Prometheus for metrics, opentelemetry for everything... and more coming!

Feel free to open an issue on our repository if you end up trying it and/or would like us to help out!

https://qryn.dev

> *it would be nice to use ClickHouse as a Prometheus backend*

Well... that's already possible and it works great! As you might know https://qryn.dev turns ClickHouse into a powerful Prometheus *remote_write* backend and the GO/cloud version supports full PromQL queries off ClickHouse transparently (the JS/Node version transpiles to LogQL instead) and from a performance point of view its well on par with Prometheus, Mimir and Victoriametrics in our internal benchmarks (including Clickhouse as part of the resource set) with millions of inserts/s and broad client compatibility. Same for Logs (LogQL) and Traces (Tempo)

Disclaimer: I work on qryn

Thanks for mentioning our project! qryn (formerly cloki) is currently more focused on the polyglot factor and trying to unify logs, metrics and telemetry on a single stateless platform, easy to scale without hundreds of services and moving parts. At this stage, its a lightweight Grafana Cloud alternative just requiring clickhouse - no sidecar databases, redis, or plugins needed, and no new query languages or rules to learn. Latest info is at https://qryn.dev

cloki can be used to read metrics out of any CH table so it should work fine.

we also just introduced experimental support for ingesting OTLP/ZIPKIN spans and a tempo-compatible API in cloki, looking for testers to validate this feature:

https://github.com/lmangani/cLoki/wiki/Tempo-Tracing#clickho...

Internally trace spans are stored as tagged JSON logs, meaning they are available from both Loki and Tempo APIs and can be used from pretty much any visualization, too!

There's also cLoki. It's a new project that puts a Loki gateway over a ClickHouse backend store. We're looking at it and plan a presentation from the author(s) at the next ClickHouse SF Bay Area Meetup.

https://github.com/lmangani/cLoki