Make Parsable output also an Input format

[gleventhal]

The Parsable output is essentially the API for interfacing with atop. It would be great if we could also ingest that data instead of the binary rawlog. That was it can be stored and parsed/used by other programs, and continue to be used by atop as well.

[gleventhal]

@Atoptool I know sometimes it takes a while to get a response, but this is actually a pretty important feature for something I need, and would be happy to contribute the code if you approve the idea. Otherwise, I may end up writing something myself which I'd rather avoid because atop covers 80 percent of my use-case already.

[Atoptool]

For my understanding, you want to log ascii data (similar to the parseable output) to a file instead of the binary raw data? As it is now, you can always run 'atop -PALL' for a live session or 'atop -r -PALL' on the binary rawlog to write that output to a file afterwards. Can you explain the benefits of your proposal?

[gleventhal]

What's important is that the logged ascii data can be used with atop -r log just like binary data (though the switch can be something different than -r if you prefer)

I would like to have the option to either read from the rawlog (binary data) or to read from a log which has the textual output of atop -PALL.

The reason is that I would like to export the text output to a database so that other tools can access these statistics for monitoring and graphs, but I dont want to have to store those statistics in a database and retain the rawlogs for future use with the atop client.

Instead, I would like to output the statistics from atop -PALL to my database / monitoring / graphs, as I believe atop is the best tool for collecting systems data, and then if I later want to use the native atop client to inspect that data, I can simply write that data back to a file and open it with atop -r.

Right now, Parsable output presents a way to interface with atop in one direction, but it would be incredibly powerful to have the option to import back into atop with that same data. It seems a shame to be forced to have to duplicate that data to be able to continue to use the atop client with the exported statistics. When there are thousands of hosts, it becomes expensive to store the rawlogs and seems like a shame if we are keeping the statistics in another format but cannot easily go back into atop.

[Atoptool]

The issue is clear. I would prefer if you write a separate program to transform the ascii data back into binary data, as you suggest by writing the data back to a (raw) file and open it with atop -r. I can add this program to the source tree.
If you find more fields from the raw file that are missing in the parsable output, please report them (as you did already with issue #98), so I can add them.

[gleventhal]

Great, thank you. I will create a Pull-request for a program to take the output generated by -P ALL and convert into raw log format. I will also raise an issue for any missing fields that I encounter.