Log Activity search fails:
Ariel Proxy and port 32011

Personal note: This is an operational troubleshooting note based on the documented QRadar failure pattern. Confirm paths and procedure against the installed QRadar version and IBM Support guidance before making changes.

1. Confirm the failure pattern

• The Log Activity tab displays real-time event streaming.
• Starting a filtered or saved search fails with There was a problem connecting to the query server.
• The same failure occurs with different filter criteria, rather than one specific AQL or filter causing the error.

This symptom points first to the search path, not necessarily event collection. Streaming and query execution are separate workflows, so working streaming does not confirm that Ariel search is ready.

2. Why it can happen

When ariel_proxy_server starts, it loads search-related items from its transient data directory before it is ready to accept requests. A large number of files or accumulated search state can lengthen startup. If the Ariel listening socket on TCP 32011 is not listening when a search is submitted, the UI can return the query-server connection error.

IBM lists TCP 32011 as the Ariel listening port used for database searches, progress information, and related commands. The exact transient path can vary by filesystem layout: IBM's file-analysis guidance references /transient/ariel_proxy.ariel_proxy_server/data/, while some environments expose it under /store/transient/. Confirm the actual mounted path on the target appliance before proceeding.

3. Start with read-only checks

Run these checks on the QRadar Console as an approved administrator. Capture output before restarting services or removing files.

systemctl status ariel_proxy_server --no-pager
df -h
ss -lntp | grep ':32011'

Inspect the size of the transient Ariel Proxy directory. Use the path that exists on your host:

du -sh /transient/ariel_proxy.ariel_proxy_server 2>/dev/null
du -sh /store/transient/ariel_proxy.ariel_proxy_server 2>/dev/null

• If the service is still starting and port 32011 is not listening, inspect service logs and startup progress.
• If the transient filesystem is near capacity or the Ariel Proxy directory contains an unusually large number of files, identify the search data responsible before removing anything.
• If the service is active and the port is listening, investigate other causes—including query criteria, search service logs, resource pressure, and version-specific issues—instead of deleting files by default.

4. Identify large or accumulated search files

IBM recommends identifying the files responsible for transient usage and correlating them with saved searches or search results before deleting them. These commands are for inspection only:

find /transient -xdev -type f -size +200M -exec ls -lh {} \;
ls -lhSr /transient/ariel_proxy.ariel_proxy_server/data/
ls -lh /transient/ariel_proxy.ariel_proxy_server/data/ | wc -l

If your deployment uses /store/transient/, substitute the confirmed path. The 200M threshold is an example for finding large files; many smaller files can also delay startup.

Review QRadar search activity and retention settings to understand why data accumulated. IBM's support note provides an AQL example for identifying users who executed searches and explains how search-result retention can affect transient storage. Align retention with your organization's policy rather than reducing it blindly.

5. Recovery procedure

Use this only after identifying the relevant search data and confirming the action with your change process or IBM Support. Restarting Ariel Proxy can cause searches to fail and may reset Ariel queues; schedule a maintenance window when required.

1. Confirm the exact transient directory and identify specific files eligible for removal. Preserve required search data and check available space before creating a backup under /store.
2. If a backup is required, store the selected files in an approved backup location and verify the copy before deleting anything. Do not back up the entire directory to a nearly full filesystem.
3. Stop the service only when the approved recovery plan calls for it:

systemctl stop ariel_proxy_server
systemctl status ariel_proxy_server --no-pager

4. Remove only the specifically identified search files and their related files, if IBM's procedure confirms they belong to the same search ID. Avoid a blanket rm .../data/* unless IBM Support has explicitly approved that option for your case and you understand the impact.
5. Restart Ariel Proxy:

systemctl start ariel_proxy_server
systemctl status ariel_proxy_server --no-pager

If your approved procedure explicitly requires restarting the service in one operation, use the version-appropriate IBM instructions. Do not combine stop, delete, and restart commands into an unattended block.

6. Verify recovery

ss -lntp | grep ':32011'

Confirm that the Ariel listening port is in LISTEN state. Then run a narrow Log Activity search over a recent time range, verify the results, and check that the service remains healthy. If the port stays closed or searches continue to fail, preserve the service logs and open or continue an IBM Support case rather than repeating cleanup.

7. IBM references

• IBM Support — Ariel Proxy error when filtered Log Activity searches fail (port 32011 not listening)
• IBM Support — Identify and remove large search data files from the transient Ariel Proxy directory
• IBM Documentation — QRadar port usage (TCP 32011)

The transient path, service behavior, and supported recovery steps vary by QRadar release and filesystem layout. Confirm the path and cleanup procedure with IBM Support before removing search data.