Not only is there redundancy, but an identical field name could mean totally different things in the two, such is the case with pctCPU. It is really a poor choice of field name on the app's part. (As of 6.2.)
In fact, the only data unique to top as a utility are those interval data as opposed to snapshot values. (Instantaneous and cumulative values, respectively exemplified by NICE and elapsed time, are both snapshot values. The two examples are both retrievable via ps command at least in modern GNU, -o nice,etime .) %CPU in top (represented as field pctCPU in sourcetype=top ) is an interval value. This is totally different from the cumulative value -o pcpu as given in ps utility. (Also represented as field pctCPU in sourcetype=ps .) The three load averages that top displays are also unavailable in ps, because though cumulative, they are aggregations (as opposed to per process). These are captured in sourcetype=vmstat via uptime utility.
In short, top is an decidedly interactive utility. GNU default displays (as used in top.ps) use human-friendly units and such, complicating field extractions, but with no purpose (because all such information is retrievable via GNU ps). The main useful field, %CPU is confused with ps' pcpu output.
For these sources to be more useful, I would (strictly GNU)
Rename %CPU in top output to something else.
Give ps a few more fields such as PPID, thcount and wchan.
top's diagnostic value is particularly high when run with -H . You can find which thread is eating up CPU. But that would add lots of overload to both host and indexer.
... View more