Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can all-in-one be used in production? #551

Closed
yurishkuro opened this issue Nov 20, 2017 · 5 comments
Closed

Can all-in-one be used in production? #551

yurishkuro opened this issue Nov 20, 2017 · 5 comments
Labels
area/storage enhancement help wanted Features that maintainers are willing to accept but do not have cycles to implement

Comments

@yurishkuro
Copy link
Member

This conversation https://gitter.im/jaegertracing/Lobby?at=5a130a9fcc1d527f6b93a7f2 raised an interesting point. What would it take to make all-in-one be usable as production deployment? Clearly, it's not a distributed setup so we're limited by the resources of a single box, but that's a typical setup for Prometheus as well, and it works fine.

Option 1 - implement data eviction policy for traces captured in memory. The data will not survive the container restarts, but the setup my still be useful.

Option 2 - implement a local storage using rocksdb or leveldb.

@mjrussell
Copy link

Thanks for creating this! I was also thinking of a docker image setup that would have the core jaeger components and then an environment variable for the external storage connection (like elasticsearch IP, etc). Then you could use docker volumes to persist data as needed, and possibly re-use a standard elasticsearch container image.

@yurishkuro
Copy link
Member Author

@mjrussell that may already be possible, the all-in-one cmd line does require span.storage-type, by default it's memory, but if you override it with cassandra or ES it may use an external storage.

@objectiser
Copy link
Contributor

Like the idea - hopefully both could be supported, but if just one, then option 2 would be good especially for users also using Prometheus. Looks like it uses leveldb but just for indexes, and its own storage layer for the data.

@fzakaria
Copy link

fzakaria commented Feb 5, 2018

Honestly something simple like LevelDB + RocksDB with a trivial eviction policy
(some go routine that evicts things older than X days) would be good enough for me.

@black-adder black-adder added the help wanted Features that maintainers are willing to accept but do not have cycles to implement label Feb 21, 2018
@jpkrohling
Copy link
Contributor

Option 1 - implement data eviction policy for traces captured in memory. The data will not survive the container restarts, but the setup my still be useful.

This has been implemented

Option 2 - implement a local storage using rocksdb or leveldb.

Is being addressed by #760. Should this one here be closed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/storage enhancement help wanted Features that maintainers are willing to accept but do not have cycles to implement
Projects
None yet
Development

No branches or pull requests

6 participants