Option for machine-readable output (e.g. JSON) from top?

--0000000000004ef9f10619ea6e00
Content-Type: text/plain; charset="UTF-8"

If this has been discussed before, my apologies for the noise, and please
point me at any summary and/or details of the previous discussion.

top is currently excellent at its primary purpose, which I would call
"presenting information about the system load, and running processes or
threads, to a human reader".

It is less ideal for consuming this information by other programs.

If top had an option to output in an easily-machine-readable format, e.g.
JSON data, and in that JSON data the numeric values were always in a
consistent unit, e.g. resident memory was always in KiBytes or MiBytes,
with no suffix for a unit, then the output would be much easier to consume
by other programs.

Does an open source program like this exist already, and I simply haven't
been able to find it in my recent searches?

Would this be reasonable to consider for a future version of top?  Or would
that be considered to be outside of its scope, and a different program
would be better suited for such a task?

If it were included in top, my first thoughts would be along these lines:

Add a new command line option (e.g. perhaps '-j') that causes output to be
in JSON format, with one JSON object per top display period.  Using this
new option would force batch mode to also enabled.  Each JSON object would
contain fields representing the summary data, and a key for the list of
processes/threads, which would be a list of one sub-objecdt per
process/thread.

Advantages to inclusion in top:

(A1) It would become widely available, once included in various Linux
distributions
(A2) Many existing command line options/configurations for top would still
be useful for limiting the scope of the output, e.g. limit the output to an
explicit list of processes.

Disadvantages to inclusion in top:

(D1) Larger binary
(D2) Another case to think about while maintaining the code.
(D3) Potential for more feature creep and maintenance burden down the line
as people start using this, e.g. different languages for JSON keywords,
perhaps?

Thanks,
Andy Fingerhut

--0000000000004ef9f10619ea6e00
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">If this has been discussed before, my apologies for the no=
ise, and please point me at any summary and/or details of the previous disc=
ussion.<div><br></div><div>top is currently excellent at its primary purpos=
e, which I would call &quot;presenting information about the system load, a=
nd running processes or threads, to a human reader&quot;.</div><div><br></d=
iv><div>It is less ideal for consuming this information by other programs.<=
/div><div><br></div><div>If top had an option to output in an easily-machin=
e-readable format, e.g. JSON data, and in that JSON data the numeric values=
 were always in a consistent unit, e.g. resident memory was always in KiByt=
es or MiBytes, with no suffix for a unit, then the output would be much eas=
ier to consume by other programs.</div><div><br></div><div>Does an open=C2=
=A0source program like this exist already, and I simply haven&#39;t been ab=
le to find it in my recent searches?</div><div><br></div><div>Would this be=
 reasonable to consider for a future version of top?=C2=A0 Or would that be=
 considered to be outside of its scope, and a different program would be be=
tter suited for such a task?</div><div><br></div><div>If it were included i=
n top, my first thoughts would be along these lines:</div><div><br></div><d=
iv>Add a new command line option (e.g. perhaps &#39;-j&#39;) that causes ou=
tput to be in JSON format, with one JSON object per top display period.=C2=
=A0 Using this new option would force batch mode to also enabled.=C2=A0 Eac=
h JSON object would contain fields representing the summary data, and a key=
 for the list of processes/threads, which would be a list of one sub-objecd=
t=C2=A0per process/thread.</div><div><br></div><div>Advantages to inclusion=
 in top:</div><div><br></div><div>(A1) It would become widely available, on=
ce included in various Linux distributions</div><div>(A2) Many existing com=
mand line options/configurations for top would still be useful for limiting=
 the scope of the output, e.g. limit the output to an explicit list of proc=
esses.</div><div><br></div><div>Disadvantages to inclusion in top:</div><di=
v><br></div><div>(D1) Larger binary</div><div>(D2) Another case to think ab=
out while maintaining the code.</div><div>(D3) Potential for more feature c=
reep and maintenance burden down the line as people start using this, e.g. =
different languages for JSON keywords, perhaps?</div><div><br></div><div>Th=
anks,</div><div>Andy Fingerhut</div></div>

--0000000000004ef9f10619ea6e00--