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.
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.
@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.
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.
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.
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?
Most helpful comment
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.