chapter nine

LASR administration

The LASR Analytic Server is critical to the operation of SAS Visual Analytics. Therefore, it is important to become familiar with the administration tasks that are necessary to care for the LASR Analytic Server. This is because the LASR Analytic Server is incredibly powerful and flexible, and there are many considerations for its administration.

In most circumstances, SAS Visual Analytics is only one part of a larger solution. Other SAS offerings as well as third-party software can play an important role in the daily operations of the environment. Each of these bring their own administration tasks and utilities to the table.

This chapter will focus on many of the administration tools and tasks for the LASR Analytic Server. There’s a lot to cover–let’s get to it!

Administration overview

The person responsible for administration of SAS Visual Analytics has a lot of ground to cover. She must manage users and resources; maintain security and system integrity; and then monitor operations and audit activities.

Specific to the LASR Analytic Server, the administrator will handle the following:

•   Starting and stopping LASR Analytic Servers

•   Loading tables into and dropping tables from LASR Analytic Servers

•   Defining data libraries and access controls

•   Monitoring resource utilization

Administration tools

SAS provides several tools for administering the SAS Visual Analytics environment. Depending on the task at hand, the administrator of SAS Visual Analytics will need to access the correct tools and to complete the full set of actions necessary to achieve her goals.

SAS Management Console

The SAS Management Console is an application (based on Java) for administration of critical SAS Enterprise Business Intelligence environment components—including many items used by SAS Visual Analytics. The SAS Management Console effectively acts as a point-and-click graphical interface to the SAS Metadata Server. So wherever metadata describing the SAS Visual Analytics environment comes into play, we will need to familiarize ourselves with using the SAS Management Console to manage it.

Figure 9.1 Logged on to SAS Management Console as the Unrestricted User with full control over all items

Use the SAS Management Console to define and manage the existence of LASR Analytic Servers, LASR libraries, and LASR tables in metadata. Security access controls to the data in LASR is also maintained with the SAS Management Console.

SAS Visual Analytics Administrator

The SAS Visual Analytics Administrator is a web application that is accessed from your web browser. Log on using your credentials that have been granted the Visual Analytics Administrator role privileges in the SAS Metadata Server.

Figure 9.2 Using VA Administrator to monitor system resource use

With SAS Visual Analytics Administrator, the administrator can perform these tasks specific to LASR:

•   Start and stop LASR Analytic Servers.

•   Load and unload LASR tables.

•   Check on the status of LASR Analytic Servers (running or not) and LASR tables (loaded or not).

•   Apply row-level security to tables in LASR.

•   Monitor system resource utilization in real time (CPU, RAM, I/O).

SAS Visual Analytics Administrator provides “live” monitoring of the environment. It does not have the ability to show any historical information–only what is currently happening.

SAS Environment Manager

SAS Environment Manager was first introduced with SAS 9.4. It’s based on open-source technologies from the VMware Hyperic to provide a modular, extensible administration and monitoring framework. The SAS Environment Manager is built from several disparate components that work together to provide a single service, including agents on each host managed in the environment and a server that consolidates all of the agent data, stores it, and provides a web-based user interface. Log on to the SAS Environment Manager using your credentials that have been granted the appropriate level of administrative role privileges in metadata.

Figure 9.3 A dashboard shown in SAS Environment Manager for monitoring the metrics captured for our environment

SAS Environment Manager can be used for “live” monitoring of the environment. But more importantly, it constantly captures, tracks, and records system activity so that you have access to historical information as well. Because SAS Environment Manager is effectively watching the environment whether you are looking at it or not, it can also provide alerts (over email, text message, and so on) to notify you if critical conditions are encountered.

Use SAS Environment Manager to do the following:

•   monitor all system services and resources (including items related to the LASR Analytic Server)

•   set alerts based on conditions that you choose

•   view and report on current and historical performance

•   perform administrative control actions for most SAS services and web applications

SAS Program Code

