Additional storage backends #638
Comments
Did you remove the flags for elasticsearch in jaeger-collector? Because I'm doing a test using the image docker, which version is:
and I cannot see the elasticsearch flags. |
It looks like you're using latest instead of 1.1. We recently moved around some of the flags so that we can support plugins better #625. Using latest, you have to instead use env variable SPAN_STORAGE=elasticsearch to use the elasticsearch flags. I'd recommend that you use 1.1 since this change will be apart of 1.2 and will be documented at that time. |
Thanks for the reply, yes I was using the latest version. I will use the 1.1 |
I would love to see a SQL option (whatever ANSI SQL that will be least vendor lock-in). |
Since I work with PostgreSQL, I sure wouldn't complain. But honestly I'm not sure a SQL db is an optimal store for largely free-form metrics of this nature. PostgreSQL at least offers the But you inevitably land up with someone putting an ORM on top to "abstract" the DB. Then the ORM performs terribly, gobbles memory and everyone says "the SQL backend is slow, use instead". |
Related issue to this one is #551. Upvote if you are interested in it. |
New related issue- |
We are looking at using BigQuery as a storage layer. Presumably this could work with a SQL storage option. SQL can be a generic way to deal with columnar data stores in a generic way. I would complain about a BigQuery specific solution, but I think there is a place for generic SQL interface beyond RDBs. |
I assume that even if some database can be treated as SQL and accessed via standard database/sql API, we still need to statically import the actual driver. Granted, this may be less maintenance than a dedicated SpanStorage implementation. However, now that the protobuf model has been merged, nothing is blocking us from moving on the storage plugin dev, eg using something like harshicorp grpc plugin framework. |
|
Giving my two cents.. an ANSI SQL could work for small workloads, so may be useful for lower-throughput applications that still want to benefit from this tool. I will also throw out there that Timescale (a Postgres extension) may be a good fit for the required high write throughput. |
Clickhouse are SQL high performance storage very efficient for log and trace storage and whold be perfect storage alternative to cassandra original one... they are a true column db... distributed...compressed... they are near to the CQL (sql like query language)... they use an SQL like language to... |
I just thought that I'd drop something here to say that there is also support for using Couchbase as a storage backend (via the grpc plugin), currently at https://github.com/chvck/couchbase-jaeger-storage-plugin. Will likely move to the couchbase-labs organisation in time. |
Has someone started to work on Azure CosmosDB integration? It has support for Cassandra API, but I couldn't manage to make it work... |
I just created an issue proposing Chronowave as storage backend. #2534 |
What about ClickHouse? Clickhouse is very cool |
It's already linked in the issue's description, but here's the tracking issue for it: #1438 |
What about Apache Solr? |
With the recent changes to ElasticSearch licensing, this just because SUPER important. |
The ES changes do look worrying, but not sure this justifies supporting Solr. It does help the case of advancing with some other storage. |
AWS announced an Apache-2 licensed fork of ES, logz.io also said something similar (could be the same effort). So I don't think there's reason to panic. I don't think Elastic changed the terms for the Go driver which we started using in OTEL-based collector, but we'd need to watch for that. |
Absolutely, especially because they can't change the license for something that was released already. So, folks currently using ES don't have a reason to change immediately. If they need to update for some reason, like due to a security problem or general bug fix, then it might become problematic. While I appreciate the work that logz.io is doing in this front, having multiple sources of ES doesn't help us in supporting our users. On day 1, they'll all be compatible among each other, but each fork will tend to follow its own path over time. Meaning: we'd need to decide which one we'll be "officially" supporting. |
We are working with several organizations including AWS on an open source version of ES and Kibana which will be Apache licensed and hopefully part of the ASF. I will know more in the coming days. I've had a hard time getting RedHat engaged (they have canceled twice now) so if you can help with that @jpkrohling then we'd love it :) Anyone interested in contributing or taking part in the community is welcome. I am collecting info here to start: https://docs.google.com/forms/d/e/1FAIpQLSfykAk4Bhc-dhjR0AXFP7T2oFmsLUxONbD6NwmgMz4usXSGkw/viewform?usp=sf_link |
Opening this issue to keep track of other related issues.
Relevant issue: plugin support #422 (done).
The text was updated successfully, but these errors were encountered: