Show HN: OpenObserve – Elasticsearch/Datadog alternative (github.com)
We are launching OpenObserve. An open source Elasticsearch/Splunk/Datadog alternative written in rust and vue that is super easy to get started with and has 140x lower storage cost compared to elasticsearch. It offers logs, metrics, traces, dashboards, alerts, functions (run aws lambda like functions during ingestion and query to enrich, redact, transform, normalize and whatever else you want to do. Think redacting email IDs from logs, adding geolocation based on IP address, etc). You can do all of this from the UI, no messing up with configuration files.
OpenObserve can use local disk for storage in single node mode or s3/gcs/minio/azure blob or any s3 compatible store in HA mode.
We found that setting up observability often involved setting up 4 different tools (grafana for dashboarding, elasticsearch/loki/etc for logs, jaeger for tracing, thanos, cortex etc for metrics) and its not simple to do these things.
Here is a blog on why we built OpenObserve - https://openobserve.ai/blog/launching-openobserve.
We are in early days and would love to get feedback and suggestions.
99 comments
[ 5.3 ms ] story [ 174 ms ] threadWe need something new and better.
We made sure to build a solution that is easy to setup and maintain. One single binary/container for single node setup and one stack to setup/upgrade/maintain for HA setup.
We also made sure that it is easy to use and learn. We allow standard SQL to be used for querying logs, metrics and traces - nothing extra to learn here. Metrics querying is supported using PromQL too. Drag and drop for creating panels and dashboards is there too :-).
Dashboarding is supported within the same stack. No need to setup Grafana or something else separately.
OpenObserve also offer functions that grafana stack does not offer. Give it a shot, you are going to love it.
Data is stored in open parquet format, allowing its usage even outside of OpenObserve if so desired.
Hope this helps.
Having a simple language/YAML to define those panels and an easy way to preview them (eg paste in your file to preview the page, paste in a panel source to try it) in addition to editing via GUI and being able to copy changes back to revision control would be great
In Elasticsearch tuning these indices is one of the bigger operational burdens. Loki solves this by asking users to not put data in the indexed fields, instead brute force through it all.
Does OpenObserve have any other approach to this?
OpenObserve use parquet as the storage format which is much more resilient to high cardinality. OpenObserve has page indexes and partitions that allow it to handle this very well.
I'm unsure what does "high cardinality" mean for ElasticSearch case. As I know it happily accepts log messages with high-cardinality labels such as ip, user_id or trace_id.
I don't know whether OpenObserve has any issues related to high cardinality.
P.S. I'm, as VictoriaMetrics core developer, confident that the upcoming log storage and analytics solution from VictoriaMetrics - VictoriaLogs - will be free from Loki-like high cardinality issues.
> Currently OpenObserve support steams of type logs, in future streams types metrics & traces will be supported.
- are metrics and traces queryable yet? I admit, I feel a little misled, if only logs are supported for now that should be made more clear.
- do (or will) metric and trace queries use a similar SQL syntax as log search?
Finally... is there a demo? I would love to be able to try out the product without actually putting in the effort to set it up.
[0]: https://openobserve.ai/docs/user-guide/streams/
Metrics is still in its infancy though.
https://github.com/parseablehq/parseable
First guess is that the underlying storage / query layer is pretty similar (Parquet + Datafusion), but OpenObserve has more built in use cases?
As an aside, it’s awesome that Datafusion’s existence and maturity makes launching a product with scalable analytical reads 10x easier than before and cool to see so many projects integrating it
Yes, OpenObserve has a lot more use cases than parseable and our focus on ease of use has allowed us to build far more features and join them in an elegant way making it easier to use it, than any other platform out there.
Give it a shot and let us know what you think.
We wish parseable team our best wishes.
This seems contradictory. If OpenObserve doesn't support Kibana, how can it be a drop-in replacement for Elasticsearch queried using Kibana? Even if the OpenObserve UI has similar features, I can't just replace Elasticsearch with OpenObserve and keep the rest of my workflow the same, which I would consider a precondition to call something a drop-in replacement.
Is Kibana support totally out of the question?
Actually no.
We already have a good amount of pieces in place to support kibana. 2-3 weeks of dev work and it will be ready. Just not the top priority right now though.
Wouldn't be easier to use Cickhouse?
Certain difference on how OpenObserve is different than Signoz:
1. Built in rust for high performance and memory safety. 2. Has its own data storage engine based on open specification of Apache Parquet. This allows the data to be used by other applications outside of OpenObserve if desired. 3. Use stateless nodes in architecture (You are going to love it from maintenance point of view). 4. Use of object storage for extreme scalability and low cost. 5. Requires far lower resources than Signoz. Can practically be run using a single binary/container. There are users ingesting terabytes of data on a single node. There are people running OpenObserve on raspberry-pi. 6. A lot easier to setup and maintain. 7. Ingest and query functions are awesome. Give them a shot.
We have also seen logs data of our users at a compression ratio of 30x/40x. We have published a logs benchmark (https://github.com/SigNoz/logs-benchmark) where the data is very high-cardinal (causing a compression factor of only 2.5x). Would love to see how does OpenObserve perform in that dataset someday.
Wishing you best for the journey ahead.
At the bottom of your GitHub project home page, you say the best way to join the project is to join a WeChat group (in Chinese text), but likely only a very small minority of us outside China use WeChat, so that may be a stumbling block if you are trying to encourage people outside Asia to contribute to the project.
Per https://openobserve.ai/about , the address at the bottom says San Francisco, California, but in the same page it says "headquartered in Bangalore, India". So where are you based out of?
Also curious what the relationship is between OpenObserve the open-source project and Zinc Labs, which is referenced in the website (but not in the GitHub project).
> headquartered in Bangalore, India This is embarrassing, just fixed it. We are a delaware based company, headquartered in San Francisco. Pure copy paste error.
Zinc Labs (Legal name) is the company behind the product OpenObserve.
Copy and paste from where? Did you even build this product or just hire cheap labor out of India to build it?
This company created ZincSearch:
https://github.com/zincsearch/zincsearch
Prabhat is one of the core contributors/maintainers:
https://github.com/zincsearch/zincsearch/graphs/contributors
https://github.com/prabhatsharma
Also the negative insinuation of using “cheap” labor out of India to build the product is unnecessary. If you’re concerned about code quality, look at the code.
Assuming everyone working with devs in India is doing so cynically is not charitable.
I dont know why the headquarters was set as india versus SF but does it actually even matter?
Assuming _only_ cheap labour exists in India is just plain ignorant. Even a discriminatory tone towards some of the outstanding engineers and hackers who live there. Please reconsider your biases, and ask questions in good faith.
Then they started sending me emails from their personal gmail accounts…
https://www.linkedin.com/posts/adrianmacneil_sdrs-are-the-fr...
As someone running a homelab, and hadn't set up logging yet, it was a great find. I didn't have to learn and combine 3+ log technologies, it's just a single all-in-one monitoring server with web UI, dashboards, log filtering/search, etc. RAM usage of the Docker container was under 100MB.
and this would allow me also to get all logs to the same place?
i see that graphana support in enterprise only feature, does it mean that long term metrics mirrored from prometheus are no longer available there?
is there any way to get just graphana plugin for self hosted deployment?
And yes you can get your logs there too.
You don't need grafana as OpenObserve has good dashboarding for metrics and logs built in. Still early days for OpenObserve - some features are missing and has some rough edges.
I am not sure what you mean by:
> does it mean that long term metrics mirrored from prometheus are no longer available there?
> is there any way to get just graphana plugin for self hosted deployment?
ping us on slack channel, If you are able to make friends with the team you can get anything :-) . Fair warning - We have found OpenObserve logs UI to be much smoother and advanced than grafana UI.
> > does it mean that long term metrics mirrored from prometheus are no longer available there?
Ok maybe i didn't describe it clearly, what i mean is that long term metrics will be only available over OO, and when we use grafana and our team is already familiar with that then it's issue that for querying long term metrics we would need to use different tool/UI.
> We have found OpenObserve logs UI to be much smoother and advanced than grafana UI.
Grafana isn't very good with logs, but as far as I understand you are able to generate metrics from logs in OO (like errors/exceptions per hour or time since last error etc) and adding them to existing dashboard in grafana is quite important.
PS: overall OO looks very promising and I'm currently investigating self hosted product to aggregate logs and I'm for sure will be evaluating OO :)
Is my math right? Or do you use something different for compression?
2 Orders of magnitude of storage saving is pretty impressive.
Have you done any comparison testing with various generations of hardware? AFAIK the latest generations don't down clock their scalar turbo that much (or at all), but Skylake definitely did.
https://openobserve.ai/docs/getting-started/
I guess having the cake and eating it too is actually not feasible in this case.
With that said I will indeed have a go at this and test and see if I can replace elasticsearch in our stack.
Good job guys!
What is your use case?
For single node installations, you can use base k8s manifests that is available using instructions at - https://openobserve.ai/docs/quickstart/#self-hosted-installa... .
Mike created a helm chart for s ingle node installation too - https://github.com/mshade/openobserve-chart/
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
Will you compare with qryn? Self-hosted sentry?
https://qryn.metrico.in/
https://develop.sentry.dev/self-hosted/
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.
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.
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.
https://qryn.metrico.in
and
https://github.com/highlight/highlight
(There are some interesting comparisons/comments vs signoiz in sibling threads).
For qryn the vision remains "abstracting" our two-way polyglot Observability APIs transparently on top of multiple modern data backends (InfluxDB IOx/Flight is right next!) and being able to operate on both edge (light js) and core (fast go/rust) and provide users more choice and control as of how they can spend resources to store and leverage the data they collect in as many ways as possible, while transparently using the protocols, tools, agents and formats they already love and trust.
Inserting lots of Observability data really fast is relatively easy nowadays but reading the same data back from multiple APIs supporting multiple vendors formats is where qryn comes in strong without requiring new tools or plugins. We love to think of qryn as one of the many good vendor-locksmith tools for observability integrators out there who want more of out their data.
If anyone's curious you can try and benchmark qryn for free at https://qryn.cloud
We think that managing clickhouse is extra effort. Direct access to object storage is vital for cost reduction which is somewhat difficult in clickhouse. Small resource footprint is extremely valuable to many too. Simplicity of deployment is key to get started and many will use a product simply because they can. I know, I have used products that simply ran, and for no other reason.
Our best wishes to all the 3 teams.
For me, thought, setting up a system is not the primary pain point today. FWIW, signing up for a cloud service is not hard.
The problem starts at the ingestion point. I am writing my apps according to 12 factors and running them in docker containers. What I want is an agent companion that will collect logs and metrics from these apps and containers and forward to the system. Datadog and Grafana has that, do OpenObserve?
Also, interesting that in your quickstart tutorial you have a step of unzipping logs file before sending to the system. I would suggest the ability to send them in (g)zipped format, as it is an organic format of keeping logs.
We did not want to reinvent the wheel and recommend that you use one of these.
quickstart tutorial does not reflect what you will do in real life scenario.
You will want to learn how to use log forwarders like fluentbit and vector. These are the ones that you will generally use in real life. These log forwarders read the log files and send them to OpenObserve. Here is a blog on how to use fluentbit to capture kubernetes logs using fluentbit and send them to OpenObserve - https://openobserve.ai/blog/how-to-send-kubernetes-logs-usin...
We will add more tutorials and examples soon.
Hope this helps.
With DataDog they have an easy to install agent that runs and ingests log data and can also handle (somewhat) for duplications due to disruptions.
Based on the OpenObserve documentation one essentially has to curl the logs themselves to the web service to submit, standardize on fluentd or equivalent, or tie into one of the other providers / agents.
I'm sure it's possible and that one of the services/software they mention briefly provides for this hopefully so I don't have to create my own agent, or ensure all services have a central logger that curls.
Not every system is on Cloudwatch (Linode, etc), and in many cases I'd like to have different ways to ingest and manage all the different logs one may produce. AWS EC2, Lambda, Linode, etc. Was really hoping for an easy server setup, plus agent, API, etc. Also, for systems you want to observe and not modify, such as 3rd party systems, would be nice to have an easy to add agent as to not have to modify or take ownership of those processes.
You don't use curl for logging except in demonstrations.
In production you would want to use a log forwarder like vector or fluentbit. If your environment is kubernetes, then use this guide - https://openobserve.ai/blog/how-to-send-kubernetes-logs-usin... .
If something else let us know, and we can have a guide. fluentbit and vector are fairly well documented and have been there for years now. I would recommend you to check them out. OTEL-collector is a good option too.