With programmatic interfaces accessible from Base SAS, SAS Enterprise Guide, SAS Studio, SAS Data Integration Studio, the administrator of SAS Visual Analytics can create new interactive or batch programs that can ultimately be used to administer almost any aspect of the data lifecycle in support of in-memory tables in LASR. SAS programming experts can craft SAS code that can start and stop LASR Analytic Servers, load data from any source supported by the environment into LASR and beyond, even to programmatically creating and modifying objects stored in the SAS Metadata Server.

Figure 9.4 Using the SAS Studio web app to submit SAS program code to work with LASR

The visual administration tools are handy and powerful. Having a graphical user interface helps make the work of tasks appear more logical and intuitive. Mature site operations, however, will require some level of scripting, programming, and scheduling to ensure that table updates can occur automatically. So creating and maintaining your own SAS program code will be a useful skill.

Other tools

A SAS Visual Analytics solution deployment relies on the tools shown here, but also on many others. While we’ve been focused on SAS utilities for administering the environment, there are other software products which you might need to consider.

Other tools that can be useful for management of your SAS solution environment:

•   SAS High-Performance Computing Management Console

◦   Can be used at sites that prefer it

◦   Not related to the SAS Management Console

◦   Primarily for creating and maintaining large numbers of user accounts

•   Operating system utilities

◦   Linux: netstat, top, iftop, ps, mpstat, and many more

◦   Windows: Task Manager, Perfmon, the System Event Viewer, and so on

•   Hadoop utilities

◦   Deployment management: Cloudera Manager, Ambari

◦   Hadoop web applications: DFS Health, YARN Manager

◦   Hadoop Command-line: Hadoop, hdfs

While we won’t discuss details of those other utilities in this book, they are still important contributors to your administration toolbox in support of the SAS Visual Analytics solution deployment.

Interesting LASR Administration Tasks

LASR Analytic Server administration, especially as it ties into the greater SAS ecosystem, is a big topic. We want to get you started by introducing you to some interesting tasks which you’re likely to encounter when administering a SAS Visual Analytics solution at your site.

The role of SAS metadata

SAS Visual Analytics relies exclusively on LASR Analytic Servers and LASR tables, which are defined in the SAS Metadata Server. If you are a SAS programmer, you can easily write your own program code to start a new LASR Analytic Server, load data into it, run actions, and get results back. However, unless you take the additional step to register that new LASR Analytic Server instance and any new tables in metadata then SAS Visual Analytics won’t see them and cannot work with them.

SAS metadata also defines access controls to manage the content available for users to view, interact with, and possibly administer as well.

Generally speaking, objects in metadata describe things that should already (or will soon) exist. In some cases, the metadata is referenced by the described item so that it knows about specific start-up or operational parameters. The point here is that metadata is meant to describe something that exists independently of the metadata itself. If you move or delete an item in the real world, the metadata will not automatically reflect that change. SAS Enterprise Business Intelligence software will coordinate its internal use of metadata with physical items. However, if you manually (or programmatically) create your own metadata objects, then you will be responsible for ongoing maintenance of those objects to ensure that they reflect the correct state of the real-world items going forward.

Defining new LASR Analytic Servers

SAS Visual Analytics relies exclusively on the SAS LASR Analytic Server to provide data and analytics for reporting and exploration. The LASR Analytic Server provides a secure, multi-user environment for access to data that is stored in memory. The LASR Analytic Server was originally built to handle the largest data volumes, but can also work with smaller tables as well.

SAS Visual Analytics needs at least one LASR Analytic Server with data in memory in order to provide reports to users. But if circumstances warrant, you can define multiple LASR Analytic Servers, which can co-exist on the same machines or be deployed to their own set of hosts.

By default, two LASR Analytic Servers are created during the deployment of SAS Visual Analytics software:

•   LASR Analytic Server on port 10010

•   Public LASR Analytic Server on port 10031

Depending on the needs of your site, there are several reasons that you might choose to create additional LASR Analytic Servers.

