aws (Amazon Web Services Monitoring) Release Notes
Amazon Web Service (AWS) provides a decentralized IT infrastructure to multiple organizations. You can create an account on the AWS cloud and can use its services according to your IT infrastructure requirements. The various capabilities of AWS include storage, web-scale computing, database access, and messaging.
The Amazon Web Services Monitoring (aws) probe remotely monitors the health and performance of available services over an AWS cloud. The probe allows you to monitor your AWS user account and retrieves all the service data from AWS CloudWatch. The probe generates Quality of Service (QoS) data and issues status alarms.
The probe from version 2.01 and later is configured only through the Admin Console GUI.
Amazon Web Service (AWS)provides a decentralized IT infrastructure to multiple organizations. You can create an account on the AWS cloud and can use its services according to your IT infrastructure requirements. The various capabilities of AWS include storage, web-scale computing, database access, and messaging.
Amazon charges the AWS account which the probe uses to monitor the AWS services. Consider this fact while configuring the probe to monitor various AWS services.
This section describes the history of the revisions for the aws probe.
Support case(s) may not be viewable to all customers.
For more information, see aws Metrics.
Note:These metrics are not applicable to other instance types.
The QoS data collection for AWS services is not dependent on the status of
Activecheck box under
Service Configurationsin AC GUI. The QoS data is collected based on the individual QoS selection for specific AWS services. The Active check box will be removed from the Admin Console’s
Service Configurationsection in the future release of the probe.
Support case number 00913242
Note:Probe is supported from CA UIM 7.6 and later only.
Probe Specific Hardware Requirements
The aws probe is installed on systems with the following minimum resources:
- Memory: 4 GB of RAM. The OOB configuration of the probe requires 256 MB of RAM.
- CPU: 3-GHz dual-core processor; 32-bit or 64-bit
Probe Specific Software Requirements
The aws probe version 2.01 and later require the following software environment:
- CA Unified Infrastructure Management 8.0 or later
Monitoring Configuration Service (MCS) requires CA Unified Infrastructure Management 8.51 or later.
- (From aws version 5.10)CA UIM 8.47 or later for Amazon Web Services (AWS) CABI dashboard
- Robot 7.62 or later (recommended)
- Java JRE version 7 or later
- Unified Dashboard 3.0.5 (for AWS 5.00 and later)
(aws 4.10 and later) EC2 Private IP Configuration
The EC2 instances that use only private IPs require additional configuration to be monitored by the probe. The probe then publishes the private DNS name to USM.
Follow these steps:
- Open theRaw Configurationinterface of the probe.
- Navigate to theSetupfolder.
- Change the value of thepublishPrivateIpkey totrue.Default: falseEC2 instances can also use both public and private IPs. In such cases, the probe uses the private IP after you modify the key.
(aws 5.00 and later) Optimize Publishing for the Discovery Server Version
(CA UIM version 8.2 or later)You can optimize the efficiency of the probe publishing process. Configure the probe to publish your QoS data to your specific version of Discovery Server.
Follow these steps:
- Verify your Discovery Server version. In the navigation tree for Admin Console, click on the machine that hosts Discovery Server. A table of probes appears where you can verify the version.
- Locate the machine that hosts the aws probe.
- Open Raw Configure for the probe.
- Select the keydiscovery_server_version. It might be necessary to add this key if it does not exist.
- Enter the version for your Discovery Server as the key value.For example: 8.2
- Apply your changes.
- Restart the probe.Optimized publishing is enabled. The probe publishes only the delta values for the data it sends to the Discovery Server.
This section contains the installation prerequisites for the aws probe.
- Ensure the following user access details:
- AnAWS user accountwith valid user-credentials, such as, Access Key and Secret Access Key.
- The probe requires access to at least the following policies on AWS:
- AmazonS3ReadOnlyAccessThe probe requires theAmazonS3FullAccesspolicy to monitorS3 Writeperformance.
- The probe requires the following policies to monitor account billing details, in addition toReadOnlyaccess forCloudWatchservice:
- (aws 5.00 and later - Groups in USM)Follow these steps to use auto groups in USM:
- Deploy the CA UIM 8.4 SP2 package.
- Enable the trellis and das probes, if disabled.
- (aws 5.00 and later)Add the following keys to the probeRaw Configurationinterface >Setupsection:
Specify an integer value for both the keys.
- thread_count: maximum number of threads that the probe can execute simultaneously. CA recommends you to use the maximum number as 50, but you can also increase this count if the probe is running on a system with high CPU memory.
- max_api_requests: maximum number of API requests that the probe sends to the AWS CloudWatch in each second. Amazon supports a maximum of 400 requests in each second.
- (aws 5.40 and later)If you want to use IAM role-based authentication, then create a role and policies that provide required access to the AWS resources (ReadOnlyAccess and AmazonS3FullAccess) and assign that role to the EC2 instance. For more information about IAM role-based authentication, see https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html
This section lists the upgrade considerations for the aws probe.
- (aws 5.00 and later)Upgrade to Unified Dashboard version 3.05 to view the latest dashboards for the probe. The probe displays the earlier dashboard, however, CA recommends you to use the latest dashboards. For more information, see theView Probe Datasection in aws AC Configuration.
- On upgrade from 4.02 or earlier to a later version, the monitoring applied using the factory template is deactivated and all configuration is lost. The probe also does not upgrade custom templates to include new monitors. However, configuration using custom templates is retained.
- When migrating to version 4.0 or later of the probe, you must manually clear the AutoScale alarms in USM. The new alarms generated by the probe are displayed in the created AutoScale group in USM.
- For viewing the new metrics that are introduced in the aws probe version 3.0, on the USM portal, you can perform any one of the following actions:
- Upgrade NMS 7.6 (or earlier) to CA UIM 8.0 and later.
- Install the ci_defn_pack version 1.01 probe. You are required to restart thenis_serverwhen you deploy theci_defn_pack.
- The aws probe version 2.0x and later is available through Admin Console GUI only and not through the Infrastructure Manager (IM) GUI. Upgrade from previous versions to version 2.0x and later is not supported.
- QoS names of the following AWS metrics have changed in version 2.0x:Old QoS NameNew QoS NameQOS_FileWriteTimeQOS_AWS_FILE_WRITE_TIMEQOS_FileReadTimeQOS_AWS_FILE_READ_TIMEQOS_DiskReadOpsQOS_AWS_DISK_READ_OPSQOS_DiskReadBytesQOS_AWS_DISK_READ_BYTESQOS_DiskWriteOpsQOS_AWS_DISK_WRITE_OPSQOS_CPUUtilizationQOS_AWS_CPU_UTILIZATIONQOS_NetworkInQOS_AWS_NETWORK_INQOS_NetworkOutQOS_AWS_NETWORK_OUTQOS_DiskWriteBytesQOS_AWS_DISK_WRITE_BYTES
- Removed the QOS_MACHINE_DEPLOYMENT_TIME metric in version 2.0.
- You must deploy Probe Provisioning Manager (PPM) probe version 2.34 or later for configuring the aws probe version 2.0x or later.
- When you install the probe version 2.01 then manually move the existing configurations, in case you are using the probe of version earlier than version 2.01.
- Delete all the versions of the probe that are earlier than version 2.01 as upgrade from a previous version to version 2.01 is not supported.
Alarm Threshold Requirements
The PPM probe maintains a table of subsystem IDs that are mapped to the probes. As of the current release, the subsystem IDs for this probe will default to 1.1.19. The aws probe supports the following types of alarms:
- Dynamic Alarms Thresholds
- Static Alarm Thresholds
- Time Over Threshold
- Time To Threshold
If you are using either dynamic or static alarm thresholds, you can change the default entry to the appropriate subsystem ID.
If you have upgraded NMS 7.6 to CA UIM 8.0 then you do not have to perform the following procedures.
Follow these steps:
- In the Admin Console, click the black arrow next to the probe, selectConfigure.
- Select the monitor that you want to modify from the available list.
- Change the Static and DynamicSubsystem (override) fieldsto220.127.116.11..
- Save your settings.
Update Subsystem ID
Alarms are classified by their subsystem ID, identifying which part of the system the alarm relates to. These subsystem IDs are kept in a table maintained by the NAS probe. If you are working with NMS 7.6 or earlier, you must add the following subsystem IDs manually using the NAS Raw Configuration menu. However, if you have upgraded to CA UIM 8.0 then you do not have to manually add the following subsystem IDs:
Follow these steps:
- Open theRaw Configurationinterface of thenasprobe.
- Navigate to theSubsystemsfolder.
- Create a new key and specify values in theKey NameandValuefields.
- Repeat this process for all the required subsystem IDs for your probe.