Technical Tip: Parser Apply fails due to references to a non-existent parser

Description

This article describes how to resolve the issue where parser configuration changes cannot be applied because parser test events fail with references to a parser that does not exist in the GUI.

Scope

FortiSIEM.

Solution

While applying parser configuration changes from the GUI: Admin -> Device Support -> Parser.

The apply operation may fail, and the Test Parser window may show permanently failing test events similar to below:

Expected Parser: ZscalerNSSParser.

Used Parser: ZscalerJsonParser.

Although the parser ZscalerNSSParser is not present in the GUI, stale backend references still exist in the system, causing parser tests to fail.

Example user symptom:

Impossible to apply ANY parser configuration changes. When selecting Apply, the Test Parser dialog shows permanently failing test events.

The issue can occur after upgrades or content updates, where older parser references remain in backend configuration files even though the parser itself no longer exists in the GUI.

Validation :

Run the following command from the Super node:

cd /opt/phoenix/config/xml

ls -l Zscaler*

Example output:

-rwxr-xr-x 1 admin admin 73874 Jan 20 01:03 ZscalerJsonParser.xml

-rwxr-xr-x 1 admin admin 16326 Jan 20 01:03 ZscalerNSSParser.xml

-rwxr-xr-x 1 admin admin 3548 Jan 20 01:03 ZscalerParser.xml

If the old parser XML file exists in the backend filesystem but the parser is not visible from the GUI, then the environment is impacted by this issue.

Workaround:

1. Move the stale parser XML file.

Run the following on all Super nodes:

cd /opt/phoenix/config/xml

mv ZscalerNSSParser.xml /tmp

2. Take a backup of the existing parser test files and move them from:
   
   

/data/custParser/

Example:

mkdir -p /tmp/custParser_backup

mv /data/custParser/* /tmp/custParser_backup/

3. Clear the cache and restart the application server.

HA Deployment :

Perform the following steps one node at a time.

Start with the Super Leader first.

su admin

cd /opt/phoenix/cache/

mv ip_dir ipdir_.old

Replace ip_dir with the actual FortiSIEM IP directory present under /opt/phoenix/cache/.

Then run:

cd /opt/glassfish/domains/domain1/

rm -rf generated/

rm -rf osgi-cache/

kill -9 $(cat /opt/glassfish/domains/domain1/config/pid)

After the GUI becomes accessible again on the Leader node, repeat the same procedure one-by-one on each follower node.

Recommended order:

1. Super Leader.

2. Follower 1.

3. Follower 2.

Ensure GUI access is restored before proceeding to the next node.

Non-HA Deployment :

For non-HA deployments, perform the cache cleanup and application server restart only on the Super node.

Additional validation:

Parser validator can be manually tested using:

/opt/phoenix/bin/phParserValidator -i /data/custParser/inputTest_<ID>.xml -o /data/custParser/outputTest_<ID>.xml

Example:

/opt/phoenix/bin/phParserValidator -i /data/custParser/inputTest_1776689001930.xml -o /data/custParser/outputTest_1776689001930.xml

API Connectivity validation :

Verify parser API connectivity using:

curl -vk https://localhost:443/phoenix/rest/config/eventAttributeType

curl -vk https://<Super-IP>:443/phoenix/rest/config/eventAttributeType

Ensure the API responds successfully and there is no proxy or intermediate connectivity issue affecting parser operations.

Result:

After completing the above steps, parser tests should pass successfully, and parser configuration changes can be applied normally from the GUI.