•   Resource usage separation – direct groups of users to different LASR Analytic Servers on separate hosts, which might be owned by different responsible parties

•   Security – direct groups of users to different LASR Analytic Servers to protect access to data

•   Dev, Test, Prod – separate environments to ensure smooth testing and transition of updates

•   Resource availability – if your original host machines are fully used, then deploy another LASR to new hosts

First of all, defining a new LASR Analytic Server in your environment assumes that the necessary software exists on all host machines. With that in place, then we can define a new LASR Analytic Server using the SAS Management Console:

Figure 9.5 Using the SAS Management Console to create a new LASR Analytic Server

In SAS Management Console, connect to the SAS Metadata Server with a user account that has appropriate administrative privileges. Then right-click the Server Manager item and select New Server. The New Server Wizard will appear and provide a list of different server types. Select SAS Servers ▶ SAS LASR Analytic Server. Click Next and give your new LASR Analytic Server a name and optional description. Then we get to the interesting part.

Figure 9.6 The New Server Wizard for creating a new metadata definition of a SAS LASR Analytic Server

On the third screen of the New Server Wizard, you can choose whether to define a “single machine server,” which refers to the Non-Distributed (SMP) LASR Server. By default, the answer is No, which will create a metadata object that describes a Distributed (MPP) LASR Server.

For an MPP LASR Server, you must also provide the answer to two more questions:

•   High-Performance Analytics Environment installation location

The HPAE software is deployed separately from the rest of VA. It provides the underlying software used to launch an MPP LASR Server on multiple host machines. The value of this prompt is usually something like /opt/sas/TKGrid_3.1/TKGrid. But it might vary at your site.

Keep in mind that if you intend to use the SAS In-Database Embedded Process with a supported remote data provider to perform parallel data loads to MPP LASR, then you must provide the path to the associated TKGrid_REP directory instead.

•   Number of machines to use:

The HPAE is installed on at least four machines as the minimum requirement for an MPP LASR Server, and often to many more. You can choose to run LASR on ALL of them (the default) or some subset number. You cannot specify which subset of machines to use in metadata. If less than ALL, then LASR is started on the number of machines you specify in the order listed in the tkgrid.hosts file in the HPAE configuration on disk.

Open the Advanced Options in metadata of the new LASR Analytic Server, and you can control key memory usage criteria.

Figure 9.7 Specifying memory limits of the LASR Analytic Server

Careless use of LASR can easily overrun the system resources in your environment. RAM is a key resource that is critical not just to LASR but to the operating system and any other software running on the same host machines. To help ensure that LASR behaves well, we can specify values for the following options:

•   Data loading (%) – default is 80% - If the LASR Analytic Server is currently holding tables that consume 80% or more of RAM, then new tables cannot be loaded.

•   External processes (%) – If specified, then processes external to LASR cannot retrieve data from or run actions in LASR if this number is exceeded.

New LASR Analytic Servers can also be defined for use by SAS Visual Analytics in the SAS Environment Manager application. As with SAS Management Console, you’ll need to sign on to SAS Environment Manager with a user account that has the appropriate level of administrative privileges and navigate into the Administration section (available from the sidebar menu in the upper-left corner of the web page). Once there, you can bring up the New Server wizard and enter the information needed for LASR:

Figure 9.8 Creating a new LASR Analytic Server for SAS Visual Analytics using the SAS Environment Manager administration tool

As an administrator, your ability to proactively manage the LASR Server’s memory usage is helpful in maintaining a smooth operating environment.

Once your new LASR Server is defined, chances are that SAS Visual Analytics can work with it. There are some considerations to keep in mind, which are not addressed directly in metadata:

•   SAS Visual Analytics users who wish to administer LASR services (starting, stopping, and loading data) must have their own OS user accounts (or using SAS token authentication) with the ability to launch a SAS Workspace Server.

•   For MPP LASR, the OS user account that launches the SAS Workspace Server must also exist on all hosts of the MPP LASR cluster and also have non-password SSH configured for that account.

•   For SAS Visual Analytics users who only need read-access to the data which is already loaded into LASR, then OS user accounts are not necessary.

SAS Visual Analytics, the SAS LASR Analytic Server, and other SAS solutions must often interact with third-party software systems, often even co-existing with them on the same hardware. For example, it’s a common practice to symmetrically co-locate a Hadoop environment alongside MPP LASR to enable the ability to work with SASHDAT tables in HDFS. If those Hadoop services – especially memory intensive software like Spark and Impala – are busily used, then there could be significant contention for the limited amount of RAM which LASR relies on. So proper planning and execution of LASR administration ensures that this powerful tool behaves well at your site.

Defining new LASR libraries

A LASR Server isn’t good for much if it doesn’t have any data loaded in-memory to perform actions on and generate analytical results. For SAS Visual Analytics to work with data, we need a library reference defined in metadata so that SAS Visual Analytics knows which LASR Analytic Server to connect to. Furthermore, the SAS Metadata Server maintains access controls on objects like LASR Analytic Servers definitions, librefs, and tables to ensure that users can only see the things in the environment that they’re supposed to see.

SAS library references (librefs) describe the connection details for SAS to communicate with a given data source. LASR libraries are used to connect SAS with LASR Analytic Servers. In order for SAS Visual Analytics to work with LASR data, the LASR libref must also be defined in the SAS Metadata Server.

Librefs provide a way for SAS to separate user access to various data sources. And so the reasons for creating new LASR libraries closely parallel those for creating new LASR Analytic Servers, including:

•   Security – restricting access to in-memory data based on access controls defined per libref

•   Data organization – data sourced from different locations will each require their own libref

Managing LASR Analytic Servers with code

Besides using point-and-click user interfaces like the SAS Visual Analytics Administrator to manage LASR operations such as starting, stopping, loading data, and establishing limits, you can also write SAS program code which is convenient for automated scripting. For example, with a well-designed set of programs, you can start up multiple LASR Analytic Servers and load them with data from disparate sources all at once.

As always, SAS offers more than one programmatic technique by which you can manage your LASR Servers and their associated data.

Distributed Mode LASR

For LASR Servers operating in distributed mode (MPP), we can use the LASR procedure. PROC LASR provides the following major functionality:

•   Start and stop the specified SAS LASR Analytic Server.

•   Load and unload tables from LASR memory.

•   Save LASR’s in-memory tables to disk in HDFS.

For example, the following code can be used to start an MPP LASR Server:

Notes

•   Line 3 is formatted to fit on this page in readable fashion – make sure that your actual path does not have any spaces.

•   The create parameter will direct SAS to start up a LASR Server with the specified attributes.

•   Ensure that the port value that you specify – it doesn’t have to be 10011 – is actually available. Otherwise, this LASR Server will not start if another service (LASR or otherwise) is already listening at that port number.

•   The signer functionality is accessed through an HTTP RESTful interface provided by the SASLASRAuthorization web application. This application is often, but not always, a different host machine than the Distributed LASR Server’s Root Node host.

•   The install parameter specifies the physical path to the SAS High-Performance Analytics Environment software (TKGrid). If you expect to perform parallel loading of data from the SAS Embedded Process in a remote data provider, then this path should point to the associated TKGrid_REP directory instead.

Stopping an MPP LASR Server is even simpler:

Notes

•   The port attribute in combination with the host provides the key criteria for stopping the intended LASR Server.

•   The stop parameter directs the LASR Server to not accept any new client connections, to not allow any current actions to finish executions, and then to terminate the server processes.

If this LASR Server is already defined in metadata (with matching attributes like port number, signer, and installed codebase location), then its status in SAS Visual Analytics Administrator or SAS Environment Manager will change to reflect the results of your successful code execution – and you can further control the LASR Server there in those interfaces as well.

