App-access.logs - Using for Troubleshooting

Products

• Clarity PPM On Premise
• Clarity PPM SaaS

Issue/Introduction

This article walks through some tips on how to use the Clarity app-access.logs for troubleshooting. 

Resolution

Information below is pulled from: CA Clarity Tuesday Tip: Enhanced App-Access Logs in 12.1.0

Overview

The app.access.log formats data in a pipe-delimited manner, which helps in importing these logs into a spreadsheet or database. The format can be useful in finding actions that take a long time to complete (including what may cause general performance issues in the system) as well as tracking what users were doing at a particular time in the application (who or what user ID made a change in the application).

The format is as follows:

• IP address of requester|
• DateTime of the completed request|
• URL request|
• HTTP Status Code|
• Bytes sent back to the client (excluding the header)|
• Elapsed time of the request (in ms). This can be subtracted from the DateTime to get the request startTime|
• Clarity sessionId cookie (a distinct way to group requests, it can be tied back to the sessions tables in Clarity to find the user)
  
  Example:

1**.1**.1**.1**|[08/Jul/2020:11:56:08 -0400]|POST /niku/nu?uitk.vxml=1&action=odf.getObjectList&uitk.session.uuid=7ce479de-74b5-4f42-8df9-87851cebf2e7 HTTP/1.0|200|8677|93|5216040__8B785EC4-F02A-4C2B-BDC2-81F02621XXXXXXX

From the above, we can see from IP address: 1**.1**.1**.1**, a Post action for the odf.getObjectList was received by the server. This came from session 5216040 and took 8.677

Finding the app-access.logs:

1. On Premise customers: Under the Clarity\logs directory.
2. On Premise and SaaS From Clarity->Security.logs. Replace everything in the Clarity URL after action: security.logs

These logs have the format, app-access-yyyy-mm-dd.log. i.e. app-access-2020-10-18.log

Finding Users

The app-access logs don't show the username in the session, however, you may be able to determine that based on information in the request. You can also use the session token to map back to the user id using the following steps:

1. In the app-access log, you'll see entries similar to the below:
   
   1**.1**.1**.1**|[11/Aug/2011:15:21:15 -0700]|GET /niku/app?action=nmc.userSelectInstanceRightType&resourceId=1&id=1&principal=USER HTTP/1.1|200|4582|234|5431144__5418a09e:131bae3XXXXXX:-80001313100502181
   1**.1**.1**.1**|[11/Aug/2011:15:21:22 -0700]|POST /niku/app?action=nmc.userAddInstanceRights&resourceId=1&id=1&principal=USER&resourceId=1 HTTP/1.1|200|5273|188|5431144__5418a09e:131bae3XXXXXX:-80001313100502181
2. Look at the session toke: i.e. 5431144__5418a09e:131bae3XXXXXXX:-80001313100502181
3. Take the number before the double underscore (__), which is 5431144.
4. Locate that user by querying the cmn_sessions table.
   i.e:  select user_id from cmn_sessions where id = 5431144.

Note for Broadcom GCP SaaS Environments

For GCP/SaaS environments, we only store 2 days worth of session data, so the session information would have to be caught within the available time frame.