Hi! thank you very much for your help!
Probably my questions are result of fundamentals ignorance... Obviously, my missing point is that I have not succeeded on log type - log source pair discrimination at the receiving data (logstash) side.
That's why I'm trying to add more and more tags/fields at the logstash-forwarder sending side.
Right now, I'm using different UDP ports to send different log types from the same host in order to discrimianate at the ending point...
I do not understand how and where you use those mutate instructions... Its not clear to me:
If I'm not wrong and in my short experience, mutate instructions are executed once certain filtering criteria has been met, and is something logstash / receive-side (and not logstash-forwarder / send side!) stuff.... so there comes the point I'm missing:
If I cannot discriminate / mark at the sending side, I could not filter by my marks at the receiving side!
Overall, in my head the picture is something like this:
If server 1 has services A, B and C, and server 2 has services A and B, there should be a way to "mark" logs as they are all sent away from different points to a single common end point...., so, in the receiving logstash side I can filter like: Hey! this log has tags/fields "server1" and "serviceA" filter that way! or Hey! this log has tags/fields "server2" and "serverA" filter that way! and so on...
Also, that way, on the query/kibana side I could claim for every entry from of service A in all servers, or querying for service A just in server 2 and, all logs form "server1", and so on...
Right now, I'm discriminating only by port, and/or by looking for fields in the log that include the IP address of the sending server (for instance firewall logs): this is poor and ugly! if log does not give any clue of the origin I'm unable to discriminate by log content and I have to rely on port (it is something I learn by googling around)... I'm sure there must be a way to handle log traffic in an ordered and elegant way!
Best regards and good work!