Non-Distributed Mode LASR

We programmatically manage operations of Non-Distributed (SMP) LASR Servers with two SAS program concepts: the SASIOLA libref and the VASMP procedure.

For SMP LASR, we can use the SASIOLA LIBNAME engine to do the following:

•   Start and stop the specified SAS LASR Analytic Server.

•   Load and unload tables from LASR memory.

And use PROC VASMP to do the following:

•   Stop (only!) the specified SAS LASR Analytic Server.

•   List the tables currently available in-memory for SMP LASR Server.

•   Provide administrative information and control over the SMP LASR Server.

The following code starts a new LASR Server and directs it to continue running:

Note:

•   Conceptually, a SAS libref – defined by the libname statement – is only available during the lifetime of the SAS System execution. But LASR is more than a libref. It can persist and work with multiple instances of SAS.

•   The SASIOLA library engine and the VASMP procedure only work with Non-Distributed (SMP) LASR Analytic Servers

•   The serverwait parameter in PROC VASMP directs the LASR Analytic Server to persist operations until it receives a direct termination directive.

•   Without the serverwait, when the SAS instance that executes this code terminates, the new LASR Server would also terminate at the same time (when the SASIOLA libref is cleared).

The VASMP procedure can also show more information about the specified LASR Server:

Note:

•   The serverinfo parameter will direct SAS to return descriptive details about the specified LASR Analytic Server

•   The serverterm parameter directs SAS to send a termination command to LASR so that it will shut down after finishing any ongoing actions.

•   Other parameters available from PROC VASMP include the following:

◦   SERVERPARM: used to specify an override of the global LASR Server settings that were defined in the SAS Metadata Server.

◦   TABLEINFO: returns information about the in-memory tables available in the specified LASR Server.

As an alternative to using PROC VASMP to stop SMP LASR, we could also submit a simple SAS libname statement such as the following:

Note:

•   The clear parameter will de-assign the libref in SAS and also send the termination command to the LASR Server

•   LASR will stop accepting new client connection, complete the current set of ongoing actions (if any), and then shut down.

Working with the Autoloader Facility

SAS Visual Analytics provides an Autoloader Facility to enable users of the system to stage their SAS data sets (or delimited text files, like CSV) on the SAS Workspace Server host machine for automatic upload to the associated SAS LASR Server. By default, the deployment of the SAS Visual solution software will define an autoload site for use with the default Public SAS LASR Analytic Server.

The Autoload Facility is provided as a convenience, but is not required for operation of SAS Visual Analytics. After the deployment of your SAS software, manual steps to direct an operating system scheduler to invoke the Autoloader on a regular basis (for example, every 15 minutes) will be needed to fully activate the Autoloader functionality.

Figure 9.9 The SAS Visual Analytics Autoloader Facility will ensure that the provided data is available in the LASR Server

The Autoloader Facility works with either SMP LASR or MPP LASR. If MPP LASR is the target, then data is only loaded serially. There is no option available to enable the Autoloader Facility to work with parallel-loading data sources.

With the Autoload Facility configured and running, then the following occurs:

•   The data from new tables placed in the Autoloader staging area directory will automatically upload to the LASR Server.

•   If the associated LASR Server is not running, the Autoload Facility will start it.

•   Tables can be removed from LASR using the other Autoload directory for that purpose.

Users of the Autoload Facility must have the ability to create and save files in the physical directories on the host(s) for the SAS Workspace Server(s). To ensure that users do not clobber each other’s files, consider enabling the “sticky bit” on the Autoloader’s staging directories.

Besides the default provided Autoload for the Public LASR Analytic Server, you have the ability to create additional sources (directories with data on the SAS Workspace Server) and targets (LASR Servers, public or not).

Monitoring resources used by LASR

