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

[Plugin design] Streamline event submission by an input plugin #2447

Open
wiibaa opened this issue Jan 27, 2015 · 1 comment
Open

[Plugin design] Streamline event submission by an input plugin #2447

wiibaa opened this issue Jan 27, 2015 · 1 comment

Comments

@wiibaa
Copy link
Contributor

wiibaa commented Jan 27, 2015

Currently all input plugins contains more or less the following lines

event["host"] = @host # from Socket.gethostname
decorate(event)
[...]   
queue << event

decorate is handling the add_field/add_tag and with #2390 it could use sprintf syntax and already manipulate event fields set by the input plugin, so it should be enforced that decorate() is called after the event is filled by the specific input.

The idea would be to DRY this into inputs/base.rb, it would avoid plugin implementor to forget or misplace the call to decorate()

Thoughts ?

Here is the list of inputs not complying with the proposed rule

  • exec
  • file
  • ganglia
  • generator
  • heroku
  • irc
  • kafka
  • log4j
  • lumberjack
  • relp
  • s3
  • snmptrap
  • sqlite
  • sqs
  • stdin
  • syslog
  • udp
  • unix
  • varnishlog
  • wmi
  • xmpp
  • zenoss
@jsvd
Copy link
Member

jsvd commented Mar 11, 2016

the only way I see this done is by changing the api to add events to the queue (usually queue << event)
to a method like publish(event) that does:

def publish(event)
  decorate(event)
  @queue << event
end

that said we're planning some changes on the pipeline and queue persistence which will likely change this behaviour. So until then let's keep this open but table this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants