Only to understand: you don't want to install the Nmon App on your Splunk Server or the TA-Nmon on your forwarders?
in the first case the easyest way is to install TA-nmon, the Technical Add-On that ingest logs showed with the NMON App.
If you don't want to install this TA on your Forwarders, open inputs.conf file of this TA and copy stanzas in one other App deployed on your Forwarders.
This isn't a good solution because in every way you have to deploy something on your forwarders.
If you don't want to install a Forwarder on your servers, you have to open TA-Nmon and study inputs.conf file to see what to ingest and find a different way to send this logs to Splunk (e.g. using syslog).
In addition to great Giuseppe's answer.
If there are any reason that you may to highlight for not wanting to use the Nmon app to ingest Nmon data in Splunk, feel free I will be happy to read.
At the origin of the Nmon App development, I intensively searched for the better way, most simple, most optimised to ingest Nmon data into Splunk, after numerous tests and attempts I have designed things the way they are (using third party parsers) for various reasons related to the structure of nmon files.
The structure of Nmon data is (for the performance data, not inventory) indeed a structured csv format, however timestamps are in a specific format Splunk cannot understand in any case (ZZZZ lines defines the timestamp in the first line of every measure collection)
This is one of the key that makes it almost impossible for a direct Splunk ingestion, there also other reasons like the inventory data (multi-line events in the AAA and BBB sections), and the per column structure for devices statistics.
There are also numerous ways of using nmon, one of those generates nmon files that you can later ingest, this is not the same than indexing the result of a simple script output.
You can start having a read at the very interesting Nmon FAQ:
In any case, the Nmon app exists since the beginning of 2014, since that time there are have been numerous large and different deployments in various conditions, which makes from the solution a very robust, efficient and simple to implement solution.
Finally, if transporting the information through syslog is the purpose (eg. no deployment of UF on servers), I also provide a solution with the nmon-logger package:
Hope this helps.