Configure an NXLog Agent relay

The purpose of a relay is to gather logs from multiple sources and forward them to the final destination, such as NXLog Platform. See Centralized log collection for more information.

Below, we provide examples of configuring NXLog Agent as a relay and collecting logs from agentless log sources and other NXLog Agent instances.

Collect logs from agentless log sources

You can configure an NXLog Agent relay to collect logs from different sources, such as network devices that can only send logs over UDP or software applications that send logs over TCP.

NXLog Platform provides a pre-built configuration template to collect logs from such sources. You can view and edit the configuration settings by navigating to Agents > Configurations Overview and clicking on the Agentless Network Input Relay template.

Follow these steps to apply the template to your agent relay:

Log in to NXLog Platform and navigate to Agents > Agents.
Find the agent you want to assign the template to. You can use the search bar to help you find the agent.
See Enroll an agent manually if you have not enrolled the agent relay to NXLog Platform yet.
Click the Actions menu for the agent and choose Assign template.
Choose the Agentless Network Input Relay template and click Save to push the configuration to the agent.

Transfer logs between NXLog Agent instances

The NXLog Transport modules efficiently transport compressed logs between NXLog Agent instances. These modules preserve all the event fields, so you don’t need to parse log records again on the relay.

Example 1. Transferring logs between NXLog Agent instances

First, configure an NXLog Agent relay to receive logs using the im_batchcompress input module.

nxlog.conf

<Input nxlog_transport>
    Module         im_batchcompress
    ListenAddr     0.0.0.0:2514
    CAFile         /opt/nxlog/cert/rootCA.pem  (1)
    CertFile       /opt/nxlog/cert/agent-cert.pem  (2)
    CertKeyFile    /opt/nxlog/cert/agent-key.pem  (3)
</Input>

1	The CAFile directive specifies the path to the CA certificate to verify the remote agent’s certificate.
2	The CertFile directive specifies the path to the relay server’s certificate.
3	The CertKeyFile directive specifies the public key that was used to sign the relay server’s certificate.

Once your relay is up and running, configure your other NXLog Agent instances to send logs to it with the om_batchcompress output module.

nxlog.conf

<Output agent_relay>
    Module         om_batchcompress
    Host           192.168.1.101:2514
    UseSSL         TRUE
    CAFile         /opt/nxlog/cert/rootCA.pem  (1)
    CertFile       /opt/nxlog/cert/agent-cert.pem  (2)
    CertKeyFile    /opt/nxlog/cert/agent-key.pem  (3)
</Output>

1	The CAFile directive specifies the path to the CA certificate to verify the remote agent’s certificate.
2	The CertFile directive specifies the path to the local server’s certificate.
3	The CertKeyFile directive specifies the public key that was used to sign the local server’s certificate.

Configure a relay cluster in failover mode

Network-based NXLog Agent modules provide failover capabilities, allowing you to configure an NXLog Agent cluster for High Availability (HA). Refer to Failover-enabled modules for a complete list of NXLog Agent modules that support failover, and see Failover for more information.

Example 2. Sending logs to an NXLog Agent relay cluster

First, configure your NXLog Agent cluster nodes to receive logs. Each agent should have an identical configuration. We will use the im_batchcompress input module in our example.

nxlog.conf

<Input nxlog_transport>
    Module        im_batchcompress
    ListenAddr    0.0.0.0:2514
</Input>

Once your relay cluster is up and running, configure your other NXLog Agent instances to send logs to it. We will use the corresponding om_batchcompress output module in this example.

nxlog.conf

<Output agent_relay>
    Module    om_batchcompress
    Host      192.168.1.51:1514 (1)
    Host      192.168.1.52:1514
    Host      192.168.1.53:1514
</Output>

1	Specify the IP address and port of your cluster nodes in the order in which you want them to be used. If the first Host becomes unavailable, the module automatically tries the next one.