Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

VictoriaMetrics core developer here.

OpenObserve looks very promising from the first sight! It prioritizes the same properties as VictoriaMetrics products:

- Easy setup and operation

- Low resource usage (CPU, RAM, storage)

- Fast performance

It would be interesting to compare the operation complexity, the performance and resource usage of OpenObserve for metrics vs VictoriaMetrics.

P.S. VictoriaMetrics is going to present its own log storage and log analytics solution - VictoriaLogs - at the upcoming Monitorama conference in Portland [1]. It will provide much smoother experience for ELK and Grafana Loki users, while requiring lower amounts of RAM, disk space and CPU [2].

[1] https://monitorama.com/2023/pdx.html

[2] https://youtu.be/Gu96Fj2l7ls



The folks at VictoriaMetrics have a track record of producing well-documented and easy-to-use software, and they're responsive.

It's easy to overlook these aspects but they will make all the difference to your team implementing the solution, so if you don't want to gamble, their products are a solid choice.

PS: I have no personal relation or connection with them. I am a user of VictoriaMetrics. Just want to point out things that matter but get ignored when choosing your software stack.


I'm looking forward to learning more about VictoriaLogs! You guys always come up with elegant solutions and I'm sure this will be no exception.


Sounds interesting!

Will you compare with qryn? Self-hosted sentry?

https://qryn.metrico.in/

https://develop.sentry.dev/self-hosted/


VictoriaLogs will be easier to setup and operate than qryn and self-hosted Sentry. Single-node VictoriaLogs is a single small self-contained statically linked binary with zero external dependencies. It runs with optimal settings out of the box on any hardware - from Raspberry PI to high-end servers with hundreds CPU cores and terabytes of RAM.

Additionally, VictoriaLogs will provide more user-friendly query language - LogsQL, which is easier to use than SQL at ClickHouse or the query language provided by Grafana Loki.


That's inaccurare: qryn does not require SQL at all . It offers LogQL, PromQL, Tempo and other customizable APIs natively by design without requiring the user to know/learn anything.

About the easier aspect that's true - qryn is designed to be an "overlay" on top of various backends such as ClickHouse and IOx (pros and cons for each up to the user) and to provide full granular data control to the underlying set (compliance, gdpr, etc) rather than an all-in-one solution with its own proprietary formats.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: