Credential Test, Dynamic Applications, and Viewing Component Devices

The following sections describe how to use the AWS credential test, understanding AWS Dynamic Applications, and how to view AWS component devices: Amazon Web Services PowerPack

Testing the AWS Credential

NOTE: The Credential Test is for use with the Manual Discovery method only.

SL1 includes a Credential Test for Amazon Web Services. Credential Tests define a series of steps that SL1 can execute on demand to validate whether a credential works as expected.

The AWS Credential Test can only be used to test a SOAP/XML credential or a SOAP/XML with AWS subtype credential for monitoring AWS using the Dynamic Applications in the "Amazon Web Services" PowerPack. The AWS Credential Test performs the following steps:

Test Reachability. Performs an ICMP ping request to the URL for the EC2 service in the region specified in the credential. If a region is not specified in the credential, the us-east-1 region is used.
Test Port Availability. Performs an NMAP request to TCP port 443 on the URL for the EC2 service in the region specified in the credential. If a region is not specified in the credential, the us-east-1 region is used.
Test Name Resolution. Performs an nslookup request on the URL for the EC2 service in the region specified in the credential. If a region is not specified in the credential, the us-east-1 region is used.
Make connection to AWS account. Attempts to connect to the AWS service using the account specified in the credential.
Scan AWS services. Verifies that the account specified in the credential has access to the services.

The AWS Credential Test does not support the testing of credentials that connect to AWS through a proxy server.

The AWS Credential Test does not support AWS UCF Credentials.

To test the AWS credential:

Go to the Credentials page (Manage > Credentials).
Locate the credential you wish to test, select the Actions button () next to it and click Test.
The Credential Test Form modal page appears. Fill out the following fields on this page:

Credential. This field is read-only and displays the name of the credential you selected.
Select Credential Test. Select AWS Credential Test.
Collector. Select the All-In-One Appliance or Data Collector that will run the test.
IP or Hostname to Test. Enter a valid IP address.

Click the Run Test button to run the credential test. The Testing Credential window appears:

The Testing Credential window displays a log entry for each step in the credential test. The steps performed are different for each credential test. The log entry for each step includes the following information:

Step. The name of the step.
Description. A description of the action performed during the step.
Log Message. The result of the step for this execution of the credential test.
Status. Whether the result of this step indicates the credential and/or the network environment is configured correctly (Passed) or incorrectly (Failed).
Step Tip. Mouse over the question mark icon () to display the tip text. The tip text recommends what to do to change the credential and/or the network environment if the step has a status of "Failed".

Testing the AWS Credential in the SL1 Classic User Interface

NOTE: The Credential Test is for use with the Manual Discovery method only.

SL1 includes a Credential Test for Amazon Web Services. Credential Tests define a series of steps that SL1 can execute on demand to validate whether a credential works as expected.

Test Reachability. Performs an ICMP ping request to the URL for the EC2 service in the region specified in the credential. If a region is not specified in the credential, the us-east-1 region is used.
Test Port Availability. Performs an NMAP request to TCP port 443 on the URL for the EC2 service in the region specified in the credential. If a region is not specified in the credential, the us-east-1 region is used.
Test Name Resolution. Performs an nslookup request on the URL for the EC2 service in the region specified in the credential. If a region is not specified in the credential, the us-east-1 region is used.
Make connection to AWS account. Attempts to connect to the AWS service using the account specified in the credential.
Scan AWS services. Verifies that the account specified in the credential has access to the services.

The AWS Credential Test does not support the testing of credentials that connect to AWS through a proxy server.

To test the AWS credential:

Go to the Credential Test Management page (System > Customize > Credential Tests).

Locate the AWS Credential Test and click its lightning bolt icon (). The Credential Tester modal page appears.

Supply values in the following fields:

Test Type. This field is pre-populated with the credential test you selected.

Credential. Select the credential to test. This drop-down list includes only credentials that you have access to that can be tested using the selected credential test.
Hostname/IP. Leave this field blank.
Collector. Select the All-In-One Appliance or Data Collector that will run the test.

Click the Run Test button to run the credential test. The Test Credential window appears.

The Test Credential window displays a log entry for each step in the credential test. The steps performed are different for each credential test. The log entry for each step includes the following information:

Step. The name of the step.

Description. A description of the action performed during the step.
Log Message. The result of the step for this credential test.
Status. Whether the result of this step indicates the credential or the network environment is configured correctly (Passed) or incorrectly (Failed).
Step Tip. Mouse over the question mark icon () to display the tip text. The tip text recommends what to do to change the credential or the network environment if the step has a status of "Failed".

Viewing AWS Component Devices

When SL1 performs collection for the AWS virtual device, SL1 will create component devices that represent each element in your AWS infrastructure and align other Dynamic Applications to those component devices. Some of the Dynamic Applications aligned to the component devices will also be used to create additional component devices. All component devices appear in the Devices page.

In addition to the Devices page, you can view the AWS service and all associated component devices in the following places in the user interface:

The Device Investigator Map page (click Map in the Device Investigator page) displays a map of a particular device and all of the devices with which it has parent-child relationships. Double-clicking any of the listed devices reloads the page to make the selected device the primary device

The Device Components page (Devices > Device Components) displays a list of all root devices and component devices discovered by SL1 in an indented view, so you can easily view the hierarchy and relationships between child devices, parent devices, and root devices. To view the component devices associated with an AWS service, find the AWS virtual device and click its plus icon (+).

