Closed blkt closed 9 years ago
(by)
works lexically--it can only capture the expressions inside (by ...)
. In this case, pipe
has bound a single (changed :state)
stream to the symbol e
, and by
is re-evaluating its body--e
, for each separate host--and because e
always points to the same changed stream, it's routing every event there. You probably didn't mean to use pipe
here--I suspect you just wanted to use the regular (by :host (changed :state ...))
style.
Well, the real configuration I have is more complex than this, this was only to reproduce the issue, thus the need to use pipe
, but I get it now.
Thank you.
So the reason pipe exists is specifically to cause this stream-unifying behavior--if you need pipe, I'm guessing you wanted this to happen. :)
I thought it could be used a la -> or ->> :) I'm closing this issue.
I'm having an issue with events reinjected by a first stream not being handled as expected by a second stream.
More specifically, I have a few machines sending events to Riemann; each of these machine sends an event with service
"incoming service"
that I monitor to check whether the particular host is alive or not (this event is sent every, say, 5 seconds, ttl is 10 seconds).Informally, the first
streams
definition should::service
to"heartbeat"
and:state
to"alive"
The second
streams
definition should:"heartbeat"
:state
fieldinfo
)My problem is that the first host to pass through the streams prevents the others from being processed until its expiration. Is there something I'm clearly making wrong?
Riemann config file
Simple (Ruby) client to test the configuration
Log I get on my machine