Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PoC proposal.
While it's quite handy to have
file ip
cluster type, still, it's more for debugging purposes rather then permanent solution.When dealing with legacy systems, it's quite handy to be able to analyse sources of incoming metrics. Syslog format widely supported and quite easy to re-route and parse (Logstash for a example).
Rather than make new cluster type and dealing with complexity of yacc/bison stuff, i'd suggest to utilise either
server->type
orserver->transport
for dealing with syslog envelope (in this PoC, I using connection type:server->type
.Sample configuration file:
Sample output for syslog receiver:
<30>Apr 11 13:25:30 127.0.0.1 crelay: hello.world 1 123456789
Implementation details:
3 (system daemons)
6 (INFO)
metric source address
crelay
.I'd also noticed that in case of udp receiver, source address is empty, which is result of
getpeername
call on udp socket (which is obviously empty, due the nature of udp protocol).Please advice, can such solution to be adopted and accepted into mainline? I'd made a separate commit without autogenerated changes to demonstrate proposed approach: arkady-emelyanov@57fea4d
Thanks.