The Component Map page (Classic Maps > Device Maps > Components) allows you to view devices by root node and view the relationships between root nodes, parent components, and child components in a map. This makes it easy to visualize and manage root nodes and their components. SL1 automatically updates the Component Map as new component devices are discovered. SL1 also updates each map with the latest status and event information. To view the map for an AWS service, go to Classic Maps > Device Maps > Components, and select the map from the list in the left NavBar. To learn more about the Component Map page, see the section on Maps.

Relationships Between Component Devices

In addition to the parent/child relationships between component devices, relationships are automatically created by the Dynamic Applications in the Amazon Web Services PowerPack between the following component devices:

AWS API Gateway Services and AWS Network Load Balancers
AWS API Instances and AWS Lambda Functions
AWS Application ELBs and AWS Availability Zones

AWS Application ELBs and AWS Route 53-Hosted Zones
AWS Application ELBs and AWS Security Groups
AWS Application ELBs and AWS Target Groups
AWS Application ELBs and AWS VPC Instances
AWS Auto Scale Groups and AWS Auto Scale Launch Configurations
AWS Direct Connect Virtual Instances and AWS Virtual Private Gateways
AWS ECS Instances and AWS EC2 Instances
AWS ECS Services and AWS Classic Load Balancers
AWS ECS Services and AWS Security Groups
AWS ECS Services and AWS Target Groups
AWS ECS Services and AWS VPC Instances
AWS ECS Services and AWS VPC Subnets
AWS EC2 Instances and AWS Auto Scale Groups
AWS EC2 Instances and AWS EBS Volumes
AWS EC2 Instances and AWS Elastic Beanstalk Applications
AWS EC2 Instances and AWS ELB Instances
AWS EC2 Instances and AWS EMR Instances
AWS EC2 Instances and AWS OpsWorks Instances
AWS EC2 Instances and AWS Security Groups
AWS EC2 Instances and AWS Target Groups
AWS EC2 Instances and AWS VPC Instances
AWS EC2 Instances and AWS VPC Subnets
AWS EC2 Instances and the Cisco Cloud Center application
AWS Lambda Functions and AWS Security Groups
AWS Lambda Functions and AWS Simple Notification Services (SNS)
AWS Lambda Functions and AWS Simple Queue Services (SQS)
AWS Lambda Functions and AWS VPC Instances
AWS Lambda Functions and AWS VPC Subnets
AWS Lambda Function Qualified Services and AWS Security Groups
AWS Lambda Function Qualified Services and AWS VPC Instances
AWS Lambda Function Qualified Services and AWS VPC Subnets
AWS Lambda Function Replicas and their parent AWS Lambda Function Versions
AWS Network ELBs and AWS Availability Zones
AWS Network ELBs and AWS Route 53-Hosted Zones
AWS Network ELBs and AWS Target Groups
AWS Network ELBs and AWS VPC Instances
AWS Organizations and AWS Accounts
AWS RDS Aurora Clusters and AWS RDS DB Instances
AWS Redshift Instances and AWS Security Groups
AWS Redshift Instances and AWS VPC Instances
AWS Route Tables and AWS Virtual Private Gateways
AWS Route Tables and AWS VPC Subnets
AWS S3 Instances and AWS CloudTrail Instances
AWS Security Groups and AWS VPC Instances
AWS SNS Instances and AWS CloudTrail Instances
AWS SNS Instances and AWS Glacier Instances
AWS Transit Gateways and AWS VPC Instances
AWS VPC Instances and AWS ELB Instances
AWS VPC Instances and AWS Target Groups
AWS WorkSpaces and AWS VPC Subnets

Vanishing Component Devices

If SL1 cannot retrieve information about a component device for the amount of time specified in the Component Vanish Timeout field (in either the Global Threshold Settings page, the Device Thresholds page for the component device, or the Device Thresholds page for a device higher in the component tree), SL1 sets the device to "vanished".

When a device is set to "vanished", SL1 stops trying to collect data about the component device. The vanished device will not appear in reports or views. The vanished device will appear only in the Vanished Device Manager page. When a device is set to "vanished", all children of that device are also set to "vanished".

NOTE: This section describes the standard device vanishing behavior that does not use the "AWS: Vanish Terminated EC2 Instances" Run Book Action and Automation policies. If you use the "AWS: Vanish Terminated EC2 Instances" Run Book Action and Automation policies, see the chapter on "AWS Run Book Actions and Automations" for more information about device vanishing.

Most AWS component devices operate using the standard SL1 vanishing logic: If the device is terminated in AWS, it then becomes unavailable in SL1. If the device is unavailable for the amount of time specified in the Component Vanish Timeout field, then that device is vanished.

However, two AWS component device types operate using slightly different logic:

EC2. EC2 instances that are deleted in AWS still appear in the AWS portal for one to two hours in a terminated state. If SL1 polls that device and receives a response from AWS that the EC2 is terminated, SL1 will classify the device as unavailable. If the Component Vanish Timeout setting has been enabled, then SL1 will vanish this device automatically. If, however, the EC2 instance has merely been stopped rather than terminated, SL1 will not vanish the device, even if the Component Vanish Timeout setting has been enabled.
RDS. RDS instances that have a status of stopped or stopping in AWS will be classified as unavailable in SL1. If the Component Vanish Timeout setting has been enabled, then SL1 will vanish this device automatically.

ScienceLogic recommends setting the Component Vanish Timeout to 120 minutes when monitoring AWS accounts.

For more information about vanishing devices, see the section on Vanishing & Purging Devices.