Amazon Workspaces is a “Desktop-as-a-Service” or Virtual Desktop Infrastructure (VDI) capability from the AWS cloud. VDI provides a secure way to enable home working, ensuring that staff are working from secure and compliant desktop machines, accessed via a remote connection from whatever physical machine they have at home.
Splunk is brilliant at ingesting data from AWS. There are various routes that can be used to bring the data in. The “Splunk Add-on for AWS” allows you to pull data in various ways from AWS. For monitoring use cases CloudWatch Metrics provide a great way to pull the AWS resource-specific metrics into Splunk. Out of the box, the Add-on provides templated support for a number of common AWS CloudWatch metric namespaces such as AWS/EC2, AWS/RDS, AWS/Billing, AWS/ApiGateway and more. Amazon WorkSpaces (AWS/Workspaces) is not set up by default, but it can be added as we show here.
Building the POC environment
Setting up Amazon Workspaces
AWS are currently offering up to 50 free users on Amazon WorkSpaces.
- Login to your AWS Console and navigate to Amazon WorkSpaces
- Click ‘Get Started Now’
- Set up Directory: AWS Managed Microsoft AD: Standard Edition
- Orgname = acmevdi
- Directory DNS name = vdi.acmevdi.com
- Set an admin password
- Choose VPC and subnets
- stick with the default or use a suitable VPC/subnet if appropriate
- Review – note that there are 30 days of trial usage, remember to delete resources after the test to avoid charges
- Create Directory – took around 20 mins to get to the ready state
- Click on the WorkSpaces option then “Launch WorkSpaces”
- Select a Directory – defaults should be fine
- Create some test users
- Select Bundle – here you can match your users to OS and connection protocols, for testing I chose:
- 1 x Windows 10 (Standard/PCoIP)
- 1 x Amazon Linux 2 (Standard/PCoIP)
- 1 x Windows 10 (Standard/WSP)
- WorkSpaces Configuration
- AutoStop was chosen as it is Free Tier eligible
- Add encryption and tags if required
- I added a tag project=splunk. (to see if it shows up in the data later)
- Launch Workspaces
Emails will be sent to the test users explaining how to connect. They will need to download the client appropriate for the OS they are using on their physical machine.
AWS User and Permissions
The Splunk Add-on for AWS will poll the AWS APIs to collect CloudWatch metric data. It does this as a user, using a Access and Secret Key to authenticate. Briefly, here are the steps:
- From the AWS Console access IAM
- Add User (splunk) with programmatic access
- Create a group – SplunkCloudWatchMetrics
- Create Policy: CloudWatchMetrics (use the policy below to grant access to all CloudWatch metrics)
- The user now has access to hit the AWS API and retrieve CloudWatch metrics
- Access the user and click on the Security credentials tab – from here you can create an access key and secret that you will use when setting up the connect in the Splunk Add-on for AWS
{
"Statement": [
{
"Action": [
"cloudwatch:List*",
"cloudwatch:Get*",
"autoscaling:Describe*",
"ec2:Describe*",
"s3:List*",
"sqs:List*",
"sns:List*",
"lambda:List*",
"elasticloadbalancing:Describe*"
],
"Effect": "Allow",
"Resource": "*"
}
],
"Version": "2012-10-17"
}
Setup the Splunk Add-on for AWS
Pre-requisites:
- Splunk v8 installed
- Splunk Add-on for AWS installed
Setup the Account to connect to AWS
Setup the account from the Configuration tab in the add-on:
- Click ‘Add’
- Name = a name for this connection
- Key ID = the AWS Access Key ID
- Secret = the AWS Secret Key ID
- Region Category = Global
Setup the Input to ingest Amazon WorkSpaces CloudWatch Metrics
From the Inputs tab:
- Click ‘Create New Input’
- Select CloudWatch
- Name = Amazon_WorkSpaces
- AWS Account = <name of account you specified previously>
- AWS Regions = the region(s) your WorkSpaces run in
- Metrics Configuration – click Edit in Advanced Mode
The default Metrics Configuration is set up to ingest from various namespaces. For this test, remove all of the namespaces from the left-hand side by clicking on the ‘x’. Also, remove any Dimensions in the right-hand section.
As AWS/WorkSpaces is not one of the listed namespaces you need to add it manually:
- Click “+ Add Namespace”
- Namespace = AWS/WorkSpaces (select from list and hit Enter)
- The Splunk Add-on populates the Dimension settings as shown below:
Warning: The default settings result in no data being ingested
Most of the AWS CloudWatch Metrics are available at the DirectoryId or the WorkspaceId dimension level but not both. For example, the “Available” metric will return the details on all of the virtual workstations if the WorkspaceId dimension is used, or a summary of the entire estate if DirectoryId is used. The table below shows this scenario for an environment with three virtual desktops:
As we can see above, decisions need to be made on each metric in terms of at which level to ingest the data (per WorkspaceId or per DirectoryId), and then also which aggregate function works best for that metric.
The table below suggests a metric setup that will allow for a comprehensive view across the estate. If you want to be able to identify issues at the workstation level (for instance, which workstations are experiencing high latency) then consider ingesting the data at the WorkstationId level. You can choose to do this alongside the DirectoryId level metrics or use Splunk to aggregate the values across the virtual workstations to get the big picture. The forest and the trees.
Metric | Description | DirectoryId Aggregation |
Available | The number of WorkSpaces that returned a healthy status. | Sum |
ConnectionAttempt | The number of connection attempts. | Sum |
ConnectionFailure | The number of failed connections. | Sum |
ConnectionSuccess | The number of successful connections. | Sum |
InSessionLatency | The round trip time between the WorkSpaces client and the WorkSpace. | Average Maximum |
Maintenance | The number of WorkSpaces that are under maintenance. | Sum |
SessionDisconnect | The number of connections that were closed, including user-initiated and failed connections. | Sum |
SessionLaunchTime | The amount of time it takes to initiate a WorkSpaces session. | Average Maximum |
Stopped | The number of WorkSpaces that are stopped. | Sum |
Unhealthy | The number of WorkSpaces that returned an unhealthy status. | Sum |
UserConnected | The number of WorkSpaces that have a user connected. | Sum |
- To Implement the settings above remove the default dimension setup from the metrics configuration screen then add each of the rows above using the following Dimension Value: [{“DirectoryId”:[“.*”]}]
- The screenshot below shows this setup in the Add-on
To finish the setup complete these steps:
- Click OK
- Change the index name as required (or leave to default)
- The Period can be changed to 60s (or kept at a higher value)
- Click Save
For further information on the CloudWatch Metrics available for Amazon WorkSpaces check this AWS documentation page: https://docs.aws.amazon.com/workspaces/latest/adminguide/cloudwatch-metrics.html
Checking the data
We can quickly check the data with the following search:
index=aws_workspaces sourcetype="aws:cloudwatch"
|stats count values(Sum) as sum avg(Average) as average max(Maximum) as maximum by metric_name
Within our test environment this currently produces the following stats table:
Conclusion
With Amazon Workspaces, as with many AWS technologies, there are CloudWatch Metrics available that can help monitor the service. As we have shown above, careful configuration of the metrics is required in order for them to be successfully ingested into Splunk.
In a future post we’ll look at building dashboards to help visualise the VDI estate.
For 2021 we’ve committed to posting a new Splunk tip every week!
If you want to keep up to date on tips like the one above then sign up below:
Subscribe to our newsletter to receive regular updates from iDelta, including news and updates, information on upcoming events, and Splunk tips and tricks from our team of experts. You can also find us on Twitter and LinkedIn.