1. 1

    I recently found https://github.com/rs/jplot which isn’t limited to using characters, but is limited to iTerm2. You also might want to check out the https://github.com/gizak/termui library for inspiration on how to do higher resolution plots.

    1. 1

      I wonder if there’s a roadmap for this. There are some bits that still need work sprinkled throughout in the source and I’m not seeing a great description of the in memory and on-disk data structures to the point where one could do capacity planning (is it just protobuf dumped to disk?). I see benchmarks in the tests as well, but nothing to put the times and MB/sec in context that’s helpful enough to do capacity planning if I were to run them in a target environment.

      1. 1

        Thanks for the comments. I don’t really have a roadmap for it, but I think the most work remaining is fleshing out the UI and allowing for more kinds of queries (zooming in on specific quantiles or histograms, etc). The specific TODO you linked there is only an issue for the shutdown code: how long do you wait when doing a best effort dump to disk on exit? In general, I also tend to use the TODO comment more loosely to remind me about design tradeoffs in specific locations, in case those decisions aren’t optimal.

        Capacity planning is discussed here, but I agree that documentation around the disk layout would be good, as well as making that more prominent. The database tends to be very disk light in terms of I/O due to it only having to write on 10 minute (configurable) intervals, and only writing a small amount of data (around ~300 bytes per metric, regardless of number of observations). I added an issue to keep track of what you’ve identified.