Troubleshooting
Problem
If STAP Status and Last Response from STAP Status Monitor report (Manage > System View > S-TAP Status Monitor) are wrong, but status for the same STAP under S-TAP Control (Manage > Activity Monitoring > S-TAP Control) looks fine, this may be an expected behavior. This article explains when this symptom can be expected behavior. Additionally, this article provides a possible workaround to resolve the issue when the root cause can not be identified.
Symptom
The STAP Status and Last Response are wrong in STAP Status Monitor report .
Cause
Possible causes:
- Expected behavior if the database for the inspection engine was not accessible at the time of the last STAP restart.
- Other unidentified root cause.
Diagnosing The Problem
The value for STAP Status and/or for Last Response in the STAP Status Monitor report are wrong.
For example, you know the STAP is running on the server , and report "Manage > Activity Monitoring > S-TAP Control" reflects this, as in image below:
Image 1. STAP is Green and Last Response is current in S-TAP Control
however STAP Status says Inactive in report "Manage > System View > S-TAP Status Monitor", or Last Response has an old Date:
Image 2. STAP is Red and Last Response is old
Resolving The Problem
1.- Refer to Technote:
Guardium S-TAP status is green in S-TAP control but red in Enterprise S-TAP view
in the Related URL section.
Follow instructions in the technote to build a custom report to verify if you are in the scenario where the STAP process is running but the database instance is not running (this may be expected in passive nodes in cluster environments for example).
If you are in that scenario, the symptom you observe is expected behavior as explained in the Technote. In this case, Guardium built-in report "Manage > System View > S-TAP Status Monitor" will show S-TAP Status as Inactive, this is by design.
2.- If you confirm you are not in the scenario described in Technote above, and a root cause is not clear at the moment, try below workaround to make the STAP re-connect to the collector. This should refresh the STAP information on the collector.
Note that these steps involve stopping traffic collection for the time the inspection engine is removed or/and the STAP stopped.
2.1) Stop the STAP on the Database Server.
2.2) Confirm the STAP is now Red under Manage > Activity Monitoring > S-TAP Control.
2.3) Remove the STAP from the S-TAP Control list on the collector GUI.
Refer to Technote How to delete an STAP from the S-TAP Control list on a collector in the Related URL section for details on how to do this.
2.4) Remove all the inspection engines from the guard_tap.ini on the Database Server (save a copy of the guard_tap.ini file first).
Manually edit the guard_tap.ini file on the Database Server, delete all the inspection engines, and save the file.
2.5) Restart the STAP.
2.6) Check report Manage > System View > S-TAP Status Monitor and verify the issue is resolved ( S-TAP Status and Last Response should reflect correct information now).
2.7) Verify the STAP information is correct under Manage > Activity Monitoring > S-TAP Control.
2.8) Stop again the STAP on the Database Server , re-add the inspection engine(s) you deleted on step 2.4) , and then restart the STAP
2.9) Verify STAP information is correct in output from both reports:
Check report Manage > System View > S-TAP Status Monitor
Manage > Activity Monitoring > S-TAP Control
Note: If STAP information was correct on 2.6) and 2.7) but not on this step, it may be an issue with your inspection engines. Verify all the parameters for all the inspection engines are correct. Contact Support if issue persists and you need additional assistance.
Related Information
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg21986039