Cross-referencing CAS Sessions between applications

[#1]

When it comes to managing CAS sessions, SAS Viya administrators have several options for session management applications such as SAS Environment Manager, the CAS Server Monitor, and the gridmon utility. Each application provides certain information about the sessions and provides a variety of actions to take against those sessions such as termination. When any one of these applications is sufficient to carry out the required session management task, there is no issue with session identification. However, any time an administrator needs to use gridmon in addition to any of the other session management tools, they may run into issues when trying to cross-reference a CAS session between tools as gridmon identifies sessions with an ID value that differs from SAS Environment Manager. So how does an administrator associate a session in gridmon with the same session in SAS Environment Manager?

Let's suppose an administrator is carrying out some routine monitoring tasks and, as part of that, is taking a look at the CAS sessions using gridmon (found in /opt/sas/viya/home/SASFoundation/utilities/bin).

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

From the display, the single highlighted session appears to be consuming nearly 20% of the CPU and 1.2G of disk space so the administrator would like to know more about that session before deciding whether or not it needs terminating. The SessID column identifies this as session 377437 and is owned by the user sasadm, but that's about all we know. For example, we do not know whether this is a session that is part of an active Visual Analytics workflow or if it is from a SAS Studio program.

For that information, this administrator may switch to SAS Environment Manager to examine the session listing.

Notice, however, that SAS Environment Manager displays a totally different looking Session ID in its listing. Here, the Session ID is a unique identifier (UID) not just an integer value. On the bright side, we can now infer a little more about the purpose of each session noting that some of sasadm's sessions originated from SAS Environment Manager and that there is one session that has been given an atypical name of FINDME. In my experience, sessions originating from routine application processing like Visual Analytics usually display with a generic prefix of Session: in the Name field. So the task before us is to try and associate the session number 377437 from gridmon with one of these sessions in SAS Environment Manager.

For that, we need to dive into the CAS log located in /var/log/sas/viya/cas/default. If we search the CAS log for the gridmon SessID value of 377437 and also for the word 'Successfully,' we can extract the log message for the creation of this session.

[root@intcas01 default]# cat cas_2019-09-09_intcas01_23762.log | grep 377437 | grep Successfully
2019-09-09T14:56:20,064 INFO [00000007] cas localhost 31051 sasadm 377437 [tkcsesinst.c:725] \
- Successfully created session 3f31cd4e-6c4e-cd40-bed8-474c30cec3ae.
[root@intcas01 default]#

The two highlighted values provide the link we need to associate a specific UID in SAS Environment Manager with the SessID of 377437 in gridmon.

From here, it is up to the administrator to decide what to do about the session - preferably, contact the user and ask if they can be of assistance. If the session needs to be terminated, either SAS Environment Manager or gridmon can be used, but at least the administrator has more context around the session's purpose.