Good news! We're staffing an Administration Booth in the Innovation Hub at SAS Innovate in April. Make sure you swing by and say hello! We'll have some experts on hand to talk about a variety of topics. Come say hello! ... View more

By default, information that your developers and users create and store in SAS Studio are organized in SAS Content folders. This SAS Content folder structure is not connected to the underlying server file system, but rather is stored in the SAS Infrastructure Data Server. This is a PostgreSQL database that persists content like SAS Programs, reports, authorization rules, models, attachments, and other uploaded files, sometimes even data. This content is shared internally across SAS Viya web applications, so you can find the same content in SAS Studio, SAS Environment Manager, SAS Model Studio, SAS Visual Analytics, and the list goes on.  In this blog, I'll show you how to enable the local file system for SAS Studio.  For those of you administering SAS Studio, here’s a link to the SAS Studio Administrator’s Guide. Select any image to see a larger version. Mobile users: To view the images, select the "Full" version at the bottom of the page.   You can view SAS Content by opening SAS Environment Manager and viewing the content page. You’ll see a list of SAS Viya folders. Content within the SAS Infrastructure Data Server is backed up by the included SAS Viya backup processes. When users log in to any SAS application for the first time, a folder is created for them called My Folder.  This folder contains items that they do not want to share with other users. The contents of this folder are visible only to individual users and administrative users. There’s also a My Favorites folder, where users can add frequently used reports and data, as well as a My History folder with a reference to the 40 most recent content items that the user accessed. They also have access to other folders such as Public and any other folders that the General Authorization system allows the user to access, based on their group memberships.    The idea behind this allows users to easily store SAS Content in a single location, seamlessly accessible with other SAS Viya applications, and backed up by SAS Viya.  However, as they are stored in a database, they are not easily referenced by other non-SAS scripts or programs. What if you were building a SAS program and then wanted to have a 3 rd party scheduler or script use it later.  Some tools only currently work well when they are stored in SAS Content. But also, items in SAS Content do not have Git support or some other version control that a company might use.   There is a way for administrators to grant access back to the underlying file system on the SAS Server. SAS Studio configuration properties allow for the showServerFiles property to be set to true. When the property is set to true, users can access the file system from SAS Studio.  The administrator has some flexibility in defining the location for SAS Studio users to access. Depending on the configuration, this could expose sensitive information about the environment and allow any user to read files in the shared directory. There are additional configuration properties to define where the file system access begins, in the configuration property named fileNavigationRoot. The configuration property allows the administrator to choose between the following options: User – which allows home directory access. System – which enables full server access. Custom – which uses the configuration value: fileNavigationCustomRootPath The configuration property named fileNavigationCustomRootPath specifies a custom directory that the administrator wants users to be able to use, like external persistent storage.     Be aware that some customers might lock down and prevent access to the underlying file system. The underlying file system is also not backed up by the SAS Viya default backup, and a system will need to be in place to back up any custom locations where data is being stored.   Additionally, the latest releases of SAS Viya are configured by default to automatically generate UIDs for users when interacting with the mounted file server. To ensure access with the automatically generated ID, see this additional resource SAS Viya 2022.10 UID and GID Changes.   This is all about flexibility—granting your users the ability to choose between saving their programs to SAS Content or on the file system, where they can easily be used and shared outside of the SAS Infrastructure Data Server. ... View more

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