Troubleshooting and Optimization Flashcards
A developer is instrumenting an application that will be hosted in a large On-Demand EC2 instance in AWS. All of the downstream calls invoked by the application must be traced properly, including the AWS SDK calls. A user-defined data should also be present to expedite the troubleshooting process.
Which of the following are valid considerations in AWS X-Ray that the developer should follow?
You can use the “metadata” field in the segment section to add custom data for your tracing. If you want to trace all the AWS SDK calls of your application, then you can add a subsegment and set the “namespace” field to “AWS”. Alternatively, you can set the “namespace” value to “remote” if you want to trace other downstream calls.
Hence, the valid considerations in this scenario are:
- Set the namespace subsegment field to aws for AWS SDK calls and remote for other downstream calls.
- Set the metadata object with any additional custom data that you want to store in the segment.
How would you send sement documents directly to X-Ray?
using the PutTraceSegments API
X-Ray compiles and processes segment documents to generate queryable trace summaries and full traces that you can access via what APIs?
GetTraceSummaries and BatchGetTraces, respectively.
Where would you add user-defined data in an X-Ray Segment?
The metadata field.
What are the options for the “namespace” field in the Subsegment?
“AWS” is for AWS SDK calls and “remote” is for other downstream calls.
What is the difference between X-Ray “annotations” and “metadata” fields?
Both can be used in Segment and Subsegments. annotations object is a key-value pairs that you want X-Ray to index for search while metadata object is used to store any additional data that you want to store in the segment.
What are X-Ray inferred segments?
using data from the subsegments, they can be generated and added to the full trace.
RDS Read Replica vs. ElastiCache Cluster?
RDS Read Replicas provide enhanced performance and durability for the database (DB) instances. This feature makes it easy to elastically scale out beyond the capacity constraints of a single DB instance for read-heavy database workloads. You can create one or more replicas of a given source DB Instance and serve high-volume application read.
You can reduce the load on your source DB instance by routing read queries from your applications to the read replica. Read replicas allow you to elastically scale out beyond the capacity constraints of a single DB instance for read-heavy database workloads.
ElatiCache will improve the read performance of the application, this solution entails a lot of code changes in the application as compared with just using RDS Read Replicas.
What is a CloudWatch namespace?
a container for CloudWatch metrics. Metrics in different namespaces are isolated from each other so that metrics from different applications are not mistakenly aggregated into the same statistics.
What is a CloudWatch dimension?
CloudWatch dimension is only a name/value pair that is part of the identity of a metric.
What would you set in Step Functions worker to define the heartbeat interval and the retry policy?
HeartbeatSeconds and Retry.MaxAttempts, repectively.
The HeartbeatSeconds attribute defines the maximum interval that the task will wait for a heartbeat signal. If an activity worker fails to send heartbeats within this interval, the state is failed. A retry policy on the state allows another activity worker to attempt to complete the
stale.
If you want to monitor the memory and swap usage of the instance and the number of idle and running processes as well. How would you do it?
Install Cloudwatch Logs agent to the EC2 instance. This will collect both system metrics and log files from Amazon EC2 instances and on-premises servers. The agent supports both Windows Server and Linux, and enables you to select the metrics to be collected, including sub-resource metrics such as per-CPU core. Aside from the usual metrics, it also tracks the memory, swap, and disk space utilization metrics of your server.
AWS Distro for OpenTelemetry vs. X-Ray?
It is recommended to instrument your application with the AWS Distro for OpenTelemetry if you need the following:
-The ability to send traces to multiple different tracing backends without having to re-instrument your code
-Support for a large number of library instrumentations for each language, maintained by the OpenTelemetry community
-Fully managed Lambda layers that package everything you need to collect telemetry data without requiring code changes when using Java, Python, or Node.js
It is recommended to choose an X-Ray SDK for instrumenting your application if you need the following:
-A tightly integrated single-vendor solution
-Integration with X-Ray centralized sampling rules, including the ability to configure sampling rules from the X-Ray console and automatically use them across multiple hosts, when using Node.js, Python, Ruby, or .NET
What is CloudWatch Namespace?
A namespace is a container for CloudWatch metrics. Metrics in different namespaces are isolated from each other, so that metrics from different applications are not mistakenly aggregated into the same statistics.
There is no default namespace. You must specify a namespace for each data point you publish to CloudWatch. You can specify a namespace name when you create a metric.
The AWS namespaces typically use the following naming convention: AWS/service. For example, Amazon EC2 uses the AWS/EC2 namespace.
AWS/ApiGateway , AWS/AppFlowetc.
What is CloudWatch Dimensions?
A dimension is a name/value pair that is part of the identity of a metric. Because dimensions are part of the unique identifier for a metric, whenever you add a unique name/value pair to one of your metrics, you are creating a new variation of that metric. For example, many Amazon EC2 metrics publish InstanceId as a dimension name, and the actual instance ID as the value for that dimension.
You can assign up to 30 dimensions to a metric.