Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

in_syslog cannot handle custom-formatted syslogs that do not start with <pri> #363

Closed
kiyoto opened this issue Jun 21, 2014 · 6 comments
Closed
Labels
bug Something isn't working

Comments

@kiyoto
Copy link
Contributor

kiyoto commented Jun 21, 2014

in_syslog has two parsing logics:

  1. If a format parameter is provided, then it parses the leading and uses the provided format for the rest of the message.
  2. If no format parameter is provided, it uses the default syslog message format, which also starts with <pri>.

This means that in_syslog barfs if the incoming message does not start with <pri>. This may happen if the user has custom syslog format that does not start with <pri>.

Should in_syslog support this? Or should it be in_forward?

@repeatedly
Copy link
Member

I don't want to add new functionality to in_foward because it cause the inconsistency with out_forward.

I have two ideas:

  • Support without_priority like option in in_syslog
  • Add new in_udp / in_tcp or in_transport like plugin to support arbitrary udp / tcp event

In general, in_udp / in_tcp plugin useful for other logging mechanizm.
For example, Netflow sends own format with udp / tcp protocol.

@kiyoto
Copy link
Contributor Author

kiyoto commented Jun 23, 2014

I agree with you on in_/out_forward. They should be primarily for Fluentd-to-Fluentd.
I like your second idea better.

@repeatedly
Copy link
Member

I'm considering which is better separating protocol or setting protocol via options.

<source>
  type udp
  format /.../
</source>

or

<source>
  type event # or better name
  protocol_type udp # or tcp or unix?
</source>

I think former case is good for users. it is clear plugin name.

@kiyoto
Copy link
Contributor Author

kiyoto commented Jun 25, 2014

If no one is using in_tcp anymore, I personally think the first one is better: I think "type <protocol_type>" is always more clear than "type ".

@repeatedly
Copy link
Member

Merged #368. So I closed this issue.

@kiyoto
Copy link
Contributor Author

kiyoto commented Jun 30, 2014

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants