Agent Mode

What you will do: turn an XPLG installation into a thin agent that stores nothing, connect it to the central deployment and route logs through it.

XPLG is fully functional agentless: install it anywhere and pull or receive the data. An agent is an ordinary XPLG installation switched into Agent Mode: a thin version that stores no data. The central cluster asks the agent for logs, the agent holds the permissions to the sources and ships only fresh data, over HTTPS. The cluster therefore needs no credentials to, and no network path into, every source — only to the agent — which improves security and reduces traffic. Instances connect to each other over HTTP/S on the console port (XPLG to XPLG).

When to use it

• Windows sources for a Linux cluster. A Linux cluster cannot read Windows machines directly (the reverse works), so a Windows agent collects Windows Events, UNC shares and Windows network logs and sends them to the Linux cluster. See Windows Server.
• Unreachable network segments — several Windows domains, no route from the central instance to the segment.
• No connectivity to the sources with the standard protocols — install the agent on or next to the source.
• Log Synchronization (Flux) always needs an agent at the source; see Install agents.
• A dedicated listener node in a V7 cluster runs in Agent Mode; see High availability and clustering.
• A forwarder that normalises and pushes data to a central XPLG.

Do not use Agent Mode for a remote instance that must process its own logs — a per-data-centre cluster, or a map-reduce layout where each instance owns a group of logs and a central instance gives users one view. Those are full installations connected the same way.

Steps

1. Install XPLG on a host that can read the sources, with the same operating-system rules as any server (a Windows agent for Windows sources). For many hosts use a silent installation and configure the agents afterwards with the SDK.
2. Activate Agent Mode on that instance: PortX > Settings > System Settings, select Activate Agent Mode, save. The instance restarts; a message warns that some functionality is disabled and that every log shows size 0, because nothing is stored. The SDK does the same remotely: -api settings -agentMode true (add -activateSecurity true to require a sign-in on the agent).
3. Register the agent on the central instance. PortX > Data > Account > New Account > Remote XpoLog: a name, the agent's address and the login details when security is active on the agent; under Advanced Settings select Enable remote configuration synchronization; Verify (a green message means the agent answers), then save. By SDK: -api addRemoteXpoLogAccount -name <account> -hostName <agent> -conType HTTPS -isCollected true — isCollected true is Agent Mode (the central instance collects through the agent), false is proxy mode.
4. Add the sources on the agent as on any instance (PortX > Data > Add Data, local files, Windows Events, …); their size shows 0.
5. Add the agent's logs on the central instance. PortX > Data > Add Data > Add Log, type Remote XpoLog, choose the account, browse the agent's Folders and Logs and select what the cluster should retrieve; save. Whenever the cluster's collection schedule requires the log to be updated, it asks the agent, which checks the source for fresh data and ships it. By SDK: -api addLog … -accountName <account> -filesPath "ROOT->Folder->log" with the path in the agent's tree.
6. A dedicated listener node (V7 cluster). Give it 2 GB, activate Agent Mode, add an empty recycleCronExpression= line to its xpologInit.prop, restart, then set each listener account's Listening node to it and its Indexing node to the master or a processor.

Licensing and limits

• An agent typically runs on a more limited license than a full server; ask XPLG for the appropriate one. In dock the agent belongs to the deployment it reports through; see How licensing works.
• The central instance reaches the agent on its console port (30303, or 30443 for HTTPS); give the agent your certificate — see TLS certificates.
• Whether a Flux-only agent should run in Agent Mode is documented for collection agents only and pending confirmation from XPLG engineering.
• Fluent Bit or syslog on the source is the alternative when you only need to ship files or events and no XPLG features at the source; see Sources.

Next: Upgrades

Source: XPLG wiki, pages 2054684673, 1594131988, 1594132401, 1598685522, 1597014018, 1594131986, 1598685520 (https://xpolog.atlassian.net/wiki/spaces/XPOL/pages/2054684673).