Skip navigation
All Places > Products > RSA Identity Governance & Lifecycle > Blog > Author: Vinayak Sagar

This blog describes what all diagnostics data is collected in RSA Identity Governance and Lifecycle V7.1.1 and how it can be useful to customers.

 

         The diagnostic data collection in RSA Identity Governance and Lifecycle is turned on by default and collects system information daily. The frequency of data collection is configurable (see Admin > Diagnostics in the product help). Customers should review the schedule for diagnostic gathering to ensure it does not conflict or delay nightly collections. With this feature enabled, statistical information is gathered about the product components like reviews, rules, access request, AFX, roles, reports, as well as information related to the deployed environment and the applications that are configured.

 

         Trends related to the change in the application configurations can be assessed by looking at the application parameters like the number of accounts, users, orphan accounts, users with multiple accounts, roles, entitlements over time. Assessment of sudden increase in data volume or spikes can be tied to symptoms like application slowness and performance degradations. Admins can use the historical data to explain such anomalous behavior or trace and tighten rouge jobs that could be the cause.

 

         Deployment related information can similarly be used to get the big picture of the type of Database configured (remote/local), number of “Remote Agents” deployed, number of AFX servers, number of nodes in cluster. This information can be used to compare any deviations from the recommended configuration by RSA and corrective actions can be taken.

 

         AFX related information like the number of connectors, daily status, number of active running connectors, and count of fulfillment request sent in a day, including failures. These can be used to understand the trend and make necessary changes including tuning of the end points to adjust the overall performance.

 

         Health of collectors can be learned from the trend in time taken for collections to complete, frequency of collection, and number of collection failures. This information will help in tuning the collection schedule and avoid redundant collections.

 

Out of the box Reports/Charts in 7.1.1 are provided for the following components:

Weekly and Monthly views are available for customers to include in their dashboards to get their statistics.

  • Reviews: Parameters like the number of review definitions defined, size of reviews, number of revokes are collected. Administrators can take stock of these statistics and take corrective actions like increasing/decreasing the number of reviewers, adjust the size of reviews, take actions based on the number of revokes (e.g. some rule may be granting more access than needed resulting in more revokes during reviews).
  • Rules: Parameters like number of rule sets, active/inactive/deleted rules, rule processing time, number of violations/exceptions caught, number of change/violations triggered by reviews each day, exception access granted in a day are monitored. Based on the chart summary admins can tune rules to improve processing, delete/modify rules as needed, can investigate exception access grants.
  • Access Request Forms: Parameters like the number of access request forms that exist, number of workflows defined, number of requests/approvals/fulfillments made per day, and approvals rejected per day are noted. Approval and fulfillment trends will help in measuring and ensuring conformance to SLAs.
  • Roles: Parameters such as the number of roles, number of roles with membership rules, roles with entitlement rules, average entitlements per role, number of users per role, number of app roles per role are captured. These statistics can hint on the complexity, hierarchy and gaps in implementation and association of roles within the system.

 

         The public view PV_TELEMETRY_DATA is also provided so customers can develop their own reports and charts against the diagnostic information gathered.

 

Diagnostics data use for troubleshooting:

         The complete set of data collected can be downloaded from the UI as a zip file containing a set of JSON files, which can be shared with RSA while reporting issues on the product. This data will be used by RSA to diagnose the reported issues and troubleshoot /fix them. Also the data will help RSA understand how customers are using the product and if the scale of objects defined is different from other customers. This will improve the time to resolve issues while reducing the number of meetings with customers. The likelihood of root causing a problem at first level of support (CS) would increase as the data is more intuitive.

 

See V7.1.1 Diagnostics overview video in the attachments.