The SAS LASR Analytic Server is a high-performance in-memory analytics engine. To do its job, data tables are loaded into RAM on the machine(s) where LASR is running where they remain until they are unloaded or until the LASR Server itself is shut down. All of the software on your LASR hosts—the operating system, any co-located data providers, and so on—rely on RAM to function. LASR expands on that to use RAM as a persistent data storage for its in-memory tables.

When dealing with many users who are relying on SAS Visual Analytics to provide them with access to reporting and analytics, ensuring that resource consumption is in line with expectations is important. Also remember that the LASR Server can be deployed to function in two ways:

•   Distributed LASR (MPP) – where multiple LASR Workers, each on its own host, perform in-memory analytics as coordinated by the LASR Worker, which is also on its own host machine.

•   Non-Distributed LASR (SMP) – where LASR runs on a single machine only. It gives us the speed of in-memory processing but without the additional gains provided by breaking the task up into smaller chunks and distributing those to multiple workers for parallel processing.

The SAS Visual Analytics Administrator web application can provide useful insights into what resources LASR is working with.

Figure 9.10 Monitoring the memory that is used in LASR Servers

In the screen capture above, SAS Visual Analytics Administrator provides us with a quick glance at our environment with the following:

•   Five defined LASR Servers

•   The host each is running on (either SMP or the LASR Root Node for MPP)

•   Their current execution state

•   RAM consumed by each (only instances of MPP LASR that are currently active)

LASR Server status

Let’s take a closer look at the server status:

Figure 9.11 The execution state of each LASR Server

There are three status modes that can describe the current execution state of a LASR Server:

Status Icon	Description
	Green Circle: The LASR Server is running and online.
	Red Square: The LASR Server is not running.
	Yellow Triangle: The LASR Server is running and online, but the amount of data that it has in memory exceeds the tables limit value defined for it (default is 80%)

First, in order for SAS Visual Analytics Administrator to show a LASR Server in the list, that LASR Server must first be defined in SAS metadata. So regardless of the status shown, the list itself is an indicator that the LASR Servers have been defined in metadata such that SAS Visual Analytics Administrator is aware of them.

These status icons only show whether the server is running. A green circle does not necessarily mean that any data has been loaded into the LASR Server yet. You’ll need to check the LASR Tables tab to get that information.

The yellow triangle is a helpful indicator in reference to the LASR tables limit value. When the data loaded into memory meets or exceeds that value, the LASR Server will not allow more data to be loaded. You’re probably wondering how that value could be exceeded. It’s because that value is ascertained only after a table has been loaded into RAM. A good example is if the limit is set at 80% of total system RAM and your tables in LASR currently only consume 79%, then the next table load – regardless of its size! – will be allowed to proceed.

LASR memory usage

The LASR Servers tab of SAS Visual Analytics Administrator shows the RAM consumed in support of hosting LASR tables in memory.

Figure 9.12 SAS Visual Analytics Administrator reports on LASR memory usage

SAS Visual Analytics Administrator reports on memory differently for LASR running in distributed (MPP) mode than it does for non-distributed (SMP) LASR.

The columns shown here display the following:

•   Virtual Memory – MPP LASR only – a percentage of the amount of RAM consumed by the Distributed LASR processes across the entire cluster.

•   Tables Memory (MB) - the amount of RAM consumed by data in LASR tables which currently reside in memory

•   Tables Limit (MB) – an optional, pre-defined limit on the amount of RAM beyond which no additional tables can be loaded into that LASR Server

The green bar in the upper right corner is a gauge of showing a percentage of the amount of total RAM utilization of all LASR hosts in aggregation in a distributed (MPP) environment. It does not appear for SMP-only deployments of LASR. If you position the mouse pointer over that gauge, a tooltip will appear with more information.

Figure 9.13 RAM utilization gauge for the LASR cluster with details in the tooltip.

Altogether, this item is explaining several things to us:

•   13% of all RAM is currently in use in the cluster. This counts not just LASR usage, but also the operating system and any other third-party RAM utilization as well.

•   The tooltip shows 7.93GB of RAM currently used by the LASR Server(s) out of a total 62.31 GB available in aggregate across all hosts

