If sessionSampleRate is less than 1, events may or may not be emitted for a given session. Try setting sessionSampleRate: 1 in the web client configuration.
The web client requires AWS credentials to sign RUM payloads. When the RUM web client does not have AWS credentials, it will not attempt to send events to CloudWatch RUM. Your application must either (A) provide the web client with an anonymous Cognito identity using identityPoolId, (B) provide the web client with AWS credentials using the cwr('setAwsCredentials', credentials); command or (C) use a proxy and disable SigV4 signing by setting signing to false.
If the the web client initially sends data, but stops sending data after a period of time, the likely cause is that the session event limit has been reached. By default, the web client limits the number of recorded events to 200 per session.
The configuration field sessionEventLimit controls this limit. If you wish to remove this limit completely, set sessionEventLimit: 0.
const config: AwsRumConfig = {
// Record an unlimited number of events per session
sessionEventLimit: 0
};CloudWatch RUM's PutRumEvents API returns 403 when authentication or authorization has failed. Since the web client has made the request, we know that either (a) the Cognito and STS calls have succeeded, (b) the cwr_c localStorage key contains AWS credentials, or (3) the application has forwarded credentials to the web client using the cwr('setAwsCredentials', credentials); command.
Data must be sent to the same region as the CloudWatch RUM AppMonitor was created. For example, if the AppMonitor was created in us-east-1, but the web client is configured to send data to the endpoint 'https://dataplane.rum.us-west-2.amazonaws.com', authentication will fail. Verify that (1) the region argument is correct and (2) the endpoint configuration option, if set, is correct.
When anonymous authorization is used, the web client stores credentials in localStorage. If multiple AppMonitors are used within the same domain, authorization will fail when navigating between pages with different AppMonitors.
If a new AppMonitor is created and re-uses an existing Cognito Identity Pool and IAM Role, the IAM Role will not automatically have permissions to call PutRumEvents on the new AppMonitor.
Verify the IAM role has the following permission:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "rum:PutRumEvents",
"Resource": "arn:aws:rum:[region]:[account]:appmonitor/[AppMonitor name]"
}
]
}Data sent to CloudWatch RUM must be signed with SigV4. When RUM data is not signed, CloudWatch RUM will return the following exception in the x-amzn-ErrorType HTTP header.
MissingAuthenticationTokenException
Verify that signing is enabled.
The configuration option signing controls whether or not the web client signs RUM data. Signing is enabled by default, so if this configuration option is not present, then signing is enabled.
const config: AwsRumConfig = {
// Sign RUM data with SigV4 -- required unless using a proxy
signing: true
}
The CloudWatch RUM web client has a default authorization mechanism that uses a a token vended by an unauthenticated Cognito identity to retrieve temporary AWS credentials from STS.
If the STS AssumeRoleWithWebIdentity operation fails, the Cognito identity may not have permission to assume the IAM role. Verify the IAM role has the following trust relationship:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "cognito-identity.amazonaws.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"cognito-identity.amazonaws.com:aud": "[cognito identity pool id]"
},
"ForAnyValue:StringLike": {
"cognito-identity.amazonaws.com:amr": "unauthenticated"
}
}
}
]
}When the CloudWatch RUM web client is provided with both identityPoolId and guestRoleArn, the web client will use Cognito's basic (classic) authflow. If the Cognito GetCredentialsForIdentity operation fails, this may be because the basic (classic) authflow is not enabled in the Cognito identity pool. In this case, the response may look similar to the following:
<Error>
<Type>Sender</Type>
<Code>InvalidIdentityToken</Code>
<Message>The ID Token provided is not a valid JWT. (You may see this error if you sent an Access Token)</Message>
</Error>
This can be fixed by removing guestRoleArn from the web client configuration. After removing guestRoleArn, the web client will use Cognito's enhanced (simplified) auth flow.
Alternatively, to continue using the basic auth flow, use the Amazon Cognito console or CLI (i.e, the aws cognito-identity describe-identity-pool command) to verify that the identity pool configuration does not contain AllowClassicFlow: false. If it does, then update the configuration so that it contains AllowClassicFlow: true.
See also:
AllowClassicFlowin the update-identity-pool CLI reference.- Identity pool (federated identities) authentication flow.
If your web application uses a content security policy, it likely needs to be amended to support the RUM web client. By default, a content security policy blocks unsafe inline scripts such as the code snippet used to install the RUM web client. You can use a hash or an nonce to allow the snippet. See MDN Web Docs: CSP: script-src for more information.
The hash method is the recommended method for adding the RUM web client installation snippet to the script-src directive. A complete CSP for the rum web client will contain the following directives and values:
| Directive | Value |
|---|---|
| script-src | 'sha256-[snippet hash]'https://client.rum.us-east-1.amazonaws.com |
| connect-src | https://dataplane.rum.[region].amazonaws.comhttps://cognito-identity.[region].amazonaws.comhttps://sts.[region].amazonaws.com |
A hash of the snippet can be generated from the command line using openssl:
SNIPPET='(function(n,i,v,r,s,c,u,x,z){x=window.AwsRumClient={q:[],n:n,i:i,v:v,r:r,c:c,u:u};window[n]=function(c,p){x.q.push({c:c,p:p});};z=document.createElement('script');z.async=true;z.src=s;document.head.insertBefore(z,document.getElementsByTagName('script')[0]);})('cwr','00000000-0000-0000-0000-000000000000','1.0.0','us-west-2','https://client.rum.us-east-1.amazonaws.com/1.x/cwr.js',{sessionSampleRate:1,identityPoolId:'us-west-2:00000000-0000-0000-0000-000000000000',endpoint:'https://dataplane.rum.us-west-2.amazonaws.com',telemetries:['errors','http','performance'],allowCookies:true});'
echo $SNIPPET | openssl sha256 -binary | openssl base64In this case, the output of this command is the following, however the output for your snippet will differ:
dhFqvDHwFpO34BJSlFlEdnhKI/jmMD2Yl50PvxjyLN0=
Place the hash in the 'sha256-[snippet hash]' directive value above. In this case, the directive will be script-src sha256-dhFqvDHwFpO34BJSlFlEdnhKI/jmMD2Yl50PvxjyLN0=.
To connect client-side and server-side traces, you must set the addXRayTraceIdHeader to true in the http telemetry configuration. The web client will then add the X-Amzn-Trace-Id header in each HTTP request. The example below shows what this configuration looks like, with all other configurations removed for readability.
⚠️ EnablingaddXRayTraceIdHeadermay cause HTTP requests to fail.Enabling
addXRayTraceIdHeaderadds a header to HTTP requests. Adding headers can modify CORS behavior, including causing the request to fail. Adding headers may also alter the request signature, causing the request to fail. Test your application before enabling this option in a production environment.
<script>
(function(n,i,v,r,s,c,u,x,z){...})(
'cwr',
'00000000-0000-0000-0000-000000000000',
'1.0.0',
'us-west-2',
'https://client.rum.us-east-1.amazonaws.com/1.x/cwr.js',
{
enableXRay: true,
telemetries: [
[ 'http', { addXRayTraceIdHeader: true } ]
]
}
);
</script>