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).

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

Example 1. Using the pm_blocker Module

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.

nxlog.conf

<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>