LoadBalancer ConfigGuide
LoadBalancer ConfigGuide
Configuration Guide
Legal Notices
Micro Focus
The Lawn
22-30 Old Bath Road
Newbury, Berkshire RG14 1QN
UK
https://www.microfocus.com
Copyright Notice
© Copyright 2020 Micro Focus or one of its affiliates
Confidential computer software. Valid license from Micro Focus required for possession, use or copying. The
information contained herein is subject to change without notice.
The only warranties for Micro Focus products and services are set forth in the express warranty statements
accompanying such products and services. Nothing herein should be construed as constituting an
additional warranty. Micro Focus shall not be liable for technical or editorial errors or omissions contained
herein.
No portion of this product's documentation may be reproduced or transmitted in any form or by any means,
electronic or mechanical, including photocopying, recording, or information storage and retrieval systems,
for any purpose other than the purchaser's internal use, without the express written permission of Micro
Focus.
Notwithstanding anything to the contrary in your license agreement for Micro Focus ArcSight software, you
may reverse engineer and modify certain open source components of the software in accordance with the
license terms for those particular components. See below for the applicable terms.
U.S. Governmental Rights. For purposes of your license to Micro Focus ArcSight software, “commercial
computer software” is defined at FAR 2.101. If acquired by or on behalf of a civilian agency, the U.S.
Government acquires this commercial computer software and/or commercial computer software
documentation and other technical data subject to the terms of the Agreement as specified in 48 C.F.R.
12.212 (Computer Software) and 12.211 (Technical Data) of the Federal Acquisition Regulation (“FAR”) and
its successors. If acquired by or on behalf of any agency within the Department of Defense (“DOD”), the U.S.
Government acquires this commercial computer software and/or commercial computer software
documentation subject to the terms of the Agreement as specified in 48 C.F.R. 227.7202-3 of the DOD FAR
Supplement (“DFARS”) and its successors. This U.S. Government Rights Section 18.11 is in lieu of, and
supersedes, any other FAR, DFARS, or other clause or provision that addresses government rights in
computer software or technical data.
Trademark Notices
Adobe™ is a trademark of Adobe Systems Incorporated.
Microsoft® and Windows® are U.S. registered trademarks of Microsoft Corporation.
UNIX® is a registered trademark of The Open Group.
Documentation Updates
The title page of this document contains the following identifying information:
l Software Version number
l Document Release Date, which changes each time the document is updated
l Software Release Date, which indicates the release date of this version of the software
To check for recent updates or to verify that you are using the most recent edition of a document, go to:
ArcSight Product Documentation on the Micro Focus Security Community
Support
Contact Information
Phone A list of phone numbers is available on the Technical Support
Page: https://softwaresupport.softwaregrp.com/support-contact-
information
memberIdentity 28
memberHosts 29
notification 30
routing 30
statisticsLogging 35
webServer 36
globalParameters 36
clusterconfigurations 39
Configuration Examples 40
Configuring MemberHosts in Standalone Mode 40
Configuring MemberHosts as Peer 41
Configuring MemberHosts as Primary-Secondary 42
Syslog Load Balancing Routing Rule Example 44
File Load Balancing Routing Rule Example 48
Sample Configuration File 52
Starting LoadBalancer 56
Installing Load Balancer as a Service 56
Starting or Stopping the Load Balancer Service 58
Load Balancer Service Commands 59
Load Balancer Service-related Logs 59
Interpreting Logs 59
Chapter 3 — Load Balancer REST API 61
Configuration 61
Load Balancer API Reference 61
Retrieving a List of Routing Rules 61
API Reference 61
Sample Request 62
Sample Response 62
Retrieving Details of a Routing Rule 63
API Reference 63
Sample Request 63
Sample Response 63
Error Code 64
Creating a Routing Rule 64
API Reference 64
Content-Type 64
Sample Request 64
Sample Response 65
Error Codes 65
Status: 400 (Bad Request) 65
Sample Response 73
Error Code 74
Retrieving a List of Destinations 74
API Reference 74
Sample Request 74
Sample Response 74
Retrieving Details of a Destination 76
API Reference 76
Sample Request 76
Sample Response 76
Error Code 77
Creating a Destination 77
API Reference 77
Content-Type 77
Sample Request 77
Sample Response 78
Error Codes 79
Status: 400 (Bad Request) 79
Status: 400 (Bad Request) 79
Deleting a Destination 79
API Reference 79
Sample Request 79
Sample Response 79
Error Codes 80
Status: 400 (Bad Request) 80
Status: 400 (Bad Request) 80
Retrieving a List of Destination Pools 80
API Reference 80
Sample Request 80
Sample Response 81
Retrieving Details of a Destination Pool 81
API Reference 81
Sample Request 81
Sample Response 81
Error Code 82
Creating a Destination Pool 82
API Reference 82
Content-Type 82
Sample Request 82
Sample Response 82
Error Codes 83
Overview
ArcSight SmartConnector Load Balancer provides a “connector-smart” load balancing
mechanism by monitoring the status and load of SmartConnectors. Currently it supports
two types of event sources and SmartConnectors. One distributes the syslog input
stream to syslog connectors using TLS, TCP, or UDP protocol and the other downloads
files from a remote server and distributes them to the file-based connectors. Note that the
TLS protocol is supported for the SmartConnector for Syslog NG Daemon only.
Load Balancer ensures efficiency by distributing the load to a pool of SmartConnectors.
Load Balancer supports high availability configuration with active and standby nodes. It
distributes the events received to one or more SmartConnectors predefined in the
SmartConnector pool.
Load Balancer is aware of the following information for SmartConnectors defined as the
SmartConnector pool:
l Availability (up or down) – Load Balancer monitors SmartConnectors for availability.
Events are not forwarded to a SmartConnector if it is not running (down). Instead,
events are forwarded to the next available SmartConnector in the pool per the defined
load-balancing algorithm rules.
l SmartConnector Load - CPU usage, memory usage, and queue drop rate for events.
l Three routing policies — round robin, weighted round robin, and aggregation
preferred.
l Event batching (TCP only) for better aggregation at the destination connector and
better network throughput.
l Email notification for up/down status on member hosts and destination connectors.
l Load and health monitoring of connector destinations.
l Load Balancer runs either as a service or standalone application.
l TLS encryption is supported between devices and Load Balancer, Load Balancer and
SmartConnectors, or both.
l Load Balancer accepts connections from both TCP and UDP on the same port.
For TLS
For TLS, you must use a SmartConnector for Syslog NG with TLS enabled. TLS is
supported over TCP syslog connections. In the destination definition of the lbConfig.xml
file, change the protocol from tcp to tls. These are configurable per destination (listener).
Using TLS, incoming events will be processed automatically, as long as a self-signed
certificate is imported into any devices sending events to the Load Balancer. Also, you
must set up CA-signed certificates if you want to use HA; otherwise, you will have to
import the certificate for both Load Balancers into all of the devices.
Note: There are many well-known CAs and identifying the commonly used CAs
varies with country.
The above command creates the lbcert.jks file. Enter the certificate subject
information and then press Enter to use the same password used for the keystore
password.
3. Generate the CSR using the following command:
/root/ArcSightSCLoadBalancer/current/jre/bin/#./keytool -keystore
/root/ArcSightSCLoadBalancer/current/user/loadbalancer/lbcert.jks -
storepass changeit -certreq -alias mykeyX -file
/root/ArcSightSCLoadBalancer/current/user/loadbalancer/lbreq.csr
/root/ArcSightSCLoadBalancer/current/user/loadbalancer/lbcert.jks -
srcstorepass changeit -deststorepass changeit -srcstoretype JKS -
deststoretype PKCS12 -destkeystore
/root/ArcSightSCLoadBalancer/current/user/loadbalancer/LB.p12
Import the certificate files to the Syslog Daemon connector using the following
command:
/ArcSightSmartConnectors/current/jre/bin/#./keytool -importcert -file
/tmp/certnew.cer -storepass changeit -alias mykey -keystore
/root/ArcSightSmartConnectors/current/jre/lib/security/cacerts
Note: The Syslog Daemon connector can now send TLS events to Load Balancer.
For TCP
When the source is a syslog-based network process and configured to use TCP
protocol, the input stream is parsed into event lines and bundled into a batch. Then the
batch is distributed to one of the destinations in the destination pool.
For UDP
If a routing rule is configured to use UDP protocol, event batching does not happen.
Instead, each incoming event is distributed into one of the destinations configured in the
routing policy.
Routing Policies
Routing policies are a set of rules that define the data distribution from a source to a set
of destinations. Eligible sources are syslog servers or FTP servers. A destination pool
consists of one or more syslog or file connector destinations, all of the same type.
Connector types cannot be mixed within a single destination pool. Routing policies
define event or file distribution rules from a source to destination pool.
The routing policies supported in Load Balancer are:
l Round Robin: Distributes events, batches, or files to each available destination in the
destination pool in round robin fashion, beginning again at the start in a circular
manner. File-based load balancing supports only the Round Robin policy.
l Weighted Round Robin: Distributes events in a round-robin fashion, but sends more
events or batches to lightly loaded destinations.
l Aggregation Preferred: Events from the same source are sent to the same
destination until a threshold is reached. Then, it will switch the routing to another
destination. This routing policy is better suited if aggregation is enabled on connector
destinations where events are sent to the same destination until certain load
thresholds are met.
When configuring the routing rule, source and destination types must match. If the
source is TCP syslog, the connectors in the destination pool must be TCP syslog
connectors. Likewise, if the source is a file type, the connectors on the destination must
be file-based connectors that expect to handle files.
When the routing rule is configured with TCP protocol, events received from the same
source IP and port number are bundled into event batches. Event batching happens
when any of the following conditions are met: buffer size, number of events, or batching
interval. The bundled event batch, which is optional, is persisted by default on the hard
drive before it is sent to the destination connector in the ${ARCSIGHT_
HOME}/user/loadbalancer/lbdata/persistence/{source}directory of the
currently active node. Note that persisted event batches are not shared across the
member hosts and any unprocessed event batches awaiting bundling during the
shutdown are sent when Load Balancer starts up again.
System Requirements
The following section outlines the minimum system requirements for ArcSight
SmartConnector Load Balancer.
General Setup
The following section describes the software and platform requirements for all releases
of MicroFocus SmartConnector LoadBalancer.
Servers should be dedicated to load balancing (not running other applications.)
For high availability (HA), there should be two separate servers, one for the active or
primary LoadBalancer and another for standby or secondary Load Balancer. They will
share a Virtual IP address, so they should be in the same network location.
In addition, use the standard hardware required to deploy more than one
SmartConnector to create the pool of SmartConnectors. See the SmartConnector
documentation for details.
Hardware Requirements
l CPU: 2 CPU X 4 Cores each (2 x Intel E5620, quad core, 2.4 Ghz or better)
l RAM: 16 GB
l Disk: 60 GB
l Number of network interfaces—1 Dedicated Gig Ethernet interface
Note: To achieve better performance, use a server with higher system
specifications.
SmartConnector Requirements
l SmartConnector release 7.12.x or later
l Syslog daemon, Syslog NG daemon, and file-based SmartConnector
# adduser arcsight // Creates arcsight group and adds the user to the
group.
# sudo visudo
3. When using two machines for HA, create a network profile or Ethernet configuration
file on each machine. In the supported distributions of Linux, this file is usually
located in the /etc/sysconfig/network-scripts directory.
a. Go to the directory and verify that the file has the primary network interface
(usually ‘eth0’) configuration. The IPADDR value of this file should show the IP
address assigned to this machine. A similar configuration file needs to be created
for the virtual IP address.
b. Log on as a privileged administrator and go to the directory where the Ethernet
profiles are located.
# cd /etc/sysconfig/network-scripts
DEVICE=eth0:1
IPADDR=<virtual-ip-address> # for example, 10.0.0.0
ONBOOT=no
NM_CONTROLLED=no
ARPCHECK=no
BOOTPROTO=static
4. Verify the full path of the ifup command, usually /sbin/ifup. Make note of the
full path of the ifup command and Ethernet profile.
# sh ArcSightSCLoadBalancer-<build-number>.bin -i console
Preparing to install...
Launching installer...
Graphical installers are not supported by the VM. The console mode will be
used instead...
==========================================================================
===
--------------------------------------------------------------------------
---
==========================================================================
===
Introduction
------------
The ArcSight installer guides you through the installation of the ArcSight
ArcSight recommends that you quit all other programs before continuing
with
this installation.
Click the ‘Next’ button to proceed to the next window. If you want to
change something on a previous window, click the ‘Previous’ button. To
cancel this installation at any time, click the ‘Cancel’ button.
3. Type an absolute path or just press Enter to accept the default location.
Choose Install Folder
---------------------
Where to install:
4. Type the option number that corresponds with the shortcut or link to be created for
Load Balancer, if any. Press Enter.
Choose Link Location
5. Check the pre-installation summary before proceeding to the installation, then press
Enter to start the installation.
Pre-Installation Summary
------------------------
Product Name:
Install Folder:
/root/ArcSightSCLoadBalancer
Link Folder:
/root
Install Set:
Typical
6. Upon completion, the screen displays the location where Load Balancer is installed.
Installing...
-------------
[=================|=================|=================|=================]
[-----------------|-----------------|-----------------|-----------------]
==========================================================================
Installation Complete
---------------------
The core components of the ArcSight SmartConnector Load Balancer have been
/root/ArcSightSCLoadBalancer
The installer loads and the Introduction screen displays. Click Next.
3. Accept the default path or enter a new path in the “Where to install” field. Click Next.
Note: If you are logged in as root, the install path is
/root/ArcSightSCLoadBalancer.
4. Select your preferred option for creating a link to Load Balancer (the link folder).
Click Next.
5. Review installation information in the Pre-Installation Summary. Click Previous to
make changes or click Install to install Load Balancer.
6. Review the installation location and click Done to quit the installer.
Note: If there are any configuration errors, Load Balancer will not start. Instead, it
logs the configuration error messages at logs/loadbalancer.log. If this
happens, fix the issue associated with the error message and start Load Balancer
again.
Note: The host that starts first will overwrite the configuration file of the host that is
started second. If the Load Balancer host with an incomplete configuration file is
started first, the configuration can be lost. It is recommended to make a backup of the
completed configuration file before starting Load Balancer.
See "Syslog Load Balancing Routing Rule Example" on page 44 or "File Load
Balancing Routing Rule Example" on page 48 for more information.
a. Configure destinations and destination pools.
b. Configure sources.
c. Configure routing rules.
6. Configure the web server.
Note: The web server configuration settings must be configured. The function will
be enabled in a future release for remote management. The value can be
changed in the future, but a value must be entered to proceed.
7. Finish optional configuration. Refer to the Configuration Parameters and the Sample
Configuration File for more information. Other optional configuration settings
include:
l Notification
l Statistics Logging
8. Log on to the second host and do the following:
a. Go to $ARCSIGHT_HOME/config/loadbalancer and copy the
lbConfig.xml.template file to the $ARCSIGHT_
HOME/user/loadbalancer/ directory. Go to $ARCSIGHT_
HOME/user/loadbalancer directory and rename the file lbConfig.xml.
b. Edit member hosts in the lbConfig.xml file. Make sure that
memberIdentity is different from the one configured following step 4b.
c. The routing rule can be copied from the configuration file created in step 5 if
preferred, but it is not required because the configuration values will be
synchronized and persist after startup.
Note: If a firewall is enabled, Load Balancer member hosts may not be able to
discover each other. The configured port in memberHost must be open. Also,
the webserver needs to be configured to start Load Balancer.
9. Configure the firewall to open the ports on both hosts as needed to allow the two
participating hosts to detect each other. Configure the firewall rule as needed. The
configured ports include: memberHosts/vipPingPort, memberHost/port
and all listening ports configured in source and outbound ports configured for
destinations.
10. Start the destination connectors before you start Load Balancer to ensure that Load
Balancer can query the destination for connector health and load.
11. Go to the $ARCSIGHT_HOME directory on the primary or active host and start Load
Balancer.
# bin/arcsight loadbalancer
Note: The virtual IP address is obtained by the host where Load Balancer is first
started when Load Balancer is configured as peer. If Load Balancer is configured
as primary-secondary, the virtual IP address will be used by the primary host.
Note: If there are any configuration errors, Load Balancer will not start. Instead, it
logs the configuration error messages at logs/loadbalancer.log. If this
happens, fix the issue associated with the error message and start Load Balancer
again.
12. Log on to the secondary or passive host and start Load Balancer.
Configuration Parameters
Configure Load Balancer with the following parameters. They fall into several basic
categories:
l "memberIdentity " below
l "memberHosts" on the next page
l "notification " on page 30
l "routing" on page 30
l "statisticsLogging" on page 35
l "webServer" on page 36
l "globalParameters" on page 36
l "clusterconfigurations" on page 39
memberIdentity
memberHost in the memberHosts section defines the list of hosts that run Load
Balancer, where each member host must have a unique name. The value of
memberIdentity should be configured with the member host name that identifies the
current host.
Verify that:
l The valid name consists of alphanumeric characters without spaces.
l The matching names are found in memberHosts/memberHost/name.
l The host configuration is the configuration for the current node.
memberHosts
Configure the list of member hosts that participate in load balancing in this section. The
Load Balancer mode is determined by this configuration. Up to two member hosts are
allowed.
l vipAddress: Specifies the virtual IP address when running Load Balancer with two
hosts to enable HA mode.
l vipPingPort: Specifies the port used internally to detect the virtual IP binding
status. Change the value if this port is being used by another application. (Default port
is 9090.)
l memberHost: Configures the participating host where Load Balancer will be
installed and running.
o name: Specifies a unique name that identifies the host.
o address: Specifies the IP address of the participating host. Load Balancer must be
installed on this host.
o port: Specifies the port number used by the underlying library for HA support.
o isPrimary: Specifies the running mode for Load Balancer.
l Set this value to true to designate a primary host when Load Balancer is running
in primary-secondary mode.
l Only one host can be configured as the designated primary host.
l To run Load Balancers in peer mode, set this value to false for both member
hosts.
o vipBindCommand: Specifies the full command used to bind the virtual IP address
to this host. Prior to configuring this, the Ethernet connection virtual IP address
should have been configured. See "Configuring the Ethernet Connection" on
page 19 for details.
o In Linux, /sbin/ifup shows the Ethernet configuration.
o Be sure to use the absolute path when specifying the command. For example, if the
virtual IP address profile is located in:
/etc/sysconfig/network-scripts/ifcfg-eth0:1
specify:
sudo /sbin/ifup /etc/sysconfig/network-scripts/ifcfg-eth0:1.
Note: If Load Balancer is running as the root user, remove 'sudo'.
notification
The configuration information provided in this section sets up notifications when certain
events occur, such as when a member host goes up or down, or when a destination host
goes down or up.
l enable: Specifies whether the sending of notification is enabled or disabled. Set this
value to true to enable notifications.
l enabledNotification: Specifies the events for which notifications are sent.
Notifications are supported for the following types of events:
o MemberHostUp
o MemberHostDown
o DestinationUp
o DestinationDown
Notifications are sent only for specified supported events. For example, if only the
MemberHostDown event is listed, the notification will be sent only when one of the
configured hosts is down.
o event: Specifies the events for which a notification will be sent.
l name: Specifies the event name.
l message: Specifies the custom message. If undefined, a default message is
used.
l email: Configures the email sender, receiver, prefix, and SMTP server.
o prefix: Configures the value used to tag the notification message in the subject
line. When not configured, the subject will not have a prefix tag.
o recipients: Specifies a list of one or more valid email addresses of the
recipients. Separate each email address by a space.
o sender: Specifies the sender's email address.
o smtpServer: Specifies the SMTP server configuration. If this value is not
configured, the email will not be sent.
routing
Use this section to define the routing rules. Data will be received from the source
machine and distributed to the destinations in the destination pool. In routing
configuration, every name should be unique whether the name is used for source or
destination. The source cannot be referenced in more than one routing rule. The
destination can be referenced in more than one destination pool.
When configuring a routing rule, the incoming and outgoing protocol used for one
routing rule must be the same. For example, if routing rule A has source configured with
TCP, destinations in the destination pool in routing rule A must be configured with the
same TCP. TLS and TCP destinations can be mixed. If the source is configured with
UDP, destinations in the same routing rule must be configured with UDP. Note that TLS
cannot be mixed with UDP.
l sources: List of sources
o source: Specifies the data ingress.
l name: Specifies the unique name that identifies the source.
l type: Specifies the source type. Valid source types are file and syslog.
l Specify syslog if the events are fed from a syslog server or syslog connector.
l Specify file if files are to be distributed to a destination.
l protocol: Specifies the protocol that Load Balancer will use to listen:
l For syslog type, tls, tcp and udp are supported.
l For file type, ftp is supported.
l host: If the source is configured as a file type, specify the host IP address,
host name, or FQDN from which Load Balancer will download the files.
l port: Specifies the port used:
l For the syslog type, specify the port where Load Balancer will be listening. All
port numbers must be unique or there will be a binding error.
l For the file type, this specifies the FTP server port to which Load Balancer
connects to download files. Skip the configuration of this value if FTP server is
configured with the default port. (The default FTP port is 21.)
The following configuration values apply only to the file type source.
l path: Specifies the path where the files are located in the FTP server. This path
should be based off the FTP root directory. For example, if the FTP root directory
is configured as /ftp/pub and the files are located under /ftp/pub/source,
specify /source to this value.
l username: Specifies the user name used to log into the FTP server.
l password: Specifies the password configured for the user. The plaintext
password is encrypted and persisted during the Load Balancer startup.
l fileFilter: Specifies the Java-style regular expression used to filter the files to
download from the specified path. For example, .*log will filter the files with
names ending with ‘log’. To download the files with names starting with ‘Simple’
and ending with ‘log’, use Simple.*log.
Note: When uploading files to the source FTP server, be sure to use a
temporary file name and specify the filter in the fileFilter parameter to filter
out temporary files, otherwise Load Balancer may download an incomplete file.
After file upload is complete, rename the file to an original name.
l recursive: Specifies that Load Balancer downloads the file recursively from
subdirectories when set to true. By default, it is set to true.
Note: Load Balancer cannot handle a file larger than 1 GB – 1 byte
(approximately 1GB). When Load Balancer detects a file that exceeds the
maximum size, it logs an error message and continues to the next file.
can be skipped if the default ports are being used. The default FTP port is 21 and
SCP is 22.
The following configuration values are applicable only to file type source.
l username: Specifies the user name used to log into the FTP server or to run an
scp command.
l password: Specifies the password set for the user. This password will also be
encrypted when the Load Balancer starts up.
l path: Specifies the path to where the files will be moved. If protocol is configured
as ftp, this path should be relative to the FTP root directory. For scp, it should be
a full path.
l knownHostsFile: Specifies the file path of known hosts file if the destination
protocol is scp. This file should contain the host key used for SSH connections,
which is usually added to $HOME/.ssh/known_hosts on an initial SSH
connection to a specified host. Specify the path of default known hosts file or the
one created for Load Balancer testing, if it exists. Note that $ARCSIGHT_
HOME/user/loadbalancer is assumed to be the base directory if the path
does not start with "/". Currently ssh-rsa or ssh-dsa are accepted as valid
algorithms.
Specify the destination connector information using in the following section to enable
Load Balancer to communicate with the connector and to check the health and load.
Before configuring the following values, first go to the connector installation directory on
the machine where the connector is installed and ensure that remote management is
enabled and get the port number configured for remote management. Corresponding
property names for these two values in agent.properties are
remote.management.enabled and remote.management.listener.port. If
the destination is a file connector, the agent name— which is specified near the end of
the installation wizard process during the connector configuration step and persisted
into destination descriptor—will be needed. Note that agent name within the container
should be unique when more than one connector is configured within the container.
l additionalParameters/properties
l username: Specifies the user name used to log into the connectors. You can
optionally change the default remote management user name value whenever
the remote management user name of connectors is changed. To change the
user name, update the lbConfig.xml configuration file by adding the following
property under each destination:
<property key="username" value="newusername"/>
l password: Specifies the password set for the user. You can optionally change
the default remote management password value whenever the remote
management password of connectors is changed. The plaintext password is
encrypted and persisted during the Load Balancer startup. Note: The new
IMPORTANT:
On remote connector installations (destination connectors), turn on the remote
management enabled flag. In the user/agent/agents.properties file,
add remote.management.enabled=true. Do this before starting the
connectors.
statisticsLogging
l logInterval: Specifies the statistics logging interval in milliseconds. By default,
the statistics are logged every minute (60,000 ms).
webServer
Note: This configuration is required per Load Balancer installation now and will be
enabled in a future release
l httpsPort: Specify the HTTPS port. By default, it uses 8443 as the listening port.
globalParameters
l batch.buffersize: Specifies the maximum buffer size in bytes that can be used
for the batch criteria. Load Balancer creates an event batch right before the total event
size limit is reached.
l batch.eventcount: Specifies the total number of events that can be used as the
batch cut-off criteria.
l batch.timeout: Specifies the timeout in milliseconds. A new batch will be created
if the time reaches this value after the last batching and at least one event is waiting in
the buffer.
Note: Load Balancer applies these three batch parameters together using
whichever condition is met first.
clusterconfigurations
hazelcast.max.no.heartbeat.seconds: Specifies the timeout interval in
seconds, for a node to assume that it is not reachable. The default value is: 300
seconds. If any event loss is observed during the fail-over, you can reduce this timeout
interval for a faster fail-over.
Example:
<hazelCastParameters>
<properties>
<property key="hazelcast.max.no.heartbeat.seconds" value="60"/>
</properties>
</hazelCastParameters>
</memberHosts>
<memberIdentity>lb-standalone</memberIdentity>
Note: vipBindCommand and vipUnbidCommand have sudo in the command because Load Balancer is not
running as root.
</memberHosts>
</memberHosts>
<memberIdentity>lb-center-1</memberIdentity>
</memberHosts>
</memberHosts>
<memberIdentity>lb-center-2</memberIdentity>
Note: vipBindCommand and vipUnbidCommand have sudo in the command because Load Balancer is not
running as root.
Note: vipBindCommand and vipUnbidCommand do not have sudo in the command because Load Balancer
is running as root.
</memberHosts>
</memberHosts>
<memberIdentity>lb-primary</memberIdentity>
</memberHosts>
</memberHosts>
<memberIdentity>lb-secondary</memberIdentity>
<routing>
<destinationPools>
<destinationPool name="tcp-syslog-connectors"
destinations="tcp-syslog-1,tcp-syslog-2,tcp-syslog-3"/>
</destinationPools>
<destinations>
port="8514" protocol="tcp">
<additionalParameters type="connector">
<properties>
</properties>
</additionalParameters>
</destination>
port="8514" protocol="tcp">
<additionalParameters type="connector">
<properties>
</properties>
</additionalParameters>
</destination>
port="8514" protocol="tcp">
<additionalParameters type="connector">
<properties>
</properties>
</additionalParameters>
</destination>
</destinations>
<routingRules>
destinationPoolName="tcp-syslog-connectors"
routingPolicy="WeightedRoundRobin" enabled="true">
<additionalParameters type="listener">
<properties>
</properties>
</additionalParameters>
</routingRule>
</routingRules>
<sources>
protocol="tcp"/>
</sources>
</routing>
Note: When uploading files to the source FTP server, be sure to use a temporary file name and specify the filter in
the fileFilter parameter to filter out temporary files. After file upload is complete, rename the file to an original
name.
Note: The agent name for file connectors is specified in this configuration.
<routing>
<destinationPools>
<destinationPool name="file-connectors"
destinations="file-connector-1,file-connector-2,file-connector-3"/>
</destinationPools>
<destinations>
username="admin" password="password"
knownHostsFile="/home/arcsight/.ssh/known_hosts">
<additionalParameters type="connector">
<properties>
</properties>
</additionalParameters>
</destination>
username="admin" password="password"
knownHostsFile="/home/arcsight/.ssh/known_hosts">
<additionalParameters type="connector">
<properties>
</properties>
</additionalParameters>
</destination>
username="admin" password="password"
knownHostsFile="/home/arcsight/.ssh/known_hosts">
<additionalParameters type="connector">
<properties>
</properties>
</additionalParameters>
</destination>
</destinations>
<routingRules>
destinationPoolName="file-connectors" routingPolicy="RoundRobin"
enabled="true"/>
</routingRules>
<sources>
password="OBFUSCATE.1:B8R3Ts5XXui0aBjFn1Js7Q=="
moveToDirectory=".done" fileFilter="SG_main.*log"
</sources>
</routing>
Note: This is a sample configuration file with passwords obfuscated since it was captured after Load Balancer
started.
<lbConfiguration>
<memberHosts vipAddress="10.0.0.0" vipPingPort="9090">
<memberHost name="primary-node" host="10.0.0.0" port="7701" isPrimary="false" vipBindCommand="sudo
/sbin/ifup /etc/sysconfig/network-scripts/ifcfg-eth0:1" vipUnbindCommand="sudo /sbin/ifdown
/etc/sysconfig/network-scripts/ifcfg-eth0:1"/>
<memberHost name="secondary-node" host="10.0.0.0" port="7701" isPrimary="false"
</additionalParameters>
</destination>
<destination name="tcp-syslog-2" type="syslog" host="10.0.0.0" port="8514" protocol="tcp">
<additionalParameters type="connector">
<properties>
<property key="remote.management.listener.port" value="9001"/>
</properties>
</additionalParameters>
</destination>
<destination name="bc-connector-1" type="file" path="/opt/ArcSightSmartConnectors/bc-connector/
</properties>
</additionalParameters>
</destination>
</destinations>
<routingRules>
<routingRule name="syslog-tcp-rule" sourceName="syslog-tcp" destinationPoolName="tcp-syslog-
connectors" routingPolicy="WeightedRoundRobin" enabled="true">
<additionalParameters type="listener">
<properties>
<property key="syslog.address.prepend.mode" value="scan"/>
</properties>
</additionalParameters>
</routingRule>
</routingRules>
<sources>
<source name="syslog-tcp" type="syslog" host="10.0.0.0" port="8002" protocol="tcp"/>
<source name="bc-ftp-server" type="file" path="bc-files" host="10.0.0.0" protocol="ftp"
username="arcsight" password="OBFUSCATE.1:y05cvjSnFlVybZFBBEOHiQ==" recursive="true" flatten="true"
passive="true" localWorkDirectory="/tmp" fileFilter=".*log"/>
</sources>
</routing>
<statisticsLogging logInterval="60000" />
<webServer httpsPort="8443" certificatePath="loadbalancer.cer" keystorePath="loadbalancer.p12"/>
</lbConfiguration>
Note: This can go anywhere in the xml but not in the middle of another
parameter.
Note: If you are not the root user, an error message displays when invoking
service tool:
# bin/arcsight loadbalancer_service
Assuming ARCSIGHT_HOME: /home/arcsight/beta1/current
Assuming JAVA_HOME: /home/arcsight-1/beta1/current/jre
Running as root
4. (Optional) To give the service a different name, use the -sn switch during service
installation. The line below shows the service name changed to arc_
loadbalancer. (The arc_ is added before all services names.) If no other name
is suggested, the default service name is ‘connlb’.
# bin/arcsight loadbalancer_service -sn loadbalancer -i
5. Use the -sd switch to give a different service description. For example, change the
service description to ‘LBService’:
# bin/arcsight loadbalancer_service -i -sd LBService
6. Using the service description change shown step 5, the status command displays
as follows:
# service arc_connlb status
Running as root
or
service arc_connlb start
Note: If you changed the default service name (connlb), use that name in place
of ‘connlb’.
or
service arc_connlb stop
Interpreting Logs
Statistics are divided by:
l Routing rule—each rule is on its own line
l Locations—from sources or to destinations
l Metrics—bytes, events, and batches
l Time units—average per second SLC, total SLC, and total since startup
For each routing rule, the combined totals from every source are listed first, followed by
the combined totals to every destination, and the individual statistics per destination.
Overall statistics:
2015-08-24 08:43:25,556 [INFO][statisticsLogging][com.arcsight.lb.stats.StatLoggingTask][run] -
Configuration
This section describes how to configure Load Balancer using Rest API. The following
configurations must be done in the same sequence:
1. Source
2. Destination
3. Destination pools
4. Routing rules
When Load Balancer is configured to run in HA mode, you can execute REST APIs
either using the virtual IP or the actual IP address of the primary/active node. Requests
to the secondary/standby node will not be successful.
The following element is unique to each node. You must add it to both primary and
secondary nodes.
<webServer httpsPort="8443" certificatePath="config/loadbalancer.cer"
keystorePath="config/loadbalancer.p12"/>
API Reference
GET /config/routingRules
Sample Request
URI: GET https://127.0.0.1:8443/config/routingRules
Sample Response
Success Code: 200 (OK)
Body:
[
{
"name": "syslog-tcp-rule",
"sourceName": "syslog-tcp",
"destinationPoolName": "tcp-syslog-connectors",
"routingPolicy": "RoundRobin",
"enabled": true,
"additionalParameters": {
"type": "listener",
"properties": {
"property": [
{
"key": "syslog.address.prepend.mode",
"value": "scan"
}
]
}
}
},
{
"name": "syslog-udp-rule",
"sourceName": "syslog-udp",
"destinationPoolName": "udp-syslog-connectors",
"routingPolicy": "WeightedRoundRobin",
"enabled": true
}
]
API Reference
GET /config/routingrules/routingrule/<name of the routing rule>
Sample Request
URI: GET https://127.0.0.1:8443/config/routingrules/routingrule/syslog-tcp-
rule
Sample Response
Status: 200 (OK)
Body:
{
"name": "syslog-tcp-rule",
"sourceName": "syslog-tcp",
"destinationPoolName": "tcp-syslog-connectors",
"routingPolicy": "RoundRobin",
"enabled": true,
"additionalParameters": {
"type": "listener",
"properties": {
"property": [
{
"key": "syslog.address.prepend.mode",
"value": "scan"
}
]
}
}
}
Error Code
Status: 400 (Bad Request)
Body:
[
{
"errorSource": "Configuration",
"description": "Routing rule not found, routing rule=[syslog-tcp-rule-non-
existent]"
}
]
Reason: This error occurs when you try to retrieve a routing rule that is not present.
API Reference
POST /config/routingrules/routingrule
Content-Type
application/json
Sample Request
URI: POST https://127.0.0.1:8443/config/routingrules/routingrule
Body:
{
"name": "syslog-udp-rule",
"sourceName": "syslog-udp",
"destinationPoolName": "udp-syslog-connectors",
"routingPolicy": "WeightedRoundRobin",
"enabled": false
Sample Response
Status: 201 (Created)
Body:
{
"name": "syslog-udp-rule",
"sourceName": "syslog-udp",
"destinationPoolName": "udp-syslog-connectors",
"routingPolicy": "WeightedRoundRobin",
"enabled": false
}
Error Codes
Status: 400 (Bad Request)
Body:
[
{
"errorSource": "Configuration",
"description": "Routing rule not found, routing rule=[syslog-tcp-rule-non-
existent]"
}
]
Reason: This error occurs when the routing rule in the request contains a source name
that is already referred by some other routing rule.
Reason: This error occurs when the routing rule in the request contains a name that is
already present in some other routing rule.
Reason: This error occurs when the destination pool mentioned in the request is not
present in lbConfig.xml.
Reason: This error occurs when the protocol of the source is not similar to the protocol
of the destination used in the destination pool of the request.
Reason: This error occurs when the routing policy mentioned in the request is not one
these: RoundRobin, AggregationPreferred, and WeightedRoundRobin.
API Reference
DELETE /config/routingrules/routingrule/<name of the routing rule to be
deleted>
Sample Request
URI: DELETE https://127.0.0.1:8443/config/routingrules/routingrule/syslog-
udp-rule1
Sample Response
Status: 200 (OK)
Body:
{
"name": "syslog-udp-rule",
"sourceName": "syslog-udp",
"destinationPoolName": "udp-syslog-connectors",
"routingPolicy": "WeightedRoundRobin",
"enabled": false
}
Error Codes
Status: 400 (Bad Request)
Body:
[
{
"errorSource": "Configuration",
"description": "Routing rule not found, routing rule=[syslog-udp-rule1]"
}
]
Reason: This error occurs when you try to delete a routing rule that is not present.
Reason: This error occurs when you try to delete a routing rule that is in the enabled
state.
API Reference
PUT /config/routingrules/routingrule/<name of the rule to be enabled>/enable
Sample Request
URI: PUT https://127.0.0.1:8443/config/routingrules/routingrule/syslog-udp-
rule/enable
Sample Response
Status: 200 (OK)
Body:
{ "name": "syslog-udp-rule", "sourceName": "syslog-udp",
"destinationPoolName": "udp-syslog-connectors", "routingPolicy":
"WeightedRoundRobin", "enabled": false }
Error Code
Status: 400 (Bad Request)
Body:
[
{
"errorSource": "Configuration",
"description": "Routing rule is already Enabled: routing rule=[syslog-udp-
rule]"
}
]
Reason: This error occurs when you try to enable a routing rule that is in the enabled
state.
API Reference
PUT /config/routingrules/routingrule/<name of the rule to be
disabled>/disable
Sample Request
URI: PUT https://127.0.0.1:8443/config/routingrules/routingrule/syslog-udp-
rule/disable
Sample Response
Status: 200 (OK)
Body:
{ "name": "syslog-udp-rule", "sourceName": "syslog-udp",
"destinationPoolName": "udp-syslog-connectors", "routingPolicy":
"WeightedRoundRobin", "enabled": true }
Error Code
Status: 400 (Bad Request)
Body:
[
{
"errorSource": "Configuration",
"description": "Routing rule is already disabled: routing rule=[syslog-udp-
rule]"
}
Reason: This error occurs when you try to disable a routing rule that is already in the
disabled state.
API Reference
GET /config/sources
Sample Request
URI: GET https://127.0.0.1:8443/config/sources
Sample Response
Success Code: 200 (OK)
Body:
[
{
"name": "syslog-tcp",
"type": "SYSLOG",
"protocol": "tcp",
"port": 512
},
{
"name": "syslog-udp",
"type": "SYSLOG",
"protocol": "udp",
"port": 513
}
]
API Reference
GET /config/sources/source/<name of the source>
Sample Request
URI: GET https://127.0.0.1:8443/config/sources/source/syslog-tcp
Sample Response
Success Code: 200 (OK)
Body:
{
"name": "syslog-tcp",
"type": "SYSLOG",
"protocol": "tcp",
"port": 512
}
Creating a Source
This method adds a new source.
API Reference
POST /config/sources/source
Content-Type
application/json
Sample Request
URI: POST https://127.0.0.1:8443/config/sources/source
Body:
{
"name": "syslog-tcp",
"type": "SYSLOG",
"protocol": "tcp",
"port": 512
}
Sample Response
Status: 201 (Created)
Bosy:
{
"name": "syslog-tcp",
"type": "SYSLOG",
"protocol": "tcp",
"port": 512
}
Error Codes
Status: 400 (Bad Request)
Body:
[
{
"errorSource": "Configuration",
"description": "Duplicate name found for Source=[syslog-tcp]"
},
{
"errorSource": "Configuration",
"description": "Duplicate port found from Source=[syslog-tcp]: Port=[512]"
}
]
Reason: This error occurs when the source already exists and some other source has
already used the port provided in the request.
{
"errorSource": "Configuration",
"description": "Duplicate port found from Source=[syslog-tcp2]: Port=[512]"
}
]
Reason: This error occurs when the port mentioned in a new source is already
associated with an existing source.
Reason: This error occurs when the value of the field type is incorrect.
Deleting a Source
This method deletes the selected source.
API Reference
DELETE /config/sources/source/<name of the source>
Sample Request
URI: DELETE https://127.0.0.1:8443/config/sources/source/syslog-tcp
Sample Response
Status: 200 (OK)
Body:
{
"name": "syslog-tcp",
"type": "SYSLOG",
"protocol": "tcp",
"port": 512
}
Error Code
Status: 400 (Bad Request)
Body:
[
{
"errorSource": "Configuration",
"description": "The source=[syslog-tcp] is being referenced by Routing Rule=
[[syslog-tcp-rule]]"
}
]
Reason: This error occurs when the source you are trying to delete is referenced by an
existing routing rule.
API Reference
GET /config/destinations
Sample Request
URI: GET https://127.0.0.1:8443/config/destinations
Sample Response
Success Code: 200 (OK)
Body:
[
{
"name": "syslog-tcp-connector-1",
"type": "SYSLOG",
"host": "10.0.0.0",
"protocol": "tcp",
"additionalParameters": {
"type": "connector",
"properties": {
"property": [
{
"key": "remote.management.listener.port",
"value": "9001"
}
]
}
},
"port": 514
},
{
"name": "syslog-udp-connector-1",
"type": "SYSLOG",
"host": "10.0.0.0",
"protocol": "udp",
"additionalParameters": {
"type": "connector",
"properties": {
"property": [
{
"key": "remote.management.listener.port",
"value": "9001"
}
]
}
},
"port": 514
}
]
API Reference
GET /config/destinations/destination/<destination-name>
Sample Request
URI: GET https://127.0.0.1:8443/config/destinations/destination/syslog-tcp-
connector-1
Sample Response
Status: 200 (OK)
Body:
{
"name": "syslog-tcp-connector-1",
"type": "SYSLOG",
"host": "10.0.0.0",
"protocol": "tcp",
"additionalParameters": {
"type": "connector",
"properties": {
"property": [
{
"key": "remote.management.listener.port",
"value": "9001"
}
]
}
},
"port": 514
Error Code
Status: 400 (Bad Request)
Body:
[
{
"errorSource": "Configuration",
"description": "Destination not found, destination=[syslog-tcp-connector-2]"
}
]
Reason: This error occurs when you try to retrieve a destination that is not present.
Creating a Destination
This method adds a new destination.
API Reference
POST /config/destinations/destination
Content-Type
application/json
Sample Request
URI: POST https://127.0.0.1:8443/config/destinations/destination
Body:
{
"name": "syslog-udp-connector-1",
"type": "SYSLOG",
"host": "10.0.0.0",
"protocol": "udp",
"additionalParameters": {
"type": "connector",
"properties": {
"property": [
{
"key": "remote.management.listener.port",
"value": "9001"
}
]
}
},
"port": 514
}
Sample Response
Status: 201 (Created)
Body:
{
"name": "syslog-udp-connector-1",
"type": "SYSLOG",
"host": "10.0.0.0",
"protocol": "udp",
"additionalParameters": {
"type": "connector",
"properties": {
"property": [
{
"key": "remote.management.listener.port",
"value": "9001"
}
]
}
},
"port": 514
}
Error Codes
Status: 400 (Bad Request)
Body:
[ { "errorSource": "Configuration", "description": "Duplicate name found for
Destination=[syslog-tcp-connector-1]" } ]
Reason: This error occurs when an existing destination is already using the name of the
destination in the request.
Reason: This error occurs when the combination of hostname, port, and protocol used
in a new request is similar to an existing destination.
Deleting a Destination
This method deletes the selected destination.
API Reference
DELETE /config/destinations/destination/<name of the destination to be
deleted>
Sample Request
URI: DELETE https://127.0.0.1:8443//config/destinations/destination/syslog-
udp-connector-1
Sample Response
Status: 200 (OK)
Body:
{ "name": "syslog-udp-connector-1", "type": "SYSLOG", "host": "10.0.0.0",
"protocol": "udp", "additionalParameters": { "type": "connector",
"properties": { "property": [ { "key": "remote.management.listener.port",
"value": "9001" } ] } }, "port": 514 }
Error Codes
Status: 400 (Bad Request)
Body:
[
{
"errorSource": "Configuration",
"description": "Destination not found, destination=[syslog-udp-connector-1]"
}
]
Reason: This error occurs when the destination that you are trying to delete is not
present.
Reason: This error occurs when the destination you are trying to delete is present in a
destination pool.
API Reference
GET /config/destinationpools
Sample Request
URI: GET https://127.0.0.1:8443/config/destinationpools
Sample Response
Success Code: 200 (OK)
Body:
[
{
"name": "syslog-tcp-connectors",
"destinations": "syslog-tcp-connector-1,syslog-tcp-connector-2"
},
{
"name": "syslog-tcp-connectors2",
"destinations": "syslog-tcp-connector-1"
}
]
API Reference
GET /config/destinationpools/destinationpool/<name of the destination pool>
Sample Request
URI: GET https://127.0.0.1:8443//config/destinationpools/destinationpool/tcp-
syslog-connectors
Sample Response
Status: 200 (OK)
Body:
{
"name": "syslog-tcp-connectors",
"destinations": "syslog-tcp-connector-1"
}
Error Code
Status: 400 (Bad Request)
Body:
[
{
"errorSource": "Configuration",
"description": "Destination pool not found, destination pool=[tcp-syslog-
connectors-non-existent]"
}
]
Reason: This error occurs when you try to retrieve a destination pool that is not present.
API Reference
POST /config/destinationpools/destinationpool
Content-Type
application/json
Sample Request
URI: POST https://127.0.0.1:8443/config/destinationpools/destinationpool
Body:
{
"name": "syslog-udp-connectors",
"destinations": "syslog-udp-connector-1"
}
Sample Response
Status: 201 (Created)
Body:
{
"name": "syslog-udp-connectors",
"destinations": "syslog-udp-connector-1"
}
Error Codes
Status: 400 (Bad Request)
Body:
[
{
"errorSource": "Configuration",
"description": "Duplicate name found for Destination Pool=[syslog-tcp-
connectors]"
}
]
Reason: This error occurs when the name of the destination pool you are trying to
create is already present for some other destination pool.
Reason: This error occurs when the destination mentioned in the request is not present.
Reason: This error occurs when the destinations' protocols present in the request are
not same.
API Reference
DELETE /config/destinationpools/destinationpool/<name of the destination pool
to be deleted>
Sample Request
URI: DELETE
https://127.0.0.1:8443/config/destinationpools/destinationpool/syslog-udp-
connectors
Sample Response
Status: 200 (OK)
Body:
{
"name": "syslog-udp-connectors",
"destinations": "syslog-udp-connector-1"
}
Error Codes
Status: 400 (Bad Request)
Body:
[
{
"errorSource": "Configuration",
"description": "Destination pool not found, destination pool=[syslog-udp-
connectors1]"
}
]
Reason: This error occurs when you try to delete a destination pool that is not present.
API Reference
PUT /config/destinationpools/destinationpool/<name of the destination
pool>/add/<name of the destination to be deleted>
Sample Request
URI: PUT
https://127.0.0.1:8443/config/destinationpools/destinationpool/syslog-tcp-
connectors/add/syslog-tcp-connector-2
Sample Response
Status: 200 (OK)
Body:
{
"name": "syslog-tcp-connectors",
"destinations": "syslog-tcp-connector-1,syslog-tcp-connector-2"
}
Error Codes
Status: 400 (Bad Request)
Body:
[
{
"errorSource": "Configuration",
"description": "Duplicate destination found from the destination pool:
destination pool=[syslog-tcp-connectors], destination=[syslog-tcp-connector-
1]"
}
]
Reason: This error occurs when the destination pool already contains the destination
you are trying to insert.
Reason: This error occurs when the destination you are trying to insert uses a different
protocol than that of the existing destination in the same destination pool.
Status: 400 (Bad Request)
Body:
[
{
"errorSource": "Configuration",
"description": "No such destination pool found: destination pool=
[destination-pool-1]"
}
]
Reason: This error occurs when the destination pool is not present.
API Reference
DELETE /config/destinationpools/destinationpool/<name of the destination
pool>/delete/<name of the destination to be deleted>
Sample Request
URI: DELETE
https://127.0.0.1:8443/config/destinationpools/destinationpool/syslog-tcp-
connectors/delete/syslog-tcp-connector-1
Sample Response
Status: 200 (OK)
Body:
{
"name": "syslog-tcp-connectors",
"destinations": ""
}
Error Codes
Status: 400 (Bad Request)
Body:
[
{
"errorSource": "Configuration",
"description": "No such destination pool found: destination pool=
[destination-pool-1]"
}
]
Reason: This error occurs when the destination pool is not present.
N
o. Error Messages
l Description: This error occurs when you call REST API using the IP address of the node that was
not active during the time of the call.
2 l Status: 405 (Method not allowed)
l Body: NA
l Description: This error occurs when you do not pass the expected method type.
N
o. Error Messages
l Description: This error occurs when a comma is missing between two fields in the JSON object of
the request body.
4 l Status: 404 (Not Found)
l Body: NA
l Description: This error occurs when the API name present in the URI is invalid.
5 l Status: NA
l Body: No response or could not get any response.
l Description: This error occurs when the IP address or the hostname or the port number in the URI is
not correct.
Data
Variable Name Type Description
2) This variable includes all CPUs (and cores, and hardware threads) added
together. For example, if the connector machine has a total of 4 hardware threads (1
socket, 2 cores, with 2 hardware threads per core), and only one hardware thread is
at 100% usage while the other 3 are at 0% usage, this will be reported as 25% load.
There is no way to distinguish this from all 4 hardware threads being at 25% load.
3) To use Linux destinations based solely on CPU load, unless they are dropping
events from their queue, use: cpuLoad + queueDrops * 100
>
<!-- Standalone mode still requires valid port number to be specified. --
>
<!-- If Load Balancer is running as non-root, add Load Balancer user to sudoer list and --
>
<!-- prefix 'vipBindCommand' and 'vipUnbindCommand' with 'sudo' such as 'sudo /sbin/ifup..'. --
>
<memberHost name="primary-node" host="10.0.0.0" port="6702" isPrimary="true"
vipBindCommand="/sbin/ifup /etc/sysconfig/network-scripts/ifcfg-eth0:1" vipUnbindCommand="/sbin/ifdown
/etc/sysconfig/network-scripts/ifcfg-eth0:1"/>
</memberHosts>
<!-- To get an email notification when the Load Balancer member host is down or up, or when --
>
<!-- the destination is down or up, set enable to 'true' and configure the email section. --
>
<notification enable="true">
<enabledNotification>
<event name="MemberHostUp" message="Member node is up." />
<event name="MemberHostDown" message="Member node is down." />
<event name="DestinationUp" message="Destination is up." />
<event name="DestinationDown" message="Destination is down." />
</enabledNotification>
<email>
<!-- Create a prefix for the subject line. -->
<prefix>[Load Balancer]</prefix>
<!-- Separate multiple recipients with a space. -->
<recipients>jane.doe@abc.com john.doe@abc.com</recipients>
<sender>admin@abc.com</sender>
<smtpServer>smtp.abc.com</smtpServer>
</email>
</notification>
<routing>
<!-- All names in the routing section must be unique. -->
<destinationPools>
<destinationPool name="tcp-syslog-connectors" destinations="syslog-connector-1,syslog-
connector-2"/>
<destinationPool name="udp-syslog-connectors" destinations="syslog-connector-3,syslog-
connector-4"/>
<destinationPool name="tls-syslog-connectors" destinations="syslog-connector-5,syslog-
connector-6"/>
<destinationPool name="file-connectors" destinations="file-connector-1,file-connector-2"/>
</destinationPools>
<destinations>
<!-- Examples of configuring TCP connectors as destinations. -->
<!-- 'host' is the host address where the tcp connector is running and 'port' is
connector's listening -->
<!-- port which can be found from agent.properties. 'tcp' corresponds to 'Raw TCP' in
agent.properties. -->
<destination name="syslog-connector-1" type="syslog" host="10.0.0.0" port="513"
protocol="tcp">
<!-- Specify the connection configuration value here with key and matching value. Load
Balancer need -->
<!-- the information to perform the connector health check and to obtain the load
information. -->
<additionalParameters type="connector">
<properties>
<property key="remote.management.listener.port" value="
{remote.management.listener.port from agent.properties}"/>
<!-- Prefer to send fewer events to this Connector by counting its CPU load as
twice as busy. -->
<property key="load.expression" value="cpuLoad * 2"/>
</properties>
</additionalParameters>
</destination>
<destination name="syslog-connector-2" type="syslog" host="10.0.0.0" port="513"
protocol="tcp">
<additionalParameters type="connector">
<properties>
<property key="remote.management.listener.port" value="
{remote.management.listener.port from agent.properties}"/>
</properties>
</additionalParameters>
</destination>
<!-- Examples of configuring UDP connectors as destinations. -->
<destination name="syslog-connector-3" type="syslog" host="10.0.0.0" port="514"
protocol="udp">
<additionalParameters type="connector">
<properties>
<property key="remote.management.listener.port" value="
{remote.management.listener.port from agent.properties}"/>
</properties>
</additionalParameters>
</destination>
<destination name="syslog-connector-4" type="syslog" host="10.0.0.0" port="514"
protocol="udp">
<additionalParameters type="connector">
<properties>
<!-- Supported protocols on the destination side are ftp and scp. Each protocol requires a
different -->
<!-- set of configuration values as shown in the examples below. Plaintext passwords are
persisted as -->
<!-- encrypted value when Load Balancer starts.
-->
<!-- In order to use 'scp' protocol, file that has ssh host key should be provided to
'knownHostsFile'. -->
<!-- Load Balancer does not populate this file automatically. In order to obtain the host
key, ssh to -->
<!-- the destination manually and specify the full path of the system default known_hosts
file or copy -->
<!-- the file to another location and give that path to 'knownHostsFile'.
-->
<destination name="file-connector-1" type="file" path="/opt/connector-1/input"
host="10.0.0.0" protocol="scp" username="admin" password="password" knownHostsFile="/root/.ssh/known_
hosts">
<!-- Configure the information about this connector before starting Load Balancer.
-->
<additionalParameters type="connector">
<properties>
<!-- If the destination connector is file-based connector, specify the
following two -->
<!-- values so that Load Balancer can handshake with the connector.
-->
<property key="remote.management.listener.port" value="
{remote.management.listener.port from agent.properties}"/>
<property key="agent.name" value="{agent name configured for the destination in
the final stage of agent setup}"/>
</properties>
</additionalParameters>
</destination>
<!-- Configure the port if FTP server is configured with a non-default port. Default port
21 is used if not specified. -->
<!-- 'host' is the host address of FTP server and 'username' and 'password' is the user
credential who has access to -->
<!-- FTP server. Plaintext password is encrypted and persisted to this file as soon as Load
Balancer starts. -->
<destination name="file-connector-2" type="file" host="10.0.0.0" protocol="ftp"
username="admin" password="password" path="landing">
<additionalParameters type="connector">
<properties>
<property key="remote.management.listener.port" value="
{remote.management.listener.port from agent.properties}"/>
<property key="agent.name" value="{agent name configured for the destination in
the final stage of agent setup}"/>
</properties>
</additionalParameters>
</destination>
</destinations>
<routingRules>
<!-- Supported routing policies are RoundRobin, WeightedRoundRobin, and
AggregationPreferred. -->
<routingRule name="syslog-tcp-rule" sourceName="syslog-tcp" destinationPoolName="tcp-
syslog-connectors" routingPolicy="RoundRobin" enabled="true">
<additionalParameters type="listener">
<properties>
<!-- Scan incoming messages to determine if there is a hostname or address
<!-- Load Balancer can run in HA mode: two hosts can run primary-secondary or peer. -->
<!-- (1) To run Load Balancer as primary-secondary, configure two memberHosts and -->
<!-- for one of the hosts, and set isPrimary to 'true'. -->
<!-- (2) To run Load Balancer as peer, configure two memberHosts and set isPrimary to -->
<!-- 'false' for both. -->
<!-- 'vipAddress' is the virtual IP addres that will be shared between two member hosts to -->
<!-- handle seamless failover of member host. 'vipPingPort' is internally used to check if -->
<!-- VIP address is still bound to one of the member hosts for continuous event collection. -->
<!-- Specify any unused port to 'vipPingPort'. -->
<memberHosts vipAddress="10.0.0.0" vipPingPort="9090">
<!-- 'host' is the host address where Load Balancer is installed and 'port' is internally -->
<!-- used to communicate with another Load Balancer to detect the health for HA support. -->
<!-- If Load Balancer is running as non-root, add Load Balancer user to sudoer list and --
>
<!-- prefix 'vipBindCommand' and 'vipUnbindCommand' with 'sudo' such as 'sudo /sbin/ifup..'. --
>
<memberHost name="primary-node" host="10.0.0.0" port="6702" isPrimary="true"
vipBindCommand="/sbin/ifup /etc/sysconfig/network-scripts/ifcfg-eth0:1" vipUnbindCommand="/sbin/ifdown
/etc/sysconfig/network-scripts/ifcfg-eth0:1"/>
<memberHost name="secondary-node" host="10.0.0.0" port="6702" isPrimary="false"
vipBindCommand="/sbin/ifup /etc/sysconfig/network-scripts/ifcfg-eth0:1" vipUnbindCommand="/sbin/ifdown
/etc/sysconfig/network-scripts/ifcfg-eth0:1"/>
</memberHosts>
<!-- To get an email notification when the Load Balancer member host is down or up, or when -->
<!-- the destination is down or up, set enable to 'true' and configure the email section. -->
<notification enable="true">
<enabledNotification>
<event name="MemberHostUp" message="Member node is up." />
<event name="MemberHostDown" message="Member node is down." />
<event name="DestinationUp" message="Destination is up." />
<event name="DestinationDown" message="Destination is down." />
</enabledNotification>
<email>
<!-- Create a prefix for the subject line. -->
<prefix>[Load Balancer]</prefix>
<!-- Separate multiple recipients with a space. -->
<recipients>jane.doe@abc.com john.doe@abc.com</recipients>
<sender>admin@abc.com</sender>
<smtpServer>smtp.abc.com</smtpServer>
</email>
</notification>
<routing>
<!-- All names in the routing section must be unique. -->
<destinationPools>
<destinationPool name="tcp-syslog-connectors" destinations="syslog-connector-1,syslog-
connector-2"/>
<destinationPool name="udp-syslog-connectors" destinations="syslog-connector-3,syslog-
connector-4"/>
<destinationPool name="tls-syslog-connectors" destinations="syslog-connector-5,syslog-
connector-6"/>
<additionalParameters type="connector">
<properties>
<property key="remote.management.listener.port" value="
{remote.management.listener.port from agent.properties}"/>
</properties>
</additionalParameters>
</destination>
<destination name="syslog-connector-6" type="syslog" host="10.0.0.0" port="515"
protocol="tls">
<additionalParameters type="connector">
<properties>
<property key="remote.management.listener.port" value="
{remote.management.listener.port from agent.properties}"/>
</properties>
</additionalParameters>
</destination>
<!-- Examples of configuring file-based connectors as destination.
-->
<!-- Supported protocols on the destination side are ftp and scp. Each protocol requires a
different -->
<!-- set of configuration values as shown in the examples below. Plaintext passwords are
persisted as -->
<!-- encrypted value when Load Balancer starts.
-->
<!-- In order to use 'scp' protocol, file that has ssh host key should be provided to
'knownHostsFile'. -->
<!-- Load Balancer does not populate this file automatically. In order to obtain the host
key, ssh to -->
<!-- the destination manually and specify the full path of the system default known_hosts
<additionalParameters type="connector">
<properties>
<property key="remote.management.listener.port" value="
{remote.management.listener.port from agent.properties}"/>
<property key="agent.name" value="{agent name configured for the destination in
the final stage of agent setup}"/>
</properties>
</additionalParameters>
</destination>
</destinations>
<routingRules>
<!-- Supported routing policies are RoundRobin, WeightedRoundRobin, and
AggregationPreferred. -->
<routingRule name="syslog-tcp-rule" sourceName="syslog-tcp" destinationPoolName="tcp-
syslog-connectors" routingPolicy="RoundRobin" enabled="true">
<additionalParameters type="listener">
<properties>
<!-- Scan incoming messages to determine if there is a hostname or address
present, and insert one if not. -->
<property key="syslog.address.prepend.mode" value="scan"/>
</properties>
</additionalParameters>
</routingRule>
<routingRule name="syslog-udp-rule" sourceName="syslog-udp" destinationPoolName="udp-
syslog-connectors" routingPolicy="WeightedRoundRobin" enabled="true"/>
<routingRule name="syslog-tls-rule" sourceName="syslog-tls" destinationPoolName="tls-
syslog-connectors" routingPolicy="AggregationPreferred" enabled="true"/>
<routingRule name="file-routing-rule" sourceName="file-watcher" destinationPoolName="file-
connectors" routingPolicy="RoundRobin" enabled="true"/>
</routingRules>
<sources>
<!-- When the source is syslog type, set 'type' to 'syslog' and configure the protocol
accordingly. -->
<!-- Supported protocols are 'udp', 'tcp', and 'tls'. 'port' is the listening port on Load
Balancer -->
<!-- and source syslog server should be configured to send the events to this port.
-->
<source name="syslog-tcp" type="syslog" port="513" protocol="tcp"/>
<source name="syslog-udp" type="syslog" port="514" protocol="udp"/>
<source name="syslog-tls" type="syslog" port="515" protocol="tls"/>
<!-- 'file' type source can be used with the file based connector and Load Balancer
downloads -->
<!-- the files from FTP server and distribute them to the defined destinations in
destination pool. -->
<!-- Supported protocol is 'ftp' and 'host' is the host address where FTP server is
running. -->
<!-- It assumes a default FTP port 21. If other port is configured, add 'port' attribute
port and -->
<!-- specify the port number. 'path' should a relative path to FTP root directory.
-->
<!-- Specify the credential for one who has a permission in accessing files from FTP
server with -->
<!-- a full permission since files will need to moved to another directory or deleted after
-->
<!-- the file is downloaded. When 'moveToDirectory' is configured, the downloaded file will
be -->
<!-- to a specified directory or when the value is empty, file will be deleted afterwards.
-->
<!-- If the specified path is located under 'path', be sure to give the path as hidden
directory -->
<!-- starting with '.'. Otherwise it will attempt to download the files from the directory
again -->
<!-- since it will recursively look for sub-directories. To disable recursive lookup, set
false to -->
<!-- 'recursive' attribute.
-->
<!-- User credential who has access to FTP server and path should be specified in
'username' and -->
<!-- 'password'. Plaintext password will be converted as encrypted value as soon as Load
Balancer -->
<!-- starts.
-->
<!-- 'localWorkDirectory' is where the file is temporarily kept before the file is sent to
one of -->
<!-- the destinations. This is required value and it assumes that the directory exists
already. -->
<source name="file-watcher" type="file" host="10.0.0.0" protocol="ftp" path="landingzone"
username="admin" password="password" fileFilter=".*log" moveToDirectory=".done" recursive="true"
passive="false" localWorkDirectory="/tmp" />
</sources>
</routing>
<!-- logInterval is in milliseconds. -->
<statisticsLogging logInterval="60000"/>
<!-- WebServer must be configured for all nodes listed as member hosts in Load Balancer. -
->
<webServer httpsPort="8443"/>
<!-- Uncomment and configure this section in order to customize the configuration. -
->
<!-- Refer to the configuration guide for the details. -
->
<!-- globalParameters>
<properties>
<property key="batch.buffer.size" value="102400" />
<property key="load.expression.default" value="cpuLoad"/>
</properties>
</globalParameters -->
</lbConfiguration>