Feature request: add a CLI option to parse & print the contents of .blog file
Hello there!
ttop is an amazing tool that covers many of my monitoring use cases, but I recently encountered a new challenge that isn't easily solved.
I have several processes that I need to monitor over extended periods to analyze their resource consumption—particularly peak usage. While I could inspect each process individually via the TUI, this approach would be prohibitively time-consuming.
I considered leveraging the data ttop already collects in its .blog files, which contain all the necessary information. However, since these files are binary, I'd need to implement a parser based on the code here - https://github.com/inv2004/ttop/blob/main/src/ttop/blog.nim
Then it occurred to me: this functionality might be a natural fit for ttop itself!
I’m not a Nim expert (not even an amateur, hehe), but with LLM assistance I could likely contribute something. My idea is a new command-line option for ttop that accepts a .blog file, parses its contents, and prints human-readable output. This would allow users to pipe the results into tools like sed, awk, or grep for custom processing.
What are your thoughts? Would you accept a pull request for this feature? Or would you prefer to implement it yourself? :)
This is what I meant:
$ ./ttop -h
ttop - system monitoring tool with TUI and historical data service
Usage:
run [optional-param]
Options:
-h, --help print this help
-s, --save save snapshot
--on enable system.timer (or cron) collector every 10 minutes
--on <number> enable system.timer (or cron) collector every <number> minutes
--off disable collector
-l <file> display overall system load from specified .blog file
-p <file> display detailed per-process data from specified .blog file
-v, --version version number (1.5.4)
In a detailed mode it shows all the process information. I started ttop at around 18-15:
$ ./ttop -p /var/log/ttop/2025-07-09.blog | head -n 3
timestamp pid cpu mem_rss_kb mem_vsize_kb mem_pct user name cmd
2025-07-09T18:15:04+03:00 1 0.00 15116 170160 0.11 root systemd /sbin/init splash
2025-07-09T18:15:04+03:00 2 0.00 0 0 0.00 root kthreadd
... and this logs goes and goes up to the very last record:
$ ./ttop -p /var/log/ttop/2025-07-09.blog | tail -n 2
2025-07-09T22:00:12+03:00 45776 0.00 0 0 0.00 root kworker/7:2
2025-07-09T22:00:12+03:00 45843 0.00 1536 1808 0.01 root ttop /usr/local/bin/ttop -s
In a load summary mode (I don't actually need it, but decided someone might):
$ ./ttop -l /var/log/ttop/2025-07-09.blog | head -n 10
Timestamp | Procs | CPU % | Mem Total | Mem Avail | I/O
------------------------+--------+--------+-----------+-----------+--------
2025-07-09T18:15:04+03:00 | 323 | 6.25 | 14235764M | 10560792M | 0
2025-07-09T18:20:12+03:00 | 322 | 2.83 | 14235764M | 10464496M | 0
2025-07-09T18:30:12+03:00 | 320 | 2.20 | 14235764M | 10580680M | 0
2025-07-09T18:40:38+03:00 | 318 | 2.64 | 14235764M | 10398624M | 0
2025-07-09T18:50:12+03:00 | 319 | 2.23 | 14235764M | 10417536M | 0
2025-07-09T19:00:11+03:00 | 318 | 2.00 | 14235764M | 10392696M | 0
2025-07-09T19:10:41+03:00 | 320 | 2.49 | 14235764M | 10277444M | 0
2025-07-09T19:20:12+03:00 | 317 | 2.17 | 14235764M | 10416000M | 0
Will prepare a pull request, if you don't mind
Sorry for late reply.
I decided that the feature could be the part of separate binary, which is really just
when isMainModule:
proc print(fName: string) =
let s = newFileStream(fName)
if s == nil:
return
defer: s.close()
var buf = ""
while not s.atEnd():
let stat = s.stat()
let sz = s.readUInt32().int
let buf = s.readStr(sz)
discard s.readUInt32()
let info = infoFromGzip(buf)
echo stat.toJson
echo info.toJson
print("/home/u/.cache/ttop/2025-09-13.blog")
in the blog.nim file
It could save some size of the static binary also.
Anyway, thank you for your PR
No worries. You're the boss here. This way or another - if the feature will be there either in the ttop itself or any other auxillary tool it will be awesome