Blocker (pm_blocker)
This module blocks log messages and can be used to simulate a blocked route. When the module blocks the data flow, log messages are first accumulated in the buffers, and then the flow control mechanism pauses the input modules. Using the block() procedure, it is possible to programmatically stop or resume the data flow. It can be useful for real-world scenarios as well as testing. See the examples below. When the module starts, the blocking mode is disabled by default (it operates like pm_null would).
This module is being phased out and will be removed in a future release. |
To examine the supported platforms, see the list of installer packages in the Available Modules chapter. |
Configuration
The pm_blocker module accepts only the common module directives.
Functions
The following functions are exported by pm_blocker.
- boolean
is_blocking()
-
Return TRUE if the module is currently blocking the data flow, FALSE otherwise.
Procedures
The following procedures are exported by pm_blocker.
block(boolean mode);
-
When mode is TRUE, the module will block. A
block(FALSE)
should be called from a Schedule block or another module, it might not get invoked if the queue is already full.
Examples
In this example, messages are received over UDP and forwarded to another host via TCP. The log data is forwarded during non-working hours (between 7 pm and 8 am). During working hours, the data is buffered on the disk.
<Input udp>
Module im_udp
ListenAddr 0.0.0.0:1514
</Input>
<Processor buffer>
Module pm_buffer
# 100 MB disk buffer
MaxSize 102400
Type disk
</Processor>
<Processor blocker>
Module pm_blocker
<Schedule>
When 0 8 * * *
Exec blocker->block(TRUE);
</Schedule>
<Schedule>
When 0 19 * * *
Exec blocker->block(FALSE);
</Schedule>
</Processor>
<Output tcp>
Module om_tcp
Host 192.168.1.1:1514
</Output>
<Route udp_to_tcp>
Path udp => buffer => blocker => tcp
</Route>