You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The big disadvantage of this component is that it only allows one RFC per listener. So you can decide to use RFC5424 or RFC3164.
If you want to cover both RFCs than you have to create two listener which means to have to different tcp/udp ports.
This is very bad for endusers which just want to send their logs via syslog to this syslog-receiver. In many cases they do not know which type of syslog their OS or their application is using. The configure the OS level syslog and then they configure the in application syslog. They just want to type in the destination IP and thats it. They do not want to take care if OS is using 5424 and application is using 3164.
There also could be the possibility that the vendor of the application is changing the syslog format in one of its updates and then the syslog destination needs to be switched to another port.
Thats another problem. Many applications or applicanes do not allow to change the syslog port. they only allow to enter an IP address and then they use the default 514.
So in my ideal world I would like to provide my users one endpoint:
I provide the IP address
I provide the port
I allow UDP and TCP
I allow both types of syslog formats rfc5425 and rfc3164 on the same port and IP
PS:
Another thing I would appreciate if the syslog format could not be identified automatically would be not to drops the message but keep it as it is.
At least in Grafana alloy it would be possible to further process the message individually - or at least it would make sure that (a) we do not lose any logs silently and (b) we can see the logs in RAW format and can try to understand why the application is not sending the logs correctly or how to handle it in further processing stages.
This feature request ist based on this conversation / issue: grafana/alloy#2287
Hello,
I am using Grafana Alloy which seems to use this go-syslog implementations in ist "loki.source.syslog" component.
https://grafana.com/docs/alloy/latest/reference/components/loki/loki.source.syslog/
The big disadvantage of this component is that it only allows one RFC per listener. So you can decide to use RFC5424 or RFC3164.
If you want to cover both RFCs than you have to create two listener which means to have to different tcp/udp ports.
This is very bad for endusers which just want to send their logs via syslog to this syslog-receiver. In many cases they do not know which type of syslog their OS or their application is using. The configure the OS level syslog and then they configure the in application syslog. They just want to type in the destination IP and thats it. They do not want to take care if OS is using 5424 and application is using 3164.
There also could be the possibility that the vendor of the application is changing the syslog format in one of its updates and then the syslog destination needs to be switched to another port.
Thats another problem. Many applications or applicanes do not allow to change the syslog port. they only allow to enter an IP address and then they use the default 514.
So in my ideal world I would like to provide my users one endpoint:
I provide the IP address
I provide the port
I allow UDP and TCP
I allow both types of syslog formats rfc5425 and rfc3164 on the same port and IP
Other syslog implementations do offer this mechanism to auto detect the syslog format like elasticsearch / filebeat:
https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-input-syslog.html#_format_2
PS:
Another thing I would appreciate if the syslog format could not be identified automatically would be not to drops the message but keep it as it is.
At least in Grafana alloy it would be possible to further process the message individually - or at least it would make sure that (a) we do not lose any logs silently and (b) we can see the logs in RAW format and can try to understand why the application is not sending the logs correctly or how to handle it in further processing stages.
This feature request ist based on this conversation / issue:
grafana/alloy#2287
And have other issues / feature requests in grafana alloy:
grafana/alloy#2275
grafana/alloy#2266
The text was updated successfully, but these errors were encountered: