OpenObserve is very easy to install. I was able to get started with it in a short time by following the guides. And it is very light on compute resources which is one of the key strengths of it. The documentation was also easy to understand and covered what I wanted to know. And when I couldn't find something there, I asked questions in the Slack channel. The OpenObserve team was very responsive and they solved my problems

I self-host OpenObserve to collect logs and traces from my projects, and the biggest win for me was how easy it was to get running. It ships as a single binary, and I had it ingesting data within minutes—without having to stand up Elasticsearch or maintain separate Prometheus and Jaeger stacks. It also accepts OpenTelemetry natively, so I simply pointed my existing OTel exporter at it and the data appeared right away. Having logs, metrics, and traces in one UI saves me a lot of time when debugging, because I can jump from an error log to the related trace in just a couple of clicks. Queries are plain SQL as well, so there’s no new query language to learn. Storage efficiency is another plus: the data is kept as compressed Parquet, which really matters when you’re paying for your own infrastructure.

A single OpenObserve pod served as a drop-in replacement for our full ELK stack, making the management of our logging infrastructure significantly easier and cheaper.<br><br>It worked with our existing Fluent Bit forwarders with only minimal changes. The UI was clean and intuitive enough that end users had no trouble switching over from Kibana. Being able to store data in S3 not only saved us money, but also improved maintenance and performance.