SAS Enterprise Session Monitor is an observability tool used to keep watch on server operations and performance. It monitors specific sessions and processes and displays that information. In short, it gives you analytics about your analytics. Enterprise Session Monitor is built for SAS, bringing insight to SAS session metrics such as PROC and DATA Steps, and CAS Actions. A developer or administrator can perceive real-time feedback on their company’s SAS workloads and see the effects of a session on the server resources.
SAS Enterprise Session Monitor Server can observe multiple environments simultaneously, on premises or in the cloud.
Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.
It's been available for a while now, and Enterprise Session Monitor agents run on the same environments where SAS 9, SAS Viya 3.X, and the latest SAS Viya environments run: Windows, Linux/Unix, and Kubernetes. The default configuration tracks those SAS 9, SAS Viya 3.X, and SAS Viya processes and sessions in your environment. This is not an exhaustive list by any means, but sessions such as: SAS Workspace servers, Compute servers, CAS controller and worker sessions, and distributed SAS Grid Workspace servers are all monitored and displayed by default. Depending on the operating system and platform, administrators can see which data tables have been accessed within a period of time, accurately count concurrent users on environments, and see which SAS statements are being used in programmer sessions across the organization. All this information is kept in a database, so you have a historical record and can generate analysis or reports on workloads that ran in your environments.
I write environments because the Enterprise Session Monitor agents run on multiple nodes, and can glean session information from multiple SAS deployments, even if they are different types. They all send their information to the same SAS Enterprise Session Monitor Server to view and store.
How does Enterprise Session Monitor discover sessions?
By default, SAS Enterprise Session monitor has two methods of finding sessions on these remote hosts. The agents are configured with either a passive method or an active method. The passive discovery method is the default. In this passive discovery method, SAS Enterprise Session Monitor Agents watch in a specific directory or folder for trigger files that contain session information. These files are generated by SAS sessions because of the Enterprise Session Monitor configuration which appends some code to SAS servers when they run. That code generates these trigger files when each session executes.
Passive Process Discovery and Active Process Discovery may work together to provide a complete record of sessions and jobs.
The active process discovery method causes the agent to query the task list or process table of a node at regular intervals, and then searches that table for sessions (defined in another file) that it is interested in tracking. The result of that search is sent to the Enterprise Session Monitor Server.
Both active and passive process discovery can be active on a node simultaneously. By default, the active process scan runs every ten seconds, and the passive discovery method’s trigger files ensure that processes are discovered even if they started and finished in the nine second window between process table scans.
All of this is configurable, and you are the administrator who gets to configure this.
Why Track Custom Sessions?
Enterprise Session Monitor can track SAS sessions out of the box by virtue of the initial configuration of SAS Enterprise Session Monitor. Enabling active monitoring and configuring the filterSpec.yaml file allows us as administrators to track other processes and sessions. And it's completely customizable.
Let’s say you want to track a version control or DevOps application that your company uses. Perhaps you want to track severs which host third-party databases. Perhaps the R&D department wants to track their custom Java application to ensure the tool they are building isn’t using too many system resources. Maybe you just want to benchmark how much slower open-source analytic tools run. You get the picture—the possibilities for node monitoring with an Enterprise Session Monitor agent is up to you.
Okay! I’m convinced. How to begin?
In the Enterprise Session Monitor Agent install location, there is a bin directory (or folder for those of you on Windows) which holds the agent configuration in a file called config.properties . Two lines in that file are of interest to you right now: monitorAllSessions and monitoringInterval . Uncommenting these lines will allow the Enterprise Session Monitor Agent to use active process discovery. The agent then references a file called filterSpec.yaml to configure the processes that you are interested in sending to the Enterprise Session Monitor Server. You'll also need to restart the Enterprise Session Monitor agent once your configuration is complete.
Uncommenting monitorAllSessions and monitoringInterval (and configuring the filterSpec, and restarting the Enterprise Session Monitor Agent) engages Active Monitoring.
The filterSpec.yaml file contains process filter blocks, and each block contains a different set of properties to identify sessions for the agent to track.
The filterSpec.yaml file contains filter blocks that specify which processes you are interested in adding to SAS Enterprise Session Monitor.
Starting each block is the processFilterRegex property, which defines a regular expression to identify the session from the node's process table. When building these, it is best to run the process table on a server, such as with ps -ef . Locate a process that you want to target and copy several lines of the process table to the clipboard, including the sample process. Use a tool like regex101.com to build your regular expressions (disclaimer: this links to a non-SAS site, but the regex101 tool is a web site that's useful in building, testing, and debugging regular expressions).
The expressions you build can be as simple as just finding the name of the process somewhere in the string, or as complicated as accounting for each delimiter, character, word, or number. You can also use capture groups to specify a string to use in the name or type of session in Enterprise Session Monitor.
Using the Regex101 interface to build a regular expression to find Java processes, and store the process name in a variable called ${appname}
Each block of properties is processed in sequential order, so if there are sessions that match multiple rules, the first one is the one that is applied. So, if your custom application also appeared in a list of all programs, the custom application one would apply if it were higher in the filterSpec.yaml file.
The process filter block can specify a userFilterRegex , which can disregard processes which don’t match a specific user. This is useful if you are tracking a service account, or it can be left alone to capture a matching process by any user.
The process filter block can specify the location of the session’s log file on Unix systems in the processLogfile property. Using this, Enterprise Session Monitor can open the log file from the graphical user interface.
The ignoreMatching property, if set to true, will ignore matching processes. If set to false, the agent will send the session information to the Enterprise Session Monitor Server.
There are three other sub properties under the esmPattern property which determine information for the Enterprise Session Monitor server to display: processName , processType , and processQueue . These three properties can be hardcoded or accept variables from the processFilterRegex, like ${appname} , ${port} , ${msg} , or others. These capture groups and variables are defined by you when writing your regular expressions. A sample process filter block might look similar to the yaml code below:
#track java processes
- processFilterRegex: (?<user>\w+).*\/usr\/bin\/java\s-jar\s(?<appname>\w+).*
userFilterRegex: ''
ignoreMatching: False
esmPattern:
processName: ${appname}
processType: java
processQueue:
These configurations and filterSpec.yaml files must be modified on each agent, and work on both Windows and Linux/Unix systems. On Kubernetes systems, all processes that run on a node are automatically discovered by default.
The result of all your hard work is being able to see your specified processes in the Enterprise Session Monitor process list and time series graphs.
I hope this helps in your understanding and helps you create some interesting uses for extending SAS Enterprise Session Monitor. Perhaps you'll be tracking additional processes across your analytical ecosystems soon!
Find more articles from SAS Global Enablement and Learning here.
... View more