Resource Monitoring

SAS Visual Analytics Administrator also offers an interactive and dynamic client that shows activity updates known as the Resource Monitor. The Resource Monitor provides graphical displays of data to provide information about current utilization of system resources.

Figure 9.14 The Resource Monitor in SAS Visual Analytics Administrator tracking CPU, RAM, and I/O across all nodes of the LASR cluster

From top to bottom, the Resource Monitor shows:

•   Utilization History – color-coded lines in a histogram tracking utilization of CPU, RAM, inbound network I/O, and outbound network I/O

•   Real-Time View – a collection of three heat maps that display the current state of the following:

◦   Utilization of each CPU core on all hosts of the cluster – notice the green-shaded rectangles above, representing 8 CPU cores for our 4-machine LASR cluster

◦   Total RAM utilization on each host – look for the light-blue shaded set of rectangles, 1 each for the 4 machines of our LASR cluster

-   Network I/O on each host – the red-shaded set of 8 rectangles where inbound traffic per host is shown on top and outbound traffic is shown on the bottom.

For the Real-Time View, notice that the color-coding of these heat maps is increasingly darker as the utilization increases. If the value of a particular metric exceeds the expected norm, then Resource Monitor will choose a bright color to draw attention to it. For example, the outbound network I/O on the fourth host of our LASR cluster is shown as a purple rectangle and we can see from the legend that it represents a value beyond the range at which the network interfaces are operating on the other cluster hosts.

The data shown in Resource Monitor is live or collected moments ago while the Resource Monitor was online. These charts are reinitialized with each invocation of the Resource Monitor. So for historical views of past resource usage, the SAS Environment Manager is a better tool to use.

Usage Reports

SAS Visual Analytics Administrator offers an automated collection of reports that can help with the administration by reporting on the actual usage of reports, objects, data sources, and LASR.

Figure 9.15 SAS Visual Analytics Administrator provides usage reports

In particular, the Administrative Overview report is interesting. It generates a SAS Visual Analytics report with multiple tabs that show usage statistics by report, by user, by data source and much more.

Figure 9.16 The LASR Server tab in the Administrator Overview usage report

Understanding how your SAS Visual Analytics solution is being used is important to ensure that the correct resources are available. And this understanding can provide justification to continue using those resource as well as acquiring more if needed.

To make full use of all of the SAS Visual Analytics Administrator Usage Reports, you will want to enable the SAS Environment Manager Extended Monitoring functionality – often referred to as the EMI Framework. When activated the EMI Framework will create and maintain a data mart of usage statistics gathered by the SAS Environment Manager. That data mart then supports extensive reporting on how the SAS solution deployment is used.

SAS provides much more information about deploying and using SAS Environment Manager Extended Monitoring and the EMI Framework in the SAS Environment Manager: User's Guide available on http://support.sas.com.

References

So far we’ve just given you a taste of the flexibility and power available when administering the LASR Analytic Server in support of SAS Visual Analytics. You are likely to be eager to learn more. SAS provides a lot of documentation to help you out. So polish up your administration skills by referring to the following SAS documentation online at support.sas.com:

SAS Institute Inc. 2016. SAS Visual Analytics 7.3: Administration Guide. Cary, NC: SAS Institute Inc.

SAS Institute Inc. 2016. SAS LASR™ Analytic Server 2.7: Reference Guide. Cary, NC: SAS Institute Inc.

SAS Institute Inc. 2016. SAS Environment Manager 2.5: User’s Guide, 3^rd edition. Cary, NC: SAS Institute Inc.

SAS Institute Inc. 2016. SAS 9.4 Intelligence Platform: System Administration Guide, 4^th edition. Cary, NC: SAS Institute Inc.

SAS Institute Inc. 2016. SAS 9.4 Intelligence Platform: Security Administration Guide, 3^rd edition. Cary, NC: SAS Institute Inc.