Service Lens with X-Ray implementation in App Mesh cluster.

0
  1. I have an APP Mesh cluster on EKS and would like to add an additional tracking layer for my applications. I added the required flags to the APP MESH controller and after restarting the deployment, my applications started to run with an additional X-RAY container. Will the container inside the pod have a negative impact on the operation of the application? What is the issue with the resource consumption of this container inside the pod?
  2. I implement X-RAY inside the cluster with APP MESH where each pod also has a side-card ENVOY PROXY container, is there a need for me to add X-RAY SDK for my application? Are the metrics provided by ENVOY PROXY and X-RAY without the implementation of the X-RAY SDK sufficiently sufficient?
  3. What is the exact list of metrics that the X-RAY SDK provides vs the X-RAY itself in the pod it will provide without X-RAY SDK? Can You show me the differences?
  4. I have also some uncertainty whether X-RAY should also serve and has the ability to check each request thoroughly, or if I notice some problems in the APP MESH, the exact logs should be checked in Cloud Watch. Where is the line between X-Ray and CloudWatch logs?
1 Answer
0

Hi,

Please check the below answers,

Query1 --> I have an APP Mesh cluster on EKS and would like to add an additional tracking layer for my applications. I added the required flags to the APP MESH controller and after restarting the deployment, my applications started to run with an additional X-RAY container. Will the container inside the pod have a negative impact on the operation of the application? What is the issue with the resource consumption of this container inside the pod?

Running the X-ray as a side car container inside a pod along with main(application container) container doesn't have any impact to the operation of application. The resource consumption will not be much but depends on the application that you are using.

It's important that the sidecar containers don't consume more resources than the main container. Sidecars are containers configured to enhance or extend the functionalities of the main container, and their function is secondary to that of the main container. While keeping them compact can reduce the likelihood of resource overconsumption, they also need to be configured in such a way that their access to resources is limited. Allowing the sidecar to freely consume resources, especially the memory resource, will negatively affect the performance of your Kubernetes cluster. One problem that may arise from this is a lack of sufficient pods to handle workloads. When a node in your cluster runs out of memory, the system kernel automatically terminates the container consuming the most memory with an out of memory (OOM) error, which often puts the pod in a terminated state. Appropriate sidecar configuration will allow you to assign resource limits to your sidecar containers, ensuring that this problem is avoided.

Query2 --> I implement X-RAY inside the cluster with APP MESH where each pod also has a side-card ENVOY PROXY container, is there a need for me to add X-RAY SDK for my application? Are the metrics provided by ENVOY PROXY and X-RAY without the implementation of the X-RAY SDK sufficiently sufficient?

AWS X-Ray can be used with multiple other applications running on Amazon EC2, Amazon ECS, EC2 Container Service, Amazon Elastic Beanstalk, and AWS Lambda. It is much easier to start the application creation process with X-Ray. You just need to integrate the application with X-Ray’s SDK and install the X-Ray.

The X-Ray SDK gathers information from request and response headers, the code in your application,and metadata about the Amazon resources on which it runs. You choose the data to collect by modifying your application configuration or code to instrument incoming requests, downstream requests, and Amazon SDK clients.

SDKs can be used to instrument your application for X-Ray tracing. Daemon works as a bridge between X-Ray SDKs and X-Ray service.

The AWS X-Ray daemon is a software application that listens for traffic on UDP port 2000, gathers raw segment data, and relays it to the AWS X-Ray API. The daemon works in conjunction with the AWS X-Ray SDKs and must be running so that data sent by the SDKs can reach the X-Ray service.

Instead of sending trace data directly to X-Ray, the SDK sends JSON segment documents to a daemon process listening for UDP traffic. The X-Ray daemon (https://docs.aws.amazon.com/xray/latest/devguide/xray-daemon.html) buffers segments in a queue and uploads them to X-Ray in batches.

Daemon uses AWS SDK to communicate with X-Ray Endpoints. The X-Ray API provides access to all X-Ray functionality through the AWS SDK, AWS Command Line Interface, or directly over HTTPS.

You can use the AWS SDK to develop programs that use the X-Ray API. The X-Ray console and X-Ray daemon both use the AWS SDK to communicate with X-Ray. The AWS SDK for each language has a reference document for classes and methods that map to X-Ray API actions and types.

Which SDK to use is purely depends on the language you are using. Please refer below links for your reference.

https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy_servicelens_xray.html https://github.com/aws/aws-xray-sdk-python https://github.com/aws/aws-xray-sdk-go https://github.com/aws/aws-xray-sdk-java

Query3 --> What is the exact list of metrics that the X-RAY SDK provides vs the X-RAY itself in the pod it will provide without X-RAY SDK? Can You show me the differences?

X-Ray correlates CloudWatch logs and metrics with your application traces if you are using the AWS X-Ray SDK for Java, which means you can quickly analyze the related metrics and logs for requests. Please refer this - https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/application-tracing-xray.html

Configure and instrument each server or endpoint in your application with X-Ray. X-Ray is implemented in your application code by making calls to the X-Ray service. X-Ray also provides AWS SDKs for multiple languages, including instrumented clients that automatically send data to X-Ray.

X-Ray provides an X-Ray daemon that you can install and run on Amazon EC2 and Amazon ECS to relay data to X-Ray. X-Ray creates traces for your application that capture performance data from the servers and containers running the X-Ray daemon that serviced the request. X-Ray automatically instruments your calls to AWS services, such as Amazon DynamoDB, as subsegments through patching the AWS SDK. X-Ray can also automatically integrate with Lambda functions.

Query4 --> I have also some uncertainty whether X-RAY should also serve and has the ability to check each request thoroughly, or if I notice some problems in the APP MESH, the exact logs should be checked in Cloud Watch. Where is the line between X-Ray and CloudWatch logs?

X-Ray gives you a visual representation of your services—a service map—that illustrates each integration point, and gives you quick insight into successes and failures. Then, you can drill down into the details of each individual trace.

Logs let you dig into specific issues, but you can also use log data to create business-level metrics via CloudWatch Logs metric filters. You can interact with logs via CloudWatch Logs to drill into any specific log entry or filter them based on a pattern to create your own metrics.

In a simple way, X-Ray will be used to trace the application flow and it logs shows where the issue has occured. But cloudwatch logs is used to know exactly what is the issue.

AWS
SUPPORT ENGINEER
answered 2 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions